How Signet Works
The problem Signet solves
Moving value across blockchain domains is one of the unsolved problems of DeFi infrastructure. The dominant solution — bridging — requires users to lock assets on a source chain, wait for a message to be relayed and verified on a destination chain, and then unlock assets on the other side. Bridges have been exploited for billions of dollars, are slow, require trust in relayers or oracles, and produce fragmented liquidity across dozens of canonical and non-canonical bridge contracts.
Signet takes a different approach. Instead of moving assets across chains by relaying messages, Signet settles intents on a shared settlement layer. A user declares what they want — inputs on one domain, outputs on another — and a filler delivers the output assets and claims the input assets as reimbursement. There is no bridge contract, no message relay, and no oracle. Settlement happens on the Signet rollup, which maintains a shared view of which intents have been filled.
The bridge security problem
Bridges are consistently the most exploited component of DeFi infrastructure. The attack surface is large: the bridge contract holds large locked asset pools; the relay mechanism is often permissioned or centralized; the oracle that verifies cross-chain events is an off-chain system with its own trust assumptions. Each of these is a target. When a bridge exploit succeeds, the impact is typically total — the entire locked pool is drained.
In the intent-based model, there is no locked pool. The filler's capital is the system's liquidity, and it is distributed across the filler's own wallet addresses rather than concentrated in a single bridge contract. An exploit of the settlement layer can, in the worst case, cause a filler to lose a single pending fill — not the entire liquidity base.
Settlement without relay
The key insight of Signet is that cross-domain settlement does not require a message passing between chains. It requires a shared record of what has happened. The Signet rollup maintains that record. When a filler delivers output assets on a destination domain, they prove it to the Signet rollup. The rollup then authorizes the filler to claim the input assets on the source domain. The domains never communicate directly; they both communicate with Signet.
Signet Orders
A Signet Order is the core data structure of the protocol. It is an intent struct — a signed declaration of what the user wants to exchange, under what conditions, and within what timeframe. Orders are not transactions; they are offers that fillers can accept.
The order struct
inputs — the assets the user is willing to give. Each input specifies a token address, a chain ID, and an amount. Inputs are locked when the order is submitted to the rollup. The filler receives the inputs as reimbursement after a successful fill.
outputs — the assets the user wants to receive. Each output specifies a token address, a chain ID, a minimum amount, and a recipient address. The filler must deliver at least the minimum amount to the recipient on the specified chain for the fill to be valid. The spread between the input value and the output minimum is the filler's economic incentive.
deadline — the block timestamp by which the fill must be proven to the Signet rollup. If the deadline passes without a valid fill proof, the order expires and the user's inputs are returned. The deadline gives users a guaranteed worst-case outcome: even if no filler fills the order, they get their assets back.
filler — an optional field specifying a designated filler address. If set, only that address can fill the order. Used for private or exclusive fills negotiated off-chain. If left unset (the default), any filler can compete to fill the order.
Order signing and submission
Orders are signed with the user's private key over the EIP-712 structured data hash of the order struct. The signature commits the user to the exact terms of the order — inputs, outputs, and deadline. The signed order is then submitted to the Signet rollup, where a contract verifies the signature, locks the input assets from the user's balance, and records the order as pending.
Partial fills
Orders can be specified as partially fillable, allowing a filler to deliver a fraction of the output and claim a proportional fraction of the inputs. This is useful for large orders where no single filler has sufficient capital to fill the entire amount in one transaction. Partial fills are tracked at the rollup level; the order remains open until fully filled or expired.
The orderbook
Submitted orders are visible to all fillers through the Signet orderbook — a public data layer that indexes pending orders and makes them discoverable. The orderbook is not an on-chain contract; it is an off-chain aggregation layer built on top of the rollup's transaction data.
Order broadcast
When a user submits an order to the Signet rollup, the submission transaction is publicly visible in the rollup's transaction feed. Orderbook indexers watch for new order submission transactions, decode the order struct from the calldata, and add the order to the indexed orderbook. Any filler running an orderbook indexer sees new orders within seconds of submission.
Users can also broadcast orders to fillers through off-chain channels — direct RFQ (request for quote) APIs, private communication channels with specific fillers, or public orderbook APIs. These off-chain broadcasts allow fillers to begin preparing fill transactions before the on-chain submission is confirmed, reducing fill latency.
Orderbook structure
The orderbook indexes orders by their status: pending (submitted, not yet filled), filled (fill proof submitted), expired (deadline passed without fill), and cancelled (user cancelled before fill). Fillers query the pending index to find fillable orders, filtering by asset pair, chain pair, amount range, and deadline proximity.
Price discovery
The orderbook does not perform price discovery itself — orders specify minimum output amounts set by the user. Price discovery happens through filler competition: fillers monitor the orderbook alongside external price feeds, calculate whether an order is profitable at current market prices, and fill orders where the spread between the input value and the output minimum exceeds their execution cost. Orders with generous output minimums fill quickly; orders with tight minimums may wait for favorable market conditions or expire.
Filling mechanics
Filling an order is a three-step process: evaluate profitability, execute the fill on the destination domain, and submit the fill proof to the Signet rollup to claim the inputs.
Profitability check
Before filling, the filler calculates whether the spread between input value and output cost covers their execution costs and desired profit margin. The inputs are denominated in one or more tokens on one or more chains; the outputs are denominated in different tokens on different chains. The filler needs to price both sides at current market rates, account for their execution costs (gas on the destination chain, bridging cost if they need to rebalance, slippage from sourcing the output tokens), and verify that the order deadline gives them enough time to submit the fill proof.
Fillers that are well-capitalized and have native inventory on multiple chains can fill immediately without sourcing the output assets from a DEX. This gives them a cost advantage over fillers that need to swap to acquire the output tokens. Capital efficiency is the primary competitive advantage in the filler market.
Fill execution
The filler submits a transaction on the destination chain that transfers the output tokens to the recipient address specified in the order. This transaction is a standard ERC-20 transfer — there is no special fill contract on the destination chain. The transaction hash, block number, and a cryptographic proof that the transaction was included in the chain's state are what the filler needs to claim their reimbursement from the rollup.
Fill proof and rebate
After the fill transaction is confirmed on the destination chain, the filler constructs a fill proof — a combination of the order hash, the fill transaction receipt, and a cryptographic proof of the transaction's inclusion in the destination chain's state. The filler submits this proof to the Signet rollup in a claim transaction.
The rollup contract verifies the fill proof: checks the order exists, verifies the fill transaction matches the order's output requirements (correct token, correct amount, correct recipient), and verifies that the fill occurred before the deadline. If the proof is valid, the contract releases the input assets to the filler's address. The filler has been reimbursed; the order is marked as filled.
The rollup layer
Signet settles on Zenith, a purpose-built rollup that provides the shared settlement layer for cross-domain intent execution. Understanding Zenith's design explains why Signet works the way it does and how it achieves security guarantees that traditional bridges cannot.
Zenith's design
Zenith is an optimistic rollup anchored to Ethereum. Transactions are posted as calldata to Ethereum mainnet; anyone can reconstruct the full Zenith state from the Ethereum data. The security model is the same as other optimistic rollups: a fraud proof window during which any observer can challenge a fraudulent state transition. After the fraud proof window, the state transition is considered final.
Zenith operates with a permissioned sequencer — a single entity that determines transaction ordering within each block. This is a deliberate design choice for a settlement layer: permissioned sequencing provides predictable transaction ordering and eliminates MEV from within the rollup's own block production, while inheriting Ethereum's security for data availability and fraud proofs.
How finality works
A Signet order becomes final in two stages. First, the rollup includes the order submission transaction and the fill proof transaction in its state. These transactions are visible immediately to anyone watching the rollup. Second, the rollup state that includes these transactions is committed to Ethereum and passes the fraud proof window — typically seven days for optimistic rollups.
For most practical purposes, rollup-level inclusion is sufficient. A fill proof that has been included in the Zenith rollup state is extremely unlikely to be rolled back — it would require either the rollup sequencer to be fraudulent and a fraud proof to be submitted successfully within the window. In practice, fillers treat rollup inclusion as working finality and do not wait for the full fraud proof window before performing subsequent fills.
Why it is not a bridge
The distinction between Signet and a bridge is not semantic. A bridge moves assets across chains by locking on one side and minting (or unlocking) on the other. The security of the bridge is the security of the lock-and-mint mechanism — the oracle that verifies the lock, the contract that holds the locked assets, and the minting logic on the destination side. Exploiting any of these drains the locked pool.
Signet does not move assets. Assets stay on their native chains. A fill is a transfer from the filler's wallet to the user's wallet on the destination chain — there is no lock, no mint, and no bridge contract on either side. The rollup provides the settlement record that authorizes the filler's reimbursement on the source chain. The attack surface is the rollup contract itself plus the filler's capital — not a centralized locked pool.
For the user, the difference is guaranteed atomicity at the settlement layer: either the fill proof is valid and the user received the outputs, or the order expires and the user's inputs are returned. There is no partial state where the user has lost their inputs but not received their outputs — the rollup enforces this invariant.