Wrapper Vaults
Roadmap - not built. No vault is deployed. The pools this design sits on, their LP receipts and every read it depends on are live; the wrapper above them is not. Sections marked verified are checked against deployed BTR code. This page specifies a design; it lists no asset as supported and commits to no launch order.
An asset can be tokenized many times over. Ether staked through different protocols, dollars issued by different issuers, one company’s shares brought on-chain by different venues: each produces a token that tracks the same underlying and none of them is fungible with the others. Holders end up split across wrappers, and so does the liquidity that serves them. Every wrapper needs its own venue against every quote asset, and each of those venues is thinner than the one market they were carved out of.
A wrapper vault holds one BTR pool whose legs are the wrappers of a single underlying, and issues one token against it: btrUSD, btrETH, btrNVDA. Holding that token is holding the underlying exposure, plus the fees the pool earns from the flow between its wrappers.
1. The fragmentation this addresses
Single-Asset Vaults aggregates one asset across several pools. This page is the other axis: several wrappers of one asset inside one pool.
The two are orthogonal and compose. A single-asset vault can hold USDC across the stable, FX, crypto and stocks cores; a wrapper vault holds one core whose legs are all dollars, or all staked ether, or all of one company’s shares.
The case for the underlying pool is the case for correlated rosters in its strongest form. A roster of wrappers of one asset is the limit of correlation: the flow that drains one leg arrives against another, which is exactly the condition under which shared depth nets rather than accumulates. Those pools price near their peg, so the coverage toll does most of its work in a narrow band, and the anchor tree is one level deep.
What the vault adds on top is not pricing. It is the receipt.
2. What a depositor holds today, and what changes
Verified against deployed code.
Depositing into a pool today mints an LP receipt for the leg deposited (Providing Liquidity). Deposit stETH, hold a stETH receipt. That receipt carries the leg’s own coverage: a same-asset exit is capped in kind at min(c_leg, C), so the depositor holds an exposure to which wrapper they happened to pick.
A wrapper vault deposits on the holder’s behalf and issues one token for the pool. Two consequences follow:
- The wrapper choice stops mattering to the holder. The token is a claim on the pool, not on a leg. Whichever wrapper was deposited, the holder ends up long the underlying and the pool’s fee stream.
- Exit is a pool decision, not a leg decision. Redemption delivers whichever legs the pool can pay in, under the same exit rate the pool already enforces. The vault does not create a redemption promise the pool cannot honour, and it must not appear to: see §5.
3. The share: non-rebasing and auto-compounding
The share is a standard ERC-4626 vault token. Supply does not rebase; convertToAssets rises as the pool earns. One btrETH is worth more ether over time rather than multiplying in the holder’s balance.
This is a design decision with three reasons behind it, and the alternatives are worth stating.
| Shape | Assessment |
|---|---|
| Non-rebasing, auto-compounding (selected) | Fixed balances. Lending markets, AMMs and aggregators ingest ERC-4626 without special casing. BTR’s own ERC4626YieldHook already speaks it, so a wrapper vault composes with the hook surface that exists |
| Rebasing, pegged to the underlying | Reads well in a wallet and integrates badly. It also has to rebase down when the pool takes a loss, and a balance that falls is precisely what integrations mishandle. BTR pools themselves gate rebasing and fee-on-transfer tokens, so a rebasing share would be hard to list in the protocol that issued it |
| Claimable rewards | Worst of both. Rewards strand for contract holders, every integration needs a claim step, and the accounting surface is larger than the vault it serves |
Where a pegged unit is genuinely required by a venue, the answer is a thin rebasing wrapper over the share - wrapped first, the way staked-ether tokens already do it - rather than making the canonical token rebase.
For an income-bearing underlying such as a tokenized share paying a dividend, the distribution is deposited into the pool and shows up in the share price. Nothing is distributed per holder and no claim step exists.
4. Pricing the share
convertToAssets is the pool’s own valuation of the vault’s position: each leg’s LP receipt at its index, valued at the marks the pool already reads, net of the exit rate the pool would apply. No new oracle, no new price feed, and nothing a depositor has to trust that a swapper does not already trust.
That number falls when the pool’s rate falls. It is a share price, not a peg, and the page says so where a holder will read it.
5. What the vault must not promise
Three invariants, each stated because the failure mode is specific.
- Redemption is bounded by the pool. The vault cannot honour an exit the pool would refuse. If a leg is halted or its coverage is short, redemption follows the pool’s rules. A vault that looked more liquid than its pool would simply be the cheaper exit, and would drain into it.
- The roster is the risk. Wrappers of one asset share an underlying but not an issuer. One wrapper failing is a leg depegging inside a pool whose other legs are fine, which is what per-leg deposit caps and the coverage wall are for. The vault concentrates that choice into one token, so the caps carry more weight, not less.
- Whoever manages the pool holds a privileged seat. If the vault is also the pool’s admin, every parameter change becomes a vault-governance action. That seat is part of the design, not an implementation detail, and it is audited as such.
The circularity rule applies here unchanged: an asset carrying an inbound vault must not run an outbound yield hook into the same venue.
6. Build scope
| Component | Status |
|---|---|
| Pools, LP receipts, exit rate, coverage reads | Built, live |
| Multi-wrapper roster (one pool, legs of one underlying) | Configuration of a live mechanism, not a code change |
| ERC-4626 wrapper vault | Not built |
| Dead-share seeding on the vault share | Not built - the pool’s own seeding is the template |
| Dividend and reward routing into the pool | Not built - per underlying class |
The on-chain surface is one vault contract per underlying. Below it, everything is live.
7. Related documentation
- Single-Asset Vaults: the other aggregation axis, one asset across many pools
- Pool Composition: why a roster is chosen for correlation
- Providing Liquidity: the LP receipt, its index and the exit rate
- Inventory Management: coverage, the pool rate and the wall
- Hooks: the outbound yield hooks and the circularity constraint