Documentation/Learn About Signet
Application Controlled Execution
How applications coordinate atomic cross-chain execution between Signet and Ethereum
Same-Block Synchronization
Signet produces blocks in lockstep with Ethereum. Every Signet block corresponds to exactly one Ethereum block, with identical timestamps. This 1:1 coupling enables Signet to observe Ethereum state as it happens—not minutes later through an oracle, but in the same 12-second window.
This synchronization is the foundation of Application Controlled Execution (ACE). Applications can react to Ethereum events and execute logic on Signet within the same block, with atomic guarantees.
L1-Driven Execution
Two primitives allow Ethereum to drive execution on Signet:
Enter/EnterToken — The Passage contract handles asset deposits. When users deposit to Passage on Ethereum, Signet observes the event and mints corresponding tokens in the same block. No relayer, no delay.
Transact — The Transactor contract enables arbitrary transaction execution. Ethereum contracts can trigger Signet execution with native authentication—the Signet transaction executes from the caller’s address.
Both mechanisms are censorship-resistant. The protocol enforces their execution; no sequencer or builder can exclude them. If the Ethereum transaction is included, the Signet action executes.
Example: L1-driven contract execution
An Ethereum contract needs to trigger an emergency pause on Signet:
- Contract calls
Transactor.transact()with the pause function calldata. - The Transactor emits a
Transactevent on Ethereum. - Signet node observes the event in the same block.
- The pause transaction executes on Signet at block end.
The Signet execution cannot be censored or delayed.
Conditional Execution
The reverse direction—Signet to Ethereum—uses conditional transactions through the Orders system.
A conditional transaction emits an Order specifying required outputs. The transaction is valid if and only if all outputs have corresponding Fills on Ethereum in the same block:
- Fills exist: Transaction executes on both chains
- Fills missing: Transaction reverts entirely, as if it never happened
The OrderDetector validates this atomicity at the protocol level. It checks that every Order has sufficient Fills before the transaction can commit. No partial executions, no stranded assets.
Example: Instant exit from Signet
A user wants to move 1 ETH from Signet to Ethereum instantly:
- User creates an Order: “Send 1 ETH on Signet, receive 1 ETH on Ethereum.”
- A Filler sees this order and sends 1 ETH to the user on Ethereum.
- The OrderDetector confirms the Fill exists.
- The user’s Signet ETH transfers to the Filler.
Both sides execute atomically. The user cannot lose their Signet ETH without receiving Ethereum ETH.
The Filler Market
Fillers are MEV searchers who compete to fulfill Orders. They provide the output tokens on Ethereum and receive the input tokens on Signet. Competition between Fillers drives efficient pricing—users get market rates for their cross-chain transfers.
This market-based approach replaces the lockup periods of traditional rollup withdrawals. Instead of waiting days for finality, users pay a small fee (typically 50 basis points or less) for instant settlement.
See The Filler Economy for a deeper exploration of how Fillers operate.
Building with ACE
The Signet SDK provides Rust primitives for building applications with controlled execution. For Solidity patterns, see the On-chain Orders documentation.
Common patterns include:
- Flash loans — Borrow on Signet, use on Ethereum, repay atomically
- Instant exits — Market-priced withdrawal with no lockup period
- Payment gating — Require L1 payment before Signet execution
- Execution bounties — Incentivize specific L1 actions
Custom Implementations
Have a specific cross-chain use case? We build custom ACE implementations for application developers—whether you need novel order types, specialized fill strategies, or bespoke cross-chain workflows.
Get in touch to discuss your requirements.