How It Works
From the moment you compose an order to the moment tokens land in your wallet — here's exactly what happens and why each step matters.
The full lifecycle
You compose your order in the app
You pick the token you want to sell, the token you want to receive, the amount, and a minimum output you're willing to accept. You also set a deadline — if the order isn't filled by then, it expires and nothing moves.
You choose a privacy level: whether solvers can see your full order, just the direction, or nothing at all until the batch closes.
Your browser encrypts the order
Before anything leaves your device, the SDK encrypts the order payload using AES-256-GCM with a one-time session key. That session key itself is encrypted with the gateway's public key using X25519 key exchange. The result is a ciphertext that only the gateway can decrypt — and only after the batch closes.
Your actual amounts never travel in plain text. The gateway stores an encrypted blob.
Your wallet signs a commitment on Starknet
Your wallet sends a short transaction to the IntentRegistry contract on Starknet. This transaction contains a fingerprint of your order (a Pedersen hash), not the order itself.
This is the binding step. Once this transaction confirms, the order exists on-chain and neither you nor the gateway can change it retroactively. Your funds aren't moved yet — only your intent is recorded.
Orders collect in a 30-second batch window
The coordinator tracks time against a fixed schedule anchored to the genesis timestamp. When the current window closes, it announces the batch on-chain, sealing which orders belong to it. Orders that arrived after the cutoff roll into the next window.
Solvers compete to fill the batch
Once the batch is announced, solvers receive the decrypted orders from the gateway. Each solver independently computes a solution — routing through DEXes, filling from inventory, or matching orders against each other — and submits it to the BatchAuction contract.
The contract scores each solution. The score is a weighted mix of: how much output traders receive, how low the solver's fees are, and the solver's historical track record. The best score wins.
The winning solution settles on-chain
The BatchSettlement contract verifies the winning solution against each order's on-chain commitment. If every fill is valid — amounts match, deadlines haven't passed, signatures check out — the token transfers execute atomically in a single transaction.
Either the entire batch settles or none of it does. There's no state where some orders fill and others don't.
Your app shows the result
The observer watches Starknet for settlement events. When it sees the batch settle, it notifies the gateway, which marks your order as settled. The dashboard updates. You can verify the transaction on Voyager at any time.
Batch windows are fixed-schedule, not per-order
Orders don't trigger batch boundaries. The coordinator opens and closes windows on a fixed 30-second clock. Your order sits in the current open window until it closes — up to 30 seconds from submission.What happens when a batch fails
Batches can fail for a few reasons: no solver submitted a valid solution within the auction window, the settlement transaction reverted, or a proof verification failed.
When this happens, no funds move. The orders inside the failed batch are automatically requeued into the next open batch window. You don't need to resubmit anything.
The five contracts
Stores on-chain commitments. Your wallet talks to this contract when you place an order.
Runs the solver auction. Receives solver solutions, scores them, declares a winner.
Executes the winning solution. Transfers tokens, verifies fills match commitments.
Manages solver collateral. Solvers deposit a bond here; bad behaviour gets slashed from it.
Whitelist of tokens that can be traded. New tokens require admin approval.
See Deployed Addresses for all contract addresses on Sepolia.