NEAR Intents: the model

How NEAR Intents works: the intents.near Verifier ledger, accounts and keys, nep141: token IDs, deposits, signed intents, solvers and cross-chain withdrawals.

Advanced5 min read3-question check

NEAR Intents is a settlement protocol. Users sign a statement of what they want (“give 100 USDC, get at least 0.03 ETH”), market makers compete to make it happen, and one contract checks every signature and balance and applies all changes atomically. That contract is the Verifier, deployed at intents.near (mainnet only). Source: near/intents (the defuse contract); docs: Verifier contract.

A ledger inside a contract#

Tokens you deposit into intents.near stop being balances in the token contract under your name and become balances in the Verifier’s own ledger, exposed as a NEP-245 multi-token. Inside the ledger, transfers and swaps are just state updates in one contract: no cross-contract calls, no callbacks, no partial failure. Cross-contract calls only happen at the edges: deposits in, withdrawals out.

Token type	Token ID in the ledger	Example
NEP-141 fungible	`nep141:<contract>`	`nep141:wrap.near`
NEP-171 NFT	`nep171:<contract>:<token_id>`	`nep171:coolnfts.near:rock.near`
NEP-245 multi-token	`nep245:<contract>:<token_id>`	`nep245:v2_1.omni.hot.tg:137_qiStmoQJDQPTebaPjgx5VBxZv6L`

Balances are plain NEP-245 views

Shell

near contract call-function as-read-only intents.near mt_batch_balance_of \
  json-args '{"account_id":"alice.near","token_ids":["nep141:wrap.near","nep141:eth.omft.near"]}' \
  network-config mainnet now
# [ "3000004000004000006", "0" ]  (smallest units)

Accounts: named, implicit, and foreign wallets#

The Verifier identifies everyone by a NEAR AccountId and keeps its own map of public keys per account. Any registered key can sign intents for that account.

Who	Account ID in the Verifier	Setup
NEAR user `alice.near`	`alice.near`	Call `add_public_key` on `intents.near` once (1 yoctoNEAR) to register a key that may sign intents. Without a key she can still receive and withdraw by direct calls.
Ethereum / EVM wallet	`0x` + 40 lowercase hex (implicit ETH account from the secp256k1 key)	None. Signs with `erc191` (MetaMask `personal_sign`).
Solana, TON, Stellar wallet	64-hex implicit NEAR account of the ed25519 key	None. Signs with `raw_ed25519`, `ton_connect`, `sep53`.
Passkey	Implicit account from the P-256 or ed25519 key	None. Signs with `webauthn`.

The lifecycle: deposit → intents → withdraw#

Deposit. From NEAR: ft_transfer_call the tokens to intents.near; msg names the owner (empty = sender). From another chain: a bridge (or a 1Click deposit address) credits a bridged token such as nep141:base-0x8335…omft.near. Native NEAR must be wrapped to wNEAR first.
Intents. The owner signs a payload with one or more intents. Anyone submits it with execute_intents (or publishes it to the solver relay). The Verifier checks signature, deadline and nonce, then applies every intent or none.
Withdraw. An ft_withdraw / nft_withdraw / mt_withdraw / native_withdraw intent, or a direct call by the owner, moves tokens out. Withdrawing a bridged token routes it back to its origin chain through its bridge (the Intents SDK picks the route for you).

Intent types#

Intent (JSON `intent`)	Effect
`transfer`	Move ledger tokens to another account: `{ receiver_id, tokens: { "<token id>": "<amount>" }, memo? }`
`token_diff`	Declare a trade: negative amounts you give, positive you get. Diffs in a batch must net to zero per token (fees aside).
`ft_withdraw`, `nft_withdraw`, `mt_withdraw`	Leave the ledger. Note: `token` is the unprefixed contract ID here, e.g. `usdc.near`.
`native_withdraw`	Unwrap wNEAR and send native NEAR
`storage_deposit`	Pay a NEP-145 storage deposit on some token contract from your wNEAR balance
`add_public_key`, `remove_public_key`	Manage the keys that may sign for the account
`auth_call`, `set_auth_by_predecessor_id`	Advanced: call out to a contract with authorization; toggle direct-call authentication

Solvers and fees#

Solvers (market makers) hold inventory inside the Verifier. When a user wants to swap, solvers return quotes; the user signs a token_diff; the solver’s opposite token_diff is submitted in the same execute_intents call, and the Verifier checks that the books balance. The protocol fee is set on the contract in pips (1 pip = 0.0001%) and taken from the given side of each token_diff; the fee view returned 1 (0.0001%) in October 2026. Distribution channels such as 1Click add their own fees on top.