Safenet Beta Q2: Progress, learnings and what is next
John Ennis
One of the recurring questions in wallet security is simple to state:
"when you are about to sign a transaction, how do you know that the transaction does what you think it does?"
For users across many wallets, the answer has historically been "you don't, really" - you trust your wallet's UI, you trust the dapp, and you hope that the bytes underneath match the picture on your screen. Smart contract accounts like Safe give us more room to work with, because the account itself is programmable and can enforce rules at execution time. But programmability alone does not solve the problem. Someone still has to decide what to check, and someone still has to actually do the checking in a way that is not itself a centralized point of trust.
Safenet is building to solve the latter. The idea is to replace the usual "one company runs a transaction scanner" model with a network of checkers and validators that attest to transaction safety onchain, so that the checking layer inherits some of the same resilience and verifiability properties that we expect from the base layer itself. We are at the midway checkpoint of the Safenet Beta - so we now have real numbers, real failure flags, and real economic data.
To be clear about the spirit of this post. It's not a victory lap (just yet). A decentralized transaction-checking network is a challenging design problem, and a Beta is precisely the phase where we find out which of our assumptions hold true and which, in fact were wrong. This is a key checkpoint to share progress, learnings and what's next.
Safenet Beta network has been performing reliably
Stats as of 29th June 2026 via Dune (1) and (2)
TLDR
The Beta proved that we can indeed process the needed load for mainnet, but the current capacity is 100,000 tx's per week and we need to improve this for the production release on many chains.
Reliability sits at ~0.1% in terms of downtime throughout the Beta.
We proved SAFE holders can be activated to provide economic security for the network, with over 534 stakers taking a total of 54,778,072 SAFE.
Scalability
Testing the scalability of the protocol was our main goal for this Beta. Namely how much transaction load can Gnosis Chain process for our consensus layer, and where our limits exist. Over the Beta, the network produced ~400,000 total attestations. Each attestation represents all validator's co-ordinating a FROST signature about a transaction it evaluated, and in aggregate this is the dataset that tells us whether the "game" of decentralised checking actually converges on correct answers in practice rather than just in theory.
Our max limit sits at 100,000 tx's per week. Promising early numbers, but for the production release on chains such as Base, Polygon, BNB etc, we'd need to increase this max load.
We have a flagged/unsafe count of 1,398 of 492, 628 in total attestations, that's roughly 0.28% of evaluated activity getting flagged. Which is low enough to suggest the checks are not firing indiscriminately, and high enough to suggest they are firing on something dangerous (delegatecall, unsupported mastercopies etc).
Also worth noting the low gas cost (30 XDAI) to operate a transaction-checking network producing nearly ~400,000 attestations. Gnosis Chain's network cost is low by design, so gas was not a significant constraint for the Beta.
Reliability
Across the lifetime of the Beta, validators maintained an average participation rate of 99.9%. Participation is a per-validator metric, and a single validator being briefly offline does not take the network down, in exactly the same way that Ethereum does not halt because some fraction of validators miss a slot.
When you translate 99.9% participation across six redundant validators into actual network downtime, the actual downtime figure is closer to ~0.1%. The honest headline is therefore validator participation was high, and network uptime was effectively complete. This downtime tail matters in Safenet as a transaction that misses its check window is not merely "delayed," it is a transaction that either gets blocked or gets waved through without the protection the user was promised. When approaching the next release, we aim for the standard expectation and maintenance of 99.9% uptime / 0.1% downtime.
Economics
The economic side of the Beta was really a test of a single hypothesis:
"can SAFE and SAFE holders be activated to provide economic security for something they care about?"
The honest summary is the hypothesis survived. SAFE holders (534 of them) can be activated for economic security. Especially with the Beta producing an average variable reward rate of ~17% with DAO subsidies and a total stake of 54,778,072 SAFE.
The Beta did not yet prove that this is true at the scale / cost structure we'd ultimately want, but "the mechanism works and stakers are activated" is the result you need before you are allowed to ask the harder questions, and we now get to ask them.
What the Beta taught us
If we summarise the Beta's lessons into a few sentences:
Scalability is the real constraint, not liveness: Going into the Beta, our main goal was to find out whether the architecture would scale - specifically, whether Gnosis Chain could carry the load. It can, up to a point, and finding that point was arguably the most valuable thing the Beta produced. The ceiling we measured is 100,000 transactions per week, and beyond it the binding factor is congestion and blockspace on Gnosis Chain, not anything about our validators or our checks. We want to be careful not to dress this up: validator liveness was a solved problem in the Beta. The honest conclusion is that the next hard problem is throughput scaling, and it is a chain-level problem we will have to tackle.
Static checks are a start, but we need dynamic checks: The Beta ran on a fixed set of checks. That was the right call for a Beta, but it opened up more conversations with teams that allow us to look at dynamic checks in the future i.e. the beta being live had an effect on showing the product and hence starting meaningful conversations, getting inbound etc.
Our subsidy hides the economics: During the Beta, SafeDAO subsidized everything, which is normal and correct for a Beta. It's a testing ground to discover whether a network is technically possible, and to bootstrap it economically. Now, one of the explicit goals for the next phase is to implement fees and further implement technical token utility of the SAFE Token within the Safenet protocol.
Q2 What we did, and what's next
Q2 was mostly a quarter of building out what Safenet's next version should defend against.
The research: from "detect malicious transactions" to "target integrity"
The instinctive framing for a transaction checker is "detect malicious transactions." We spent a good chunk of Q2 convincing ourselves that this framing is wrong - or more precisely, that it is too subjective to anchor a network with rewards and slashing. If checkers are economically penalized for getting answers wrong, then "was this transaction malicious?" is a dangerous question to put to a vote, because maliciousness is a judgment about intent and intent is not onchain.
So we surveyed the space of ways you can actually attack a Safe - configuration manipulation, recipient manipulation, address poisoning, ENS spoofing, unintended approvals, authorization-scope abuse, economic-intent manipulation etc, and scored them roughly on reach, impact, confidence, and effort (check out the RICE framework if you want to learn more).
The conclusion that emerged is that the right scope is not "malicious transactions" but target integrity: preventing transactions that move value or grant control rights to addresses outside the set the user actually intended. This reframing is the whole game, because it converts a subjective question ("is this bad?") into a more objective one ("does this transaction send value or authorization to a target that is not in their expected set?").
The Q3 plan: Bring the protection of Safenet to all multisig users and generate fees for network participants
The shape of Q3 is as follows:
Build dynamic target manipulation checks for various types of attacks e.g. solving address poisoning
Enable onchain enforcement of Safenet checks via an audited guard
Integrate Safenet into Safe{Wallet}, available to all multisig users
Implement a fee model that distributes to participants as opposed to purely subsidies.
Closing thoughts
Deciding what to check next was one of the harder problems to solve this quarter. A decentralized network that checks the wrong things, or checks the right things subjectively, is worse than no network at all, because it launders false confidence through a credible-looking process.
What the Beta gave us, more than any single statistic, was the discipline to narrow the scope to something a network can actually be held accountable for. Target integrity is exactly that scope that actually matters to users. "Did this transaction send value or control to somewhere you didn't intend" is a question with a real answer, and building a resilient, decentralized, economically-secured network that answers it correctly is a very useful thing to do.
As always, this is our attempt to share with transparency the progress and all of the numbers are subject to revision as we close out the Safenet Beta, and I'd encourage people to give feedback on our reasoning, or apply to become an early Safenet user, checker or validator! Thanks for reading.
Website: safenet.xyz
News Telegram: updates.safenet.xyz
Reach out to collaborate: https://contact.safefoundation.org/
Share this
