How NEAR Intents 1Click works under the hood

The hand-wave version of intent settlement is straightforward: you say what you want, solvers compete to fill it, the protocol guarantees nobody runs off with your money. The actual version has more moving parts. This post is the mechanism, step by step, with the assumptions named where they live.

Companion pieces: intent settlement vs bridges is the architectural comparison and solver economics in plain English is the why-would-anyone-do-this. If you want the mental model first, read those. This post is what happens once you press the button.

Step 1: the intent

Every flow starts with an intent: a structured description of the trade you want, signed by your wallet. The intent names a source asset on a source chain, a destination asset on a destination chain, the amount, a minimum acceptable receive (your slippage tolerance), and a deadline.

The intent is not a transaction. It is, formally, an offer — a piece of signed data that says "if someone can fill these terms before this deadline, I authorize them to take my source asset." The signing happens client-side, in the user's wallet. Nothing moves yet.

Step 2: the quote

The signed intent is submitted to a quote endpoint. The endpoint runs an auction: it shows the intent to a pool of registered solvers, each of whom returns the price at which they can fill it. The protocol picks the best price that meets the user's minimum and returns a quote.

The quote carries four pieces of information that matter downstream. First, the executed price — what the user will actually receive, net of solver spread and protocol fees. Second, a deposit address on the source chain — the address where the user must send their source asset. Third, a deadline — a hard expiration after which the quote is void and any deposit made will be refunded. Fourth, an opaque identifier the user's client can use to monitor settlement.

Quotes are short-lived by design. A solver pricing a swap is exposing themselves to the price risk of holding the source asset on their books until they can rebalance, so their quote includes only the price they will honor for a narrow window — typically seconds to a few minutes.

Step 3: the deposit

The user sends their source asset to the deposit address from the quote. From the user's wallet's perspective, this is an ordinary transfer on the source chain — a Bitcoin transaction if the source is BTC, an EVM transaction if the source is ETH or an ERC-20, and so on. The user signs and broadcasts exactly the same kind of transaction they would for a transfer to a friend.

The deposit address is the most subtle piece of the mechanism. It is not a long-lived contract or a shared bridge vault. It is a per-intent address controlled by the protocol, generated specifically for this trade. The protocol watches that address; when funds arrive, it triggers settlement. If funds do not arrive before the deadline, the address is retired and any future deposit is refunded automatically.

Step 4: settlement

Once the source asset is observed at the deposit address, the protocol releases the destination asset to the user from the winning solver's inventory on the destination chain. This is the atomic step. From the user's perspective, three things are guaranteed to happen in order: the source asset arrives at the deposit address, the destination asset arrives at the user's wallet on the destination chain, the solver becomes entitled to claim the source asset.

The guarantee that matters is the conjunction of the second and third events. The solver cannot claim the source asset until they have delivered the destination asset. The user cannot end up holding nothing. This is not enforced by a bridge multisig or a wrapped-token mint; it is enforced by the NEAR Intents settlement layer, which sees both chains and conditions one transfer on the other.

Step 5: refund (if it goes wrong)

Settlement can fail. The most common failure modes are: the quote expires before the user's deposit confirms; no solver actually delivers the destination side; the user's deposit arrives with the wrong amount.

In all three cases, the source asset is returned to the sender. The refund is not a customer-service process; it is part of the protocol's logic. The deposit address knows where the funds came from and routes them back if the conditions for settlement are not met by the deadline.

This is the most important property of the mechanism for the everyday user. The worst case is not "you lose your money." The worst case is "you wait fifteen minutes and get your money back."

Where the trust assumptions live

Every system has them; the question is whether they are legible. In 1Click, the trust assumptions are roughly:

First, the NEAR Intents protocol layer correctly enforces the conditional transfer. If the protocol's settlement contract has a bug, the atomicity guarantee fails. This is the analogue of trusting that a bridge's smart contract is correctly written — except the bridge holds a shared treasury and the intent protocol does not, so the blast radius of a bug is much smaller.

Second, solvers post collateral that gets slashed if they fail to deliver. The economics of solver participation depend on this; a solver who can grief users without cost would do so. The collateral economics are an ongoing design question — see solver economics.

Third, the user is trusting that the quote endpoint is running an honest auction — picking the solver with the best price rather than the one paying the most rebate. In practice this is verifiable after the fact by inspecting the on-chain settlement record and comparing it to public quote data. Trust-but-verify, in the strict sense.

What 1Click is not doing

A few things are worth naming explicitly because they are what bridges do and what 1Click does not.

1Click does not maintain a shared treasury. There is no single contract holding everyone's funds. The deposit address for your trade exists for the duration of your trade; the solver's inventory is the solver's inventory; the protocol never accumulates value in a way a hacker could drain.

1Click does not mint wrapped tokens. The destination asset is the actual destination asset — native USDC on Solana, native ETH on Arbitrum, native BTC on Bitcoin. No w(X), no synthetic, no IOU. The solver had inventory; the inventory moved.

1Click does not require the user to learn anything new about wallets, networks, or transaction signing. The deposit step is an ordinary transfer on the source chain. The user's existing wallet, with no special integration, works.

The summary, in five sentences

You sign an intent. The protocol runs an auction and returns a quote with a per-trade deposit address. You deposit. A solver delivers the destination side conditional on your deposit being seen. Either both transfers happen or neither does, and if neither, you get refunded.

That is the entire mechanism. The interesting properties — non-custodial throughout, no shared treasury, atomic across chains, native assets on both sides — are not features added on top. They are direct consequences of the shape of the protocol.