Pool Composition

A deployment does not have to be one pool or one pool per pair. Assets are grouped into a small number of cores, each holding a set of legs that share a reserve, a curve family and a risk configuration. This page explains why a deployment is cut that way and records the roster each core currently carries.

Why several cores rather than one

Nothing in the protocol requires more than one pool. The grouping is an economic choice, and it turns on three things:

• A shared curve has to fit every leg it serves. A core’s legs are priced by one shape scaled per asset. Assets with a similar depth and volatility profile take that scaling well; a stablecoin and a single-name equity in the same core would force a shape that suits neither, since the width that keeps a $1 leg tight is nowhere near the width an equity needs.
• Correlated legs make inventory mean-revert. Within a core, flow that drains one leg tends to arrive against another, so the skew that prices the imbalance also gets paid to undo it. Assets with no relationship simply accumulate one-sided inventory, and the pool ends up holding whatever the market wanted to sell.
• Isolation bounds a failure. A depeg, a dead feed or a halted asset stops the core it belongs to. Splitting by asset class means a stablecoin losing its peg does not take the equity book down with it.

Cores are cut so that assets inside one are alike enough to share a curve and correlated enough to net against each other, and different enough between cores that a problem stays where it started. That is a configuration decision, and composition is expected to change as rosters grow, as an asset’s behaviour diverges from the core it was placed in, or as a new class justifies its own core.

The current deployment is cut into four: stable, FX, crypto and stocks. Every asset in it anchors directly to the base, so each core is presently a flat star on a USDC base, routed through the mintable faucet twin USDC.b. That is this deployment’s shape, not the protocol’s: the anchor tree admits depth up to 4, and an asset may anchor to any correlated parent (Anchor Path Pricing).

Rosters below track the deployment manifests; authoritative per-pool membership is the receipt record each deploy ceremony writes per (pool, leg). Pool addresses: Contract Addresses. Per-asset metadata: Asset Registry.

1. The cores

All four are deployed and quoting. Current balances are not recorded here: they change by the block, and GET /v1/assets/pools plus GET /v1/liquidity report them live.

Roster symbols are upper-case and dot-free; the .b suffix is ERC-20 display metadata carried by the faucet twins (Asset Registry).

2. Stable core

All five legs are $1-pegged and run the depeg-band guards (Depeg Halt). Risk parameters derive from measured density; shipped values are generated from the deployment manifests, not hand-tuned.

3. Crypto core

Feed mapping collapses wrapper variants onto one mark:

EURC is a member of both the crypto core and the FX core - the only asset that spans two pools.

4. FX core

Non-USD fiat stablecoins, so unlike the stable core these are not $1-pegged: each marks against its own currency, and every non-base leg carries an independent breaker feed on refOracle (EURC-USDC, QCAD-USDC, AUDF-USDC, JPYC-USDC, KRW1-USDC). JPYC and KRW1 sit far from parity, so legs are sized from the real ceremony mark, never a peg default.

5. Stocks core

The ten stock legs plus the USDC base are bound on the oracle, the mocks are minted, and the core is funded and quoting.

It was listed before it was funded, and deliberately so. At ceremony time the measured equity tape was far too short to clear the dispersion-fit gate (every servable constituent spanned well under the 10 days a fit requires), so no fitted fee floor existed to ship with. The rule that produced that delay is the one worth remembering: fee floors are fitted from measured density and ship with the listing, never as class defaults, so a leg waits for tape rather than borrowing a neighbour’s parameters. Selection criteria for the ten names: Asset Registry.

6. Faucet twins

USDC.b sits on all four pools; EURC.b on FX and crypto. Neither owns a feed of its own - each rides one the keeper already services, which leaves USDC.b with a small permanent basis against native USDC and means a USDT depeg passes straight through to USDC.b without tripping its band (Asset Registry). Membership authority is always the ceremony’s per-pool receipts, not any roster summary - including the table above.

7. Future work: yield-bearing pooling

No NAV-accruing asset is listed today. A NAV wrapper’s fair value is its share price, which drifts upward by design, so bands sized around a $1 peg would fire on ordinary accrual. Planned for a later phase as a dedicated cohort with its own class, never inside the stable core: sUSDS, sUSDe, syrupUSDC, syrupUSDT, USYC. Requirements: NAV-aware marks (share price, not $1 peg) and non-peg parametrization (haircutSuppressorBps = 0, ${\kappa }_{\mathrm{c}\mathrm{o}\mathrm{v}}>0$ on every listed asset including the hub; see Parametrization).

8. See also

• Asset Registry
• Pool Deployment & Curation
• Oracle Price-Push Security