Overview
TheRoute struct defines the complete set of instructions for executing a cross-chain message on the destination chain. It specifies where to send the message, what calls to make, what tokens are required, and the execution deadline.
Type Location: contracts/types/Intent.sol
Route
Fields
Unique identifier provided by the intent creator to prevent duplicate intents.Purpose:Best Practice: Use a combination of user address, timestamp, and a user-specific nonce to ensure global uniqueness.
- Ensures intent uniqueness even with identical execution parameters
- Prevents replay attacks and duplicate submissions
- Allows creating multiple similar intents with different salts
Timestamp by which the route must be executed on the destination chain.Format: Unix timestamp (seconds since epoch)Validation:Note: Using
- Must be greater than current
block.timestampwhen intent is created - Should be less than
reward.deadlineto allow time for proof submission - Typical range: 10 minutes to 24 hours from intent creation
uint64 is safe until the year 2262 (far beyond uint32’s 2106 limit).Address of the portal contract on the destination chain that receives and processes the message.Role:
- Receives the cross-chain message from the prover
- Validates message authenticity and authorization
- Executes the route’s calls in sequence
- Handles token transfers and native token forwarding
- Must implement the
IPortalinterface - Must be deployed at the same address on the destination chain
- Should be a trusted contract authorized to make calls on behalf of users
Amount of native tokens (in wei) to send with the route execution.Purpose:Note: Use
- Provides native tokens for executing calls that require ETH/native payment
- Covers gas costs for complex execution sequences
- Enables native token swaps or transfers
- Provided by the solver/filler when executing
fill()on destination chain - Must be included in
maxSpentoutputs in ERC-7683 orders
0 if no native tokens are required for execution.Array of ERC20 tokens and amounts required for execution of calls on the destination chain.Purpose:Example:Important: Always use the correct decimal precision for each token.See TokenAmount Type for more details.
- Specifies which tokens the solver must provide
- Portal transfers these tokens to call targets as needed
- Enables token swaps, liquidity provision, and multi-token operations
Array of contract calls to execute on the destination chain in sequence.Purpose:Example:Execution Order: Calls are executed in array order. If any call fails, the entire transaction reverts.See Call Type for more details.
- Defines the actual operations to perform (swaps, transfers, contract interactions)
- Executed sequentially by the portal contract
- Each call can send native tokens and invoke arbitrary contract functions
Route Encoding
When used inOrderData for ERC-7683 orders, the route is ABI-encoded:
Route Hash Calculation
Routes are hashed for intent identification:Usage Examples
Simple Token Transfer
Multi-Step DeFi Operation
Native Token Swap
Validation and Security
Pre-Execution Checks
Before executing a route, implementations should validate:- Deadline:
block.timestamp <= route.deadline - Portal: Portal address matches expected contract
- Token Balances: Portal has sufficient tokens after solver transfers
- Native Amount: Sufficient native tokens provided with
fill()call
Execution Safety
- Sequential Execution: Calls execute in order; any failure reverts entire transaction
- Reentrancy Protection: Portal should implement reentrancy guards
- Token Approvals: Ensure tokens are approved for portal before execution
- Gas Limits: Complex routes may hit gas limits; test thoroughly
Best Practices
- Salt Generation: Use unique, unpredictable salts to prevent collisions
- Deadline Setting: Allow enough time for cross-chain message delivery (10-60 minutes typical)
- Token Precision: Always use correct decimal places for token amounts
- Call Ordering: Order calls logically (approvals before transfers, etc.)
- Error Handling: Design calls to fail gracefully with clear error messages
- Gas Estimation: Test routes on destination chain to ensure gas efficiency
Integration with ERC-7683
TheRoute is central to ERC-7683 integration:
- Order Creation: Route encoded in
OrderData.route - Resolution: Route hash included in
ResolvedCrossChainOrder.fillInstructions[0].originData - Fill Execution: Route decoded and executed by
DestinationSettler.fill()
Related
- Intent Type - Complete intent structure including route
- Reward Type - Reward parameters paired with routes
- Call Type - Individual call structure details
- TokenAmount Type - Token specification format
- DestinationSettler - Executes routes on destination chain