How traditional asset managers are controlling risk in DeFi

June 13, 2022. Celsius froze withdrawals on $12 billion in customer assets. Alex Mashinsky had been personally directing trades for months, moving customer deposits into risky DeFi positions, staking illiquid tokens, and running leveraged strategies with no guardrails. There was no oversight committee reviewing his allocations. No programmatic limit on what he could do with the money. Customers trusted a person, and that person had a blank check.

Within six months, Voyager, BlockFi, and FTX followed. Each collapse had its own specifics, but the failure mode was identical: users handed over custody and trusted humans to manage their capital responsibly, and those humans operated with zero enforceable restrictions on what they could do with it.

The industry's collective response was to move everything onchain, into self-custody wallets, DeFi protocols and transparent smart contracts. That was the right instinct, though it only addressed half the problem.

Self-Custody Solves One Problem

In a non-custodial vault, your funds sit in a smart contract. No company holds your deposits in an omnibus account. No CEO can wire your money to a hedge fund on a whim. That's genuine progress over the Celsius model, where customer assets were commingled and deployed at management's discretion.

Self-custody settles where the funds sit, and leaves open what happens to them once they're there. Take a non-custodial ERC-4626 vault where the operator can deploy deposits into any protocol on any chain, swap into any token, and call any smart contract function. The funds are in a smart contract, which is progress. The operator still has complete discretion over strategy execution, and the depositor has no programmatic guarantee about how that discretion will be used. Depositors are still exposed to unconstrained human judgment, just inside a new custody model.

For retail users, that might be acceptable. For institutional allocators deploying $50 million from a foundation treasury, or a compliance team evaluating vault infrastructure for an exchange Earn product, "trust the operator" leaves a gap where the risk framework should be.

Policy Engines: Investment Mandates Enforced by Code

In traditional asset management, a fund manager operates under an investment mandate. The rules might say: no more than 30% in any single position, only investment-grade counterparties, no illiquid assets beyond a defined threshold. A compliance team audits the portfolio, usually quarterly or after the fact. If the manager violated a constraint last Tuesday, the compliance review catches it next month.

That enforcement model is reactive. Violations are discovered after they've already happened. And the data shows why this matters: according to Halborn's Top 100 DeFi Hacks report, 80.5% of stolen funds in 2024 came from off-chain and operational attacks. The biggest risk facing institutional capital in DeFi is operational: what humans do with the keys.

A policy engine flips that model. It's an investment mandate wired directly into the smart contract layer, enforced on every transaction, in real time, before execution. The operator submits a transaction. The policy engine evaluates it against a set of rules. If the transaction violates any rule, it gets rejected. The capital never moves. Upshift vaults whose curators trade through Upshift prime accounts run on this model: the policy engine checks every transaction against chain, protocol, token and function rules.

The result is that compliance becomes pre-emptive. There's no review to schedule, no quarterly audit to wait for, because the violation is technically impossible at the contract level.

How Policy Engines Work

The architecture that Upshift prime accounts use is a good concrete example. The policy engine enforces restrictions across four layers, each one narrowing what the operator can do.

Chain-level restrictions. The vault specifies which blockchains the operator can deploy to. If Arbitrum and Ethereum are whitelisted but Blast isn't, the operator can't bridge capital to Blast. The transaction won't execute.

Protocol-level restrictions. Within approved chains, only whitelisted DeFi protocols are accessible. If the vault approves Morpho and Aave but not a new, unaudited lending market, the operator can't deploy there. The contract blocks it.

Token-level restrictions. The vault defines which assets can be held. If the mandate allows USDC, USDT, and DAI, the operator can't swap deposits into a volatile governance token. The policy engine rejects the swap.

Function-level restrictions. Even within approved protocols, only specific smart contract functions are callable. The operator can call deposit() and withdraw() on a lending market, but can't call an admin function or interact with an unvetted contract method.

In practice it looks like this. A curator managing a stablecoin vault spots an attractive yield on a new lending protocol and submits a transaction to deploy $5 million in USDC. The policy engine checks whether the protocol is on the whitelist. It isn't. The transaction is rejected with no human intervention and nothing to discover after the fact, and the capital stays exactly where it was.

Compare this to traditional fund compliance. A portfolio manager at a mutual fund might exceed a concentration limit on a Friday afternoon. The compliance team flags it during their Monday review. By then, the position has been live for three days. The manager might argue it was temporary, or that market conditions justified the deviation. There's a conversation, maybe an escalation, maybe a forced unwind.

With a policy engine, that conversation never happens. The rule runs inside the transaction itself. The closest analogy is a compliance officer embedded in every trade, reviewing it in real time, with the authority to reject, except the officer is code that runs continuously, can't be overruled by seniority, and can't be persuaded to make an exception.

Beyond the Policy Engine: The Full Security Stack

A policy engine is the core, and for onchain asset management at institutional scale it's one layer in a deeper stack. The full stack looks like this.

