TESTNET ONLINE: PECORINO PECORINO —
Docs Blog

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:

 1impl Filler {
 2    pub async fn fill(&self, orders: Vec<SignedOrder>) -> Result<()> {
 3        // 1. Construct and sign Permit2 fills for destination chains
 4        let fills = self.construct_fills(&orders).await?;
 5
 6        // 2. Build atomic bundle combining initiates and fills
 7        let bundle = self.build_signet_bundle(&orders, &fills).await?;
 8
 9        // 3. Submit to Transaction Cache for builder inclusion
10        self.tx_cache.submit_bundle(bundle).await
11    }
12}

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)

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

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)

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

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:

 1impl SendOrder {
 2    pub async fn initiate_order(&self, order: OrderSpec) -> Result<()> {
 3        // 1. Construct Permit2 authorization for inputs
 4        let permit = self.build_permit2(&order.inputs).await?;
 5
 6        // 2. Sign order with user's key
 7        let signed_order = self.sign_order(permit, &order.outputs).await?;
 8
 9        // 3. Submit to Transaction Cache for filler discovery
10        self.tx_cache.submit_order(signed_order).await
11    }
12}

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
 1# Configure environment
 2export CHAIN_NAME=pecorino
 3export RU_RPC_URL=https://rpc.pecorino.signet.sh/
 4export SIGNER_KEY=[AWS KMS key ID or local private key]
 5export SIGNER_CHAIN_ID=14174
 6
 7# Run rollup-to-host swap
 8cargo run --bin order-roundtrip-example
 9
10# Run rollup-to-rollup swap
11cargo 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:

1cast send [TOKEN_ADDRESS] "approve(address,uint256)" \\
2  0x000000000022D473030F116dDEE9F6B43aC78BA3 \\
3  0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff \\
4  --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

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

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:

Get Started:

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.