How onchain yield vaults are secured

Vault security is the product of several independent layers: audited code, enforced restrictions on what an operator can do, split keys, simulated transactions and continuous monitoring. Each one covers a gap the others leave open.

A vault protects depositor capital by stacking controls that all have to fail before funds are at risk. Audits cover bugs in the code, a policy engine bounds what the operator can do with the money, and MPC custody means no single stolen key is enough on its own. Every transaction is then simulated and approved by a second person, while monitoring watches the protocols the vault is exposed to.

When you deposit into a yield vault you're trusting code, an operator and a set of external systems to behave the way the documentation says. The yield is the easy part to evaluate. The harder question is what happens when something goes wrong, and there's plenty of history to learn from.

What actually causes losses onchain?

The data here should change how you weight your diligence. TRM Labs recorded 207 incidents and roughly $972 million in losses in the first half of 2026, the highest incident count on record. The important detail sits underneath that total.

Across that same first half of 2026, infrastructure and operational compromises made up around 15% of incidents and roughly 76% of the money lost. Attackers are going after access control, phishing and oracle manipulation more than they're hunting for novel contract bugs. Forbes reported the same pattern in July 2026, describing the year's attacks as fewer but far more surgical.

So a security review that stops at "how many audits do you have" is measuring the smaller share of the risk. The operational questions carry more of the weight, and they're the ones most allocators ask last.

What are the threat categories?

Oracle manipulation deserves a note because it's the least intuitive. Chainlink's explainer walks through how these attacks work mechanically if you want the detail. The short version is that a vault valuing collateral from a single thin market is quoting a number an attacker can afford to move.

How does defense in depth actually work?

A serious posture assumes any single layer can fail. The table below is how Upshift stacks them.

The policy engine is the structural one. It constrains what an operator can do with your capital in the first place, which turns several threat categories from catastrophic into contained. A compromised operator key can't route funds to an attacker's address, because the engine won't authorise a transaction outside its rules. The restrictions sit below the operator, so the operator's own judgment can't override them. The risk management framework documents how they're set and changed.

Audits reduce smart contract risk without eliminating it. A deeply reviewed contract is far less likely to carry a critical bug than an unreviewed one, and audit history is the first thing most allocators check. The full audit list is published rather than summarised. For the general limits of what review can prove, Ethereum's own smart contract security documentation is a useful neutral source.

The monitoring layer runs through Hypernative, which watches deposits, strategies and redemptions continuously rather than after the fact. Its detection combines machine learning models, simulations and graph analysis. As of August 2026 the platform covers more than $100 billion in digital assets across 75+ chains for over 350 organisations, and reports having prevented more than $3 billion in losses.

What that buys a vault is time. If a protocol the vault is exposed to starts behaving abnormally, the signal arrives while there's still room to act rather than in the post-mortem. Monitoring improves the odds of an early response, and it doesn't make a vault unhackable.

Why do the layers matter together?

Each layer covers what the others leave open. Audits reduce the chance of a code bug and can't stop a compromised key. A policy engine contains a compromised key and can't catch an operationally wrong transaction that sits inside policy. Simulation catches that transaction and doesn't watch external protocols. Monitoring watches the environment and works best once the preventive layers have narrowed what can go wrong.

Stacked, an attacker has to defeat audited code, find a transaction the policy engine permits, compromise multiple key shares, get past a second human reviewer working from a simulation, and avoid tripping monitoring. That's the practical meaning of defense in depth, and it's why no single control is the thing you're asked to trust.

This architecture is also what lets the platform stay flexible. Curators deploy across DeFi lending, CeFi credit, basis trades and liquidity provision on 30+ chains, because the policy engine, MPC custody and monitoring travel with the vault wherever it runs.

Always make sure to do your own research and be aware of the above and any other risks before depositing. Security controls reduce risk rather than removing it, and yields are never guaranteed.

What should you ask a vault provider?

Each question below maps to a layer. If a provider can't answer one of them cleanly, that's the layer to dig into.

• Who reviewed the code, and when was it last re-reviewed? Ask for the reports rather than a count. Coverage frozen at launch tells you little about a contract shipping new vault types.
• What can the operator do with my money? The answer should be a list of enforced restrictions, not a description of a process or a policy document.
• At what level are restrictions enforced? Protocol-level allowlists still permit an approved venue to be used in ways you never sanctioned. Function level closes that.
• How are operator keys held? A single key on a single machine is a single point of failure, and it's where the largest losses have come from.
• Who approves a transaction before it's signed? One party proposing and a second approving against a simulated result removes the single-operator mistake.
• Who's watching while my capital is deployed? Preventive controls stop at execution. Something has to cover the protocols you're exposed to afterwards.