Multi-party governance. Vault proxy administration runs through a 4-of-6 multisig. The signers are split evenly: 2 from the asset issuer, 2 from the platform (Upshift), 2 from the curator. No single party can act alone. Upgrading the vault contract requires coordination across organizations. Parameter changes go through the vault owner, a Gnosis Safe multisig.

MPC key management. Operator keys are held in Fireblocks or Fordefi MPC (Multi-Party Computation) wallets. There is no single private key sitting on a laptop or in a hot wallet. The key is split into multiple shares distributed across independent parties and environments. Signing requires a threshold of shares to reconstruct, which eliminates the single-point-of-failure risk that has been behind some of DeFi's worst exploits.

Pre-transaction simulation. Before any operator transaction hits the blockchain, Upshift's admin portal runs a full simulation of the state change. A maker-checker approval flow means one person proposes the transaction and a second person reviews the simulated outcome before approving. The reviewer sees exactly what the transaction will do to vault balances, positions, and NAV before it executes.

NAV protection. A maxChangePercent parameter constrains how much the vault's net asset value can shift in a single update. If an operator action would cause NAV to move beyond the allowed threshold, the transaction reverts. This guards against flash manipulation, oracle errors, and fat-finger mistakes.

Independent audit depth. Upshift's vault contracts have completed 11 smart contract audits by 6 independent firms: Halborn, Hacken, OtterSec, ChainSecurity, Sigma Prime and Zellic. Six firms means six different methodologies, six sets of assumptions, six teams trying to break the same code. The difference between a single audit report and several independent reviews from firms with different methodologies is the difference between a compliance checkbox and a genuine security posture.

‍

‍

What Honest Gaps Remain

Policy engines are a significant step forward, but the onchain security model isn't perfect. Institutions evaluating this infrastructure should understand the current limitations alongside the strengths.

Proxy upgrades have no timelock. Some vault parameter changes (like management fee adjustments) go through a configurable timelock, giving depositors notice before changes take effect. Proxy contract upgrades, which can modify the vault's core logic, don't currently have a mandatory timelock. They still require the 4/6 multisig, which stops any single party pushing an upgrade unilaterally, though there's no enforced waiting period between proposal and execution.

Not all fee changes are timelocked. Management fee updates go through the timelock on most vaults. Performance fees, instant redemption fees and withdrawal fees don't. The rationale is operational flexibility (these fees may need adjustment quickly in response to market conditions), but it's a distinction compliance teams should be aware of.

No smart contract insurance. There's no insurance product covering smart contract failure for vault depositors. This is a gap across the industry, and it matters for institutional due diligence. The mitigation is audit depth and the security stack described above.

Acknowledging these gaps is part of the institutional evaluation process. Compliance teams should weigh them against the full security stack and compare against the alternative: custodial models where these controls don't exist at all. A separate guide shows which vault providers ship which controls.

What Compliance Teams Should Evaluate

If you're an institutional allocator, foundation treasury, or compliance team evaluating onchain vault infrastructure, here's a practical checklist. These are the questions that separate vault platforms with real security architecture from those that just claim "non-custodial" and stop there.

1. Is the vault non-custodial? The smart contract should hold funds directly. No intermediary wallet, no omnibus account, no "we'll custody it for you."

1. What restrictions exist on operator actions? Look for chain, protocol, token, and function-level restrictions. If the answer is "the operator follows best practices," that's a process. Look for a control that enforces it.

1. Are restrictions enforced onchain or at the application layer? A policy that lives in a dashboard but isn't enforced by the smart contract can be bypassed. Onchain enforcement means the contract itself rejects violations.

1. What is the multisig composition? How many signers? Who are they? Are they from independent organizations? A 2-of-3 multisig where all 3 signers work at the same company is functionally a single point of control.

1. What MPC provider manages operator keys? Fireblocks and Fordefi are the two established providers. Ask whether any operator keys are standard EOAs (externally owned accounts) with a single private key.

1. Is there a pre-transaction simulation flow? Maker-checker approval (propose, simulate, review, approve) adds a layer that catches errors and malicious transactions before they hit the chain.

1. How many independent audit firms have reviewed the contracts? One audit is a starting point. Several independent audits by firms with different methodologies is a stronger position.

1. What is the timelock coverage? Which parameters are timelocked? Which aren't? Can proxy upgrades happen immediately, or is there an enforced delay?

1. What is the emergency withdrawal mechanism? If something goes wrong, how are vault-held assets recovered? Who can trigger it? Where do the funds go?

These questions map directly to the controls that would have prevented every major CeFi collapse in 2022. Celsius had no programmatic restrictions on operator actions, no multi-party governance, no onchain transparency. $3.8 billion was stolen in crypto hacks that year, and $2.2 billion in 2024. The losses came overwhelmingly from systems where human discretion operated without enforceable constraints.

The Market Is Moving

Onchain asset management is one of the fastest-growing categories in crypto.

Discretionary vault strategies (where professional curators actively manage capital allocation) grew 738% year-to-date, making them the fastest-expanding segment in onchain asset management, according to a Keyrock and Maple Finance report that tracked the sector reaching $35 billion in AUM. The capital flowing in is heavily concentrated: whale depositors (over $1 million) and dolphins ($100K to $1M) account for over 99% of vault AUM.

