Fixed-recipe ETFs,
backed by the tokens they hold.

4.1 Purpose

Holding a diversified position in Stock Tokens means holding several ERC-20s. A basket ETF folds that set into one token with a fixed, public recipe, so a portfolio can be transferred, quoted and held as a single asset while remaining fully backed by the underlying tokens at every moment.

The design is deliberately minimal. A basket contract stores an ordered list of constituent addresses and an amount of each per unit. It can do exactly two things with those tokens: pull them in on mint and pay them out on redeem. It never reads a price, never trades, never charges, and cannot be changed after deployment.

4.2 Recipe registration

BasketFactory.create(name, symbol, tokens[], unitsPerBasket[]) is callable by any address. The factory validates the recipe, deploys a BasketToken with CREATE2 using the recipe hash as salt, and records it. What the creator chooses and what is fixed:

The interface derives unitsPerBasket from percentage weights and the marks it observes, sized so that one unit is worth a reference notional at those marks (default 100 USD). Those prices exist only in the browser; the chain sees the resulting integer units and nothing else.

4.3 Mint and redeem

Both operations are exact and symmetric up to rounding. There is no fee, no slippage and no dependency on any price.

• Mint. mint(baskets, receiver) computes ceil(units_i × baskets / 1e18) for each constituent, pulls that amount from the caller with safeTransferFrom, verifies the vault balance rose by at least that amount, then mints baskets units to receiver. A short deposit — fee-on-transfer, rebasing, or a partial fill — reverts the whole call.
• Redeem. redeem(baskets, receiver) burns baskets from the caller, then pays floor(units_i × baskets / 1e18) of each constituent to receiver. The burn happens before any transfer.

4.4 Backing invariant

For every constituent i and at every block:

balanceOf(basket, token_i)  ≥  unitsPerBasket_i × totalSupply / 1e18

The inequality follows from the rounding direction alone. Every mint deposits at least the pro-rata amount (rounded up, and verified by balance delta), and every redeem pays out at most the pro-rata amount (rounded down). No other code path moves constituents: there is no admin withdrawal, no fee sweep, no rebalancing and no swap. The vault can only ever hold at least what its supply claims.

The basket never reads uiMultiplier() or any price. It holds raw token balances; whatever an issuer multiplier means for a direct holder of a Stock Token means the same for the balances the basket holds. The recipe itself is immutable — a corporate action does not change unitsPerBasket.

4.5 The registered Mag 7 basket

A Mag 7 basket is registered on the factory. The interface's Mag 7 preset is six constituents at equal weight: AAPL, NVDA, TSLA, MSFT, AMZN, GOOGL; SPY and QQQ are excluded from the preset, and META has no Robinhood Chain representation in the registry the interface mints from. The exact unitsPerBasket of any deployed basket are chain state — read them from constituents() on the basket or from /api/baskets; they are not reproduced here because they depend on the marks observed at registration.

Constituents the interface can mint from, with their Robinhood Chain addresses:

The factory itself accepts any ERC-20 that reports decimals(); this list is the interface's, not the contract's.

4.6 Trading

A basket unit is an ordinary ERC-20. It can be transferred, held in any wallet, and traded wherever a market for it exists. The protocol deploys no pool, no order book and no market maker for baskets, and guarantees no venue or liquidity.

Reference value is arithmetic: Σ units_i × price_i / 1e18. Because anyone can mint at that value and redeem for it, any market price away from it is an opportunity for whoever is willing to do the mint or redeem — but the contracts do not perform that arbitrage, and no one is obliged to.

4.7 Risks

• Issuer controls on constituents. Stock Tokens are issuer-controlled instruments that can be paused, blocked, burned or upgraded. A constituent that refuses transfers blocks the whole mint or redeem — the basket will not pay out an incomplete recipe. A redeem to a blocked receiver reverts; redeem to another address. An upgrade that changes transfer semantics (a fee, a rebase) makes mints revert with ShortDeposit.
• Fixed units, drifting weights. The recipe is a quantity of each token, not a percentage. As prices move, the value share of each constituent moves with them. There is no rebalancing.
• Names carry no authority. Anyone can deploy a basket named anything. Verify the recipe — constituents() — and the factory's isBasket() before treating a token as a StockYield basket.
• No venue. Liquidity for basket units, if any, is external. The only guaranteed exit is redemption for the underlying tokens.
• Immutability. A basket cannot be paused, migrated or corrected. A recipe that includes a token later frozen by its issuer stays frozen with it.

4.8 Key parameters