Cross-chain crypto activity still asks users to make a lot of execution decisions.
A simple swap can involve choosing a bridge, checking the destination asset, managing gas, approving tokens, comparing routes, and waiting for settlement. Experienced users may understand these steps, but the process still creates room for mistakes and hidden trust assumptions.
Intents are one approach to simplifying that flow.
Instead of asking the user to specify every step, an intent lets the user specify the result they want. A user might say, “I have ETH on Ethereum and want USDC on Arbitrum,” with constraints around price, timing, and acceptable execution. The system can then package that request as an order and show it to specialized actors — often called solvers, fillers, market makers, or routers — that compete to fill it.
The basic shift is from specifying each transaction step to specifying the outcome a user wants.
NEAR Intents are one widely-used example of this primitive. They combine signed user intents, market-maker competition, a NEAR-based Verifier contract, and account abstraction.
Furthermore, NEAR Intent's Confidential Swaps allows users to swap cross-chain without exposing their transaction's metadata to the public.
An Intent is a DeFi primitive for transactions.
An intent expresses what you want to achieve, not how to get it. For example, a user can express: "I have 1 ETH on Ethereum, I want USDC on Arbitrum.”
In the older transaction model, the user or frontend specifies the path. The transaction says exactly which contract to call and with which parameters. If the user chose a bad route, lacked gas, used the wrong bridge, or misunderstood the destination asset, the system mostly did what it was told.
A DEX aggregator improves this by finding better swap routes across liquidity sources. But the user is still largely executing a selected path.
An intent system goes a step further. The user specifies an outcome and constraints. The execution layer decides how to satisfy them.
Model | User says | System does |
|---|---|---|
Classic transaction | “Call this contract with these parameters.” | Executes the specified path. |
DEX aggregator | “Find the best route for this swap.” | Optimizes across pools and routes, then the user executes the selected route. |
Intent system | “Give me this outcome under these constraints.” | Solvers choose the execution path and compete to satisfy the outcome. |
ERC-7683, the draft Ethereum standard for cross-chain intents, helps explain where this market may be heading.
The standard does not try to create one universal settlement contract. In fact, it explicitly says it does not require protocols to use a common escrow, settlement contract, or fill function.
Instead, ERC-7683 focuses on the solver-facing side of the system. A protocol can expose an order as an opaque payload, then provide a resolver contract that translates that payload into a common representation solvers can understand.
Solver markets need legibility. If every protocol has a different order format, execution flow, payment rule, and settlement assumption, only a small number of deeply integrated solvers can participate. Integration costs go up. Solver liquidity fragments. New intent protocols have a harder time attracting competitive execution.
A common solver-facing interface could make intent systems more competitive without forcing every protocol to use the same backend design.
But ERC-7683 is careful about its own limits. It standardizes how a protocol describes an order to solvers. It does not guarantee the security of the protocol that ultimately settles the order.
NEAR Intents is a core part of the NEAR protocol, which has historically been focused on building an enjoyable experience for users.
At a high level, NEAR Intents work like this:
A user expresses a desired outcome.
Solvers (a.k.a. market makers or fillers) compete to fill the quote.
A selected quote is settled onchain through NEAR’s Verifier contract.
The transaction is finalized and finishes executing.
Users can initiate a dispute.
The Verifier contract, deployed at intents.near, is the on-chain settlement layer for NEAR Intents. NEAR’s docs describe it as an internal ledger that tracks token balances for participants. Swaps and transfers can happen within the contract’s balance records, while actual token movement to external chains happens on withdrawal through one of three token bridges (Omni, POA, or HOT).
NEAR Intents also supports account abstraction across multiple ecosystems. According to the docs, the Verifier contracts supports signatures from NEAR, Ethereum, TRON, Solana, Stellar, TON, and passkey-based wallets. Users do not necessarily need to create a NEAR account to use NEAR Intents.
There is also an offchain Message Bus for price discovery and communication between users and market makers. NEAR’s docs say the Message Bus helps optimize price discovery and submit settlement transactions to the Verifier contract, while also noting that the protocol can operate without it.
Then there is 1Click Swap API, the more user- and developer-facing abstraction. It handles quote requests, intent submission, retries, refunds, and status tracking. But the docs include a notable trust detail: 1Click Swap temporarily transfers assets to a trusted swapping agent that coordinates with market makers to execute the intent.
A clean way to describe NEAR Intents is that it is a vertically integrated implementation of the Intents primitive.
The first appeal of intents is usually convenience: better routing, fewer steps, less chain-specific friction.
NEAR’s confidential swaps add a different question: what if some of the execution path is not only simplified for the user, but also made less visible to the public?
Public transactions leak a lot of information. They can reveal wallet addresses, amounts, timing, routes, counterparties or pools, and trading behavior. For an individual, that may mean copy-trading, wallet tracking, or unwanted exposure. For a DAO, treasury, fund, or market maker, it can reveal strategy.
Confidential swaps hide amounts, routes, and wallets from the public. NEAR Protocol announced in March 2026 that confidential swaps were live on near.com, with messaging around hiding what users trade, who they trade with, and how much. A later NEAR Protocol X post said that nearly half of swap volume was already confidential.
The broader appeal of Intents in today's age of AI agents is that crypto applications should let human users and agents express goals, constraints, and permissions, then rely on competitive execution markets to handle the path.
This may matter more as AI agents begin to act as economic actors.
An agent should not have to manually construct every transaction across every chain, bridge, liquidity venue, and gas environment if a safer constrained request can produce the same result. It should be able to operate under constraints:
rebalance this treasury;
pay this vendor;
move this asset to the lowest-cost venue;
maintain these risk limits;
use only approved routes;
do not expose more information than necessary;
stop if settlement assumptions fail.
Wallets give agents a way to hold assets. Intents could give them a more structured way to request actions under constraints.
The same pattern that makes cross-chain swaps easier for humans may also be useful for AI agents that need to operate under clear permissions and limits.
Intents are not magic. They do not remove risk, trust, or complexity.
They change where those things sit.
Instead of forcing users to manage every bridge, route, approval, gas token, and settlement path, intents let users sign outcomes. Solvers compete to execute. Settlement layers verify whether the promised result happened.
NEAR Intents show what this can look like in a live product stack: apps, APIs, market makers, a verifier contract, and account abstraction working together. Confidential swaps add the next question: if execution can be made easier for users, can sensitive transaction metadata also be made private to the public?
Intents become a practical way to move execution complexity away from users and into more specialized markets.

