Stellar DeFi Security Standards and Best Practices

DeFi on Stellar is no longer experimental: protocols are live, they lock hundreds of millions of dollars worth of value, and they operate at a scale that impacts thousands of users. That's a milestone worth recognizing. It's also a moment that requires more of many teams in the ecosystem.

This post defines a set of practices SDF believes should be standard for any DeFi protocol on Stellar that holds, lends, swaps, or otherwise touches user funds. Some teams already do most of this. Some are working toward it. We're putting it in writing because builders have told us they want a clearer picture of what good looks like, and because the ecosystem is healthier when expectations are explicit rather than assumed.

None of the suggestions are novel. Most of them reflect what mature DeFi teams already do across other ecosystems, adapted to the realities of building on Stellar. We're publishing it so the conversation can be more concrete: this is what we mean when we talk about responsible DeFi on Stellar.

Three things have shifted in the last year.

First, Stellar's DeFi ecosystem is in a different place than it was twelve months ago. More users are active onchain, more value is sitting in lending pools and AMMs, and more protocols are composed with each other. Practices that were reasonable for an early-stage experimental pool don't work for a production protocol holding tens of millions of dollars of user funds.

Second, the attacker side has gotten faster, cheaper, and more capable. Vulnerability discovery, exploit-code generation, social-engineering at scale, and reconnaissance against deployed contracts have all moved from "skilled specialist with weeks of time" to "competent operator with a good toolchain." AI-assisted analysis is now being run against published audit reports to find what auditors flagged but teams didn't fully remediate, and against open-source contract code to surface patterns that have been exploited elsewhere. The result is that oracle manipulations, novel flash-loan patterns, governance takeovers, and admin-key compromises are no longer rare events at the frontier of DeFi: they're a baseline operational risk for any protocol of meaningful size. A team that ships without thinking through these possibilities is not innovating; it's externalizing risk onto its users.

Third, Stellar's DeFi ecosystem now has enough interconnection that one protocol's failure can ripple through several others. A compromised oracle, a drained liquidity pool, or a cascade of forced liquidations don't stay contained. Standards are partly a tool for protecting users of an individual protocol, but they're also a tool for protecting the rest of the ecosystem from any single protocol's mistake.

We don't think the answer is heavy-handed gatekeeping. Stellar is permissionless and should stay that way. But permissionless access does not mean protocols that hold user funds should operate without mature security and risk practices. These are the standards SDF expects serious DeFi teams to work toward, and what follows is what we'd like to see become normal.

A third-party security audit by a recognized firm is table stakes for any protocol that handles user funds. The baseline:

A completed audit before any material user funds are accepted, conducted by a firm with a demonstrated track record in the relevant primitive (lending, AMM, derivatives, bridging, etc.). The audit report should be published, not just summarized in a tweet, and it should include a full summary of findings, the remediated status of all discovered vulnerabilities, and the specific version of the code that was reviewed.

Audit-to-deployment parity. The code running in production should be the code that was reviewed. When teams deploy meaningful changes after the last audit, those changes should be disclosed, and a re-audit (or at minimum a scoped follow-up review) should be initiated before changes are pushed to mainnet.

Audit cadence tied to change, not the calendar. A protocol that ships frequently needs a security partner that reviews frequently. A protocol that's largely static after launch still benefits from periodic re-review as the threat landscape evolves.

When the absence of an audit is unavoidable—for early experiments, hackathon projects, or genuinely pre-product code—that status should be communicated unmistakably to users, and the protocol should not be marketed as production-ready.

An audit is a point-in-time snapshot. It tells you the code was sound as of a particular version on a particular date, reviewed by a particular set of eyes. It says nothing about the vulnerability discovered six months later, or the researcher who finds a bug next week and has to decide what to do with it. Live protocols need a way to receive that information safely, and a live protocol without one is trusting that whoever finds the next bug chooses to report it rather than exploit it or sell it.

The baseline:

A published vulnerability disclosure policy that tells a researcher exactly where to send a report, what's in scope, what to expect in response, and a commitment not to pursue good-faith reporters. This should be trivially discoverable—linked from the docs and the site, not buried in a Discord channel.

A standing bug bounty program, scaled so the reward for a critical finding is meaningful relative to what an attacker could extract by exploiting it instead. A bounty that pays a fraction of the exploitable value is not really competing for the researcher's decision.

A triage and remediation process with committed timelines, so reports don't sit unread. A researcher who gets no acknowledgment for two weeks is a researcher who stops reporting—or reports somewhere you'd rather they didn't.

Audits are necessary but not sufficient. A protocol holding tens of millions of dollars in user funds must operate with a security and operational risk posture commensurate with the sheer scale of the assets it manages. What this looks like in practice depends on a protocol's size, stage, and structure, but the components are broadly the same:

Written risk procedures that describe how the team identifies, evaluates, and responds to security and operational risks. These should include a risk appetite statement outlining what the team is willing to accept, what it isn't, and how those lines are enforced.

Written vendor and partner risk management policy, including a clear-eyed view of every external dependency. Which oracles a protocol relies on, which bridges, which off-chain services, what happens if any one of them is wrong or compromised, and what the team would do in the first hour after a failure.

Security procedures for the team itself, including key custody arrangements, multisig thresholds, hardware-wallet practices, code-review requirements, and deployment controls.

For protocols at scale, we encourage independent validation of these controls—SOC 1 / SOC 2 reports or a functionally equivalent third-party attestation. The point isn't the certificate; it's the discipline of being audited by someone who isn't on the team.

Not every DeFi failure is a code exploit. Some of the most damaging losses come from economic design that was sound under normal conditions and broke under stress: collateral that couldn't be liquidated fast enough in a sharp drawdown, incentives that unwound in a bank-run dynamic, a parameter that was safe in isolation and dangerous in combination with another. Code audits rarely catch these, because the code did exactly what it was written to do. The design was the vulnerability.

Protocols whose safety depends on economic parameters—lending markets, AMMs, stablecoins, derivatives—should treat that design with the same rigor as the code:

Stress testing and scenario modeling against sharp price moves, liquidity crunches, and correlated drawdowns, not just steady-state conditions. The relevant question is not whether the system works on an average day but whether it survives its worst plausible one.

Concentration limits on collateral, liquidity, and counterparty exposure, so a single asset, pool, or actor can't put the whole protocol at risk.

Liquidation simulations that confirm positions can actually be unwound at scale, under stress, with the liquidity that would realistically be available—not the liquidity present on a calm day.

Oracle manipulation modeling that asks what an adversary could do by moving a price feed, and how much it would cost them relative to what they'd gain.

A parameter-change review process. Changes to risk parameters—collateral factors, interest-rate curves, liquidation thresholds—should go through documented review and, for non-urgent changes, the same timelock and disclosure discipline as any other privileged action. A parameter tweak can drain a protocol as effectively as a code bug.

The DeFi protocols that recover from incidents tend to be the ones that planned for them financially before they happened. That planning has two parts.

First, a capital buffer. As a directional benchmark, we encourage protocols to set aside approximately 5% of total user-facing liabilities as a first-loss resource. For a protocol with $100M TVL, that's something on the order of $5M in liquid assets earmarked to absorb shocks before they reach users. The exact figure is less important than the principle: the team should know, in advance, how much it can absorb without users taking the hit, and where that capital lives. For decentralized protocols, this might take the form of a treasury allocation, a governance-controlled safety module, or an equivalent mechanism appropriate to the protocol's structure.

Second, insurance where it makes sense. It is not a substitute for security, but it is a meaningful tool, and we'd like to see more Stellar protocols evaluating it seriously.

Together, a capital buffer and insurance are how a protocol says, in advance, that the cost of a bad day will not fall entirely on its users.

Some of the largest losses in DeFi history have resulted from compromised dependencies: manipulated oracles, hacked bridges, leaked keys. Every team needs to pay attention to infrastructure hygiene, which looks like this:

For protocols that consume price oracles: price deviation guards, time-weighted averages, multi-source consensus, and circuit breakers that pause sensitive functions when something looks wrong. Trust no single price feed for liquidation decisions if you can avoid it.

For protocols that operate bridges or cross-chain logic: documented assumptions about every chain you touch, and a written response plan for the day a counterparty chain has a problem.

For admin keys and protocol governance: multisig with meaningful thresholds and geographically distributed signers; hardware key storage; clearly documented and rehearsed procedures for emergency action. The convenience of a single key is not worth what it costs when it's compromised.

For circuit breakers and emergency pauses: build them, test them, and know who can pull the lever. A protocol that cannot pause a compromised contract is a protocol that watches its users lose funds in real time.

Most Stellar DeFi protocols retain some privileged power: an admin key that can pause the system, a governance process that can change parameters, an upgrade path that can replace the contract logic users are trusting. These capabilities are often necessary. They are also, in the wrong hands, the fastest way to drain a protocol—a governance takeover or a compromised admin key doesn't need to find a bug, because it already holds the keys. The bar here is that privileged power is constrained, documented, and observable:

Public documentation of every privileged role —what it can do, who holds it, and how it's constrained. Users and integrators should be able to see the full set of powers that exist over a protocol without reading the source or trusting a verbal assurance.

Multisig with meaningful thresholds and geographically distributed signers, hardware key storage, and a defined, rehearsed process for signer rotation when someone joins, leaves, or is compromised. The convenience of a single key is not worth what it costs when it's compromised.

