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: self-custody wallets, DeFi protocols, transparent smart contracts. That response was the right instinct. But it addressed only half the 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 addresses where the funds sit, but it doesn't address what happens to them once they're there. Consider a non-custodial ERC-4626 vault where the operator can deploy deposits into any protocol on any chain, swap into any token, and interact with any smart contract function. The funds are in a smart contract, which is progress. But the operator retains complete discretion over strategy execution, and the depositor has no programmatic guarantee about how that discretion will be exercised. The custody model changed; the exposure to unconstrained human judgment remained.

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" isn't a risk framework. It's a gap.

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, not smart contract bugs. The biggest risk facing institutional capital in DeFi is operational: what humans do with the keys, not whether the smart contracts have bugs.

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.

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

The architecture that Upshift and August Digital 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.

Walk through what this looks like in practice. A curator managing a stablecoin vault spots an attractive yield on a new lending protocol. They submit a transaction to deploy $5 million in USDC. The policy engine checks: is this protocol on the whitelist? It isn't. Transaction rejected. No human intervention needed. No post-hoc discovery. The capital stayed 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.

A policy engine is the core. But for institutional-grade onchain asset management, it's one layer in a deeper stack. Here's what the full picture looks like.

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, changing critical parameters, or modifying the policy engine itself requires coordination across organizations.

MPC key management. All operator keys are Fireblocks MPCs (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 been reviewed by four independent audit firms over two years: Hacken, ChainSecurity, Sigma Prime, and Zellic. Four firms means four different methodologies, four sets of assumptions, four teams trying to break the same code. The difference between a single audit report and four independent reviews from firms with different methodologies is the difference between a compliance checkbox and a genuine security posture.

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. Vault parameter changes (like management fee adjustments) are timelocked, giving depositors notice before changes take effect. But 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, so no single party can push an upgrade unilaterally. But there's no enforced waiting period between proposal and execution.

Not all fee changes are timelocked. Management fee updates go through the timelock. 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, not specific to any one platform, but it matters for institutional due diligence. The mitigation is audit depth and the security stack described above, not an insurance policy.

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.

If you're an institutional allocator, foundation treasury, or compliance team evaluating DeFi 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.

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.

Onchain asset management isn't theoretical. It's 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 aren't retail users yield farming. They're 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 TVL across 40+ vaults on 30+ chains, with curators like Sentora and UltraYield 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.

Every CeFi collapse in 2022 shared the same root cause: unconstrained human discretion over other people's money. The fix wasn't just moving assets into smart contracts. It was 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 are the mechanism that closes the gap between "self-custody" and "institutional-grade." They take the compliance function out of quarterly reviews and embed it into every single transaction. They make violations impossible rather than merely discoverable.

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 don't need to trust a person, a company, or a process. They 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.

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 rather than reviewed by a compliance team after the fact.

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.

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.

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, all operator keys are Fireblocks MPCs, meaning no single person or device holds a complete signing key.

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.

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).

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 rather than through process or policy documents. A compliance policy says "the operator shall not deploy to unapproved protocols." A policy engine makes it so the operator can't.