Skip to main content
Signet

Updates

Application Controlled Execution

Anthony //5 min read

Cross-chain applications have an oracle problem. Your app needs to know what happened on another chain, but oracles add latency, cost, and trust assumptions. Price feeds lag by minutes. Bridge relayers can censor or front-run. Failed transactions leave assets stranded between chains.

What if your application could just… read L1 state directly? And execute based on it in the same block?

Signet enables this through Application Controlled Execution—the ability to read Ethereum state and execute logic on Signet within the same block, with atomic guarantees. No oracles. No relayers. No partial failures.

The Traditional Cross-Chain Problem

Consider a simple cross-chain swap. A user wants to exchange ETH on Signet for ETH on Ethereum. On traditional rollups, this requires:

  1. Initiate: User locks assets on the rollup
  2. Wait: Oracle or relayer observes the lock (minutes to hours)
  3. Execute: Counterparty releases assets on L1
  4. Finalize: User claims assets after proof window (days)

Each step introduces failure modes. The oracle might lag. The relayer might censor. The counterparty might not execute. The proof might fail. Users end up with assets locked on one chain while waiting for the other side to complete.

Same-Block Synchronization

Signet eliminates these problems through synchronized block production. Every Signet block corresponds to exactly one Ethereum block, with identical timestamps:

Block Synchronization

Ethereum:  ──[Block N]────────────────[Block N+1]──
                 │                         │
                 │  identical timestamps   │
                 ▼                         ▼
Signet:    ──[Block N]────────────────[Block N+1]──

L1 state visible to Signet in the same block

This 1:1 coupling means Signet can observe Ethereum state as it happens—not minutes later through an oracle, but in the same block. Applications can read L1 events and react within the same 12-second window.

L1-Driven Actions: Ethereum → Signet

Three primitives enable applications to react to Ethereum state:

Enter / EnterToken

When users deposit assets to the Passage contract on Ethereum, Signet observes the deposit event and mints corresponding tokens in the same block:

text
User deposits 10 ETH to Passage on Ethereum
       │
       ▼
Passage emits Enter event
       │
       ▼
Signet node observes event (same block)
       │
       ▼
10 ETH minted to user on Signet

No relayer. No delay. No trust assumption beyond Ethereum itself.

Transact: Arbitrary Execution

The Transactor contract enables arbitrary transaction execution from Ethereum to Signet:

solidity
// On Ethereum
transactor.transact(
    rollupChainId,        // Target Signet chain
    signetContractAddress, // Contract to call on Signet
    calldata,              // Encoded function call
    value,                 // USD to attach (in wei)
    gas,                   // Gas limit for Signet execution
    maxFeePerGas           // Max fee per gas in USD
);

// Executes on Signet at end of same block

Transact events are processed at the end of each Signet block. They’re censorship-resistant—the protocol enforces their execution, not a relayer.

Conditional Transactions: Signet → Ethereum

The reverse direction—Signet applications that require L1 outcomes—uses conditional transactions through the OrderDetector mechanism.

A conditional transaction emits an Order event specifying required outputs. The transaction is valid if and only if all outputs have corresponding Fill events on Ethereum in the same block:

Conditional Transaction Flow

User Intent: "Send 1 ETH on Signet, receive 1 ETH on Ethereum"

Signet Tx:    [Order: input 1 ETH, output 1 ETH on L1]
                              │
                              ▼
              OrderDetector validates
                              │
                ┌─────────────┴─────────────┐
                │                           │
         Fill found on L1            No fill found
                │                           │
                ▼                           ▼
         Tx executes                Tx reverts
       (both chains)              (as if never happened)

The OrderDetector is an EVM inspector that enforces atomicity at the protocol level. It validates that every Order has corresponding Fills:

  1. Fills execute first, crediting outputs to recipients
  2. Orders execute, debiting inputs from users
  3. For each output in the Order, the detector checks: does a sufficient Fill exist?
  4. If any Fill is missing, the entire Order reverts

Fill transactions must execute before the Order transaction. If any fill is missing, the entire Order is rejected—no partial executions, no stranded assets.

Building ACE Applications

The Signet SDK provides the primitives for building applications with controlled execution:

Core crates:

  • signet-types — Order and output type definitions
  • signet-zenith — Transactor and Passage bindings
  • signet-bundle — Bundle construction and simulation

Constructing Orders

Orders express atomic intent through Permit2, enabling gasless authorization:

rust
use signet_types::signing::order::UnsignedOrder;
use signet_constants::parmigiana as constants;

let signed = UnsignedOrder::default()
    .with_input(constants::RU_WETH, U256::from(1e18))
    .with_output(
        constants::HOST_WETH,
        U256::from(1e18),          // 1 ETH
        recipient_address,
        1,                          // Ethereum mainnet
    )
    .with_chain(constants)
    .with_nonce(permit2_nonce)
    .sign(&signer)
    .await?;

Bundle Simulation

Before submitting, simulate bundles to verify they’ll execute atomically:

rust
let response: SignetCallBundleResponse = provider
    .client()
    .request("signet_callBundle", (bundle,))
    .await?;

// Response includes orders and fills for validation
// Bundle is valid when fills satisfy all order outputs
println!("Orders: {:?}", response.orders);
println!("Fills: {:?}", response.fills);

Practical Patterns

Several contract patterns demonstrate ACE capabilities:

Flash.sol — Cross-Chain Flash Loans

Borrow on Signet, use on Ethereum, repay atomically. The loan only executes if repayment is guaranteed in the same block.

GetOut.sol — Instant Exits

Market-priced exit from Signet to Ethereum. Users pay a small fee (e.g., 50bps) for instant settlement rather than waiting for standard withdrawal processes.

PayMe.sol — Payment Gating

Orders with only outputs—require payment on L1 before Signet action executes. Useful for cross-chain purchases or access control.

PayYou.sol — Execution Bounties

Orders with only inputs—offer bounties for execution. Useful for incentivizing specific L1 actions.

See our Solidity examples for implementation details.

Need Something More Specialized?

If your use case requires general-purpose message passing, mid-execution L1 calls with return values, or other cross-chain patterns—we’d love to hear about it. There’s often a way to achieve similar or better results by thinking outside the box with Signet’s primitives.

Get in touch and tell us what you’re building.

Getting Started

Build applications with controlled execution:

ESC

Start typing to search documentation...

↑↓ Navigate ↵ Select ⌘K Open