Timelocks on non-urgent privileged changes, so users can see a change coming and exit if they disagree with it. A protocol that can alter the rules with no delay is asking users to trust that it never will.

Clearly scoped emergency powers. Emergency actions—pausing, freezing, halting—should be narrowly defined and limited to what's needed to stop an incident, not a backdoor to arbitrary control. Document what emergency powers exist, who can invoke them, and what they can and cannot do.

Quorum requirements and governance-attack mitigations for onchain governance: sensible proposal thresholds, voting delays and periods, and defenses against flash-loan-funded vote capture and other governance manipulation. Governance that can be borrowed for an afternoon is not a safeguard.

The worst time to figure out incident response is during an incident. The teams that handle exploits well—the ones that recover trust and that sometimes recover funds—are the ones that had a playbook before the call came in. At minimum, that means:

Real-time onchain monitoring and alerting. You can't respond to what you don't detect. Protocols should actively watch their own contracts for abnormal activity—anomalous withdrawals, unexpected price or balance movements, unusual call patterns, oracle deviations, sudden drops in reserves—with automated alerting that reaches an on-call human fast. Whether built in-house or through a monitoring provider, the goal is minutes to detection, not hours, and the ability to trigger a pause on the strength of an alert. Many of the worst outcomes in DeFi weren't caused by the exploit alone but by the hours that passed before anyone noticed.

A designated incident lead and a documented escalation path before anything has gone wrong. Every team member should know whom they call at 3 a.m. and what that person is empowered to do.

A preliminary incident report within roughly 48 hours of detection, documenting affected addresses, estimated losses, and preliminary root cause. This is for users, for the broader ecosystem, and for any partners who need to make decisions based on what happened.

A full post-mortem, published, with enough technical detail that other Stellar builders can learn from it. The temptation to bury an incident is real and we understand it; the long-term cost of doing so is much higher than the short-term embarrassment of being transparent.

Active cooperation with blockchain analytics firms and, where appropriate, law enforcement. Funds get recovered when the right people see the right transactions early.

A user restitution plan that the team can actually execute, including verified addresses, communication channels, and a clear timeline.

Everything above is easier to trust when users can verify it. Much of DeFi still asks users to take a protocol's safety on faith—or to reconstruct it themselves from block explorers and GitHub. A protocol that accepts meaningful user funds should be able to point to a single place where an ordinary user, or a protocol composing with it, can see what's true. We'd like to see a public risk page—linked from the docs and the app—that consolidates:

The audit history, with links to the full published reports and the code versions they covered.

Known risks and current limitations, stated plainly. Every protocol has them; the trustworthy ones say so.

The privileged roles and upgrade paths that exist over the protocol, consistent with the governance documentation above.

External dependencies —the oracles, bridges, and off-chain services the protocol relies on—and what each one being wrong or compromised would mean for users.

The status of financial backstops, including the capital buffer and any insurance coverage, so users know what protection actually exists rather than assuming.

Incident history, including links to past post-mortems. A protocol that's been through an incident and handled it well has earned the right to show that.

None of this is exotic; it's the information users would need to make an informed decision, gathered in one place instead of scattered or withheld. Transparency is not just good practice—it's how an ecosystem builds the kind of trust that survives a bad day.

Some of what's above assumes a team that can be identified and held accountable. Many of the best Stellar protocols are, or aspire to be, more decentralized than that. We see the tension, and we don't think it's a reason to lower the bar.

For decentralized protocols, the question is whether functionally equivalent controls exist. Governance processes that produce real accountability. Technical safeguards that don't depend on a person being on call. Treasury arrangements that survive contributor turnover. Transparency mechanisms that let users see what's true without having to take anyone's word for it. The form of the control may differ; the substance should not.

None of this is a checklist we expect every protocol to satisfy on day one. Maturity takes time. New teams will be earlier on this curve than established ones, and that's appropriate. What we'd like to see is movement: every protocol on Stellar working visibly toward a higher standard, and a community where teams talk to each other about how to get there.

SDF will keep contributing to this in the ways we can: convening security roundtables, supporting access to recognized auditors for early-stage teams through our Audit Bank, publishing what we learn from incidents the ecosystem has lived through, and engaging with the broader DeFi security community on standards that work. We'd love to build these practices together with you. We also believe that any protocol that accepts meaningful user funds should be able to explain which controls are in place, which are missing, what risk that creates for users, and when the gaps will be closed.

If you're a builder on Stellar and you'd like to talk about how any of this applies to what you're working on, please reach out. The strongest DeFi ecosystem is one where these practices are normal, not exceptional. And we know Stellar is positioned to get there.