Available intent types and how to structure them for the Verifier contract
An intent is a desired action on your account in the Verifier smart contract, performed by submitting a transaction to the NEAR blockchain. The Verifier allows submitting a list of actions using the functionexecute_intents.This page covers how intents are structured, wrapped into signed payloads, and the available intent types you can submit.
Multiple intents can be submitted to execute_intents in a list, where they execute in the order provided.
Important: Because NEAR is an asynchronous and sharded blockchain, intents submitted in sequence do not guarantee they will complete in that sequence. While individual intents execute in order, there is no guarantee that cross-contract calls originating from the Verifier will finish in order.
The usdc.near contract requires a storage deposit before tokens can be deposited. While Intent 1 executes first, there’s no guarantee the storage deposit call will complete before Intent 2’s withdrawal call is made.
The nonce is a 256-bit (32-byte) value encoded as base64. It must be unique per intent to prevent replay attacks.Structure:[4-byte salt][28-byte unique data]
Salt (first 4 bytes): Must match the current contract salt (retrieve via simulate_intents)
Unique data (remaining 28 bytes): Can be random or sequential, as long as it’s never reused for the same account
The salt rotates periodically. Always fetch the current salt before constructing intents. See the nonce documentation for implementation details.
You can fetch the current salt in two ways:
Via simulate_intents — the response includes the current salt alongside simulation results.
Directly via current_salt — a dedicated view method on the Verifier contract:
To create a valid, signed intent for the execute_intents function, wrap the payload in a message string and sign it. See Signing Intents for supported signature types (NEP-413, ERC-191, WebAuthn, and more). Note that the message is the same JSON serialized as a one-liner with escaped quotes:
Adds a public key to an account in the Verifier contract. The added key’s private key can sign intents on behalf of this account, including adding new keys.
Implicit account IDs have their corresponding public keys added by default. If a private key is leaked for an implicit account, you must manually rotate the public key in the Verifier.
The token contract to withdraw (e.g., usdc.near). No prefix for this field.
receiver_id
The NEAR account that will receive the withdrawn tokens.
amount
The amount in the token’s smallest unit.
memo
Optional memo for the withdrawal.
msg
Optional message to pass to ft_transfer_call. If omitted, ft_transfer is used instead. See Withdrawals for refund behavior.
storage_deposit
Optional wNEAR amount to pay for storage deposit on the token contract for the receiver. Will not be refunded on failure.
Example: Withdraw from Alice’s account to Bob’s account. On success, the tokens will be in the usdc.near contract under Bob’s account—they have exited the Verifier:
Makes an NEP-145storage_deposit call for an account_id on a contract_id. The amount is subtracted from the user’s NEP-141 wNEAR balance and will not be refunded.
Parameter
Description
contract_id
The contract to make the storage deposit on (e.g., usdc.near).
account_id
The account to deposit storage for.
amount
The wNEAR amount in yoctoNEAR. Subtracted from the signer’s wNEAR balance and will not be refunded.
Example: Pay for storage deposit in the usdc.near contract. The NEAR token specified will be taken from alice.near’s account and paid to bob.near in the usdc.near contract:
The user declares willingness to have a set of changes applied to their tokens. For example, a trade of 100 token A for 200 token B can be represented as {"A": -100, "B": 200}. The Verifier resolves matching diffs into transfers between parties.
When token_diff intents are submitted together in a batch, the total diffs across all intents must sum to zero for each token. If the amounts don’t balance, the entire batch will fail. For example, if Alice gives 10 USDC, another intent in the batch must receive exactly 10 USDC.
Parameter
Description
diff
Map of token IDs to signed amount strings. Negative values indicate tokens given, positive values indicate tokens received.
memo
Optional memo for the trade.
referral
Optional account ID for referral tracking.
Example: Two users trading USDC for USDT. Alice declares she’ll give up 10 USDC to get 10 USDT; Bob declares the opposite. These intents can be matched through the Message Bus or any off-chain channel, then submitted together:
As described in the Introduction, there are many ways to bundle these intents together for submission—the Message Bus, third parties, or any off-chain communication channel.
