Main Takeaways
- Sui approaches security at the programming and protocol layers, helping mitigate some classes of errors before an application ships.
- An audit gives the security picture of an application or protocol in its current state, but as it evolves, its security analysis also needs continued rechecking.
- Sui believes in sharing security tooling and infrastructure with its builders as it strengthens the ecosystem for all.
Onchain security is largely organized around the product launch moment. Build the product, commission a review, publish the audit, and deploy. That process assesses one version at one moment, but it doesn’t account for what changes after.
Products evolve. Teams add features, change permissions, and connect to new code. If an application succeeds, more value comes under its control, more products may depend on it, and the consequences of a security incident increases.
Security must adapt as protocols evolve and risk profiles change . Security must continue after deployment, assess every change to code and underlying mechanisms, and concentrate attention at the most concentrated points of risk. That is what it means for security to follow value.
Incidents across DeFi, including on Sui, have made evident the need for this continuous security approach. Applications with audited contracts have been affected by issues in shared code they depended on, and by weaknesses in administrative access rather than in contract logic. Both patterns point to the same lesson: application security has to account for dependencies, administrative authority, and exposure that changes after launch and every change to the system must be measured and evaluated
To better counter the risks following Summer 2025 DeFi incidents, the Sui Foundation created a $10 million fund for ecosystem security, subsidizing builder audits, formal verification, increasing bug bounties, and strengthening shared monitoring defense tools. That was a start. The next step is to turn those investments into infrastructure and tools builders can use directly, before and after deployment.
DeFi makes security a platform problem
DeFi apps rely on one another. A lending market may depend on a price feed, a transaction router, several asset vaults, and shared libraries maintained by other teams. A DeFi protocol’s security depends not only on its own code, but also on everything it trusts. Risk extends beyond code vulnerabilities. Permissions may be broader than teams realize, governance might be compromised from economic structures, and data feeds can become stale or incorrect without any system being hacked.
Composability is what makes DeFi worth building. But it also means the surface a team has to understand is larger than the code it wrote, and it grows every time someone else builds on it. A team can see what its application imports, but not which applications have come to depend on its code, how much value now sits behind them, and when a dependent has become important enough that a bug in a minor function turns into an ecosystem problem.
Sui security tools can trace dependencies, observe where value is accumulating, and identify code that many applications rely on. That makes it possible to direct attention according to the consequences of a failure rather than treating every application alike.
This gives builders better information without turning the Foundation into an approval authority. Platform tools can surface risks that individual teams cannot see alone. They do not decide what is allowed to launch.
Agents shorten the response window
When agents hold assets and sign transactions without requiring human approval, the underlying security problems do not change. The time available to detect and contain them shrinks. An agent can act on stale information or repeat the same mistake hundreds of times before anyone notices. It can read a published audit report, but it cannot assume that the report describes the code currently running or that nothing has changed since the review.
Autonomous systems therefore need security evidence that is current, structured, and connected to the version of the code it covers. But better evidence is not enough. An agent’s judgment is not a security control. The boundaries that matter must be enforced by the infrastructure, even when an agent misunderstands the risk or acts on incomplete information.
Four principles guide this work, both for onchain finance today and for more autonomous transactions in the future.
Principle 1: Rule out problems before production
Security starts with the programming model. Move gives digital assets built-in rules for how they can be created, owned, transferred, or destroyed. On Sui, assets also have explicit ownership. These constraints prevent some mistakes by construction instead of requiring every application to recreate the same protections correctly.
No programming language makes an application safe. A good programming model reduces the number of ways developers can get important properties wrong. The same logic applies below the application layer: Sui's post-quantum signature work addresses a class of risk once, at the protocol level, rather than leaving every application to solve it alone.
Principle 2: Keep review evidence with the code
An audit describes the code an auditor inspected. If the code changes, the report does not change with it. Evidence of a review should therefore remain connected to the exact code and version it covers.
A builder relying on someone else’s code needs to know what was reviewed and whether that code has changed since. An institution needs the same information before moving assets into an application. An agent needs it before executing a transaction. Each needs three basic facts: what was reviewed, what has changed since the review, and whether new issues have been found.
This does not require teams to publish every finding. Teams should be able to show that a review took place and identify what it covered without disclosing vulnerabilities that have not yet been fixed. The goal is to provide evidence others can use, not a guarantee against loss.
Principle 3: Keep watching after deployment
Once deployed, an application begins interacting with users, assets, and other applications. Teams update the product, add features, change permissions, and connect to new code. Each change can invalidate an assumption the original review relied on.
The goal of ongoing analysis is not to replace audits. It is to identify when the application and its operating environment no longer match what the audit covered.
That requires tools that monitor deployed code and transaction activity, connect findings to the code they affect, and show builders what has changed since the last review. Security evidence should remain current as the application changes.
Principle 4: Put attention where the consequences are greatest
A game’s leaderboard and a lending market holding much of an ecosystem’s collateral have different risk profiles. Giving them equal scrutiny wastes effort on one and leaves the other underprotected.
Value is the clearest signal of potential consequences, but it is not the only one. Code may also matter because many applications depend on it, because it controls powerful administrative functions, or because its failure could spread across the ecosystem.
Teams can assess the applications they operate. They may not know every product that relies on their code or how important one of their dependencies has become elsewhere. Ecosystem-level analysis can reveal those relationships and focus review, monitoring, and response where failure would cost the most.
Security is part of the platform
Prevention, review, and monitoring reduce risk, but they do not eliminate it. None of these tools is insurance, a warranty, or a promise that loss cannot happen. Platform infrastructure cannot replace careful design, testing, and review.
Builders remain responsible for their applications, including their threat models, administrative controls, testing, and fixes. But they should not have to assemble basic verification, monitoring, and response infrastructure from scratch using separate auditors, service providers, reports, and informal relationships.
Individual teams also cannot see the whole ecosystem. Someone needs to understand the dependencies and connections between applications, identify where exposure is growing, and help coordinate a response when shared infrastructure fails. That is work the Foundation is building toward.
Prevention, verification, ongoing analysis, and response should operate as parts of one security system. Security should begin before an application launches, continue as it changes, and follow where value is most exposed.
An audit still matters. It can’t carry the whole load.
We are building that infrastructure now. It will help teams verify that published source code matches what is running onchain, and connect audits and other security signals to the versions they cover. It will let applications be analyzed without exposing proprietary methods or unresolved findings, monitor changes in code and behavior, and identify ecosystem risks no individual team can see alone. Together, these tools will give builders, auditors, institutions, and agents more current, verifiable evidence to assess risk and respond faster.
As each is released, we will explain what it does, what it covers, and how builders can use it. To see where builders start today, visit the Sui Security Hub.
