How we select DeFi protocols
The six criteria behind Curve, Pendle, Balancer, Beefy, Aave and StakeDAO — and what we exclude.
Curve 
Pendle 
Balancer 
Aave Non-custodial protocols · No client keys held · Selection as of September 2026
The short version
- Six protocols carry the allocation: Curve, Pendle, Balancer, Beefy, Aave and StakeDAO. All are non-custodial and none holds client keys.
- The same six tests decide entry: time in production, public independent audits, oracle design, governance and upgradeability, liquidity depth, and coverage eligibility.
- Selection is per pool, not per brand. Approving a protocol does not approve every market it operates.
- Leverage, looping, exposure to volatile assets, unaudited forks and anything other than USD or USDC are excluded — which lowers the ceiling on the rate, deliberately.
- Passing the criteria does not make a protocol safe. Smart contract risk remains, which is why the coverage arranged through OpenCover sits behind the allocation.
Our six selection criteria.
The same six tests are applied to every pool before any corporate funds reach it. They are deliberately boring: none of them is about the advertised rate, because the rate is the output of a risk decision, not a reason to make one.
Time in production
A protocol enters the allocation only after its core contracts have run in production at material size through more than one market cycle. Recent deployments, unaudited forks and rewritten codebases are out, regardless of the rate they advertise.
Public independent audits
The contracts we deploy into must have public audit reports from independent firms, and an active bug bounty. We read the findings and how they were resolved, not the badge on a landing page. An audit that predates a material rewrite is treated as expired.
Oracle design
How the protocol prices assets decides how it fails. We look at which feeds it depends on, whether a price can be manipulated within a block, whether there are bounds or circuit breakers, and what the protocol does when a feed goes stale.
Governance and upgradeability
Who can change the contract, under what majority, and how much notice the change gets. Timelocks, multisig thresholds and emergency powers are part of the risk, because a protocol that can be upgraded instantly can be upgraded against depositors.
Liquidity depth and exit path
A position is only as good as the way out of it. We size each allocation against the depth of the pool it sits in, so that unwinding it does not depend on favourable conditions, and so that the 48-hour withdrawal window holds without forcing a bad exit.
Coverage eligibility
The pool has to fall within the scope of the coverage arranged through OpenCover. A protocol we cannot cover for the listed events is not used for corporate funds, even when it is otherwise well regarded.
What the six criteria do not do
Passing them does not make a protocol safe. Audited contracts have failed, governance has been captured, and oracles have been manipulated on protocols that met every criterion on this list. The tests narrow the set of ways a position can go wrong and they inform the size of each allocation. What they cannot do is remove smart contract risk, which is why the coverage arranged through OpenCover sits behind them and why the coverage page states the residual risks that stay yours.
Curve — why, which pools, which risks.
Curve is an automated market maker built for assets that are meant to trade at the same price. That specialization is the reason it is in the allocation: a stable-to-stable pool is the closest thing in DeFi to a position whose intended behaviour is to stay flat and collect fees.
Curve · pools used, and the three risks that come with them
Deposits provide liquidity to pools where USDC is exchanged against another dollar-denominated asset. The position earns a share of the swap fees paid by traders, plus the incentives distributed to that pool. We use pools whose other side we would be prepared to hold outright, because that is exactly what happens if the two assets stop trading at par.
- Role in the allocation: Stablecoin liquidity provision
- Where the yield comes from: Swap fees and gauge incentives
- Pools used: Stable-to-stable pools with USDC on one side
- Custody: Non-custodial, no client keys held
Nature of the risk — Pool imbalance risk. A stableswap pool absorbs the weaker asset. If a stablecoin paired against USDC loses its peg, the pool ends up holding more of it, and the position tracks that outcome. This is the risk that decides which pools we use, and it is why we stay on pools whose other side we are willing to hold.
Nature of the risk — Contract risk on pool and gauge. Depositing means interacting with the pool contract and, where incentives are claimed, the gauge contract as well. Each is a separate piece of code and a separate failure point. Code bugs are the event the OpenCover policy is built around, subject to its terms.
Nature of the risk — Incentive dependency. Part of the yield on an incentivized pool comes from emissions rather than swap fees. Emissions are set by governance and can be reduced or redirected, so the realized rate on a pool is not a fixed property of that pool.
Selection is per pool, not per brand. Curve being on this page does not mean every Curve pool is used, and the pools in the current allocation are the ones shown in your dashboard and listed during onboarding.
Pendle, Balancer, Beefy, Aave and StakeDAO.
Each one is in the allocation for a specific job, and each one brings a specific failure mode. Both are stated below. Two of them — Beefy and StakeDAO — are layers on top of other protocols, which means their risk is additive rather than alternative.
Protocol · role in the allocation, and nature of the risk
Role in the allocation. Pendle separates a yield-bearing position into its principal and its future yield, which makes it possible to fix a known rate to a known date. That maturity structure is what a term tier maps onto: a rate agreed up front rather than a floating one.
Nature of the risk. The position is priced to a date. Leaving before maturity means selling at market, not at par, and the market for a maturity can be thin. On top of that sits the contract risk of the tokenization layer, and the risk of whatever underlying asset the yield is derived from — Pendle does not remove it, it repackages it.
Role in the allocation. Balancer provides another pool architecture for stablecoin liquidity. Its value in the allocation is not a higher headline rate but codebase diversification: two venues built by different teams fail for different reasons, which is the point of splitting an allocation across them.
Nature of the risk. Pool-level contract risk, plus the rate providers a pool relies on when it holds a yield-bearing token rather than a plain stablecoin. Composability adds convenience and adds dependencies; each wrapped asset in a pool is one more contract that has to behave.
Role in the allocation. Beefy vaults harvest and reinvest rewards from an underlying position on a schedule, without manual intervention. The gain is operational: fewer discretionary actions, fewer missed compounding cycles, and a lower cost per harvest than doing it position by position.
Nature of the risk. It is a layer on top of another protocol. Using it means taking the vault and strategy contract risk in addition to the risk of the underlying protocol, not instead of it. Strategies can also be changed by the protocol, so the position is monitored as an active mandate, not a static deposit.
Role in the allocation. Supplying USDC to a lending market earns the interest paid by over-collateralized borrowers. It is the simplest instrument in the allocation and usually the most liquid one, which makes it the natural place for the portion that has to stay easiest to unwind.
Nature of the risk. Withdrawals depend on utilization: when a large share of the supplied liquidity is borrowed, exiting waits for repayments or for new supply. Beyond that sit bad debt from liquidations that do not execute as designed, dependency on the oracles pricing collateral, and governance control over risk parameters.
Role in the allocation. StakeDAO builds on the vote-escrow mechanics of the Curve ecosystem to improve the rate earned on gauge positions and to handle the claiming and locking work those positions require. Its role is efficiency on an exposure we already hold, not a new exposure.
Nature of the risk. Another contract layer stacked on the underlying protocol, so both sets of code have to hold. It also inherits the governance dynamics of vote-escrow systems, and the liquidity of any liquid locker token involved is a real constraint on how fast the position can be unwound.
Why six and not one
Concentrating a corporate allocation in a single protocol makes the whole balance depend on one codebase, one governance body and one oracle configuration. Splitting it across venues built by different teams means a failure in one does not take the position with it. It also means more contracts in play, which is the cost of that choice and one we state rather than hide. How deployment works step by step is set out on the how it works page.
What we exclude, and why.
A selection policy is defined as much by what it refuses. These are the categories that are out of scope for corporate funds, with the reason each one is excluded.
| Excluded | Why |
|---|---|
| Anything but USD and USDC as the base asset | Algorithmic, yield-bearing and thinly traded stablecoins are not used as the deposited asset. The product is denominated in USD or USDC and the base asset is not where we take risk. |
| Leverage and looping strategies | Recursive borrowing raises the rate by raising the chance of liquidation. A treasury allocation should not hold a position that can be closed against it by a price move. |
| Directional exposure to volatile assets | No pools where the position takes on price exposure to a volatile asset. If the dollar value of the balance can move with a token price, it is not a savings product. |
| New deployments and unaudited forks | A fork inherits the reputation of the original and none of its testing. Without a public independent audit of the deployed code, it does not qualify, whatever the rate. |
| Instant-upgrade contracts and unconstrained admin keys | Where an admin key can change contract behaviour with no timelock and no notice, depositors have no window to react. That is a governance risk we decline rather than price. |
| Positions outside the coverage scope | If a pool cannot be brought within the coverage arranged through OpenCover for the listed events, it is not used for corporate funds. Yield is not a reason to run an uncovered position. |
The consequence of this list is a lower ceiling on the rate than a strategy without it would show. That is the intended trade: the rate grid is what remains after the exclusions, not before them.
Review cadence and exit conditions.
Selection is a decision that has to be re-made. A pool stays in the allocation because it still qualifies, and it leaves when it stops qualifying — not when the loss has already happened.
- 01
Entry review
A pool is reviewed on the six criteria before any allocation. The unit of the decision is the pool, not the brand: approving a protocol does not approve every market it operates.
- 02
Continuous monitoring
Positions, pool composition and protocol conditions are monitored on an ongoing basis. Contract upgrades, governance proposals and oracle changes are treated as events to reassess rather than as noise.
- 03
Periodic re-review
Every pool in the allocation is re-examined against the same six criteria on a recurring schedule, so that a position stays in the allocation because it still qualifies, not because it qualified once.
What triggers an exit
What a review process cannot promise
Exiting a pool is an allocation decision and does not change your tier. Your own withdrawal terms are unchanged: funds are available within 48 hours, and leaving a locked tier early returns capital and forfeits accrued interest.
Referenced public audits.
Every protocol in the allocation publishes its own audit reports. We reference those published reports — we do not produce our own summary of them on this page, and we do not restate their conclusions as ours.
Where the reports come from
Each protocol publishes its own audit reports and bug bounty program in its public documentation and repositories. Those published reports are what we review and what we reference — we do not commission or resell them.
What we read in them
The scope of the audit and the commit it covers, the severity of findings, how each one was resolved, and whether the deployed code still matches the audited code after later upgrades.
What we provide on request
During onboarding, the list of the pools in the current allocation with their contract addresses, and links to the public reports covering them, so that a review team can verify the chain themselves.
What we do not publish here
We do not restate audit conclusions, publish firm names and dates, or summarize findings on a marketing page. An audit summary written by the party allocating the funds is not evidence. Where a reference is not sourced, it is not stated.
Where to take this next
This page covers how a protocol gets into the allocation and how it gets out. The two pages a finance review usually asks for next are the coverage terms behind these positions, and the onboarding requirements with the contracting entity.
Request access, or ask the hard questions first.
Open an account directly. If your finance team needs the coverage terms and the KYB requirements before that, a call is the faster route.