Signet Orders

Market-driven cross-chain execution requires practical implementation patterns. This guide provides working code for placing and filling Orders on Signet, demonstrating how applications can leverage competitive fillers for instant cross-chain operations.

Building on Signet’s simplified atomicity and settlement system, these examples show how to implement the order flow that powers same-block cross-chain execution.

Implementation Components

Three core components enable Order-based applications:

• Order Creation: Applications express user intent through signed Permit2 structures
• Order Filling: Market participants compete to fulfill orders for profit opportunities
• Bundle Coordination: Atomic execution ensures all-or-nothing settlement

The signet-orders repository provides reference implementations for each component using utilities from signet-sdk.

Filler Implementation

Code: src/filler.rs

The Filler struct demonstrates the steps required to fill Signet Orders competitively:

impl Filler {
    pub async fn fill(&self, orders: Vec<SignedOrder>) -> Result<()> {
        // 1. Construct and sign Permit2 fills for destination chains
        let fills = self.construct_fills(&orders).await?;

        // 2. Build atomic bundle combining initiates and fills
        let bundle = self.build_signet_bundle(&orders, &fills).await?;

        // 3. Submit to Transaction Cache for builder inclusion
        self.tx_cache.submit_bundle(bundle).await
    }
}

Production fillers extend this pattern with custom business logic:

• Profitability: Calculate spread opportunities across order sets
• Inventory: Source liquidity through swaps when needed
• Competition: Evaluate win probability against other fillers

Filling Strategies

The implementation demonstrates two complementary approaches:

Aggregate Execution (fill)

pub async fn fill(&self, orders: Vec<SignedOrder>) -> Result<()> {
    // Submit all Orders/Fills in single Bundle
    // Atomic execution: all succeed or none do
}

Benefits:

• Gas efficiency: Batched execution reduces transaction costs
• Capital optimization: Reuse inputs from one order to fill another
• Complex strategies: Enable sophisticated cross-order arbitrage

Trade-offs:

• All-or-nothing: Single order failure breaks entire bundle
• Complexity: Requires pre-validation of order state

Individual Execution (fill_individually)

pub async fn fill_individually(&self, orders: Vec<SignedOrder>) -> Result<()> {
    // Submit each Order/Fill in separate Bundle
    // Independent execution: orders succeed or fail separately
}

Benefits:

• Simplicity: Rely on builder simulation instead of pre-checking
• Resilience: Failed orders don’t affect successful ones
• Parallel processing: Multiple strategies can run simultaneously

Trade-offs:

• Higher gas costs: Individual transaction overhead per order
• Limited optimization: Cannot reuse capital across orders

Order Creation

Code: src/order.rs

The SendOrder struct provides the application-side implementation for initiating orders:

impl SendOrder {
    pub async fn initiate_order(&self, order: OrderSpec) -> Result<()> {
        // 1. Construct Permit2 authorization for inputs
        let permit = self.build_permit2(&order.inputs).await?;

        // 2. Sign order with user's key
        let signed_order = self.sign_order(permit, &order.outputs).await?;

        // 3. Submit to Transaction Cache for filler discovery
        self.tx_cache.submit_order(signed_order).await
    }
}

Applications integrate this pattern to offer users instant cross-chain operations without managing bridge infrastructure or withdrawal periods.

Complete Roundtrip Example

Code: bin/roundtrip.rs

The roundtrip example demonstrates end-to-end order flow:

1. Construct Order: Define input/output tokens and amounts

2. Submit Order: Send signed order to Transaction Cache

3. Fill Order: Compete with other fillers to execute

4. Verify Settlement: Confirm atomic cross-chain execution

   # Configure environment
   export CHAIN_NAME=pecorino
   export RU_RPC_URL=https://rpc.pecorino.signet.sh/
   export SIGNER_KEY=[AWS KMS key ID or local private key]
   export SIGNER_CHAIN_ID=14174
   
   # Run rollup-to-host swap
   cargo run --bin order-roundtrip-example
   
   # Run rollup-to-rollup swap
   cargo run --bin order-roundtrip-example -- --rollup

The example handles both AWS KMS and local private key signing, demonstrating production-ready key management patterns.

Setup Requirements

Fund Your Key

The signing key must hold:

• Input tokens: Assets being swapped from (rollup)
• Output tokens: Assets being provided to user (host and/or rollup)
• Gas tokens: ETH (Host) or USD (Rollup) for transaction fees

Configure Permit2 Approvals

Enable Permit2 to spend relevant tokens:

cast send [TOKEN_ADDRESS] "approve(address,uint256)" \\
  0x000000000022D473030F116dDEE9F6B43aC78BA3 \\
  0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \\
  --rpc-url $RPC_URL

Permit2 uses consistent addresses across Pecorino and Ethereum mainnet, simplifying multi-chain applications.

Bundle Execution Model

Orders execute through Signet’s atomic bundle system:

Block-Specific Execution: Bundles target specific blocks for deterministic inclusion Retry Pattern: Failed bundles can be resubmitted for subsequent blocks

Atomic Guarantees: All transactions in bundle succeed or none do

// Bundle construction with host fills
let bundle = SignetEthBundle {
    host_fills: Some(permit2_fills),    // Ethereum-side actions
    bundle: EthSendBundle {
        txs: signet_transactions,       // Signet-side transactions
        block_number: target_block,
        reverting_tx_hashes: vec![],    // No partial execution allowed
    }
};

This model enables applications to offer users the same UX as centralized services while maintaining decentralized execution.

Market Dynamics

Order-based execution creates competitive markets that benefit users:

• Filler Competition: Multiple parties compete to fill orders, driving efficient pricing
• Capital Efficiency: Fillers optimize inventory across chains rather than maintaining idle liquidity pools
• Execution Incentives: Better filling strategies capture more volume and profit

Applications benefit from this competition without building internal market-making infrastructure.

Production Considerations

• Business Logic: Implement custom profitability analysis for your specific use case
• Key Management: Use hardware security modules or key management services for production Monitoring: Track order fill rates and competitive positioning
• Capital Strategy: Plan inventory management across supported chains
• Error Handling: Implement retry logic for failed bundles and network interruptions
• Gas Optimization: Consider aggregate vs individual filling strategies based on order patterns

Integration Patterns

• Cross-chain DeFi: Enable instant cross-chain positions without bridge delays
• Payment Systems: Route payments optimally across chains based on liquidity
• Arbitrage Bots: Capture price differences while providing user services
• Wallet Interfaces: Offer seamless cross-chain swaps through order abstraction

Build with Orders

The order system transforms cross-chain operations from complex infrastructure challenges into simple market interactions. Applications post orders, competitive fillers provide execution, users get instant settlement.

Resources:

• signet-orders - Complete example implementations
• signet-sdk - Core types and utilities

Get Started:

• Testnet Faucet - Fund your development keys
• Pecorino Explorer - Monitor order execution

Start building applications that leverage competitive execution rather than fighting it. Orders enable market-driven cross-chain operations that scale with demand.

Questions about implementation patterns? Reach out to discuss specific integration approaches.