Building intent-based applications is a different mental model from building transaction-based applications. Instead of constructing a sequence of contract calls and broadcasting them through a wallet's RPC, the developer composes an intent (a desired outcome), submits it to a solver network, and waits for a settlement event to confirm delivery. The shift moves complexity from the application layer to the orchestration layer, which is what makes the model attractive for production teams.
​

This guide walks through the developer-facing primitives for intent-based apps in 2026: choosing a standard (ERC-7683 is the dominant EVM choice), constructing orders, integrating with solver networks, handling settlement callbacks, and building UX around variable latency. Code samples reference the standard and the major SDKs. Eco's CLI and API are referenced where they collapse multi-step integration into a single call for stablecoin orchestration.
​

A transaction-based app constructs and broadcasts the steps to achieve a state change. Approve token. Call swap function. Wait for confirmation. Call deposit function. Wait for confirmation. The app's responsibility is the entire path. An intent-based app constructs and broadcasts the desired state change. Output X token at address Y on chain Z by deadline T. The solver network's responsibility is the path.
​

This changes three things at the integration layer. First, the app no longer manages multi-step retries — the solver does. Second, the app no longer estimates gas across multiple chains — the solver prices it into the spread. Third, the app's UX shows one signature and one confirmation event instead of N signatures and N confirmations. Paradigm's intent essay framed the shift in 2023; the production tooling caught up in 2024-2025.
​

The cost of the shift is monitoring. The app must track intents in flight, handle expirations, and surface settlement status to the user. Solvers can fail to fill, fills can be disputed in optimistic settlement networks, and finality on the destination chain may lag the solver's commit. The app's job becomes UX over uncertain timelines, not management of execution paths.
​

For EVM-to-EVM cross-chain intents in 2026, ERC-7683 is the standard with the deepest implementation support. Across, UniswapX, CoW Protocol, and Eco all expose ERC-7683 endpoints. Wallets including Safe, Argent, Rabby, and MetaMask emit ERC-7683 orders natively per MetaMask's release notes. An app integrating ERC-7683 inherits access to every solver network that supports the standard.
​

For non-EVM chains, ERC-7683 does not directly apply. Solana and SVM-based intents currently use protocol-specific formats; Tron and Sui intents are even less standardized. Apps needing multi-VM coverage either integrate per-chain protocols or use an orchestration layer that abstracts the standards. Eco's orchestration layer handles this by exposing one SDK that emits ERC-7683 for EVM destinations and protocol-specific formats for non-EVM destinations.
​

For application-specific intent flows that don't map cleanly to ERC-7683 (multi-party trades, conditional execution, programmable order types), the choices are narrower. Anoma's intent-centric architecture is on testnet but not production-ready. Custom integrations with CoW Protocol's batched-auction primitive can express coincidence-of-wants matches but require deep protocol-specific knowledge.
​

An ERC-7683 order is an EIP-712 typed message with this approximate shape:

The orderData encodes input/output tokens, amounts, destination chain, recipient, and any settler-specific metadata. Each settlement contract publishes its own orderData ABI. Across publishes the V3SpokePoolInterface format; Uniswap publishes the ReactorOrder format; Eco publishes its EcoOrder format that maps across multiple underlying settlement primitives.
​

The user signs the order via EIP-712 in their wallet. The signature can be submitted onchain by anyone — the user themselves (paying source-chain gas) or a solver (gasless from the user's perspective). The ERC-7683 reference implementation includes example code in Solidity and TypeScript.
​

Once the order is signed, the app submits it to one or more solver mempools. Each network exposes a different submission endpoint. Across has a public order book. UniswapX uses a Dutch-auction parameter encoded in the order. Eco's API accepts orders directly and routes them to the appropriate solver pool internally.
​

The submission decision matters because solver coverage is uneven across networks. An order submitted only to Across reaches Across's relayer set; an order submitted to multiple networks reaches more solvers but introduces coordination problems (which solver wins, how is the user's escrow released to the right one). Apps generally pick one network per route or use an orchestration layer that handles the routing.
​

For production stablecoin teams, the integration pattern is:

Eco's getting-started guide walks through this pattern with code samples for TypeScript and Python.
​

Once a solver fills the order, the app needs to know. Two mechanisms exist: webhooks and polling. Webhooks are pushed by the orchestration layer when the destination-chain delivery is confirmed; polling reads the tracking endpoint at intervals. Webhooks are lower latency; polling is simpler to implement and more robust to network partitions.
​

The settlement event includes the destination-chain transaction hash, the actual amount delivered (which may differ from the requested amount within the slippage tolerance), and a finality flag. The finality flag matters because some settlement primitives (optimistic, like Across) consider an order "filled" when the solver delivers but "final" only after the dispute window. Apps handling treasury operations should wait for finality; apps handling user-facing UX can show "delivered" immediately.
​

Failure cases include: order expiration (no solver filled within the deadline), solver default (solver committed but failed to deliver), and settlement dispute (a fill was disputed within the optimistic window). Each case has a different UX implication. Expiration returns the user's escrowed funds automatically; default triggers a fallback flow; dispute holds the relayer's reimbursement but the user's funds remain delivered.
​

Intent fills are fast on the median (sub-15 seconds for major stablecoin routes per Across stats) but variable on the tail. Apps building UX should not assume instant delivery. The standard pattern is a three-state UI: "submitting" (signature in flight), "filling" (solver committed, waiting for destination delivery), "complete" (delivery confirmed).
​

