Parity Engine

One canonical market, settled on two chains.

Architectures evaluated

A · Canonical stateChosen

One curve holds the only price. Both chains submit trades that are sequenced and settled against it. Parity holds by construction; the cost is cross-chain latency on the non-home chain.

B · Coordinated curvesRejected

Two curves synced by async messages can't stop both chains filling against the same stale state without locking inventory. That means double-spend risk or a frozen market.

C · Arbitrage-linked poolsRejected

The spread is always non-zero and set by bridge latency and arbitrage capital. That breaks the one-price promise and needs a funded market maker.

Guarantees enforced in code

· All amounts are integers; rounding always favours the pool. The product of reserves can never decrease.
· Unissued + Solana + HyperEVM + pending + burned always equals the canonical maximum supply.
· Cross-chain messages carry unique nonces; duplicates and replays are rejected.
· Market cap counts each unit once, whichever chain it sits on.

Honest limitations

· The reference price is shared. Your execution price depends on trade size (price impact) and on trades sequenced ahead of yours.
· Quotes expire after 15 seconds and settle against the current state. If the price moved past your slippage, the trade is rejected rather than filled at a stale price.
· Trades on the non-home chain wait for cross-chain message finality before they settle.
· Trading pauses automatically if a chain's sync lags more than 60 seconds or reserves don't reconcile.
· Native HyperCore order-book listing needs a HIP-1 ticker auction. It is a separate, paid, opt-in step.
· Contracts are unaudited and not deployed. Nothing on this site moves real funds today.