Glossary
Definitions of key terms and concepts in Signet
Blind Signing
A security feature where the sequencer signs a block without seeing its contents. The sequencer only sees the block’s hash and the builder’s identity. This prevents selective censorship or manipulation based on block contents.
In Signet, the sequencer blind signs every block, ensuring fair and unbiased inclusion.
Block Builders
Participants who assemble and propose new blocks. They collect pending transactions, organize them to maximize fees, and submit the block for inclusion.
Signet assigns block production rights via round-robin rather than auctions. A central sequencer rotates assignment across builders, preventing concentration of block production.
Conditional Transactions
Transactions that only execute if all specified conditions are met. If any condition fails, the entire transaction is cancelled with no effect on state.
In Signet, conditional transactions enable cross-chain transfers: the transfer executes in the same block on both chains, or not at all.
State Roots
A single hash representing the entire chain state (accounts, balances, contract storage) at a specific block. Any change to any part of the state produces a different root.
Signet does not use state roots. See No proofs or state roots.
Orders (Signet Orders)
Atomic, instant, cross-chain swaps between Signet and Ethereum. Orders specify inputs (what you’re providing on Signet) and outputs (the assets you want to receive, the chain, and address for delivery). Orders can be created on-chain via the Orders Contract or off-chain via SignedOrder objects. Cross-chain transfers must be fully executed in the same block on both chains; otherwise, the transaction is invalid and has no effect on Signet’s state.
See Working with Orders for implementation details.
Fillers
MEV Searchers who compete to fulfill Orders by providing the output tokens. When a Filler provides the outputs specified in an Order, they receive the Order’s inputs.
See How Orders Work for more details.
Bundles (Signet)
Flashbots-style bundles of transactions wrapped with a host_fills field. Host fills must be atomically included with their corresponding rollup transactions. If a host fill is included without its corresponding rollup transaction, the bundle is considered invalid. Block builders must respect ordering (preserved), atomicity (all or nothing), and revertibility (no unexpected reverts) guarantees.
See Bundle Guarantees for details.
Host Chain / Rollup Chain
Terminology used in Signet configuration and APIs. Host Chain refers to Ethereum. Rollup Chain refers to Signet. On the Parmigiana testnet, Rollup Chain ID is 88888.
See Parmigiana Quickstart for network configuration.
Sequencer
The entity responsible for co-signing blocks in Signet. Unlike most rollups where the sequencer orders transactions directly, Signet’s sequencer delegates ordering to block builders and blind signs the result.
- Round-robin assignment: block production rights rotate across builders rather than being auctioned.
- Blind signing: the sequencer sees only the block hash and builder identity, not the contents.
- Simplicity: the sequencer is designed to be minimal and easy to maintain.
Application Controlled Execution (ACE)
The ability for applications to read Ethereum state and execute logic on Signet within the same block, with atomic guarantees. ACE enables cross-chain operations without oracles, relayers, or trust assumptions beyond Ethereum itself.
Key components:
- Same-block synchronization: Every Signet block corresponds to exactly one Ethereum block with identical timestamps.
- L1-driven execution: Passage deposits and Transactor calls from Ethereum execute on Signet in the same block.
- Conditional execution: Orders on Signet require corresponding Fills on Ethereum to be valid.
See Application Controlled Execution for details.
OrderDetector
An EVM inspector that enforces atomicity for conditional transactions. The OrderDetector validates that every Order has sufficient corresponding Fills before the transaction can commit.
How it works:
- Detects Order and Filled events during transaction execution
- Uses frame-based tracking to handle nested calls and reverts
- Validates fills against orders via aggregate comparison
- Returns an error if any output lacks a sufficient fill
If validation fails, the entire transaction reverts—no partial executions, no stranded assets.
Passage
The contract that handles asset deposits from Ethereum to Signet. When users deposit assets to Passage on Ethereum, Signet observes the deposit event and mints corresponding tokens in the same block.
Supported operations:
- Enter: Deposit native ETH
- EnterToken: Deposit ERC-20 tokens (USDC, USDT, WBTC, WETH)
Passage deposits are censorship-resistant—the protocol enforces their execution.
See Passage Documentation and the Passage contract.
Transactor
The contract that enables arbitrary transaction execution from Ethereum to Signet. Ethereum contracts can call Transactor to trigger Signet execution with native authentication—the Signet transaction executes from the caller’s address.
Use Transactor when:
- You need guaranteed transaction inclusion
- You want to trigger Signet actions from Ethereum
- You need censorship resistance
Transactor events execute at the end of each Signet block and cannot be censored.
See Transactor Documentation and the Transactor contract.
Zenith
The core smart contract system that anchors Signet to Ethereum. Zenith handles block submission, sequencer signatures, and cross-chain coordination.
Key contracts in the Zenith system:
- Zenith.sol: Block submission and sequencer signature verification
- Passage.sol: Asset bridging from Ethereum to Signet
- Transactor.sol: L1-driven transaction execution
- Orders contracts: Cross-chain order matching
See the Zenith repository for contract source code.