Wallets like MetaMask and Rabby surface this UX natively when emitting ERC-7683 orders. Apps embedding solver-network flows server-side need to build the UX themselves, including timeout handling, retry prompts, and refund triggers when intents expire unfilled.
​

For mobile apps, the latency variance is more visible because the user is staring at the screen waiting. The pattern that works is to set realistic expectations upfront ("delivery typically completes in 10-30 seconds") rather than promising instant. Users who see "delivered in 8 seconds" after expecting up to 30 seconds report higher satisfaction than users who expected instant and got 8 seconds, per consumer-app UX research from a16z's State of Crypto 2024.
​

For production deployment, three considerations dominate. First, monitoring: track fill rates, median latencies, and tail latencies per route, and alert on regressions. Solver-network performance varies across routes and over time; what was 8-second median in January can drift to 25-second median in April if a major solver exits the network.
​

Second, fallback paths. Solver networks can have outages or wide spreads during low-liquidity periods. Apps with hard SLAs need a fallback to direct-bridge integration for high-priority transfers. Orchestration layers like Eco handle this automatically by routing to bridge primitives when solver networks are unfavorable; apps integrating networks directly need to build the fallback themselves.
​

Third, accounting and reconciliation. Intent flows have multiple settlement events: solver fill, optimistic finality, source-chain release. Apps with bookkeeping requirements need to model each event and reconcile against the settlement layer's authoritative state. Treasury operations should wait for finality before debiting internal ledgers.
​

Three integration patterns dominate in production intent-based apps as of 2026. First, the gasless-payment pattern: a SaaS platform billing in stablecoins lets the customer pay from any chain. The platform constructs an intent that delivers the customer's payment to the platform's treasury chain; the customer signs and the solver fills. Eco's payments documentation includes a worked example for SaaS billing.
​

Second, the cross-chain swap pattern: an exchange or DeFi app lets the user swap tokens that live on different chains. The app constructs an intent that takes Token A from Chain X and delivers Token B on Chain Y; the solver bridges and swaps in one fill. The user sees one signature and one outcome.
​

Third, the treasury-rebalancing pattern: a treasury management system periodically rebalances stablecoin holdings across chains based on operational needs. The system emits intents server-side (using a programmatic signer with delegated authority) and tracks settlement events for accounting. This pattern is common in exchange backends and market-making operations.
​

Each pattern shares the same architecture (intent construction, signature, solver fill, settlement event) but differs in who signs (user vs server), how settlement events are consumed (UI updates vs accounting reconciliation), and what fallback flows exist (refund prompt vs alert-and-retry).
​

Production intent-based apps need to handle several error categories. First, signature errors: the user's wallet may reject the EIP-712 signature, time out, or sign an order with parameters that violate the solver network's policies. Apps should validate parameters before requesting signature and surface specific error messages.
​

Second, mempool errors: the signed order may fail to reach a solver mempool due to API outages or network conditions. Apps should retry submission with exponential backoff and provide a manual-retry option for the user. The order is signed at this point but not yet on-chain, so funds are not at risk.
​

Third, fill errors: a solver commits but fails to deliver. This is rare in production solver networks (Across reports 99.7% successful fill rate per its public stats) but apps should handle it. The standard response is to wait for order expiration and trigger refund automatically.
​

Fourth, settlement errors: the solver delivered but verification failed or was disputed. This typically means the user has received their funds but the solver's reimbursement is held. The app's accounting should reflect the user-side success regardless of the solver-side resolution.
​

Eco exposes intent-based execution as a CLI and API designed for production stablecoin teams. The CLI is for one-off operations and prototyping (eco transfer --token usdc --from base --to solana --amount 1000). The API is for application integration: a single POST creates the intent, returns a tracking ID, and triggers a webhook on settlement.
​

The orchestration layer underneath handles solver selection across 15 chains and multiple settlement primitives. The team integrating Eco does not pick whether the route uses Across-style solver fills, CCTP burn-and-mint, or Hyperlane-secured intent execution; the orchestration layer evaluates and routes per request. Permit3 handles cross-chain approvals so the team's users sign once for global approvals across every Eco-supported chain. Permit3 documentation covers the global-approval pattern.
​

The major SDKs ship in TypeScript and Python. Solidity is needed for on-chain settlement contract integration. For most application teams, TypeScript-on-Node is the production default; Python is common for backend services and webhook handlers.
​

No. Apps consume solver networks; they do not run solvers. Running a solver is a separate business model that requires capital, inventory management, and protocol-specific routing expertise.
​

Most networks have testnets. Across has a Sepolia deployment; UniswapX has Sepolia and Base Sepolia; Eco has a comprehensive testnet covering all 15 supported chains. Test orders behave the same as mainnet orders with no real value at stake.
​

User funds are escrowed in the settlement contract on the source chain. If the orchestration API is unavailable, the user's funds remain in escrow until the order's deadline; after expiration, the user can call refund directly on the settlement contract. The user's funds are never custodied by the orchestration layer itself.
​

Yes, but it adds coordination complexity. Most teams pick one orchestration layer (which routes across multiple underlying networks) rather than integrating each network directly. The orchestration layer handles the routing, retries, and reconciliation that would otherwise be application logic.
​