> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ERC-7683

> Open, resolve, and fill Eco orders through the Portal's cross-chain order interfaces.

The EVM Portal exposes origin and destination settler interfaces for ERC-7683 orders. These methods map an order into the same funding and fulfillment operations used by Routes.

This page describes Eco's [OriginSettler](https://github.com/eco/eco-routes/blob/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/ERC7683/OriginSettler.sol), [DestinationSettler](https://github.com/eco/eco-routes/blob/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/ERC7683/DestinationSettler.sol), and [order types](https://github.com/eco/eco-routes/blob/ea5111ba0cd644089d04f922e05a5253dbd21fb8/contracts/types/ERC7683.sol) in Routes 2.12.0. Match the ABI to your deployment.

## 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

| Method | Purpose |
| - | - |
| `open` | Decode an onchain order, publish it, and fund it from the caller |
| `openFor` | Validate a user's signed order and publish/fund it on their behalf |
| `resolve` | Convert an onchain order into the resolved order format |
| `resolveFor` | Resolve a signed order |
| `domainSeparatorV4` | Read the EIP-712 domain separator |

`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, and `maxSpent` 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:

| Argument | Encoded contents |
| - | - |
| `originData` | Encoded route bytes and reward hash |
| `fillerData` | Destination-side prover address, source domain ID, claimant, and prover-specific data |

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

| Failure | Check |
| - | - |
| `TypeSignatureMismatch` | Order-data type hash and matching encoding |
| `OpenDeadlinePassed` | Opening deadline |
| `InvalidOriginSettler` or `InvalidOriginChainId` | Domain and target Portal |
| `InvalidSignature` | Signer, domain, and all signed order fields |
| Fulfillment revert | Decoded route, funding approvals, deadline, claimant, and prover data |

Simulate the complete opening or filling transaction before submitting it and estimate its gas on the target chain.

## Next steps

Read [Portal](/routes/architecture/portal) for the underlying operations and [Provers](/routes/architecture/provers/overview) for proof integration.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.