The Perimeter: A New Security Program for Sovryn
TL;DR: We propose a program to significantly improve protocol security and move toward sustainable self-funding. At the center of the program is the Sovryn Perimeter: a withdrawal security layer that creates a monitored delay between a withdrawal request and its completion. A security fee on selected withdrawals (SecFee) would fund the continuous monitoring that makes the Perimeter effective. This program also introduces revenue enhancements, including new fee structures, capturing currently missed revenue from watcher fees and parameter changes, and automating the transfer of vested SOV to the Exchequer. This is one program for a comprehensive update of Sovryn, to be implemented through a series of SIPs.
There is a structural problem in DeFi security that gets discussed after every major exploit, then mostly forgotten until the next one. The defender must protect against every possibe. The attacker needs only one that works. Automated tooling and AI-assisted probing have made it cheaper and faster to search for every possible weakness and placed this capability in the hands of practically anyone., And the gap is widening. AI-assisted cyber attack capabilities are improving exponentially.
Near-instant, irreversible settlement is one of crypto’s most valuable features. Transactions confirm in seconds, funds move without intermediaries, and no intermediary can revert transactions. That same speed serves an attacker just as well. A successful exploit can be followed by a withdrawal and a complete exit from the protocol before any monitoring system has generated an alert, let alone acted on one. The attack completes before the defender can respond.
We cannot plug every gap in every contract. There is too much code and too much complexity. No contract can be guaranteed 100% secure, even less so if it manages the complex financial transactions. h . What we can do is a bottleneck where we can build something extremely simple that defends the whole system. That realization is where this program started.
This post explains the full program, what it is designed to do, what it asks of users, and what you should scrutinize before you vote.
The Security Problem Is Structural, and Prevention Alone Cannot Solve It
Security spending in DeFi is mostly pre-deployment: audits, formal verification, bug bounties. These are valuable. They are also backward-looking. An audit certifies the code at a point in time. It does not follow the funds after deployment.
Post-deployment monitoring is the other main tool. Teams watch on-chain activity and try to intervene when something looks wrong. The problem is that intervention usually means alerting a person or group, who then need to create and initiate transactions, which takes time. Attackers using flash loans or multi-step exploits can complete an attack and move funds faster than any human-mediated response can travel.
Three broad categories of attack are relevant here: code defects or zero-day vulnerabilities, social engineering or compromise of privileged signers, and economic attacks involving markets, oracles, or flash loans. Sophisticated attacks combine all three. There is no such thing as perfect security. The goal is to change who has the advantage.
Right now the advantage belongs to the attacker. They need to be right once. We need to be right every time. This program is designed to flip that.
KelpDAO, Arbitrum and Why It Matters Here
In April 2026, an exploit targeting rsETH and KelpDAO resulted in a $292 million dollars stolen on Arbitrum. As the attack was unfolding, Arbitrum’s Security Council exercised its emergency powers and moved the affected assets. The intervention worked in the sense that some funds were frozen before the attacker could fully exit.
What happened next was the important lesson:
Courts in New York allowed individuals to pursue legal action and as a result the funds were frozen. The reason that was possible is that the Arbitrum Security Council had made a discretionary decision about where the funds went. A committee of identifiable people had chosen the destination. That choice created a control surface - a moment of human decision-making over asset flow - that the court treated as meaningful enough to subject to legal intervention. The path from exploit to resolution had passed through a committee, and that made it effectivley, legally functionally and in practice, enough like custody to be treated as such.The court, in effect, ruled that the system was no longer decentralized at the point that mattered. [The court was right, Arbitrium could freeze the funds and did. DINO theatre] Aave LLC, which had nothing to do with causing the exploit, subsequently moved to vacate the restraining notice as part of the downstream legal fallout, leaving $71 million frozen until the legal dust settles.
The lesson is not that emergency intervention is wrong. It is that any system which requires humans to choose where disputed funds go creates the same exposure. Once a committee makes that call, there are identifiable decision-makers to restrain. The funds stop following protocol rules and start following whoever controls the committee.
This is the problem the Sovryn Perimeter is designed to avoid, something that as far as we can tell, is done by no other system in the world.
The Sovryn Perimeter: Defense Built Into the Exit
The core idea is straightforward - and now seems obvious to us in hindsight. Anytime a user wants to withdraw funds from Sovryn, the funds do not flow directly to the user. They pass through the Perimeter. The Perimeter pauses the transaction and gives the system time to evaluate whether the withdrawal is part of an exploit. If nothing suspicious is detected during that window, the funds continue to the user after the defined delay. If the withdrawal is identified as malicious, it does not complete. The assets return to the contract from which they came.
That second outcome is the critical design choice. The destination of a rejected exit is specified in advance by the protocol rule: return to the originating contract. That’s it. No person redirects the funds. To our mind, that’s the stop-gap measure that keeps Sovryn truly DeFi.
This also flips the attack/defence asymmetry. The attacker no longer needs only to be right once. Even a successful exploit does not guarantee a successful exit. The defenders only need to detect the exploit within the monitoring window. If they do, the funds bounce back. The economic value of attempting an attack on Sovryn approaches zero once the exit is no longer guaranteed.
The Boundary: What Is Delayed, and What Stays Immediate
The Perimeter applies to selected covered withdrawals — exits from protected parts of the system. Swaps remain immediate and are not subject to withdrawal delays. The Perimeter is concerned with egress: the moments when value moves from the protected boundary to an external address.
The scope at launch - which specific products, assets, and withdrawal types are covered - will be defined in the SIPs. Currently we propose that swaps will be excluded from the Perimeter, since those require low latency. Loans, AMM pools, and the Zero pool should be included, since these are the honey pots and delaying a withdrawal is probably a worthwhile tradeoff for the added security. The delay duration will also be specified there.
For a normal covered withdrawal, the process is: request the exit, enter a pending state, monitoring runs during the defined interval, and if nothing is flagged, the withdrawal completes. It will not be instantaneous. That is the tradeoff the Perimeter asks users to accept in exchange for the security window it creates.
Why This Stays DeFi
The question is worth asking plainly. Does a protocol that can delay or block a withdrawal still function as DeFi?
The answer depends on how rejections are handled. If a committee decides whether a withdrawal is blocked and where the funds go afterward, that is discretionary custody. It creates the same control surface that made legal intervention possible in the Arbitrum case.
The Perimeter removes that discretion at the point that matters. This a rules based, not decision-based system. A rejected exit returns to its originating protocol state. No committee selects the destination. No person redirects the funds. The protocol executes a predetermined instruction.
The strongest accurate statement of the design intent: the protocol does not award disputed funds to a third party. A rejected exit returns them to the state from which the exit began. There is no address to freeze, no committee to restrain, no discretionary decision to challenge.
**Long Term Resilience
**
The proposed Sovryn Perimeter addresses the headline security concern - defending against exploits. Just as important is that we address the long term reliability of the protocol and Bitocracy. For this we need to achieve three things:
-
Increase net profitability
-
Redirect profits to SOV stakers and create a buy and burn mechanism for SOV to fund Bitocracy and creates a clear link between SOV value and protocol value.
-
Clean up some of the technical debt that slows down development and adds bureaucracy.
On the revenue side, with SecFee the perimeter can be self-funding. Additionally, we have identified several instances where the protocol is leaving money on the table, such as watcher fees and zero parameter changes. Additionally, we will fix a long-standing issue where SOV that has vested and was earmarked for the Exchequer has not automatically transferred to the exchequer.
In addition to the above - and not requiring SIPs, are changes and improvements to the UI that are being built, tested and deployed. **
SecFee: Continuous Security Funding**
The Perimeter is not a one-time deployment. The security value depends on detection systems that run continuously, update as attack methods change, and improve with time.
SecFee is the fee mechanism that funds that ongoing work. It applies to selected protocol payouts. The precise list, the rate, and the scope will be defined in the SIPs.
There is a second rationale alongside the security argument. Sovryn has provided substantial protocol infrastructure to users for years. Sustaining that over time requires a revenue base tied to protocol activity. SecFee is part of what will provide that sustainability.
SIP Forum Posts
We intend to publish the formal SIP forum posts next week. I hope to have a productive discussion until about the concept, and about the technicalities of it after the SIP forum posts are released.
Thank you for keeping your funds and trust in the system, we aim that you’ll be able to do so without losing any sleep for years into the future.
Yago