These are treasuries, foundations, and funds that need the same controls they had in TradFi. Policy engines, multi-party governance, MPC key management, and pre-transaction simulation are what make that possible.

Upshift's own trajectory reflects the pattern. Over $550 million in peak TVL across 50+ vaults on 30+ chains, with curators like Sentora managing strategies spanning DeFi lending, basis trading, CeFi lending, and ecosystem bootstrapping vaults like earnAUSD on Monad (over $80 million peak TVL). Partners including exchanges, wallets, and asset managers integrate through the vault SDK.

The Common Thread

Every CeFi collapse in 2022 shared the same root cause: unconstrained human discretion over other people's money. The fix meant rebuilding the controls that institutional finance has relied on for decades (investment mandates, compliance oversight, custodian separation, audit requirements) as onchain primitives that execute automatically.

Policy engines close the gap between self-custody and the controls an institutional mandate requires. They take the compliance function out of quarterly reviews and embed it into every single transaction, where a violation can't execute.

Traditional asset management is coming onchain. The controls, the governance structures, the risk frameworks that made institutional capital comfortable in TradFi are being rebuilt in code and enforced by smart contracts. The result is infrastructure where depositors can verify the rules, see the positions, and know that the policy engine will enforce the mandate whether anyone is watching or not.

That's the standard the next generation of onchain asset management is being built to.

FAQ

What is a policy engine in DeFi?

A policy engine is a set of rules enforced at the smart contract layer that restricts what a vault operator can do with deposited capital. It defines which chains, protocols, tokens, and smart contract functions the operator is allowed to interact with. Every operator transaction is checked against these rules before execution. If a transaction violates any rule, it gets rejected automatically. Think of it as a TradFi investment mandate, except enforced by code in real time.

How do policy engines differ from smart contract audits?

Audits review the vault's code for bugs and vulnerabilities. A policy engine governs what the vault's operator can do with the capital inside. They solve different problems. An audit confirms the smart contract works as designed. A policy engine constrains the operator's actions within that design. You need both: audits to verify the code is sound, and a policy engine to enforce the investment mandate on an ongoing basis.

Can a vault operator steal funds in a non-custodial vault?

In a properly designed non-custodial vault with a policy engine, the operator's actions are restricted to whitelisted protocols, tokens, chains, and functions. The operator can deploy capital into approved strategies but can't withdraw funds to their own wallet, swap into unapproved tokens, or interact with non-whitelisted contracts. Combined with multi-party governance (4/6 multisig across 3 organizations) and MPC key management, the attack surface for operator theft is dramatically reduced compared to custodial models.

What is MPC key management?

MPC (Multi-Party Computation) splits a cryptographic key into multiple shares held by different parties. No single share can sign a transaction alone. Signing requires a threshold of shares to participate. This eliminates the risk of a single compromised private key draining a vault. Providers like Fireblocks are the industry standard for institutional MPC wallets. In Upshift's architecture, operator keys are Fireblocks or Fordefi MPC wallets, meaning no single person or device holds a complete signing key.

How do institutions evaluate onchain vault security?

Start with custody model (non-custodial vs. custodial), then evaluate operator restrictions (chain/protocol/token/function level enforcement), governance structure (multisig composition and quorum), key management (MPC vs. single-key), pre-transaction controls (simulation and maker-checker flows), audit history (how many independent firms, how recently), and timelock coverage (which parameters have enforced delays). The audit page and risk framework documentation are the right starting points for technical due diligence.

What is a maker-checker approval flow?

A maker-checker flow requires two separate people to complete a sensitive action. One person (the maker) proposes a transaction and submits it for review. A second person (the checker) reviews the proposed action, including a simulation of its outcome, and either approves or rejects it. This is standard practice in banking operations and is now being applied to onchain vault management. It prevents both errors (the checker catches mistakes) and insider threats (no single person can execute a transaction alone).

Are onchain policy engines the same as DeFi compliance?

Policy engines are one component of DeFi compliance, but they're the most structurally important one. DeFi compliance also includes KYC/AML on depositors (via whitelisting), audit coverage, governance procedures, and reporting. What makes policy engines distinctive is that they enforce rules at execution time. A compliance policy says "the operator shall not deploy to unapproved protocols." A policy engine makes it so the operator can't.

Keep Reading

• What is Upshift? - How the vault infrastructure works, from deposit to strategy execution to withdrawals
• Which party sets a vault's mandate: the four roles around a vault, and what the policy engine stops each of them doing.

• Risk Management Framework - Full documentation of Upshift's policy engine, governance, and security architecture

• Smart Contract Audits - Reports from 11 audits by Halborn, Hacken, OtterSec, ChainSecurity, Sigma Prime and Zellic

Keep reading

• What is an onchain vault: what a vault is, who holds the assets, and how money moves in and out.
• How to use an onchain vault in a treasury product: the ETP comparison, fees, and what to decide first.
• What it takes to launch a vault for your own clients: the operational path from mandate to live vault.