How MAG7 works
Everything the contract does, why it does it that way, and what it deliberately refuses to do. If something here disagrees with the source, the source is right, and it is published.
What it is
$SEVEN is an ERC-20 token whose supply is a pro-rata claim on a basket of seven tokenized stocks that the contract physically holds. It is not a synthetic, not a perpetual, not a price feed wrapped in a token. If you own 1% of the supply, the vault is holding 1% of every one of those seven balances on your behalf, and you can take them out.
The seven are, NVIDIA, Microsoft, Apple, Alphabet, Amazon, Tesla and SpaceX, in their tokenized form on Robinhood Chain. The vault holds them at equal weight: every leg targets one seventh of net asset value.
The basket
Why equal weight and not market-cap weight. Cap weighting needs a current share count for each issuer. There is no honest way for a contract to know that: share counts change through buybacks, issuance and splits, and nothing on chain reports them. A contract that claimed to be cap-weighted would be trusting an off-chain number that someone has to keep updating, and could stop updating, or update wrongly.
Equal weight needs nothing but the vault's own balances and seven price feeds. Every claim this product makes about its own composition is checkable by anyone with an RPC endpoint. That is worth more than matching an index methodology nobody on chain can verify.
| Stock | Target | Venue | Token |
|---|---|---|---|
| NVDA NVIDIA | 14.28% | Uniswap v3 · 0.05% | 0xd060…9EEC |
| MSFT Microsoft | 14.28% | Uniswap v3 · 0.30% | 0xe932…2e74 |
| AAPL Apple | 14.28% | Uniswap v3 · 0.30% | 0xaF3D…93f9 |
| GOOGL Alphabet | 14.28% | Uniswap v4 · 0.30% | 0x2e08…4FE3 |
| AMZN Amazon | 14.28% | Uniswap v3 · 0.30% | 0x12f1…bF54 |
| TSLA Tesla | 14.28% | Uniswap v4 · 0.30% | 0x322F…3b2d |
| SPCX SpaceX | 14.28% | Uniswap v3 · 0.05% | 0x4a0E…5eEa |
The basket is fixed at deployment. There is no function to add, remove or swap a constituent. If the seven should ever change, that is a new vault and a migration people opt into, not a transaction someone can send against the one holding your money.
Minting
mint(usdgIn, minShares). You approve USDG, call it, and get $SEVEN. In order:
- Checks. Minting is not paused, the amount is inside the per-transaction cap, and every one of the seven feeds has published recently. If any feed is stale the call reverts here.
- Fee. Nothing comes off the top. Trade fees are charged on exit and split 80/20 between the backing contract and the treasury.
- Split. What is left is divided into seven equal slices. The integer-division remainder, at most six millionths of a dollar, rides along with the first leg, so the vault is never left holding stray USDG that NAV cannot see.
- Seven swaps. Each slice is swapped to its stock through the DEX router. Each swap carries a
minOutderived from that leg's own Chainlink price, less the router fee and 1.5% of slippage tolerance. Never zero. - Pricing. The vault reads its NAV before the swaps and after, and mints you shares for the difference, the value that actually arrived.
Worked example
A $700 mint, with all seven pools filling exactly at their feed price (the unit tests assert this to the wei):
700.000000 USDG in
- 0.000000 no mint fee - entry is free
= 700.000000 split 7 ways → 100.000000 per leg
- 1.000000 router's 1% on each leg
= 99.000000 reaches each pool
7 legs × $99.00 = $693.00 of stock acquired
shares minted = 693.00 MAG7 (first mint: 1 share = $1.0000)On the real pools this lands slightly lower, the mainnet-fork rehearsal measured each leg filling 8 to 57 basis points away from its feed, which is where the 150 bp slippage guard comes from.
Redeeming
There are two exits, and the second one is the important one.
redeem(shares, minUsdgOut), out to USDG
The vault works out your pro-rata slice of each of the seven balances, burns your shares, sells each slice through the router, takes 1% off the proceeds, and sends you the rest. Requires fresh feeds, same as minting.
redeemInKind(shares), out to the stocks themselves
Same claim, paid in NVDA, MSFT, AAPL, GOOGL, AMZN, TSLA and SPCX rather than in USDG. The 1% fee is charged in kind at the same rate, so this is an exit and not a way to dodge the fee.
This path reads no price feed and calls no router. It is pure arithmetic over balances. That means it still works if every Chainlink feed has stopped, if a pool has been drained, or if the router has been bricked entirely.
redeemInKind is what makes the trade acceptable: whatever else breaks, holders can always walk out with the inventory.In-kind creation
mint() buys each leg through a DEX pool, so its capacity is whatever those pools will sell. mintInKind() takes the basket itself: you deliver the seven stocks and receive shares. No swaps, no router, no oracle.
Why it exists
This is how ETF creation actually works, and here it is the difference between a small product and a large one. There are roughly twenty dollars of USDG on this chain for every dollar of tokenized stock, and only a fraction of that stock sits in pools. Buying through them consumes the very depth the next mint needs, so a vault that can only be entered with cash is capped by other people's liquidity. Delivering the basket is capped by how much stock exists, which is two orders of magnitude larger and grows with issuance rather than shrinking with use.
Pro-rata, not any basket
You name the shares you want and deliver the vault's current composition. Choosing the mix yourself would let someone pay entirely in whichever leg is cheapest to acquire, and rebalancing is deliberately capped at $200 per leg per day, so a large skew could not be corrected for weeks.
Requirements round up
Rounding down would let a caller mint shares while delivering fractionally less than their slice, diluting every existing holder by a wei per leg per call. previewMintInKind() quotes what a given share count needs, and maxAmounts bounds it, because the streaming fee moves supply between the quote and the transaction.
Rebalancing
Stocks do not move together, so the weights drift. rebalance() sells a slice of the most overweight leg and buys the most underweight one. It is permissionless, anyone can call it, which is safe only because three independent limits bound what any single call can do:
- A band. Nothing happens unless a leg is more than ±20% away from its one-seventh target. Below that the call reverts.
- A notional cap. At most $200 of value moves per call.
- A cooldown. Both legs it touches are frozen for 24 hours afterwards.
Both swaps pay the router's 1% fee, so a full-size rebalance costs the vault roughly 2% of $200 - about $4. That is the deliberate ceiling on what rebalancing can cost per leg per day, and it is what makes poking thin pools with a stale feed unprofitable rather than merely discouraged.
A keeper calls it once each weekday afternoon, while US markets are open and the feeds are awake. If the keeper stops, nothing breaks, the function stays open to everyone.
Fees
| Fee | Rate | When |
|---|---|---|
| Mint | 0 | Free. Entry costs only the router's fee on the swaps |
| Redeem | 0.20% | Off the proceeds, in USDG or in kind |
| Streaming | 1.00% / yr | Accrued by the second, minted to the treasury as shares |
| Router | 1.00% | On the input of each swap the vault makes |
| Transfer | 0 | Never. There is no transfer tax. |
Why the exit fee is small
It is the tracking error. Nothing in the contract forces the market price of a share to NAV; what forces it is that anyone can create at NAV and anyone can redeem at NAV less this fee. Above NAV the arbitrage is to create and sell, which costs gas. Below NAV it is to buy and redeem, which costs the exit fee. So the fee is exactly how far a share may drift from the seven stocks before anyone can profitably close the gap. At 0.20% the no-arb band is about NAV minus a quarter of a percent. At 5% it would be five percent, and the token would follow the basket at a wandering discount rather than following it.
Where the fees go
80% goes to the buyback address, which is the collection's backing contract, so the protocol's revenue compounds into the NFT floor rather than sitting idle. The remaining 20% goes to the treasury.
The streaming fee is dilution, not a withdrawal
It never touches the basket. On every interaction the vault mints itself a small number of new shares to the treasury, proportional to supply and to the time since it last did so. Your share count does not change; the total does, so your fraction of the vault shrinks very slightly. That is why the fee needs nobody to call anything and cannot be outrun by not trading.
What a round trip actually costs
In and straight back out is the router's 1% each way plus the 0.20% exit fee, so about 2.2% before pool costs. Taking the seven stocks instead of USDG skips the router on the way out and costs the 0.20% alone, which is why the in-kind exit is the cheap one as well as the safe one.
Safety rails
The pools underneath hold $10,000–50,000 each. Every limit below exists because of that number.
| Rail | Setting | What it prevents |
|---|---|---|
| Per-transaction mint cap | $500 | A mint large enough to move the pools it is buying into |
| Per-leg slippage guard | 150 bp off the feed | A drained or repriced pool silently eating the deposit |
| Feed staleness bound | 6 hours | Trading against a price nobody is updating |
| Rebalance band | ±20% of target | Paying two router fees to chase noise |
| Rebalance notional | $200 per call | A large forced trade through thin liquidity |
| Rebalance cooldown | 24h per leg | Repeat calls compounding into a large one |
| Owner pause | Mint only | Nothing, the exit has no switch by design |
| Rescue timelock | 3 days, announced | A surprise withdrawal of anything |
Feed staleness deserves a note. Tokenized stock feeds only publish while US equity markets are open, so for most of any given week they are stale by design. During those hours the vault refuses to mint or redeem for USDG. redeemInKind stays open the whole time, because it does not consult a price to be right.
Who may hold and move $SEVEN
$SEVEN answers two separate questions on every transfer, and keeping them separate is what lets the protocol run one canonical market.
Who may hold
Both ends of a transfer must be a wallet or an approved contract. This is what stops an unauthorised pool being funded. It cannot stop one being created - creating a Uniswap pool never touches the token, and initialising it only sets a price - but an unauthorised pool can never receive a single $SEVEN, so it stays an empty shell.
The holder list is add-only. There is no removal function anywhere in the contract, and a test asserts none can be added. An allowlist you can revoke is a freeze switch: the owner could strand a holder or stop them selling. Because entries can only be added, the worst the owner can do is decline to approve something new.
Who may move
A contract moving somebody else's $SEVEN must be approved separately. Without this the holder gate leaks: adding liquidity to an approved pool is a transfer from a wallet to that pool, so both ends pass, and any third party could supply the canonical pool and take a share of the fees. Gating the operator means a swap router can be approved to move tokens without a position manager being able to add liquidity. Swapping open, liquidity provision closed.
This list is revocable, and the asymmetry is deliberate. Revoking a holder would strand them. Revoking an operator cannot: you can always transfer directly, because then you are the sender, and you can always redeem, because redemption burns from the caller. The freeze vector that forces the holder list to be add-only does not exist here, while the need to drop a compromised router does.
The collection
MAG7 Genesis is 7,777 PFPs, each holding $SEVEN shares that are redeemable at any time. The art is a wrapper around a balance, not a claim on a treasury somebody has to remember to fund.
What is inside one
- Seed. 80% of the mint price, tagged to that exact token id and converted into $SEVEN shares belonging to it alone. The split is fixed at deployment with no setter.
- Shared. 5% secondary royalties and 80% of the vault's exit fee, converted and distributed across every token still outstanding by weight.
- Loaded. Anything you choose to deposit later. It stays yours and stays redeemable.
Loading
You can add $SEVEN to a token at any time. The deposit stays yours and stays redeemable: it raises that token's floor one for one and its weight in the shared pool, lowers nobody else's floor, and takes supply out of circulation. Weight is the square root of total backing, so depositing a hundred times more earns ten times the weight rather than a hundred - commitment is paid for without letting one token own the stream.
Redemption raises the floor for everyone else
Burning a token pays out its backing less 5%, and the difference stays behind. That fee is the small part. The large part is that a burn removes a claimant permanently, so every future royalty divides among fewer tokens. Per-NFT income rises as holders leave.
Liquidity is locked and its fees are not
Protocol-owned liquidity sits in a contract that holds its position directly rather than through a position manager, so there is no position NFT to move and no manager any third party could use to supply the same pool. Principal is locked behind a deadline that only ever moves forward; collectFees() is permissionless and never gated, with the destination fixed at deployment so a caller chooses when and never where.
What the owner can and cannot do
Being specific about this matters more than any assurance about intent. The owner key is a two-stepOwnable2Step role.
Can
- Pause minting.
- Change mint and redeem fees, capped at 2% each. Change the streaming fee, capped at 2%/yr.
- Change the per-transaction mint cap, the slippage tolerance (max 5%), and the rebalance band, notional and cooldown, all within hard-coded bounds.
- Change the staleness bound between 10 minutes and 7 days, or override it entirely, for a feed that has genuinely stopped publishing, where the alternative is a vault nobody can use. Every change emits an event.
- Change the treasury and buyback addresses.
- Announce a rescue of a non-constituent token and, three days later, execute it.
Cannot
- Cannot pause redemption. There is no function. A vault whose owner can close the exit is not a vault.
- Cannot touch the basket. The rescue hatch reverts on any of the seven constituent tokens and on the share token itself. There is no path from the owner key to the holdings.
- Cannot change the router. It is immutable. The vault grants it approvals, so a settable router would be a drain switch.
- Cannot change the basket. No add, no remove, no substitute.
- Cannot mint shares to anyone. Shares come from deposits and from the streaming fee accrual, nothing else.
- Cannot upgrade the contract. It is not a proxy. The code that is deployed is the code, forever.
Market price vs NAV
Once $SEVEN trades in a pool, its market price and its NAV are two different numbers. Mint and redeem are what tie them together: if the market price rises far enough above NAV, minting at NAV and selling is profitable, and that pushes the price back down. If it falls far enough below, buying and redeeming is profitable, and that pushes it back up.
The word doing the work is far enough. With free entry and a 0.20% exit, arbitrage becomes worth doing after roughly a 2–3% gap. So expect the market price to wander a few percent either side of NAV, and treat that as normal rather than as a fault. The published NAV on the holdings page is always the honest number.
redeemInKind makes the arbitrage cleaner than it would otherwise be: an arbitrageur can take the underlying directly and unwind it wherever they like, rather than being forced through the vault's own router path.
Risks
Read this part twice.
- Smart contract risk. The contracts are tested, 42 unit tests asserting the arithmetic to the wei, plus a nine-test rehearsal against a mainnet fork with the real tokens, feeds, pools and router. They have not been through a third-party audit. Assume bugs are possible.
- Oracle risk. NAV is only as good as seven Chainlink feeds. A wrong feed produces a wrong NAV, and the staleness check catches a feed that has stopped, not one that is publishing a bad number.
- Liquidity risk. The underlying pools are small. Large mints and redemptions move them, which is why the mint cap exists, but the cap limits damage, it does not remove it.
- Underlying asset risk. Each leg is a tokenized stock issued by a third party. It carries that issuer's counterparty, custody and pause risk, none of which this vault controls or can insure against. The real tokens have pause switches. If one is paused, that leg cannot be traded.
- Market risk. It is seven technology names. They are correlated, they are concentrated in one sector, and equal weighting does not diversify away a sector-wide drawdown.
- Fee drag. 1% a year, plus roughly 2.2% for a round trip.
- Regulatory risk. Tokenized equities are a young and unsettled area.
Contracts
Robinhood Chain mainnet, chain ID 4663. Everything is verified on Blockscout.
| Contract | Address | What it does |
|---|---|---|
| DEX router | 0x32c9…854e | Executes every swap; takes 1% of the input |
| USDG | 0x5fc5…d168 | The 6-decimal quote asset for mint and redeem |
| Buyback reserve | 0x50e7…99fc | Receives 50% of fees and holds the reserve asset |
| Treasury | 0x81c6…BC20 | Receives 50% of fees and the streaming fee |
Source, tests and deployment scripts: github.com/btcmachineordinals/mag7. Live balances: the holdings page.
