Glossary

Blind signing is a security feature where a party (in this case, the sequencer) signs a piece of information without knowing its full contents. It’s like signing a sealed envelope without being able to see what’s inside.

Key points:

1. The signer only sees a hash (a unique digital fingerprint) of the content, not the actual content itself.
2. This prevents the signer from selectively censoring or manipulating the content based on what it contains.
3. It enhances privacy and reduces the potential for bias or censorship.

In Signet’s context: The sequencer blind signs blocks. It only sees the block’s hash and the builder’s identity, not the actual contents of the block. This ensures fair and unbiased block inclusion while preventing potential censorship.

Block builders are specialized participants in a blockchain network who assemble and propose new blocks to be added to the blockchain. They’re like puzzle makers who gather and arrange transactions into a format that fits the blockchain’s rules.

Traditionally:

1. Block builders collect pending transactions from the network’s mempool (a pool of unconfirmed transactions).
2. They organize these transactions in a way that maximizes their profit (through transaction fees) while adhering to the network’s rules.
3. In some systems, block builders compete to have their blocks chosen by proposers or validators.
4. They often use sophisticated algorithms and infrastructure to optimize block composition.

Signet takes a different approach to block building compared to traditional systems:

1. Instead of using auctions where wealthy builders can dominate, Signet uses a round-robin style system.
2. A central sequencer assigns block production rights to different block builders in turns.
3. This approach aims to prevent centralization and ensure fairer participation among block builders.
4. The sequencer uses blind signing (as we discussed earlier) to prevent censorship and ensure unbiased block inclusion.

Conditional transactions are operations that only execute if certain predefined conditions are met. They’re like “if-then” statements in programming, but for blockchain transactions.

Key points:

1. The transaction is only processed and finalized if all specified conditions are satisfied.
2. If any condition is not met, the entire transaction is cancelled as if it never happened.
3. This feature enables more complex and secure interactions, especially between Signet and Ethereum.

In Signet’s context: Conditional transactions are used for cross-chain transfers. They ensure that the transfer is fully executed in the same block on both chains. If the conditions aren’t met, the transaction is invalidated and has no effect on Signet’s state.

State roots are like a cryptographic snapshot of the entire state of a blockchain at a specific point in time. They serve as a compact way to represent and verify all the accounts, balances, and smart contract data on the blockchain without needing to store or process the entire history of transactions.

To break it down further:

1. Think of the blockchain as a giant ledger or database.
2. This ledger contains information about every account, its balance, and all the data stored in smart contracts.
3. The state root is a single, unique hash (a fixed-length string of characters) that represents the entire contents of this ledger at a specific block.
4. Any change to any part of the ledger, no matter how small, will result in a completely different state root.

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.

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.

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.

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.

Sequencers are special entities in rollup systems that are responsible for ordering and batching transactions. Think of a sequencer as a traffic controller for blockchain transactions.

Most rollups use a single centralized Sequencer with near-total control over transaction ordering. Signet’s sequencer doesn’t actually order transactions. Instead, it delegates that to block builders, and then co-signs the blocks.

1. Round-robin assignment: Instead of using auctions, the sequencer assigns block production rights to different block builders in turns.
2. Blind signing: The sequencer only sees the block’s hash and the builder’s identity, not the actual contents of the block. This prevents selective censorship.
3. Simplicity: Signet’s sequencer is designed to be simple, easy to maintain, and less prone to errors.

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:

1. Same-block synchronization: Every Signet block corresponds to exactly one Ethereum block with identical timestamps.
2. L1-driven execution: Passage deposits and Transactor calls from Ethereum execute on Signet in the same block.
3. Conditional execution: Orders on Signet require corresponding Fills on Ethereum to be valid.

See Application Controlled Execution for details.

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:

1. Detects Order and Filled events during transaction execution
2. Uses frame-based tracking to handle nested calls and reverts
3. Validates fills against orders via aggregate comparison
4. Returns an error if any output lacks a sufficient fill

If validation fails, the entire transaction reverts—no partial executions, no stranded assets.

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.

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’re building cross-chain workflows
• 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.

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.