Those questions mirror the control frameworks traditional asset managers already run internally, which is why the onchain version tends to read as familiar. There's more on that mapping in how traditional asset managers are controlling risk in DeFi.

How do you verify any of this yourself?

Most of these claims are checkable without taking a provider's word, which is the point of putting them onchain. Four things you can confirm independently before you allocate:

• Read the audit reports, not the count. Check the date, the scope and whether the findings were remediated. A report covering an older contract version tells you less than the headline number suggests.
• Read the vault contract. It's deployed and verifiable. The ERC-4626 standard defines what the deposit, redeem and accounting functions have to do, so deviations are visible to an engineer.
• Check the allowlist onchain. The set of approved protocols and tokens is a parameter you can inspect rather than a claim in a PDF.
• Watch a redemption. Ask for a test redemption during scoping and time it.

The same logic applies to the underlying strategies. Position-level exposure is visible onchain, so you can confirm what a vault actually holds rather than relying on a monthly factsheet. The strategy reference covers what each strategy does and how it behaves under stress. If your team wants independent grounding on the wider risk picture, the Bank for International Settlements has published work on tokenisation and financial stability with no commercial stake in the answer.

What does this mean if you're building on top?

An exchange, wallet, neobank or asset manager putting an earn product in front of its own users needs a security model it can explain in its own words. Your risk team should be able to walk through the layers, and your support team should be able to answer a customer asking where the money goes. Everything above is published rather than described, so both are doable without a vendor call.

Across 50+ vaults, more than 60,000 users and over $550M in deposits at peak as of August 2026, the security stack is what allows that scale to exist. Allocators underwrite the stack before they deposit, so it gets read closely.

One practical note for integrators. Your users will ask you the questions in the section above, and support teams field them badly when the answers live in a vendor's PDF. Get the six answers written into your own help content before launch, in your own words. It takes an afternoon and it removes the most common reason an earn product generates tickets in its first month.

Frequently asked questions

Are DeFi vaults safe?

No onchain yield product is risk-free, though a well-built vault is far safer than an unaudited one. What matters is how many independent firms reviewed the code, whether a policy engine constrains the operator, how keys are held, and whether positions are monitored continuously. A vault managing risk through several independent layers beats one relying on any single control.

What causes the most losses onchain?

Operational and infrastructure compromise. In the first half of 2026 those made up roughly 15% of incidents and around 76% of the money lost, according to TRM Labs. Stolen keys, phishing and access-control failures cost more than novel contract bugs, which is why MPC custody and policy constraints matter as much as audit count.

What does a smart contract audit actually prove?

It's an independent review looking for bugs, flawed access control and inputs that push a contract into an unsafe state. It reduces the chance of a critical flaw, especially with multiple firms reviewing the same code, and it can't prove the absence of every bug. That's why audits are one layer rather than the whole model.

What is a policy engine?

It enforces restrictions on what a vault operator can do, at the chain, protocol, token and function level. Capital only moves into whitelisted protocols, holds approved tokens and calls permitted functions, and anything outside those rules is rejected before execution. This contains the damage from a compromised key, since the attacker can't route funds to an arbitrary address.

How does MPC custody protect operator keys?

Multi-party computation splits a private key into shares held separately, so no single party holds a complete key and no single compromised device exposes one. Stealing one share achieves nothing on its own. Upshift uses Fireblocks and Fordefi for the keys authorising vault operations, which removes the single-machine failure mode behind many of the industry's largest losses.

Does a strong security stack guarantee my deposits are safe?

No. Audits, policy engines, MPC custody, maker-checker approval and monitoring all reduce risk, and together they reduce it substantially. None guarantees safety. Onchain yield always carries smart contract, counterparty and market risk. A strong stack lowers the probability and limits the blast radius of a failure, which is different from eliminating risk. Size positions accordingly.

Keep reading

• What is Upshift: how non-custodial vault infrastructure works, from deposit to strategy execution.
• How to tier vault strategies by risk: sorting strategies the way a treasury team does.
• Who does what in an onchain vault: which party owns each step, including who can pause.
• Upshift DeFi yield: the strategies curators deploy across DeFi and CeFi.