The peg & market maker

The band: a leash, not a cage

Each dual coin's two prices are allowed to trade anywhere within ±5% of each other. Inside that band, the protocol does nothing at all — Solana trades at Solana speed, Base trades at Base depth, and small differences are just the two crowds disagreeing for a few minutes. That disagreement is healthy; it's what arbitrage traders eat.

The band is what makes a dual coin one coin rather than two coins with the same name. Without it, the two listings would drift apart permanently — the exact failure you see when teams launch on one chain and bridge a wrapped copy to another.

Reading the gap

Every block on each chain, keepers compute the gap between the two venue prices, each expressed in USD via that chain's native oracle:

A positive gap means the Solana side is rich; a negative gap means the Base side is. The sign decides which direction the market maker trades.

A correction cycle, step by step

Say a whale market-buys on Solana and pushes the gap to +11%. Here's the full sequence, exactly as the simulation on the home page plays it:

• 1 · Detect. Keepers see |gap| > 5% and arm the correction engine for that coin.
• 2 · Sell the rich side. The vault sells coin inventory on Solana into the inflated bid — capturing the premium as spread.
• 3 · Buy the cheap side. Simultaneously, the vault's Base float buys coin on Base at the discount.
• 4 · Converge partially. Each cycle closes 18% of the gap, not all of it. A +11% gap takes roughly 5 cycles (~a few minutes) to re-enter the band.
• 5 · Rebalance later. Inventory drift between chains is squared up through the bridge in batches, on a schedule — never inside the correction itself.

Why only 18% per cycle?

Instant convergence would make the MM a free lunch: snipers could sandwich its predictable full-size orders, and a single oracle misprint would make it dump an entire inventory at the wrong price. Partial steps cap the damage of any one bad cycle, cost attackers more than they can extract, and still close gaps in minutes rather than hours.

The MMVault

Every dual coin gets a dedicated vault at genesis, seeded from the launch deposit. It holds three things:

The vault is self-feeding: 15% of all protocol revenue flows back into it (see Fees), so heavy correction activity — the thing that drains it — is also the thing that refills it. Vault balances are public, per coin, on-chain.

Bridging & batching

Corrections themselves never wait for a bridge — both legs execute from local inventory on each chain. The bridge only enters the picture afterwards, to square up inventory drift, and it does so in batches on a rolling schedule.

• Traders never bridge. You buy on the chain you live on. Period.
• Your tokens never wrap. Both deployments are native; the vault moves its own float, not user assets.
• Congestion degrades gracefully. If the bridge slows, local inventory thins and the effective band widens until batches land — corrections continue, just smaller.

Band states

Every dual coin is always in exactly one of four states, shown live on its coin page:

Parameters

Template note: these are the reference parameters this concept ships with — tune them to your deployment and audit before publishing them as fact.

What can break (honestly)

Every state transition is emitted on-chain and mirrored to the coin's page in real time. The protocol's position is simple: when the mechanism strains, it says so in public, immediately.

Questions traders actually ask