Prerequisites
You need the Portal addresses, matching order types and ABI, funding approvals, and the selected prover’s configuration. The Routes API already returns execution instructions for application integrations; use this surface when integrating an order-opening or filling system directly.Origin methods
openFor checks the opening deadline, origin settler, origin chain, order-data type, and signature. Its EIP-712 domain uses name EcoPortal, version 1, the origin chain ID, and the Portal address. Signature authorization does not remove token-funding or transaction-gas requirements.
In this implementation, the signed nonce is not consumed as a separate replay counter. Reopening an active, funded intent can emit Open again without funding it twice. Deduplicate events by order ID; do not treat every Open event as a new order.
Order data
Eco’s order data contains the destination, encoded route, reward, destination Portal, route deadline, andmaxSpent outputs. Use the published type definition and ORDER_DATA_TYPEHASH; an arbitrary encoded Intent is not interchangeable with OrderData.
Resolution produces an order ID, spending and receiving constraints, and a fill instruction. The intent hash is the order ID. Eco’s generated minReceived entries use a zero recipient; the source reward claimant is supplied during fulfillment.
Destination method
fill(orderId, originData, fillerData) decodes:
It then calls
fulfillAndProve. The caller supplies the route tokens, approvals, native value, and message fee required for that operation. Source domain IDs are prover-specific and may differ from chain IDs.
Troubleshooting
Simulate the complete opening or filling transaction before submitting it and estimate its gas on the target chain.