Beyond ERC-4626

Async vaults, perps, and prediction markets — where one appreciating share stops being enough

Part 1 made a clean claim: option vaults, lending markets, and perp LP pools are all the same chassis — deposit an asset, get one fungible share, let a strategy grow totalAssets so the share appreciates. That model is powerful because it's narrow. This follow-up is about the three places the narrowness shows: when settlement can't be synchronous (ERC-7540), when the position isn't a share at all (perps), and when a single appreciating token simply can't express the payoff (ERC-1155 conditional tokens, the standard behind Polymarket).

---

0. Recap in one paragraph

Part 1's whole trick was pricePerShare = totalAssets / totalSupply. Yield is anything that grows totalAssets while share supply stays flat: a DOV's option premium, a lending market's interest, a perp LP's funding. One standard, three engines, three risk shapes. But baked into that model are two silent assumptions — (a) you can always redeem your share right now for its current value, and (b) the entire position collapses to one fungible token whose price only goes up (or down) along a single axis. Each section below breaks one of those assumptions.

---

1. Crack #1 — settlement isn't always synchronous → ERC-7540

Part 1 name-dropped ERC-7540 in the DOV section and moved on. It deserves a proper look, because it's the standard that fixes the single most common ERC-4626 mismatch.

Vanilla ERC-4626 assumes withdraw() / redeem() settle atomically — the assets are sitting in the contract, ready to hand back this block. That's true for a lending wrapper (Aave liquidity is usually on demand). It is false for anything whose capital is temporarily unreachable:

• a DOV with collateral locked inside a live option until expiry,
• an RWA vault whose underlying is a T-bill that settles T+1 off-chain,
• a cross-chain vault waiting on a bridge message.

For all of these, redeem() can't return funds synchronously — so the naive fix (revert until the epoch ends) makes the share illiquid and breaks every integrator that assumes 4626 semantics.

What ERC-7540 adds

ERC-7540 is a superset of ERC-4626 that turns deposit and redeem into two-step, asynchronous flows. Nothing about the accounting changes — pricePerShare still rules — only the timing of when you can act.

Phase	ERC-4626	ERC-7540
Enter	deposit() — mints shares now	requestDeposit() → (pending) → later deposit()/mint() claims the shares
Exit	redeem() — returns assets now	requestRedeem() → (pending) → later redeem()/withdraw() claims the assets
State you can query	—	pendingRedeemRequest() and claimableRedeemRequest() per controller

The lifecycle is pending → claimable → claimed. You submit a request (your shares are escrowed), the vault fulfils it when its strategy can free the capital (epoch settles, bridge confirms, T-bill matures), and only then does your request become claimable.

// ERC-7540 async redeem, stripped to the essentials.
// The vault escrows shares on request and settles them when capital is free.
interface IERC7540Redeem {
    // Step 1: queue it. Shares move into escrow now; assets come later.
    function requestRedeem(uint256 shares, address controller, address owner)
        external returns (uint256 requestId);

    // How much of my request has the vault made claimable so far?
    function claimableRedeemRequest(uint256 requestId, address controller)
        external view returns (uint256 claimableShares);

    // Step 2: once claimable (epoch settled), pull the assets out.
    function redeem(uint256 shares, address receiver, address controller)
        external returns (uint256 assets);
}

Takeaway: ERC-7540 doesn't change what a share is worth — it changes when you're allowed to trade it back. It's the honest interface for any strategy that can't promise instant liquidity. A DOV is "4626 accounting + option strategy in totalAssets + a 7540 withdrawal queue."

---

2. Crack #2 — a bet isn't a share → perps have no vault standard

Part 1 flagged this and it's worth stating plainly, because it's the cleanest example of "not everything is a vault."

An ERC-4626 share is pro-rata and fungible: every share is identical, and your claim is yourShares / totalSupply of one pool. A perp position is neither. It has a direction (long/short), a leverage, an entry price, a liquidation price, and margin that's specific to you. Two traders in "the same" ETH perp hold completely different instruments. There's nothing to tokenize as one fungible share, so there is no vault standard for a perp position — it's an entry in the exchange's margin ledger, not an ERC-20/4626 token.

Where 4626 does come back is the other side of the trade. The liquidity that stands as counterparty to every trader — GMX's GLP, Hyperliquid's HLP — is a pooled, fungible, appreciating share. That's Part 1's "perp LP vault" engine. So the rule is:

• The position (one trader's leveraged bet) → no standard, lives in the margin engine.
• The counterparty pool (the house) → ERC-4626, earns funding + fees − trader PnL.

Perps are the reminder that "is this an ERC-4626 vault?" has a real answer, and sometimes it's no.

---

3. Crack #3 — one appreciating token can't express the payoff → ERC-1155 conditional tokens

Now the genuinely different one. And to be precise about the framing: a prediction market is not a fourth yield engine. The three engines in Part 1 all answer the same question — "what makes totalAssets grow?" A prediction market has no growing pool and no yield. It's a payout instrument: you buy a claim on a future event, and at resolution it pays exactly 1 unit of collateral if you were right and 0 if you were wrong. Different question entirely — not "what grows the pool?" but "what resolves this, and to what?"

That difference forces a different token standard.

Why ERC-4626 can't do it, and ERC-1155 can

A market on "Will X happen?" needs two complementary tokens — a YES and a NO — that (a) are each independently fungible and tradeable, (b) share one lifecycle and settlement, and (c) obey the invariant YES + NO = 1 unit of collateral. A multi-outcome market ("who wins the election?") needs N such tokens. ERC-4626 gives you exactly one share per vault. It structurally can't represent a set of complementary outcome tokens.

ERC-1155 — the multi-token standard — is built for exactly this. One contract holds many token ids, each id being its own fungible balance, with batch transfers and shared logic. One deployment, N outcome tokens, cheap and atomic. That's why every serious prediction market sits on it.

The Polymarket stack

Polymarket is the canonical example. Its plumbing:

Layer	What it is
Collateral	USDC (on Polygon).
Token layer	Gnosis Conditional Tokens Framework (CTF) — an ERC-1155 contract that mints outcome tokens.
Resolution	UMA Optimistic Oracle (via the CTF adapter) reports which outcome won.
Trading	An off-chain CLOB (central limit order book) for price discovery, with on-chain settlement through the CTF Exchange contract — non-custodial, atomic swaps of outcome tokens ↔ USDC. (Early Polymarket used an LMSR AMM; the order book replaced it for tighter spreads.)

The mechanic — split, trade, redeem

1. Prepare the condition. Someone registers the question: conditionId = keccak256(oracle, questionId, outcomeSlotCount). For a binary market, outcomeSlotCount = 2.
2. Split collateral into a full set. Call splitPosition with 1 USDC → you receive 1 YES token and 1 NO token. Collateral is locked in the CTF contract; you now hold both legs. This is the primary mint — a market maker does it, then sells the legs they don't want.
3. Each leg is an ERC-1155 id. The id is derived deterministically: conditionId + an indexSet (which outcome) → a collectionId → positionId = keccak256(collateral, collectionId). That positionId is the ERC-1155 token id you hold and trade.
4. Trade on the order book. A YES token trades at a price ∈ (0, 1), and that price is the market's implied probability. Arbitrage pins YES + NO ≈ 1 USDC: if the pair trades below 1 you buy both and mergePositions back into 1 USDC risk-free; above 1 you split and sell.
5. Resolution. After the event, UMA's oracle reports payoutNumerators (e.g. [1, 0] — YES won). Holders call redeemPositions: each winning token burns for 1 USDC, each losing token for 0. The market is settled.

// Gnosis Conditional Tokens (ERC-1155), reduced to the three moves that matter.
interface IConditionalTokens /* is ERC1155 */ {
    // 1 USDC of collateral -> one token of EACH outcome in `partition` (e.g. [1,2] = YES,NO).
    // Locks collateral, mints the complementary set. YES + NO = 1 collateral, always.
    function splitPosition(
        IERC20 collateralToken,
        bytes32 parentCollectionId,
        bytes32 conditionId,
        uint256[] calldata partition,
        uint256 amount
    ) external;

    // The inverse: burn a full set back into collateral (this is the arb that pins YES+NO=1).
    function mergePositions(
        IERC20 collateralToken,
        bytes32 parentCollectionId,
        bytes32 conditionId,
        uint256[] calldata partition,
        uint256 amount
    ) external;

    // After the oracle calls reportPayouts, winners burn outcome tokens for collateral
    // pro-rata to payoutNumerators / payoutDenominator. Losing tokens redeem for 0.
    function redeemPositions(
        IERC20 collateralToken,
        bytes32 parentCollectionId,
        bytes32 conditionId,
        uint256[] calldata indexSets
    ) external;
}

The risk axis is completely different

A DOV's tail risk is short-volatility blow-ups; a lending vault's is bad debt. A prediction market has neither, because there's no strategy and no pool to impair. Its dominant risk is resolution/oracle risk:

• Ambiguous questions — a poorly-specified market where "what actually happened" is genuinely contested (the infamous edge cases where the event is clear but the market wording isn't).
• Oracle disputes — UMA proposals can be disputed and escalated to a token-holder vote (the DVM); resolution can be delayed or, in adversarial cases, contested by economic pressure on the voting token.
• Settlement latency — your capital is tied up until the oracle finalizes, which can be days after the real-world event.

There's no "APY" here and no pricePerShare. The only questions that matter are how is this resolved, by whom, and how cleanly is it worded.

---

4. Putting Part 1 and Part 2 together

Three token models, three questions a depositor/holder should actually ask:

	ERC-4626 vault	ERC-7540 async vault	ERC-1155 conditional tokens
Token you hold	One fungible appreciating share	Same share, async claim	N complementary outcome tokens (YES/NO/…)
What "price" means	totalAssets / totalSupply, unbounded up	Same	Implied probability ∈ (0,1); set sums to 1
Yield?	Yes — strategy grows totalAssets	Yes — same, capital just illiquid	No — it's a payout, not yield
Settlement trigger	Synchronous — redeem anytime	Request → claim when strategy frees capital	Redeem after oracle resolution
Dominant risk	Strategy tail (short-vol / bad debt / adverse selection)	Same + liquidity-timing	Resolution / oracle risk
Examples	Ribbon, Aave, Morpho, GLP, HLP	DOVs, RWA vaults, cross-chain vaults	Polymarket (Gnosis CTF + UMA)

The one-line upgrade to Part 1's mental model:

• ERC-4626 (and its async sibling 7540) is for "one share that appreciates" — ask what makes totalAssets go up, and what makes it crash.
• ERC-1155 conditional tokens are for "many binary claims that resolve" — ask what resolves this, and to what.
• And some things — a perp position — are neither, and that's a real answer too.

Same DeFi surface, three fundamentally different objects underneath. Knowing which one you're holding is the risk analysis.

---

Continued in Part 3 — When DeFi Stops Being DeFi. Parts 1 and 2 varied the shape of the claim but never left the permissionless model — the answer to "who can hold this?" was always anyone. Part 3 is the axis where that breaks: real-world assets carry the law of a jurisdiction, that law has to be enforced on-chain, and permissioned tokens (ERC-3643, permissioned 4626/7540 vaults) become the seam where DeFi rails meet TradFi rules.