# Get transaction history
Source: https://docs.near-intents.org/api-reference/account/get-transaction-history
https://1click.chaindefuser.com/docs/v0/openapi.yaml get /v0/account/history
Returns paginated public and confidential transaction history. History is invite-only for now. For the initial request, omit both nextCursor and prevCursor to retrieve the latest history. For subsequent requests, pass either nextCursor or prevCursor from the previous response.
# Get user token balances
Source: https://docs.near-intents.org/api-reference/account/get-user-token-balances
https://1click.chaindefuser.com/docs/v0/openapi.yaml get /v0/account/balances
Returns token balances for the authenticated user from private balance sources
# Get transactions
Source: https://docs.near-intents.org/api-reference/get-transactions
https://explorer.near-intents.org/api/v0/openapi.yaml get /api/v0/transactions
# Check swap execution status
Source: https://docs.near-intents.org/api-reference/oneclick/check-swap-execution-status
https://1click.chaindefuser.com/docs/v0/openapi.yaml get /v0/status
Retrieves the current status of a swap using the unique deposit address from the quote, if quote response included deposit memo, it is required as well.
The response includes the state of the swap (e.g., pending, processing, success, refunded) and any associated swap and transaction details.
# Generate an intent for signing
Source: https://docs.near-intents.org/api-reference/oneclick/generate-an-intent-for-signing
https://1click.chaindefuser.com/docs/v0/openapi.yaml post /v0/generate-intent
Generates an unsigned intent payload that needs to be signed by the user.
This endpoint takes a quote or limit-order deposit address, validates the target state and caller ownership when required, and returns an intent payload formatted according to the specified signing standard (e.g., NEP413, ERC191).
The generated intent must be signed by the user's wallet and then submitted via the `/submit-intent` endpoint to complete the action (e.g. swap).
**Request Type Variants:**
- `swap_transfer`: Generate an intent for a swap operation (requires depositAddress, signerId, standard)
# Get ANY_INPUT withdrawals
Source: https://docs.near-intents.org/api-reference/oneclick/get-any_input-withdrawals
https://1click.chaindefuser.com/docs/v0/openapi.yaml get /v0/any-input/withdrawals
Retrieves all withdrawals by ANY_INPUT quote with filtering, pagination and sorting
# Get supported tokens
Source: https://docs.near-intents.org/api-reference/oneclick/get-supported-tokens
https://1click.chaindefuser.com/docs/v0/openapi.yaml get /v0/tokens
Retrieves a list of tokens currently supported by the 1Click API for asset swaps.
Each token entry includes its blockchain, contract address (if available), price in USD, and other metadata such as symbol and decimals.
# Request a swap quote
Source: https://docs.near-intents.org/api-reference/oneclick/request-a-swap-quote
https://1click.chaindefuser.com/docs/v0/openapi.yaml post /v0/quote
Generates a swap quote based on input parameters such as the assets, amount, slippage tolerance, and recipient/refund information.
Returns pricing details, estimated time, and a unique **deposit address** to which tokens must be transferred to initiate the swap.
You can set the `dry` parameter to `true` to simulate the quote request **without generating a deposit address** or initiating the swap process. This is useful for previewing swap parameters or validating input data without committing to an actual swap.
This endpoint is the first required step in the swap process.
# Submit a signed intent
Source: https://docs.near-intents.org/api-reference/oneclick/submit-a-signed-intent
https://1click.chaindefuser.com/docs/v0/openapi.yaml post /v0/submit-intent
Submits a signed intent to execute.
After generating an intent for a quote or limit order via `/generate-intent` and having the user sign it with their wallet, submit the signed intent through this endpoint.
The system validates the signature, processes the intent, and returns the intent hash upon successful submission.
**Request Type Variants:**
- `swap_transfer`: Submit a signed swap intent (requires signedData object)
# Submit deposit transaction hash
Source: https://docs.near-intents.org/api-reference/oneclick/submit-deposit-transaction-hash
https://1click.chaindefuser.com/docs/v0/openapi.yaml post /v0/deposit/submit
Optionally notifies the 1Click service that a deposit has been sent to the specified address, using the blockchain transaction hash.
This step can speed up swap processing by allowing the system to preemptively verify the deposit.
# Cancel an order
Source: https://docs.near-intents.org/api-reference/order/cancel-an-order
https://1click.chaindefuser.com/docs/v0/openapi.yaml post /v0/orders/{orderId}/cancel
Requests asynchronous cancellation. Unspent input is refunded and successfully filled output is withdrawn.
**Errors.** Branch on `code`, never on `title` or `detail`. New codes arrive without a major
version, so treat an unrecognized code as the HTTP status alone.
| Status | Codes |
| --- | --- |
| 400 | `order-rejected` |
| 401 | `authentication-required` |
| 404 | `order-not-found` |
| 429 | `rate-limit-exceeded` |
| 500 | `internal-error` |
| 503 | `service-unavailable` |
# Create an order
Source: https://docs.near-intents.org/api-reference/order/create-an-order
https://1click.chaindefuser.com/docs/v0/openapi.yaml post /v0/orders
Creates a confidential order.
**Errors.** Branch on `code`, never on `title` or `detail`. New codes arrive without a major
version, so treat an unrecognized code as the HTTP status alone.
| Status | Codes |
| --- | --- |
| 400 | `malformed-request`, `validation-failed`, `request-rejected`, `order-rejected` |
| 401 | `authentication-required` |
| 403 | `client-generated-id` |
| 409 | `resource-type-mismatch` |
| 429 | `rate-limit-exceeded` |
| 500 | `internal-error` |
| 503 | `service-unavailable` |
# Get an order
Source: https://docs.near-intents.org/api-reference/order/get-an-order
https://1click.chaindefuser.com/docs/v0/openapi.yaml get /v0/orders/{orderId}
Retrieves an order.
**Errors.** Branch on `code`, never on `title` or `detail`. New codes arrive without a major
version, so treat an unrecognized code as the HTTP status alone.
| Status | Codes |
| --- | --- |
| 401 | `authentication-required` |
| 404 | `order-not-found` |
| 429 | `rate-limit-exceeded` |
| 500 | `internal-error` |
| 503 | `service-unavailable` |
# List orders
Source: https://docs.near-intents.org/api-reference/order/list-orders
https://1click.chaindefuser.com/docs/v0/openapi.yaml get /v0/orders
Retrieves visible orders, newest first.
**Errors.** Branch on `code`, never on `title` or `detail`. New codes arrive without a major
version, so treat an unrecognized code as the HTTP status alone.
| Status | Codes |
| --- | --- |
| 400 | `validation-failed` |
| 401 | `authentication-required` |
| 429 | `rate-limit-exceeded` |
| 500 | `internal-error` |
| 503 | `service-unavailable` |
# Authenticate User with Signed Data
Source: https://docs.near-intents.org/api-reference/user-auth/authenticate-user-with-signed-data
post /v0/auth/authenticate
Exchange a signed message for a User-Session access token
Send this endpoint a signed message from your user, and you'll get back a **User-Session** token. That token is what lets the user's confidential balances and transaction history (`GET /v0/account/balances`, `GET /v0/account/history`) be revealed. It's separate from your Partner JWT, which authenticates your integration, not an individual user.
This is part of **Confidential Intents**. See [Authenticating end users](/integration/distribution-channels/1click-api/authentication#authenticating-end-users-confidential-intents) for the full guide.
## Getting a signature to send
Your user's NEAR wallet produces `public_key` and `signature`. The steps:
1. Build a NEP-413 payload: `recipient` set to `"intents.near"`, a fresh random `nonce`, and `message` set to a stringified JSON object with an empty `intents` array plus a `deadline` and the user's `signer_id`. The empty `intents` array is what makes this a proof of ownership instead of a real swap.
2. Have the user's wallet sign that payload. The wallet returns the `publicKey` that signed it and the resulting `signature`, both prefixed `ed25519:`.
3. Send `payload`, `public_key`, and `signature` together as `signedData` on this endpoint.
If you're on `@defuse-protocol/intents-sdk`, `createIntentSignerNEP413` and `buildAndSign()` do steps 1 and 2 for you, that's what the TypeScript SDK example below uses.
## Example request
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/auth/authenticate \
-H "Content-Type: application/json" \
-d '{
"signedData": {
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hfrNi8/We0ieTmcMBti1YE=",
"message": "{\"deadline\":\"2026-07-16T12:00:00.000Z\",\"intents\":[],\"signer_id\":\"your-account.near\"}"
},
"public_key": "ed25519:YOUR_PUBLIC_KEY",
"signature": "ed25519:YOUR_SIGNATURE"
}
}'
```
```javascript JavaScript theme={null}
const response = await fetch('https://1click.chaindefuser.com/v0/auth/authenticate', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
signedData: {
standard: 'nep413',
payload: {
recipient: 'intents.near',
nonce: 'Vij2xgAlKBKzAEiS6N1S/hfrNi8/We0ieTmcMBti1YE=',
message: JSON.stringify({
deadline: '2026-07-16T12:00:00.000Z',
intents: [],
signer_id: 'your-account.near'
})
},
public_key: 'ed25519:YOUR_PUBLIC_KEY',
signature: 'ed25519:YOUR_SIGNATURE'
}
})
});
const auth = await response.json();
```
```typescript TypeScript SDK theme={null}
import { createIntentSignerNEP413, IntentsSDK } from '@defuse-protocol/intents-sdk';
import { UserAuthService } from '@defuse-protocol/one-click-sdk-typescript';
// Step 1 + 2: wire up a signer backed by the user's wallet
const signer = createIntentSignerNEP413({
accountId: userAccountId,
signMessage: async (_payload, hash) => {
const { publicKey, signature } = await userWallet.signMessage(hash);
return { publicKey: publicKey.toString(), signature: Buffer.from(signature).toString('base64') };
},
});
// Build a payload with an empty intents array (just a signature, not a real swap) and sign it
const sdk = new IntentsSDK({ referral: 'your-integration', env: 'production' });
const { signed } = await sdk
.intentBuilder()
.setDeadline(new Date(Date.now() + 5 * 60_000))
.buildAndSign(signer);
// Step 3: exchange the signed payload for a User-Session token
const auth = await UserAuthService.authenticate({ signedData: signed });
// auth.accessToken, auth.refreshToken, auth.expiresIn, auth.refreshExpiresIn
```
## Example response
```json theme={null}
{
"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"refreshToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"expiresIn": 3600,
"refreshExpiresIn": 2592000
}
```
`signedData` is the same `MultiPayload` signed-message format used for [Signing Intents](/integration/verifier-contract/signing-intents), signed here with an empty `intents` array. It's used purely as proof of account ownership, not a real swap.
Store `refreshToken` securely. Anyone holding it can mint new `accessToken`s for this account until it expires.
# Refresh Access Token
Source: https://docs.near-intents.org/api-reference/user-auth/refresh-access-token
post /v0/auth/refresh
Exchange a refresh token for a new access token
Once the `accessToken` from [Authenticate User with Signed Data](/api-reference/user-auth/authenticate-user-with-signed-data) expires, exchange `refreshToken` for a new `accessToken` without re-signing.
## Example request
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/auth/refresh \
-H "Content-Type: application/json" \
-d '{ "refreshToken": "YOUR_REFRESH_TOKEN" }'
```
```javascript JavaScript theme={null}
const response = await fetch('https://1click.chaindefuser.com/v0/auth/refresh', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ refreshToken: 'YOUR_REFRESH_TOKEN' })
});
const auth = await response.json();
```
## Example response
```json theme={null}
{
"accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"expiresIn": 3600
}
```
The response only contains a new `accessToken`, `refreshToken` itself does not rotate. Keep using the same `refreshToken` until it expires (`refreshExpiresIn` from the original authenticate call).
# Changelog
Source: https://docs.near-intents.org/changelog/overview
What's new in NEAR Intents.
## August 2026
### 1Click API: Limit Orders
Wallets and apps can rest a confidential swap at a price the user sets, through
the 1Click Swap API. This is not Perpetuals on near.com.
Offer a swap at the user's price through the 1Click Swap API.
## July 2026
### Confidential Intents B2B launch
Confidential Intents is live for B2B partners. Confidential swaps execute on a
private chain with shielded balances and settle back to public NEAR through
the Private PoA Bridge.
Two-chain architecture, shield and unshield flows, versioned nonces, and the solver response format.
### Changelog on the docs website
This changelog is now part of the docs site. New features, API changes, and
launches land here as dated entries.
Bookmark this page to track what's new in NEAR Intents.
### WebSocket-only whitelisted solvers on Confidential Intents
Solver access on the confidential relay is now gated by an allowlist.
Whitelisted solvers connect over WebSocket only, subscribing to relay streams
and responding with signed quotes; solvers not on the list are denied entirely.
Whitelisted solvers receive quote requests and respond via `quote_response` over `/ws`. Contact the Defuse team to get whitelisted.
### FE (near.com): Limit Orders on Perpetuals
Perpetuals on near.com now support limit orders. Set your price and the order
fills when the market reaches it.
Place limit orders on the Perpetuals interface at near.com.
### Shield Incident API
A partner-facing API to pull active Shield incidents and submit new ones. Use
`GET`/`POST https://shield.chaindefuser.com/incident` with a `SHIELD` API key.
Endpoints, request and response shapes, scope fields, and how to get a token.
### Confidentiality parameter
Quote requests now accept a `confidentiality` field that makes a normal quote a
confidential swap.
What changed, the two integration paths, and an example request.
## June 2026
### Verify Quote Signatures
1Click signs quote payloads so partners can verify the payload origin and detect
tampering before using fields like `depositAddress` in 1click quote response
payloads.
What is signed, how to verify, and code examples.
# What are Intents?
Source: https://docs.near-intents.org/getting-started/what-are-intents
Define desired outcomes instead of managing execution steps
An intent expresses **what you want** to achieve, **not how to get it**. Instead of writing code to bridge assets, find quotes, and execute swaps, you submit an intent such as *"I have 1 ETH on Ethereum, I want USDC on Arbitrum"*.
***
## How it works
Specify your desired outcome: the tokens you have, the tokens you want, and where you want them delivered.
Multiple market makers bid to fulfill your intent (quote request), competing on price, speed, and execution quality.
Approved quotes are submitted to a smart contract ensuring atomic execution; your swap either completes fully or you get automatically refunded.
Your requested tokens arrive at the destination address you choose, secured by on-chain verification.
***
## Key benefits
Express desired outcomes instead of managing individual steps
Solvers compete to fill orders quickly
Use your existing wallets on any supported chain
Multiple solvers compete on price and execution quality
Funds are returned if the intent cannot be executed
You maintain control of your assets throughout the process
***
## Learn more
NEAR Intents uses atomic execution enforced by smart contracts on NEAR Protocol. Transactions either complete with all conditions met, or they are reverted and funds returned to the refund address. All transactions are verified on-chain before settlement.
NEAR Intents supports major blockchains including Ethereum, NEAR, and others. The list of supported chains and tokens is continuously expanding. Check our [Chain Support page](/resources/chain-support) for the current list.
The 1Click API charges 0.2% (20 basis points) for unauthenticated requests. Authenticated users (with JWT tokens) pay no platform fees—only network gas costs and market maker spreads. [Learn more about fees](/resources/fees).
When you create an intent, it is broadcast to multiple market makers who bid to fulfill it. They compete on price, speed, and execution quality. The best execution path is selected while ensuring the intent's terms are met.
***
## Additional Resources
Explore the technical architecture and design philosophy behind NEAR Intents in this comprehensive blog post.
Learn the basics of what NEAR Intents are and how they work in this video overview.
# Refund a stuck BTC deposit
Source: https://docs.near-intents.org/integration/bridging/btc-deposit-refund
Recover Bitcoin you sent to a bridge deposit address that never finalized on NEAR
If you send BTC to a bridge deposit address but the deposit never finalizes on NEAR, the Bitcoin isn't lost. You can pull it back to a Bitcoin address you control using a manual refund flow on the BTC connector contract.
Most deposits finalize automatically — you only need this flow if yours didn't. **Confirm the deposit actually failed before you start** (see [Before you start](#before-you-start-confirm-the-deposit-never-finalized)). If you already received your bridged BTC, the deposit completed and no refund is needed.
Use this flow only when **all** of the following are true:
* You sent BTC to a bridge deposit address.
* The deposit never completed on NEAR — you never received the bridged BTC.
* You want the BTC returned to a Bitcoin address you control.
A deposit can only be refunded if it never finalized. The contract rejects the refund request if the deposit was already completed via `verify_deposit` or `safe_verify_deposit`.
## Before you start: confirm the deposit never finalized
A refund only works if your deposit never completed on NEAR. The contract has no single "is it finalized" view method, so check the *result* of finalization instead:
1. **Did you receive your bridged BTC?** Finalization mints nBTC to the recipient. If the recipient holds the nBTC, the deposit completed — you don't need a refund.
2. **The contract is the final word.** Step 1 below (`request_refund`) is rejected if the deposit already finalized via `verify_deposit` or `safe_verify_deposit` — so a successful step 1 confirms it never completed.
## How it works
The refund runs as three on-chain operations:
1. **Request the refund** — pin the original Bitcoin transaction to a refund address (`bridge-cli`).
2. **Execute the refund** — call the BTC connector contract after a timelock passes (`near-cli`).
3. **Sign the Bitcoin transaction** — trigger MPC signing so the relayer can broadcast the refund on Bitcoin (`bridge-cli`).
Steps 1 and 3 go through `bridge-cli`. Step 2 is a direct contract call through `near-cli`, because it only becomes callable after a timelock and can be invoked by anyone — not just the original depositor.
The contract that owns this flow is [`satoshi-bridge`](https://github.com/Near-One/btc-bridge), deployed on mainnet as `btc-connector.bridge.near`.
## Prerequisites
* **`bridge-cli`** — download a binary from the [releases page](https://github.com/Near-One/bridge-sdk-rs/releases/latest), or build it from source:
```bash theme={null}
git clone https://github.com/near-one/bridge-sdk-rs.git
cd bridge-sdk-rs
cargo build --release
# binary at ./target/release/bridge-cli
```
* **[`near-cli`](https://github.com/near/near-cli-rs)** — used for the `execute_refund` call in step 2.
* **The Bitcoin transaction hash** of your original deposit, and the output index (`vout`) of the deposit address within it.
* **A funded NEAR account** to sign the transactions and cover gas and storage.
Configure the NEAR signer for `bridge-cli` through environment variables (the preferred method) or a `.env` file:
```bash theme={null}
NEAR_SIGNER=
NEAR_PRIVATE_KEY=
```
## Refund the deposit
The minimal invocation is the chain and the BTC transaction hash. The CLI asks the bridge indexer which output of the transaction is a tracked deposit address, recovers the original `DepositMsg`, and uses its `refund_address` as the refund destination:
```bash theme={null}
bridge-cli mainnet btc-request-refund \
--chain btc \
--btc-tx-hash
```
**Optional arguments:**
| Argument | When to use it |
| ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--vout N` | Pick a specific output when the transaction has more than one tracked deposit address. The CLI tells you which vouts to choose from. |
| `--refund-address X` | Only used when the original `DepositMsg` has no `refund_address`. If the deposit message carries one, that address is used as the refund destination and this flag is ignored. |
| `--recipient-id`, `--fee`, `--msg`, `--no-deposit-refund-address` | Supply the original deposit args manually instead of relying on the indexer lookup. These must match the values used at deposit time — the contract recomputes the deposit address from them and rejects mismatches. |
| `--dry-run` | Print the unsigned `request_refund` NEAR transaction (base64 borsh) for offline or hardware-wallet signing instead of submitting it. Requires `--near-public-key`. |
Example with manual args (the `safe_deposit.msg` path, where `receiver_id` inside `--msg` is the intents account the deposit was routed to):
```bash theme={null}
bridge-cli mainnet btc-request-refund \
--chain btc \
--btc-tx-hash \
--recipient-id intents.near \
--refund-address bc1q.... \
--msg '{"receiver_id":"your_account.near"}'
```
After the refund request, call `execute_refund` directly on the BTC connector contract. Anyone can call it — the Bitcoin transaction is already pinned to your `refund_address` by step 1.
The wait depends on whether a refund address was set on the original deposit:
| Timelock | Condition |
| -------- | ------------------------------------------------------------------ |
| 2 days | `refund_address` was provided in the original deposit |
| 14 days | `refund_address` was **not** provided in the original deposit |
| Instant | The caller holds the DAO or `RefundOperator` role on the connector |
`utxo_storage_key` is `@` of the original deposit. Attach a deposit to cover storage for the `BTCPendingInfo` entry — the connector exposes the amount it expects through the `required_balance_for_execute_refund` view method (1 NEAR on mainnet at the time of writing):
```bash theme={null}
near contract call-function as-read-only btc-connector.bridge.near \
required_balance_for_execute_refund json-args '{}' \
network-config mainnet now
```
Pass that amount as the attached deposit:
```bash theme={null}
near contract call-function as-transaction btc-connector.bridge.near \
execute_refund \
json-args '{"utxo_storage_key":"@0"}' \
prepaid-gas '100.0 Tgas' \
attached-deposit '1 NEAR' \
sign-as your-account.near \
network-config mainnet sign-with-keychain send
```
Per the contract, this deposit covers storage for the refund and is **not** returned to you — treat it as a fee on the refund, not part of the recovered amount.
`execute_refund` creates a `BTCPendingInfo` and emits a `GenerateBtcPendingInfo` event. Find `btc_pending_id` in the event logs of the `execute_refund` transaction (NEAR explorer or `near tx-status`) and pass it below. Once signed, the relayer broadcasts the Bitcoin transaction:
```bash theme={null}
bridge-cli mainnet near-sign-btc-transaction \
--chain btc \
--btc-pending-id
```
If you run this flow and attach a sufficient fee, the relayer has a good chance of handling it for you starting from step 2.
## Notes
* If the original deposit's `DepositMsg.refund_address` was set, that address is the refund destination — `--refund-address` is ignored. The contract enforces that the refund transaction pays out to exactly that address.
* `request_refund` is rejected if the deposit was already finalized via `verify_deposit` or `safe_verify_deposit`.
* Replace all placeholder values (transaction hashes, addresses, account IDs) with your own before running any command.
## Next steps
See which bridges route assets between NEAR Intents and external chains
Learn how withdrawals move assets out through bridges
# Token Bridges
Source: https://docs.near-intents.org/integration/bridging/overview
Bridges that route assets between NEAR Intents and external blockchains
![NEAR Intents Token Bridges]()
![NEAR Intents Token Bridges]()
NEAR Intents uses multiple bridges to move assets between the Verifier contract and external blockchains. Each bridge handles a different set of chains and has its own trust model. When a [withdrawal](/integration/verifier-contract/deposits-and-withdrawals/withdrawals) is executed, the protocol selects the appropriate bridge based on the destination chain.
These bridges provide the infrastructure for moving assets between external chains and NEAR Intents.
Cross-chain transfers for major EVM chains, Solana, and Bitcoin
Proof of Authority bridge supporting the widest chain set
HOT/Omni protocol for EVM rollups, TON, Stellar, and more
***
## Omni Bridge
The Omni Bridge is designed for high-throughput transfers across the most widely used chains. It supports both EVM-compatible networks and non-EVM chains like Solana and Bitcoin.
**Supported chains:** Ethereum, Base, Arbitrum, BNB, Solana, Bitcoin
**Route ID:** `omni_bridge`
**Official documentation:** [Omni Bridge docs](https://docs.near.org/chain-abstraction/omnibridge/overview)
***
## POA Bridge
The POA (Proof of Authority) Bridge supports the widest range of chains in the NEAR Intents ecosystem. It uses a Proof of Authority consensus model to validate cross-chain transfers, covering UTXO-based chains (Bitcoin, Litecoin, Dogecoin, BCH, Zcash) and newer L1s (Sui, Aptos, Cardano, Starknet).
**Supported chains:** Ethereum, Base, Arbitrum, Gnosis, Berachain, Bitcoin, BCH, Litecoin, Dogecoin, Solana, XRP, Zcash, Tron, Sui, Aptos, Cardano, Starknet
**Route ID:** `poa_bridge`
***
## HOT Bridge
The HOT Bridge routes assets through the HOT/Omni protocol, extending NEAR Intents to chains like TON and Stellar, as well as newer EVM rollups like Scroll and Monad.
**Supported chains:** BNB, Polygon, Optimism, Avalanche, Scroll, Monad, TON, Stellar, LayerX, Adi, Plasma
**Route ID:** `hot_bridge`
**Official documentation:** [HOT Bridge docs](https://docs.hotdao.ai/omni-tokens)
***
## Next steps
Learn how withdrawals use bridges to move assets out
See the full list of supported chains and tokens
# Intents SDK
Source: https://docs.near-intents.org/integration/devkit/intents-sdk
Complete library to interact with NEAR Intents
The [NEAR Intents SDK](https://github.com/defuse-protocol/sdk-monorepo/tree/main/packages/intents-sdk) provides tools for intent execution, deposits, withdrawals, and interacting with various bridge implementations across multiple blockchains.
For a higher-level API focused on cross-chain swaps, check out the [1Click Swap API](/integration/distribution-channels/1click-api/about-1click-api) and its SDK libraries for TypeScript, Go, and Rust.
| Feature | Status | Description |
| ---------------- | :----: | ---------------------------------------------------------------------- |
| Intent Execution | ✅ | Sign, submit, and track intent execution on NEAR Intents |
| Deposits | ❌ | Deposit funds to NEAR Intents (use bridge interfaces directly) |
| Withdrawals | ✅ | Complete withdrawal functionality from NEAR Intents to external chains |
The Intents SDK provides low-level functionality for interacting with NEAR Intents, check out the [1Click Swap API](/integration/distribution-channels/1click-api/about-1click-api) for a higher-level API focused on cross-chain swaps
***
## Using the SDK
```bash theme={null}
npm install @defuse-protocol/intents-sdk --save-exact
```
```typescript theme={null}
import { IntentsSDK, createIntentSignerNearKeyPair } from '@defuse-protocol/intents-sdk';
import { KeyPair } from 'near-api-js';
const sdk = new IntentsSDK({
referral: 'your-referral-code',
intentSigner: createIntentSignerNearKeyPair({
signer: KeyPair.fromString('your-private-key'),
accountId: 'your-account.near',
}),
});
```
The most common use case — withdraw funds from NEAR Intents to an external chain:
```typescript theme={null}
const result = await sdk.processWithdrawal({
withdrawalParams: {
assetId: 'nep141:usdt.tether-token.near',
amount: 1000000n, // 1 USDT (6 decimals)
destinationAddress: '0x742d35Cc6634C0532925a3b8D84B2021F90a51A3',
feeInclusive: false,
},
});
console.log('Intent hash:', result.intentHash);
console.log('Destination tx:', result.destinationTx);
```
For advanced use cases beyond withdrawals, use the lower-level `signAndSendIntent` method:
```typescript theme={null}
const result = await sdk.signAndSendIntent({
intents: [
{
intent: 'transfer',
receiver_id: 'recipient.near',
tokens: { 'usdt.tether-token.near': '1000000' },
},
],
});
console.log('Intent hash:', result.intentHash);
```
Use `processWithdrawal` for withdrawals and `signAndSendIntent` for custom intent logic. The withdrawal method handles fee estimation, validation, and completion tracking automatically.
***
## Next steps
Explore the [Github Repository](https://github.com/defuse-protocol/sdk-monorepo/tree/main/packages/intents-sdk) for the Intents SDK to learn about asset identifiers, intent signers, withdrawals, withdrawal routes, and intent management.
# React Widget
Source: https://docs.near-intents.org/integration/devkit/react-widget
Add a cross-chain swap widget to your app in minutes
The **Intents Swap Widget** lets you integrate a fully functional, cross-chain swap interface into your application in just a few lines of code.
![Swap Widget UI]()
You can use the [Intents Widget Studio](https://intents.aurora.dev/) to customize the widget's appearance and behavior, then export the configuration for use in your app.
***
## Quickstart
Install the widget package using your preferred package manager:
```bash theme={null}
npm install @aurora-is-near/intents-swap-widget
```
Alternatively, if you want to use the widget in standalone mode with embedded wallet connection mechanisms:
```bash theme={null}
npm install @aurora-is-near/intents-swap-widget-standalone
```
Wrap your app, or just the area where the widget appears, with the `WidgetConfigProvider`, then render one of our prebuilt widgets within it.
For example, the snippet below shows how to render the combined widget.
```tsx theme={null}
import {
WidgetConfigProvider,
Widget,
} from '@aurora-is-near/intents-swap-widget';
export default function App() {
return (
);
}
```
There are also individual `WidgetSwap`, `WidgetTransfer`, and `WidgetWithdraw` widgets.
For a full list of configuration options, see the [Configuration](https://docs.intents.aurora.dev/readme-1-1) page.
To apply styles, you need to import the package styles into your app's stylesheet, for example:
```css theme={null}
@import '@aurora-is-near/intents-swap-widget/styles.css';
.my-class {
background-color: #fff;
}
```
For more details about the available theming options, see the [Theming](https://docs.intents.aurora.dev/theming) page.
If you are using standalone mode, the wallet connection mechanism is built in.
If you want to use your existing wallet integration (e.g., AppKit, Provy, TonConnect), you can pass the connected address via the `connectedWallets` config option.
Here is an example that assumes you are using [AppKit](https://docs.reown.com/appkit/overview) and have a hook that provides the wallet address and a button for connecting.
```tsx theme={null}
import {
WidgetConfigProvider,
Widget,
} from '@aurora-is-near/intents-swap-widget';
import { useAppKitWallet } from './hooks/useAppKitWallet';
import { WalletConnectButton } from './components/WalletConnectButton';
export const SimpleWidgetDemo = () => {
const { address: walletAddress, isConnecting: isLoading } = useAppKitWallet();
return (
}
/>
);
};
```
***
## Next steps
Explore the [Widget Docs](https://docs.intents.aurora.dev/readme-1-1) for detailed information on configuration options, theming, and advanced usage examples.
# Agent Skills
Source: https://docs.near-intents.org/integration/devkit/skills
Enable AI Agents to build cross-chain apps
Most modern AI Agents support the use of `skills`, which are small knowledge bases that explain how to use a particular API or tool.
By providing the `near-intents` skill to your agent, you can enable it to build cross-chain swap applications using the 1Click Swap API.
Skill repo: near/agent-skills → skills/near-intents
***
## Using the skill
Install the `near-intents` skill:
```bash theme={null}
npx skills add near/agent-skills --skill near-intents
```
Your agent should automatically pick up the `near-intents` skill, otherwise you can explicitly ask the agent to read the `SKILL.md` file to learn how to use NEAR Intents.
# 1Click Swap API
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/about-1click-api
REST API for cross-chain swaps powered by NEAR Intents
1Click Swap is a REST API that automates routing and settlement on NEAR Intents. It requests quotes from [Market Makers](/integration/market-makers/introduction), constructs the swap, and tracks execution. Assets move to a quote-specific deposit address and settle on-chain; 1Click does not take custody of them.
This REST API abstracts the complexity of intent creation, solver coordination, and transaction execution.
By using the 1Click Swap API, you agree to the [1Click Terms of Service](/security-compliance/terms-of-service).
***
## Key Benefits
Create intents, submit deposits, and track status with a few endpoints.
Market makers compete on price through automatic solver discovery.
Includes status tracking, automatic retries, and refund handling.
Configure fee collection with a single parameter in your quote requests.
***
## Ready to Dive In?
Step-by-step tutorial to make your first swap in under 10 minutes
Learn how to generate API keys and authenticate your requests
Explore our SDK libraries for TypeScript, Go, and Rust
Learn how to set up fee collection for your swaps
Offer multichain yield through the 1Click Swap API
Offer a swap at the user's price through the 1Click Swap API
Programmatic access to historical 1Click Swap transactions
Learn how NEAR Intents proactively manages suspicious fund flows, transaction risk, and security posture across swaps
# API Keys
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/authentication
Obtain a JWT token for authenticated API access
Unauthenticated requests incur a **0.2% (20 basis points)** platform fee. Authenticated requests using a JWT token are **fee-free** - you only pay network gas costs and market maker spreads.
Get your JWT token from the Partner Dashboard for authenticated API access and fee-free swaps.
***
## How to Use Your API Key
Once you have your JWT token from the Partner Dashboard, send it as `X-API-Key` on API requests. `Authorization: Bearer` is also accepted for the same partner JWT.
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "X-API-Key: YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"originAsset": "nep141:wrap.near",
"destinationAsset": "nep141:usdt.tether-token.near",
"amount": "1000000000000000000000000",
"recipient": "your-account.near",
"recipientType": "INTENTS",
"refundTo": "your-account.near",
"refundType": "INTENTS"
}'
```
```javascript JavaScript theme={null}
const response = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-API-Key': 'YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
originAsset: 'nep141:wrap.near',
destinationAsset: 'nep141:usdt.tether-token.near',
amount: '1000000000000000000000000',
recipient: 'your-account.near',
recipientType: 'INTENTS',
refundTo: 'your-account.near',
refundType: 'INTENTS'
})
});
```
```python Python theme={null}
import requests
response = requests.post(
'https://1click.chaindefuser.com/v0/quote',
headers={
'Content-Type': 'application/json',
'X-API-Key': 'YOUR_JWT_TOKEN'
},
json={
'dry': False,
'swapType': 'EXACT_INPUT',
'originAsset': 'nep141:wrap.near',
'destinationAsset': 'nep141:usdt.tether-token.near',
'amount': '1000000000000000000000000',
'recipient': 'your-account.near',
'recipientType': 'INTENTS',
'refundTo': 'your-account.near',
'refundType': 'INTENTS'
}
)
```
Store your JWT token securely and never commit it to version control. Use environment variables or secure secret management systems.
***
## Authenticating end users (Confidential Intents)
Your Partner JWT authenticates **your integration** and waives the platform fee. It does not let you read a user's confidential data. Reading private balances or confidential transaction history requires a separate **User-Session** token that proves the account owner (an end user, or a solver checking its own balance) actually controls the account, since none of that data is exposed by any public endpoint.
### Get a User-Session token
`public_key` and `signature` aren't something you type in, they come from having the account owner's wallet sign a message:
1. Build a `MultiPayload` message: `recipient` set to `"intents.near"`, a fresh `nonce`, and `message` set to a stringified JSON object with an empty `intents` array plus a `deadline` and the account's `signer_id`. The empty `intents` array is what makes this a proof of ownership instead of a real swap, see [Signing Intents](/integration/verifier-contract/signing-intents) for the full `MultiPayload` spec across every supported wallet standard.
2. Have that account's wallet sign the message. The wallet returns the `public_key` that signed and the resulting `signature`.
3. Send `payload`, `public_key`, and `signature` together as `signedData` to `/v0/auth/authenticate`.
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/auth/authenticate \
-H "Content-Type: application/json" \
-d '{
"signedData": {
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hfrNi8/We0ieTmcMBti1YE=",
"message": "{\"deadline\":\"2026-07-16T12:00:00.000Z\",\"intents\":[],\"signer_id\":\"your-account.near\"}"
},
"public_key": "ed25519:YOUR_PUBLIC_KEY",
"signature": "ed25519:YOUR_SIGNATURE"
}
}'
```
```typescript TypeScript SDK theme={null}
import { createIntentSignerNEP413, IntentsSDK } from '@defuse-protocol/intents-sdk';
import { UserAuthService } from '@defuse-protocol/one-click-sdk-typescript';
// Step 1 + 2: wire up a signer backed by the account's wallet
const signer = createIntentSignerNEP413({
accountId: userAccountId,
signMessage: async (_payload, hash) => {
const { publicKey, signature } = await userWallet.signMessage(hash);
return { publicKey: publicKey.toString(), signature: Buffer.from(signature).toString('base64') };
},
});
// Build a payload with an empty intents array and sign it
const sdk = new IntentsSDK({ referral: 'your-integration', env: 'production' });
const { signed } = await sdk
.intentBuilder()
.setDeadline(new Date(Date.now() + 5 * 60_000))
.buildAndSign(signer);
// Step 3: exchange the signed payload for a User-Session token
const auth = await UserAuthService.authenticate({ signedData: signed });
// auth.accessToken, auth.refreshToken, auth.expiresIn, auth.refreshExpiresIn
```
| Field | Description |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `accessToken` | Short-lived bearer token. Send it as `Authorization: Bearer ` on `GET /v0/account/balances` and `GET /v0/account/history` |
| `refreshToken` | Exchange this for a new `accessToken` without re-signing |
| `expiresIn` / `refreshExpiresIn` | Lifetime of `accessToken` / `refreshToken`, in seconds |
### Refresh a token
When `accessToken` expires, exchange `refreshToken` for a new one instead of re-signing:
```bash theme={null}
curl -X POST https://1click.chaindefuser.com/v0/auth/refresh \
-H "Content-Type: application/json" \
-d '{ "refreshToken": "YOUR_REFRESH_TOKEN" }'
```
Returns a new `{ accessToken, expiresIn }`.
See this flow wired into a real solver in [Confidential Example → Authentication](/integration/market-makers/confidential-example#authentication).
# Earn
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/earn
Offer multichain yield through the 1Click Swap API
Earn lets wallets and apps route users into third-party yield protocols through the [1Click Swap API](./about-1click-api). The user pays a supported asset; NEAR Intents coordinates execution; the user receives **fungible receipt tokens** (for example vault shares) that represent the position.
NEAR Intents does not run these yield protocols, set their APY, or guarantee principal. Protocols are operated by independent providers. See [§7 Special asset types](/security-compliance/terms-of-service#7-special-asset-types-and-disclaimers).
***
## Integration model
Earn uses the standard 1Click lifecycle:
1. Resolve `assetId`s with [`GET /v0/tokens`](#yield-and-receipt-assets).
2. Request a quote with [`POST /v0/quote`](./quickstart/making-a-request).
3. Complete the deposit and track status with [`GET /v0/status`](./quickstart/making-a-request).
Deposit quotes use a payment asset as `originAsset` and a receipt token as `destinationAsset`. Withdraw quotes reverse that. Use the same [swap types](./swap-types) as other 1Click quotes.
These fields control where value is taken from and where it is delivered:
| Field | On deposit | On withdraw |
| ----------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------ |
| `depositType` | Where the **payment** comes from (`ORIGIN_CHAIN` or `INTENTS`) | Where the **shares** come from (`ORIGIN_CHAIN` or `INTENTS`) |
| `recipient` / `recipientType` | Where the **receipt tokens** go (`DESTINATION_CHAIN` or `INTENTS`) | Where the **payout** goes (`DESTINATION_CHAIN` or `INTENTS`) |
Deposit and withdraw examples below cover both delivery options.
***
## Yield and receipt assets
```bash theme={null}
curl https://1click.chaindefuser.com/v0/tokens
```
Only instruments that appear in this list and return quotes are available for Earn via 1Click. Look up the receipt token and payment asset by `symbol` (or other fields you care about) and use the returned `assetId` values in quotes.
You can request additional protocol support. Protocols already listed in the [Yield.xyz DeFi yields](https://docs.yield.xyz/docs/defi-yields) catalog are usually faster to add than those outside it.
For the examples on this page we use two vault-share symbols that are listed today — **`TLO`** and **`gtUSDCp`** — plus **USDC** as the payment asset. Treat the `assetId` strings in the snippets as illustrative snapshots; always take current IDs from `/v0/tokens` before you ship.
Listings and liquidity can change. A quote may return `No liquidity available` or reject an unsupported delivery mode for a given asset.
See [Asset support](/resources/asset-support).
***
## Deposit — destination-chain wallet
Use this when the user should receive receipt tokens on the protocol’s chain.
Set `recipient` to their address on that chain and `recipientType` to `DESTINATION_CHAIN`. Highlighted lines are the delivery fields.
Example below: Ethereum USDC → `TLO`, delivered to an Ethereum address. Resolve both `assetId`s from `/v0/tokens` (symbols `USDC` on `eth`, `TLO` on `eth`).
```bash cURL {12,13} theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"destinationAsset": "nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near",
"amount": "100000000",
"depositType": "ORIGIN_CHAIN",
"recipient": "0xYourEvmAddress",
"recipientType": "DESTINATION_CHAIN",
"refundTo": "0xYourEvmAddress",
"refundType": "ORIGIN_CHAIN",
"deadline": "2026-12-31T00:00:00.000Z"
}'
```
```typescript TypeScript {16,17} theme={null}
const quote = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
slippageTolerance: 100,
originAsset: 'nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near',
destinationAsset: 'nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near',
amount: '100000000',
depositType: 'ORIGIN_CHAIN',
recipient: '0xYourEvmAddress',
recipientType: 'DESTINATION_CHAIN',
refundTo: '0xYourEvmAddress',
refundType: 'ORIGIN_CHAIN',
deadline: '2026-12-31T00:00:00.000Z'
})
});
```
`amount` `100000000` is 100 USDC (6 decimals). The same pattern works with other listed receipt tokens that quote for destination-chain delivery.
***
## Deposit — Intents balance
Use this when the user should hold receipt tokens in Intents (bridged to NEAR) instead of on the protocol’s chain.
Set `recipient` to their Intents account and `recipientType` to `INTENTS`. Highlighted lines are what differs from destination-chain delivery.
Example below: Ethereum USDC → `TLO`, held in Intents. Same symbols as above; only delivery fields change.
```bash cURL {12,13} theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"destinationAsset": "nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near",
"amount": "100000000",
"depositType": "ORIGIN_CHAIN",
"recipient": "user.near",
"recipientType": "INTENTS",
"refundTo": "0xYourEvmAddress",
"refundType": "ORIGIN_CHAIN",
"deadline": "2026-12-31T00:00:00.000Z"
}'
```
```typescript TypeScript {16,17} theme={null}
const quote = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
slippageTolerance: 100,
originAsset: 'nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near',
destinationAsset: 'nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near',
amount: '100000000',
depositType: 'ORIGIN_CHAIN',
recipient: 'user.near',
recipientType: 'INTENTS',
refundTo: '0xYourEvmAddress',
refundType: 'ORIGIN_CHAIN',
deadline: '2026-12-31T00:00:00.000Z'
})
});
```
You can use the same Intents delivery with other listed shares (for example `gtUSDCp`). Replace `recipient`, `refundTo`, and the JWT as needed. After the quote, deposit and track status as in the [Quickstart](./quickstart/making-a-request).
***
## Withdraw — payout to destination-chain wallet
Quote from the receipt token back to a payment asset. Use the user’s share balance as `amount`.
Example below: redeem `TLO` held in Intents (`depositType: INTENTS`) to Ethereum USDC on a chain wallet. `amount` `10000000000` is **100 `TLO`** at 8 decimals — confirm decimals from `/v0/tokens`. Highlighted lines are the payout delivery fields.
```bash cURL {12,13} theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near",
"destinationAsset": "nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"amount": "10000000000",
"depositType": "INTENTS",
"recipient": "0xYourEvmAddress",
"recipientType": "DESTINATION_CHAIN",
"refundTo": "user.near",
"refundType": "INTENTS",
"deadline": "2026-12-31T00:00:00.000Z"
}'
```
```typescript TypeScript {16,17} theme={null}
const quote = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
slippageTolerance: 100,
originAsset: 'nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near',
destinationAsset: 'nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near',
amount: '10000000000',
depositType: 'INTENTS',
recipient: '0xYourEvmAddress',
recipientType: 'DESTINATION_CHAIN',
refundTo: 'user.near',
refundType: 'INTENTS',
deadline: '2026-12-31T00:00:00.000Z'
})
});
```
## Withdraw — payout to Intents balance
Use this when the payout should stay in Intents. Same redeem as above; only delivery fields change. Highlighted lines are what differs.
```bash cURL {12,13} theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near",
"destinationAsset": "nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"amount": "10000000000",
"depositType": "INTENTS",
"recipient": "user.near",
"recipientType": "INTENTS",
"refundTo": "user.near",
"refundType": "INTENTS",
"deadline": "2026-12-31T00:00:00.000Z"
}'
```
```typescript TypeScript {16,17} theme={null}
const quote = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
slippageTolerance: 100,
originAsset: 'nep141:eth-0x0f38f1ce62776d4a0038bc6cac66877a5687383b.omft.near',
destinationAsset: 'nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near',
amount: '10000000000',
depositType: 'INTENTS',
recipient: 'user.near',
recipientType: 'INTENTS',
refundTo: 'user.near',
refundType: 'INTENTS',
deadline: '2026-12-31T00:00:00.000Z'
})
});
```
Quote from the balance you intend to redeem; do not assume a fixed share-to-underlying rate. The same shapes work for other listed shares such as `gtUSDCp`. If the shares sit on the origin chain, set `depositType` (and matching refund fields) to `ORIGIN_CHAIN` and keep choosing payout with `recipientType` as above.
***
## APY
The 1Click API does not return protocol metadata such as APY. When you show rates in your UI, load them from the Yield.xyz aggregator API:
1. Use [List yields](https://docs.yield.xyz/reference/yieldscontroller_getyields) to find the yield that matches your receipt token (for example by protocol or token symbol).
2. Use [Get a yield](https://docs.yield.xyz/reference/yieldscontroller_getyield) for that yield’s APY and other metadata.
Yield.xyz data is third-party; it is not returned or guaranteed by 1Click.
***
## Fees and disclosures
* 1Click platform fees apply as for other quotes ([Fee configuration](./fee-config), [Fees](/resources/fees)).
* Third-party protocols may charge their own fees.
* Yield, share price, and principal are not guaranteed by NEAR Intents.
* End-user disclosures for yield assets should align with [Terms of Service §7](/security-compliance/terms-of-service#7-special-asset-types-and-disclaimers).
***
## Related
Quote, deposit, and status for 1Click swaps
EXACT\_INPUT, EXACT\_OUTPUT, and deposit handling
Live token catalog from the 1Click API
Yield-bearing assets and Earn
# Explorer API
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/explorer/introduction
Programmatic access to historical 1Click Swap transactions
The Explorer API provides read-only access to historical 1Click Swap transactions and their statuses, mirroring the data available on the [NEAR Intents Explorer](https://explorer.near-intents.org/).
**Base URL:** `https://explorer.near-intents.org/api/v0`
***
## Overview
This API is designed for distribution channels and analytical services that need to:
* Retrieve historical swap transaction data
* Filter swaps by chains, tokens, timestamps, and status
* Build dashboards and analytics tools
* Monitor swap activity programmatically
The Explorer API is read-only and specifically for 1Click Swap transactions.
## Authentication
Include the token in your requests:
```bash theme={null}
curl -X GET "https://explorer.near-intents.org/api/v0/transactions" \
-H "Authorization: Bearer YOUR_JWT_TOKEN"
```
A JWT token is **required** for all requests. Get your token from the [Partner Dashboard](https://partners.near-intents.org/).
***
## Rate Limiting
All API endpoints are rate-limited per partner:
* **1 request every 5 seconds** per partner ID
* Rate limits are enforced based on your JWT token
* Exceeding the limit returns `429 Too Many Requests`
***
## Endpoints
Cursor-based pagination for efficient traversal
***
## API Specification
Interactive API documentation
Download the YAML specification
# Fee Configuration
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/fee-config
Configure fee collection and aggregation
Configure how fees are collected and distributed when using the [1Click Swap API](/integration/distribution-channels/1click-api/about-1click-api). As a distribution channel, you can add your own fees on top of the base platform fees.
This guide covers **distribution channel fees** (fees you collect). For an overview of all platform fees including protocol fees and API fees, see [Fees](/resources/fees).
***
## Fee Parameters
Include these parameters in the `appFees` array when requesting a quote:
| Parameter | Type | Description |
| ----------- | ------ | --------------------------------------------------------------------------------------------------- |
| `recipient` | string | Any NEAR-supported address (named account like `alice.near`, implicit account, or EVM-like address) |
| `fee` | number | Fee in basis points. `100` = `1.00%`. Fee is charged from the input token. |
* **Conversion formula:** `percentage = fee / 10,000` (e.g. `fee: 50` equals 0.5% fee)
* **Constraints:** Fee range: `0` to `500` (where `500` = 5%)
A **50/50 revenue share** applies by default — half of the `fee` amount goes to your `recipient` address and half goes to the 1Click protocol address. For example, `"fee": 10` means 5 bps to you and 5 bps to 1Click.
***
## How Fees Are Applied
Fees are calculated differently depending on the swap type:
For EXACT\_INPUT swaps, the fee is deducted from your input amount before the swap:
1. `net_in = amount_in * (1 - p)` where `p = fee / 10,000`
2. The quote calculates `amount_out` from `net_in`
3. `fee_amount = amount_in - net_in` (deducted in input token)
**Example:**
* Input: `amount_in = 1,000,000`, `fee = 100` (1%)
* Calculation: `net_in = 1,000,000 * (1 - 0.01) = 990,000`
* User deposits `1,000,000` and quote calculates output from `990,000`
* Fee: `10,000` units (in input token)
For EXACT\_OUTPUT swaps, the fee increases the required input amount:
1. `net_in = min_amount_in * (1 + p)` where `p = fee / 10,000`
2. `fee_amount = net_in - min_amount_in` (deducted in input token)
3. If user deposits more than `min_amount_in`, fees are deducted from actual `amount_in`
**Example:**
* Input: `min_amount_in = 500,000`, `fee = 100` (1%)
* Calculation: `net_in = 500,000 * (1 + 0.01) = 505,000`
* User must deposit `505,000` to receive the exact output amount
* Fee: `5,000` units (in input token)
FLEX\_INPUT is input-side like EXACT\_IN, so the fee is deducted from the input token. Because the deposit amount can vary within the quoted band, the fee is applied to whatever is actually deposited:
1. `net_in = amount_in * (1 - p)` where `p = fee / 10,000` and `amount_in` is the actual deposit
2. The quote calculates `amount_out` from `net_in`
3. `fee_amount = amount_in - net_in` (deducted in input token)
**Example** (quote band `0.99–1.00 NEAR`, `fee = 100` / 1%):
* User deposits `amount_in = 1,000,000`
* Calculation: `net_in = 1,000,000 * (1 - 0.01) = 990,000`
* Output is calculated from `990,000`
* Fee: `10,000` units (in input token)
A smaller deposit within the band pays a proportionally smaller fee, since the percentage applies to the actual amount deposited.
```json theme={null}
{
"dry": false,
"swapType": "EXACT_INPUT",
"originAsset": "nep141:wrap.near",
"destinationAsset": "nep141:usdt.tether-token.near",
"amount": "1000000000000000000000000",
"recipient": "user.near",
"recipientType": "INTENTS",
"refundTo": "user.near",
"refundType": "INTENTS",
"appFees": [{
"recipient": "your-fee-wallet.near",
"fee": 50
}]
}
```
***
## Fee Aggregation
For high-volume integrations that collect fees in many different tokens, the `ANY_INPUT` swap type aggregates them all into a single destination asset and withdraws automatically.
To compare `ANY_INPUT` with the other swap types, see the [Swap Types](./swap-types) page.
### How it works
* Deposits in **any supported token** are sent to one dedicated `depositAddress` and accumulate there.
* A background job continuously swaps everything to your chosen `destinationAsset` and withdraws it to `recipient` once the pool reaches **\$1,000 USD**.
* The `deadline` is checked only when the quote is **created** — after that the quote runs **indefinitely**, so a single quote keeps collecting and withdrawing without being refreshed.
* Failed swaps retry every 5 minutes.
**No refunds.** If a swap fails it retries automatically rather than returning funds — set `refundTo` to an address you control as a safety measure.
### Set it up
Every request must include an `Authorization: Bearer YOUR_JWT_TOKEN` header to receive the quote and its `depositAddress`. Get your API key from the [Partner Dashboard](https://partners.near-intents.org/).
Request a quote with `originAsset: "1cs_v1:any"` and `amount: "0"` to get a dedicated `depositAddress` for fee collection.
```json theme={null}
{
"dry": false,
"swapType": "ANY_INPUT",
"slippageTolerance": 0,
"originAsset": "1cs_v1:any",
"depositType": "INTENTS",
"destinationAsset": "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near",
"amount": "0",
"refundTo": "your-wallet.near",
"refundType": "INTENTS",
"recipient": "0x1ddA60d784483FBB54304c68830d42A706327C6d",
"recipientType": "DESTINATION_CHAIN",
"deadline": "2025-01-01T00:00:00.000Z",
"referral": "YOUR_REFERRAL",
"quoteWaitingTimeMs": 10000
}
```
| Field | Description |
| ------------------ | ---------------------------------------------- |
| `originAsset` | Must be `"1cs_v1:any"` for fee aggregation |
| `destinationAsset` | Token you want to collect fees in |
| `recipient` | Address where converted fees will be withdrawn |
| `recipientType` | `"DESTINATION_CHAIN"` or `"INTENTS"` |
| `refundTo` | Set to an address you control |
Set `quoteWaitingTimeMs` to 5000–10000ms for optimal performance (3–4s is often enough).
Use the `depositAddress` from the quote response as the `appFees.recipient` in your user quotes (see [Fee Parameters](#fee-parameters)). Collected fees now flow to the aggregation address and convert automatically.
### Track withdrawals
Use the `/v0/any-input/withdrawals` endpoint to retrieve withdrawal records for your deposit address.
**Request:**
```bash theme={null}
GET /v0/any-input/withdrawals?depositAddress=YOUR_DEPOSIT_ADDRESS
```
Records are filtered by `depositAddress` and sorted by `timestamp` (newest first). Page through results with these query parameters:
| Parameter | Description |
| ---------------- | ------------------------------------------------------------------- |
| `depositAddress` | **Required.** The deposit address whose withdrawals you're fetching |
| `depositMemo` | Memo, if the deposit address requires one |
| `timestampFrom` | Only return withdrawals from this ISO timestamp onward |
| `page` | Page number (default `1`) |
| `limit` | Records per page (max and default `50`) |
| `sortOrder` | `asc` or `desc` by `timestamp` (default `desc`) |
**Response:**
```json theme={null}
{
"recipient": "0x88b9da55b59a59751424b357cf8aea239770944c",
"affiliateRecipient": "2fd5aba4dc4729dcaec040242fc3b0b1faf8c81f74831c7c7843c6a96ad28add",
"asset": "nep141:base-0x833589fcd6edb6e08f4c7c32d4f71b54bda02913.omft.near",
"withdrawals": [
{
"status": "SUCCESS",
"amountOut": "140735",
"amountOutFormatted": "0.140735",
"amountOutUsd": "0.140693483175",
"withdrawFee": "2400",
"withdrawFeeFormatted": "0.0024",
"withdrawFeeUsd": "0.0023992919999999995",
"timestamp": "2025-10-07T10:16:19.702Z",
"hash": "0xcc005d3e3340c61b1240905c4e383d8b8ecb114a827bef3e0394293997406621"
}
]
}
```
**Response Fields:**
| Field | Description |
| ---------------------- | ---------------------------------------------------------------------------------------------- |
| `recipient` | The `destinationAsset` address these fees are withdrawn to (top-level, applies to all records) |
| `affiliateRecipient` | Internal identifier for this fee-collection deposit address (top-level) |
| `asset` | The `destinationAsset` fees are converted into (top-level) |
| `status` | Withdrawal status (e.g., `SUCCESS`) |
| `amountOut` | Raw amount withdrawn |
| `amountOutFormatted` | Human-readable amount |
| `amountOutUsd` | USD value at time of withdrawal |
| `withdrawFee` | Fee charged for withdrawal, in the smallest unit |
| `withdrawFeeFormatted` | Human-readable withdrawal fee |
| `timestamp` | When the withdrawal occurred |
| `hash` | Transaction hash |
# Hyperliquid
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/hyperliquid
Send USDC to Hyperliquid, or deposit USDC from Hyperliquid, through the 1Click Swap API
You can send USDC to Hyperliquid, and deposit USDC from Hyperliquid, through the [1Click Swap API](./about-1click-api). Same [quote, deposit, and status](./quickstart/making-a-request) flow as any other swap.
### Hyperliquid USDC
`1cs_v1:hypercore:hip1:0x6d1e7cde53ba9467b783cb7c530ce054` (8 decimals)
***
## Send USDC to Hyperliquid
Set `destinationAsset` to Hyperliquid USDC and `recipient` to the user's Hyperliquid `0x` address. USDC is credited to their Hyperliquid **perps** balance.
| Field | Value |
| ------------------ | ----------------------------------- |
| `destinationAsset` | Hyperliquid USDC |
| `recipient` | User's Hyperliquid EVM `0x` address |
| `recipientType` | `DESTINATION_CHAIN` |
| `swapType` | `EXACT_INPUT` or `EXACT_OUTPUT` |
Funds do not arrive as HyperEVM ERC-20 or in Hyperliquid spot.
Example: Ethereum USDT → Hyperliquid USDC. Highlighted lines are the Hyperliquid fields.
```bash cURL {9,12,13} theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near",
"destinationAsset": "1cs_v1:hypercore:hip1:0x6d1e7cde53ba9467b783cb7c530ce054",
"amount": "5000000",
"depositType": "ORIGIN_CHAIN",
"recipient": "0xYOUR_HYPERLIQUID_ADDRESS",
"recipientType": "DESTINATION_CHAIN",
"refundTo": "0xYOUR_ETHEREUM_ADDRESS",
"refundType": "ORIGIN_CHAIN",
"deadline": "2026-12-31T00:00:00.000Z"
}'
```
```typescript TypeScript {12,15,16} theme={null}
const quote = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
slippageTolerance: 100,
originAsset: 'nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near',
destinationAsset: '1cs_v1:hypercore:hip1:0x6d1e7cde53ba9467b783cb7c530ce054',
amount: '5000000',
depositType: 'ORIGIN_CHAIN',
recipient: '0xYOUR_HYPERLIQUID_ADDRESS',
recipientType: 'DESTINATION_CHAIN',
refundTo: '0xYOUR_ETHEREUM_ADDRESS',
refundType: 'ORIGIN_CHAIN',
deadline: '2026-12-31T00:00:00.000Z'
})
});
```
`amount` `5000000` is 5 USDT on Ethereum (6 decimals, origin). Then send `quote.amountIn` to `quote.depositAddress` and track status as in the [Quickstart](./quickstart/making-a-request).
***
## Deposit USDC from Hyperliquid
Same `POST /v0/quote` as above, with origin and destination swapped.
| Field | Value |
| ------------- | ---------------- |
| `originAsset` | Hyperliquid USDC |
| `depositType` | `ORIGIN_CHAIN` |
Example: Hyperliquid USDC → Ethereum USDT. Highlighted lines are the Hyperliquid fields.
```bash cURL {8,11} theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "1cs_v1:hypercore:hip1:0x6d1e7cde53ba9467b783cb7c530ce054",
"destinationAsset": "nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near",
"amount": "500000000",
"depositType": "ORIGIN_CHAIN",
"recipient": "0xYOUR_ETHEREUM_ADDRESS",
"recipientType": "DESTINATION_CHAIN",
"refundTo": "0xYOUR_HYPERLIQUID_ADDRESS",
"refundType": "ORIGIN_CHAIN",
"deadline": "2026-12-31T00:00:00.000Z"
}'
```
```typescript TypeScript {11,14} theme={null}
const quote = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
slippageTolerance: 100,
originAsset: '1cs_v1:hypercore:hip1:0x6d1e7cde53ba9467b783cb7c530ce054',
destinationAsset: 'nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near',
amount: '500000000',
depositType: 'ORIGIN_CHAIN',
recipient: '0xYOUR_ETHEREUM_ADDRESS',
recipientType: 'DESTINATION_CHAIN',
refundTo: '0xYOUR_HYPERLIQUID_ADDRESS',
refundType: 'ORIGIN_CHAIN',
deadline: '2026-12-31T00:00:00.000Z'
})
});
```
`amount` `500000000` is 5 USDC (8 decimals).
### Deposit fee
A flat **0.2 USDC** is deducted from each USDC transfer to the deposit address.
Example: **5 USDC** arrives → **4.8 USDC** is credited to Intents, then paid out to `recipient`.
Send `quote.amountIn`. Do not add 0.2 on top.
### Minimum deposit
Minimum deposit is **0.5 USDC**. Smaller amounts are not processed.
### Transfer methods
Hyperliquid network/gas fees are paid on the transfer and are **not** part of the USDC figures.
Supported. Spot or perp — the standard **Send** in the Hyperliquid app.
Send `quote.amountIn`.
Supported. Spot only — USDC transfer on Hyperliquid spot.
Send `quote.amountIn`.
Partial. Perp only. Extra **1 USDC** is deducted on top of the 0.2 USDC deposit fee.
Send `quote.amountIn` **+ 1 USDC**. Sending only `amountIn` (e.g. 10) credits **8.80** (10 − 1 − 0.2) and can leave the quote in `INCOMPLETE_DEPOSIT`.
NEAR Intents gives no guarantees of processing or crediting of funds for:
* Any bridge transfer directly to the deposit address (CCTP, the native Arbitrum ↔ Hyperliquid bridge, and similar)
* Any transfer method not listed above
# Limit Orders
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/orders
Offer a swap at the user's price through the 1Click Swap API
Limit Orders let wallets and apps rest a swap at a price the user sets, through the [1Click Swap API](./about-1click-api).
Limit orders run as confidential 1Click swaps. They are not Perpetuals on near.com. See [Confidential Swaps](./quickstart/confidential-swaps) and the [1Click Terms of Service](/security-compliance/terms-of-service).
***
## Place a limit order
Sell **1 NEAR** for Ethereum USDC at **5 USDC** per NEAR. The user pays on NEAR; filled USDC goes to their Ethereum address. Partial fills are allowed.
1. Look up both `assetId`s with [`GET /v0/tokens`](#tokens).
2. Create the order with `POST /v0/orders`.
3. Send the amount on `swapView` to `depositAddress`, then poll [`GET /v0/orders/{orderId}`](#watch-the-order).
You send `quantity`, `side`, and `price`. `quantity` is the base in smallest units. `price` is quote per one base — `"5"` is 5 USDC per 1 NEAR.
This page uses NEAR (24 decimals) and Ethereum USDC (6 decimals):
| | `SELL` | `BUY` |
| ----------- | ------------------- | ------------------- |
| `quantity` | 1 NEAR (`10^24`) | 1 NEAR (`10^24`) |
| You deposit | 1 NEAR (`10^24`) | 5 USDC (`5 × 10^6`) |
| You receive | 5 USDC (`5 × 10^6`) | 1 NEAR (`10^24`) |
The quote-side amount is `quantity × price × 10^quoteDecimals / 10^baseDecimals`, rounded up to a whole smallest unit. [After create](#create), send the amount on `swapView`.
***
## Tokens
```bash theme={null}
curl https://1click.chaindefuser.com/v0/tokens
```
Look up both sides of the pair by `symbol` (or other fields you care about) and use the returned `assetId` as `baseAsset` and `quoteAsset`. Take `decimals` from the same object.
For the examples on this page:
| | `symbol` | `blockchain` | `decimals` |
| ----- | -------- | ------------ | ---------- |
| Base | `wNEAR` | `near` | 24 |
| Quote | `USDC` | `eth` | 6 |
`baseAsset` is `nep141:wrap.near`. `quoteAsset` is `nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near`. Treat those `assetId` strings as snapshots; take current IDs from `/v0/tokens` before you ship.
See [Asset support](/resources/asset-support).
***
## Authorization
Send a [partner JWT](./authentication) as `X-API-Key` for your app. If the user is signing in, send their [User-Session](./authentication#authenticating-end-users-confidential-intents) as `Authorization: Bearer`.
Use that same identity on create, get, list, and cancel so you can keep managing the order.
***
## Create
The user pays on the origin chain and receives filled output on a destination-chain address.
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/orders \
-H "Content-Type: application/json" \
-H "X-API-Key: YOUR_JWT_TOKEN" \
-d '{
"data": {
"type": "orders",
"attributes": {
"orderType": "LIMIT",
"baseAsset": "nep141:wrap.near",
"quoteAsset": "nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"quantity": "1000000000000000000000000",
"side": "SELL",
"price": "5",
"depositType": "ORIGIN_CHAIN",
"refundTo": "your-account.near",
"refundType": "ORIGIN_CHAIN",
"recipient": "0xYourEvmAddress",
"recipientType": "DESTINATION_CHAIN",
"confidentiality": "basic"
}
}
}'
```
```typescript TypeScript theme={null}
const created = await fetch('https://1click.chaindefuser.com/v0/orders', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-API-Key': 'YOUR_JWT_TOKEN'
},
body: JSON.stringify({
data: {
type: 'orders',
attributes: {
orderType: 'LIMIT',
baseAsset: 'nep141:wrap.near',
quoteAsset: 'nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near',
quantity: '1000000000000000000000000',
side: 'SELL',
price: '5',
depositType: 'ORIGIN_CHAIN',
refundTo: 'your-account.near',
refundType: 'ORIGIN_CHAIN',
recipient: '0xYourEvmAddress',
recipientType: 'DESTINATION_CHAIN',
confidentiality: 'basic'
}
}
})
});
const order = await created.json();
const orderId = order.data.id;
const { depositAddress, depositMemo, swapView } = order.data.attributes;
```
| Response | Next step |
| ---------------- | ---------------------------------------------------- |
| `id` | Poll and cancel |
| `depositAddress` | Send the deposit here |
| `swapView` | How much to send |
| `depositMemo` | Include it on the transfer when the response has one |
Send `swapView.amountIn` on a SELL, or `swapView.maxAmountIn` on a BUY, to `depositAddress`. You can optionally notify 1Click with [`POST /v0/deposit/submit`](/api-reference/oneclick/submit-deposit-transaction-hash).
`swapView.swapType` is `EXACT_INPUT` on a SELL and `EXACT_OUTPUT` on a BUY. See [Swap types](./swap-types).
The order stays open until it fills, you cancel it, or `deadline` (default 7 days). `timeInForce` is `GTC`.
| Optional | Default |
| ------------- | ------------------------------------------------------------------------- |
| `timeInForce` | `GTC` (only value) |
| `deadline` | 7 days from creation |
| `appFees` | None. If set, deducted from input. See [Fee configuration](./fee-config). |
***
## Watch the order
Poll until `isPayoutStatusFinal` is `true`. That's when filled output has been withdrawn and any unfilled amount refunded (`COMPLETED` or `FAILED`).
```bash theme={null}
curl "https://1click.chaindefuser.com/v0/orders/ORDER_ID" \
-H "X-API-Key: YOUR_JWT_TOKEN"
```
While you wait, `fillStatus` is the matching state:
| `fillStatus` | Meaning |
| ------------------ | --------------------------------------------- |
| `AWAITING_DEPOSIT` | Waiting for the deposit |
| `OPEN` | Funded, resting |
| `PARTIALLY_FILLED` | Some quantity filled, rest still working |
| `FILLED` | Fully matched |
| `PENDING_CANCEL` | Cancel requested; a last slice can still fill |
| `CANCELED` | Canceled |
| `EXPIRED` | Deadline passed |
When payout is final, `payouts` has the `withdrawal` and `refund` legs (`txHash` on completed legs). `partialFills` are fills that already executed. `depositedAmount` is how much was funded.
Once the order is in flight, extra deposits are not applied to it. They come back separately from the unfilled refund (`payouts.refund`).
***
## Cancel
```bash theme={null}
curl -X POST "https://1click.chaindefuser.com/v0/orders/ORDER_ID/cancel" \
-H "X-API-Key: YOUR_JWT_TOKEN"
```
Cancel is asynchronous. Matching stops; filled output is still withdrawn and the unfilled remainder is refunded. A last slice can still fill, so the order may end `FILLED` instead of `CANCELED`.
***
## List
`GET /v0/orders` returns your orders, newest first. Page with `page[after]` and `page[size]` (1–50, default 50). `links.next` is `null` on the last page.
| Query | Purpose |
| ----------------------------- | --------------------------------------------- |
| `filter[fillStatus]` | One or more fill statuses (repeat the param). |
| `filter[isPayoutStatusFinal]` | `true` when payout has finished. |
| `page[after]` | Cursor from the previous page. |
| `page[size]` | Page length, max 50. |
```bash theme={null}
curl "https://1click.chaindefuser.com/v0/orders?filter[isPayoutStatusFinal]=false&page[size]=20" \
-H "X-API-Key: YOUR_JWT_TOKEN"
```
***
## If the user already holds an Intents balance
Use this when the payment already sits in Intents or Confidential Intents — an in-app balance, for example [near.com](https://near.com).
On create, set `depositType`, `refundType`, and `recipientType` to `INTENTS` or `CONFIDENTIAL_INTENTS`. Then fund the order with [signed intent execution](./quickstart/signed-intent-execution): generate an intent against the order's `depositAddress`, have the user sign it, and submit it.
```bash theme={null}
curl -X POST https://1click.chaindefuser.com/v0/orders \
-H "Content-Type: application/json" \
-H "Authorization: Bearer USER_ACCESS_TOKEN" \
-d '{
"data": {
"type": "orders",
"attributes": {
"orderType": "LIMIT",
"baseAsset": "nep141:wrap.near",
"quoteAsset": "nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"quantity": "1000000000000000000000000",
"side": "SELL",
"price": "5",
"depositType": "CONFIDENTIAL_INTENTS",
"refundTo": "user.near",
"refundType": "CONFIDENTIAL_INTENTS",
"recipient": "user.near",
"recipientType": "CONFIDENTIAL_INTENTS",
"confidentiality": "basic"
}
}
}'
```
| Step | Who |
| --------------------------------------------- | -------------------------------------------------- |
| Generate against the order's `depositAddress` | `X-API-Key` with a [partner JWT](./authentication) |
| Sign | User |
| Submit | `X-API-Key` with a [partner JWT](./authentication) |
Each generate call covers the remaining unfunded amount.
***
## Fees
1Click platform fees apply as for other flows ([Fee configuration](./fee-config), [Fees](/resources/fees)). Optional `appFees` on create are deducted from input.
***
## If it fails
Errors come back as `errors[]` with a stable `code`. Use `code` when you handle them. Include `meta.correlationId` if you report a problem.
| Situation | `code` |
| ---------------------------------------------------------------- | --------------------- |
| `confidentiality` was `public`, or a field was invalid | `validation-failed` |
| Amount below the USD minimum, or create/cancel could not proceed | `order-rejected` |
| Unknown order, or a different key created it | `order-not-found` |
| Too many requests | `rate-limit-exceeded` |
***
## Related
Quote, deposit, and status for 1Click swaps
`confidentiality` and `CONFIDENTIAL_INTENTS`
Fund Intents deposits without an on-chain transfer
`appFees` on create
# Confidential Swaps
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/quickstart/confidential-swaps
Add privacy to a swap with the confidentiality parameter or an embedded Confidential Intents balance
## What is Confidential Intents
Confidential Intents is a private transaction layer built on top of NEAR Intents. You can swap and transfer tokens without the on-chain deposit and withdrawal being trackable to each other.
* **Public Intents:** deposits and withdrawals can be matched to each other.
* **Confidential Intents:** deposits and withdrawals cannot be tracked to each other.
***
## Integration paths
There are two ways to request a confidential swap. Most partners only need the first.
Run a normal `ORIGIN_CHAIN` → `DESTINATION_CHAIN` swap and set the `confidentiality` parameter to `basic` or `advanced`. You do **not** need the `CONFIDENTIAL_INTENTS` type fields or signed-intent execution — the user deposits and receives on external chains exactly as a standard swap.
When the funds already live inside a user's Confidential Intents balance, set `depositType`, `recipientType`, and/or `refundType` to `CONFIDENTIAL_INTENTS` and authorize the swap with [Signed Intent Execution](./signed-intent-execution). This is the advanced, wallet-style use case — integrators that keep user balances in Intents, for example [near.com](https://near.com).
To request a foreign-to-foreign confidential quote, add `confidentiality` to a standard quote request. Everything else in the request/response cycle is identical to [Making a Request](./making-a-request):
```json theme={null}
{
"dry": false,
"swapType": "EXACT_INPUT",
"originAsset": "nep141:wrap.near",
"depositType": "ORIGIN_CHAIN",
"destinationAsset": "nep141:arb-0x912ce59144191c1204e64559fe8253a0e49e6548.omft.near",
"amount": "100000000000000000000000",
"recipient": "0xYourArbitrumAddress",
"recipientType": "DESTINATION_CHAIN",
"refundTo": "your-account.near",
"refundType": "ORIGIN_CHAIN",
"confidentiality": "basic",
"deadline": "2025-01-01T00:00:00.000Z"
}
```
# Going Live
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/quickstart/going-live
Next steps and troubleshooting for your first 1Click integration
## Next steps
Clone and run a working TypeScript implementation to get started quickly.
Follow along with this guided workshop explaining all the steps in detail.
Integrate with our official SDK libraries for TypeScript, Go, or Rust.
Track transactions and view swap history
## Troubleshooting
* Check the blockchain explorer for your deposit transaction
* Verify the deposit address matches the quote response
* Allow up to 15 minutes for cross-chain processing
* Use the status endpoint to check current state
* Verify you sent the exact amount specified in the quote
* Check your refund address for returned funds
* Ensure your destination address format is correct for the target chain
* Request a new quote and try again
Join our [Telegram community](https://t.me/near_intents) for support.
# Quickstart
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/quickstart/introduction
Execute your first intent-based swap using 1Click API
1Click API enables you to specify a cross-chain swap **intent** (**what** you want to swap), and handles the **execution** for you.
There is no testnet version of NEAR Intents - use small amounts for test swaps.
***
## Prerequisites
* A small amount of tokens on ANY [supported chain](/resources/chain-support).
* A [JWT token](../authentication) to avoid the 0.2% fee.
***
## Choose your flow
The standard flow: query tokens, request a quote, send your deposit, and track it to completion.
Add privacy to a swap, either foreign-to-foreign or from an embedded Confidential Intents balance.
Authorize a swap by signing an intent off-chain instead of sending an on-chain deposit.
Next steps and troubleshooting once your first swap works.
# Making a Request
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/quickstart/making-a-request
Query tokens, request a quote, send your deposit, and track it to completion
This covers the standard `ORIGIN_CHAIN` swap flow end-to-end: find a token, request a quote, send your deposit, and poll status until it settles.
Fetch available tokens to find the `assetId` values you will need.
```bash cURL theme={null}
curl https://1click.chaindefuser.com/v0/tokens
```
```typescript TypeScript theme={null}
const response = await fetch('https://1click.chaindefuser.com/v0/tokens');
const tokens = await response.json();
```
The response includes tokens with their `assetId` in this format:
* NEAR tokens: `nep141:wrap.near`
* Bridged tokens: `nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near`
```json theme={null}
[
{
"assetId": "nep141:wrap.near",
"decimals": 24,
"blockchain": "near",
"symbol": "wNEAR",
"price": 1.1,
"priceUpdatedAt": "2026-02-27T15:18:30.437Z",
"contractAddress": "wrap.near"
},
{
"assetId": "nep141:eth.omft.near",
"decimals": 18,
"blockchain": "eth",
"symbol": "ETH",
"price": 1947.28,
"priceUpdatedAt": "2026-02-27T15:25:30.527Z",
"contractAddress": null
},
{
"assetId": "nep141:btc.omft.near",
"decimals": 8,
"blockchain": "btc",
"symbol": "BTC",
"price": 66093,
"priceUpdatedAt": "2026-02-27T15:25:30.527Z",
"contractAddress": null
}
]
```
Request a quote with your swap parameters. Include your [JWT token](../authentication) to avoid the 0.2% fee.
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/quote \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_JWT_TOKEN" \
-d '{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:wrap.near",
"depositType": "ORIGIN_CHAIN",
"destinationAsset": "nep141:arb-0x912ce59144191c1204e64559fe8253a0e49e6548.omft.near",
"amount": "100000000000000000000000",
"recipient": "0xYourArbitrumAddress",
"recipientType": "DESTINATION_CHAIN",
"refundTo": "your-account.near",
"refundType": "ORIGIN_CHAIN",
"deadline": "2025-01-01T00:00:00.000Z"
}'
```
```typescript TypeScript theme={null}
const quote = await fetch('https://1click.chaindefuser.com/v0/quote', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_JWT_TOKEN'
},
body: JSON.stringify({
dry: false,
swapType: 'EXACT_INPUT',
slippageTolerance: 100,
originAsset: 'nep141:wrap.near',
depositType: 'ORIGIN_CHAIN',
destinationAsset: 'nep141:arb-0x912ce59144191c1204e64559fe8253a0e49e6548.omft.near',
amount: '100000000000000000000000',
recipient: '0xYourArbitrumAddress',
recipientType: 'DESTINATION_CHAIN',
refundTo: 'your-account.near',
refundType: 'ORIGIN_CHAIN',
deadline: new Date(Date.now() + 3 * 60 * 1000).toISOString()
})
});
const result = await quote.json();
```
| Parameter | Description |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `dry` | `true` to validate parameters and **get a quote without executing the swap** |
| `swapType` | `EXACT_INPUT` (specify input amount) or `EXACT_OUTPUT` (specify output amount) |
| `slippageTolerance` | Maximum acceptable slippage in basis points (100 = 1%) |
| `originAsset` | Source token `assetId` from the tokens endpoint |
| `depositType` | `ORIGIN_CHAIN` for origin-chain deposits, `INTENTS` for public Intents balances, or `CONFIDENTIAL_INTENTS` |
| `destinationAsset` | Target token `assetId` from the tokens endpoint |
| `amount` | Amount in smallest unit (wei, yoctoNEAR, etc.) |
| `recipient` | Address to receive swapped tokens |
| `recipientType` | `DESTINATION_CHAIN`, `INTENTS`, or `CONFIDENTIAL_INTENTS` |
| `refundTo` | Address for refunds if swap fails |
| `refundType` | `ORIGIN_CHAIN`, `INTENTS`, or `CONFIDENTIAL_INTENTS` |
| `confidentiality` | `public` (default), `basic`, or `advanced`. Enables a confidential swap on an otherwise normal quote, see [Confidential Swaps](./confidential-swaps) |
| `deadline` | Quote expiration timestamp in ISO format |
This guide uses `EXACT_INPUT`, but 1Click also supports `EXACT_OUTPUT`, `FLEX_INPUT`, and `ANY_INPUT`. Check out [Swap Types](../swap-types) to see what each one does and when to use it.
For `ORIGIN_CHAIN` quotes, transfer tokens to the `depositAddress` from the quote response. The swap begins automatically upon receipt.
Save the deposit address and your transaction hash for tracking.
If your quote uses `depositType: INTENTS` or `depositType: CONFIDENTIAL_INTENTS`, skip the on-chain transfer and use [Signed Intent Execution](./signed-intent-execution) instead.
Speed up processing by notifying 1Click of your deposit.
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/deposit/submit \
-H "Content-Type: application/json" \
-d '{
"depositAddress": "address-from-quote-response",
"txHash": "0xYourTransactionHash"
}'
```
```typescript TypeScript theme={null}
await fetch('https://1click.chaindefuser.com/v0/deposit/submit', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
depositAddress: 'address-from-quote-response',
txHash: '0xYourTransactionHash'
})
});
```
Check swap progress using the deposit address.
```bash cURL theme={null}
curl "https://1click.chaindefuser.com/v0/status?depositAddress=your-deposit-address"
```
```typescript TypeScript theme={null}
const status = await fetch(
'https://1click.chaindefuser.com/v0/status?depositAddress=your-deposit-address'
);
const result = await status.json();
```
| Status | Description |
| -------------------- | --------------------------------------------- |
| `PENDING_DEPOSIT` | Awaiting your token deposit |
| `KNOWN_DEPOSIT_TX` | Deposit transaction detected |
| `PROCESSING` | Swap being executed |
| `SUCCESS` | Tokens delivered to destination address |
| `INCOMPLETE_DEPOSIT` | Deposit below required amount |
| `REFUNDED` | Swap failed, funds returned to refund address |
| `FAILED` | Swap encountered an error |
View detailed transaction info on the [NEAR Intents Explorer](https://explorer.near-intents.org) by searching for your deposit address.
You just completed your first intent-based cross-chain swap!
# Signed Intent Execution
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/quickstart/signed-intent-execution
Authorize a swap by signing an intent off-chain instead of an on-chain deposit
Use signed intent execution when a quote uses `depositType: INTENTS` or `depositType: CONFIDENTIAL_INTENTS`. In both cases, the funds are already inside NEAR Intents, so the user authorizes the swap by signing an intent message off-chain instead of sending an on-chain deposit.
Foreign-to-foreign confidential swaps (using the `confidentiality` parameter with `ORIGIN_CHAIN` deposits) do **not** use signed intent execution, they follow the standard on-chain deposit flow in [Making a Request](./making-a-request). See [Confidential Swaps](./confidential-swaps) for both paths.
| Deposit channel | depositType | How the deposit is made |
| ---------------------------- | ---------------------- | -------------------------------------------------------------------------------- |
| Origin chain transfer | `ORIGIN_CHAIN` | Send tokens to `depositAddress`, optionally notify via `POST /v0/deposit/submit` |
| Signed intent | `INTENTS` | Generate intent, user signs, `POST /v0/submit-intent` |
| Signed intent (confidential) | `CONFIDENTIAL_INTENTS` | Generate intent, user signs, `POST /v0/submit-intent` |
For public Intents balances, this can speed execution because there is no on-chain deposit to wait for. For Confidential Intents balances, this is the required path because there is no RPC path for confidential intents.
`POST /v0/generate-intent` and `POST /v0/submit-intent` use partner authentication (`X-API-Key` recommended, `JWT-auth` legacy). They do not use the end-user `User-Session` token; the user's authorization is the wallet signature submitted as `signedData`.
Request a quote with `POST /v0/quote` using `depositType` `INTENTS` or `CONFIDENTIAL_INTENTS`. Save the returned `depositAddress`; it links the signed intent back to the quote.
See [Making a Request](./making-a-request#request-token) for the full quote flow — the only required change is setting `depositType` (and matching `refundType` / `recipientType` when those balances also live in Intents).
Call `POST /v0/generate-intent` with the `depositAddress`, the user's `signerId`, and their wallet's signing `standard` (`nep413`, `erc191`, `raw_ed25519`, `webauthn`, `ton_connect`, `sep53`, or `tip191`). It returns the unsigned intent payload.
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/generate-intent \
-H "Content-Type: application/json" \
-H "X-API-Key: YOUR_API_KEY" \
-d '{
"type": "swap_transfer",
"standard": "nep413",
"signerId": "user.near",
"depositAddress": "address-from-quote-response"
}'
```
```typescript TypeScript theme={null}
const response = await fetch('https://1click.chaindefuser.com/v0/generate-intent', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-API-Key': 'YOUR_API_KEY'
},
body: JSON.stringify({
type: 'swap_transfer',
standard: 'nep413',
signerId: 'user.near',
depositAddress: 'address-from-quote-response'
})
});
const { intent, correlationId } = await response.json();
```
```json theme={null}
{
"intent": {
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hcQLaHzX2s1fNKhBDblXT4=",
"message": "{\"deadline\":\"2026-07-16T12:00:00.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:wrap.near\":\"-1000000000000000000000000\",\"nep141:usdt.tether-token.near\":\"1000000\"}}],\"signer_id\":\"user.near\"}"
}
},
"correlationId": "550e8400-e29b-41d4-a716-446655440000"
}
```
For the exact request fields and response shape, see [Generate an intent for signing](/api-reference/oneclick/generate-an-intent-for-signing).
The user signs the returned `intent` payload with their wallet off-chain. Do not modify the payload between generation and signing; the signature must cover the exact payload returned by the API.
The wallet returns `public_key` and `signature`. Combine those with the generated `intent` fields to form the full `signedData` MultiPayload you submit next. See [Signing Intents](/integration/verifier-contract/signing-intents) for the payload shape across supported standards.
Call `POST /v0/submit-intent` with the signed payload (`type: swap_transfer`, `signedData`: the signed MultiPayload). It returns the `intentHash`.
```bash cURL theme={null}
curl -X POST https://1click.chaindefuser.com/v0/submit-intent \
-H "Content-Type: application/json" \
-H "X-API-Key: YOUR_API_KEY" \
-d '{
"type": "swap_transfer",
"signedData": {
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hcQLaHzX2s1fNKhBDblXT4=",
"message": "{\"deadline\":\"2026-07-16T12:00:00.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:wrap.near\":\"-1000000000000000000000000\",\"nep141:usdt.tether-token.near\":\"1000000\"}}],\"signer_id\":\"user.near\"}"
},
"public_key": "ed25519:YOUR_PUBLIC_KEY",
"signature": "ed25519:YOUR_SIGNATURE"
}
}'
```
```typescript TypeScript theme={null}
// `intent` is the object returned by /v0/generate-intent
const response = await fetch('https://1click.chaindefuser.com/v0/submit-intent', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-API-Key': 'YOUR_API_KEY'
},
body: JSON.stringify({
type: 'swap_transfer',
signedData: {
...intent,
public_key: 'ed25519:YOUR_PUBLIC_KEY',
signature: 'ed25519:YOUR_SIGNATURE'
}
})
});
const { intentHash, correlationId } = await response.json();
```
```json theme={null}
{
"intentHash": "44XpLRAuZKoVGs9T4qbSNv33MDKMePPAibA52geVLWFw",
"correlationId": "550e8400-e29b-41d4-a716-446655440000"
}
```
For the exact `signedData` schema and response shape, see [Submit a signed intent](/api-reference/oneclick/submit-a-signed-intent).
Poll `GET /v0/status` with the `depositAddress`, as with any swap, see [Making a Request → Monitor status](./making-a-request#monitor-status) for the status values. Include `depositMemo` if the quote response included one.
# Swap SDK
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/sdk
Client libraries for integrating with the 1Click Swap API
The 1Click SDK provides client libraries in multiple languages for seamless cross-chain token swaps using the [1Click Swap API](/integration/distribution-channels/1click-api/about-1click-api).
npm package
Go module
Cargo crate
***
## Using the SDK
There is no testnet version of NEAR Intents - use small amounts for test swaps.
* A small amount of tokens on ANY [supported chain](/resources/chain-support).
* A [JWT token](/integration/distribution-channels/1click-api/authentication) to avoid the 0.2% fee.
```bash TypeScript theme={null}
npm install @defuse-protocol/one-click-sdk-typescript
```
```bash Go theme={null}
go get github.com/defuse-protocol/one-click-sdk-go
```
```bash Rust theme={null}
# Clone the repo next to your project
git clone https://github.com/defuse-protocol/one-click-sdk-rs.git
# Add to your Cargo.toml under [dependencies]
# one-click-sdk-rs = { path = "./one-click-sdk-rs" }
```
```typescript TypeScript theme={null}
import { OpenAPI } from '@defuse-protocol/one-click-sdk-typescript';
// The base URL defaults to https://1click.chaindefuser.com
OpenAPI.BASE = 'https://1click.chaindefuser.com';
// Required for getQuote, submitDepositTx, and getExecutionStatus
OpenAPI.TOKEN = 'YOUR_JWT_TOKEN';
```
```go Go theme={null}
import (
"context"
"fmt"
openapiclient "github.com/defuse-protocol/one-click-sdk-go"
)
configuration := openapiclient.NewConfiguration()
apiClient := openapiclient.NewAPIClient(configuration)
authCtx := context.WithValue(
context.Background(),
openapiclient.ContextAccessToken,
"YOUR_JWT_TOKEN",
)
```
```rust Rust theme={null}
use one_click_sdk_rs::apis::configuration::Configuration;
// base_path already defaults to https://1click.chaindefuser.com
let config = Configuration {
bearer_access_token: Some("YOUR_JWT_TOKEN".to_string()),
..Default::default()
};
```
```typescript TypeScript theme={null}
import { OneClickService } from '@defuse-protocol/one-click-sdk-typescript';
const tokens = await OneClickService.getTokens();
console.log(tokens);
```
```go Go theme={null}
// GetTokens does not require authentication
tokens, _, err := apiClient.OneClickAPI.GetTokens(context.Background()).Execute()
if err != nil {
fmt.Fprintf(os.Stderr, "GetTokens error: %v\n", err)
panic(err)
}
fmt.Printf("Supported tokens: %v\n", tokens)
```
```rust Rust theme={null}
use one_click_sdk_rs::apis::one_click_api;
// get_tokens does not require authentication
let tokens = one_click_api::get_tokens(&config).await?;
println!("{:?}", tokens);
```
```typescript TypeScript theme={null}
import { OneClickService, QuoteRequest } from '@defuse-protocol/one-click-sdk-typescript';
// Example: swap USDC on Arbitrum for USDC on Solana
const quoteRequest: QuoteRequest = {
dry: false, // true = simulate only, no depositAddress returned
swapType: QuoteRequest.swapType.EXACT_INPUT,
slippageTolerance: 100, // basis points (100 = 1%)
originAsset: 'nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near',
depositType: QuoteRequest.depositType.ORIGIN_CHAIN,
destinationAsset: 'nep141:sol-5ce3bf3a31af18be40ba30f721101b4341690186.omft.near',
amount: '1000000', // 1 USDC in smallest units (6 decimals)
refundTo: '0xYourArbitrumAddress',
refundType: QuoteRequest.refundType.ORIGIN_CHAIN,
recipient: 'YourSolanaAddress',
recipientType: QuoteRequest.recipientType.DESTINATION_CHAIN,
deadline: new Date(Date.now() + 3 * 60 * 1000).toISOString(),
};
const quote = await OneClickService.getQuote(quoteRequest);
```
```go Go theme={null}
import "time"
// Example: swap USDC on Arbitrum for USDC on Solana
quoteRequest := *openapiclient.NewQuoteRequest(
false, // dry
"EXACT_INPUT", // swapType
float32(100), // slippageTolerance (basis points, 100 = 1%)
"nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near", // originAsset
"ORIGIN_CHAIN", // depositType
"nep141:sol-5ce3bf3a31af18be40ba30f721101b4341690186.omft.near", // destinationAsset
"1000000", // amount (1 USDC, 6 decimals)
"0xYourArbitrumAddress", // refundTo
"ORIGIN_CHAIN", // refundType
"YourSolanaAddress", // recipient
"DESTINATION_CHAIN", // recipientType
time.Now().Add(3*time.Minute), // deadline
)
quote, _, err := apiClient.OneClickAPI.GetQuote(authCtx).QuoteRequest(quoteRequest).Execute()
if err != nil {
fmt.Fprintf(os.Stderr, "GetQuote error: %v\n", err)
panic(err)
}
```
```rust Rust theme={null}
use one_click_sdk_rs::apis::one_click_api;
use one_click_sdk_rs::models::{DepositType, QuoteRequest, RecipientType, RefundType, SwapType};
// Example: swap USDC on Arbitrum for USDC on Solana
let quote_request = QuoteRequest::new(
false, // dry
SwapType::ExactInput,
100.0, // slippage_tolerance (basis points, 100 = 1%)
"nep141:arb-0xaf88d065e77c8cc2239327c5edb3a432268e5831.omft.near".to_string(), // origin_asset
DepositType::OriginChain,
"nep141:sol-5ce3bf3a31af18be40ba30f721101b4341690186.omft.near".to_string(), // destination_asset
"1000000".to_string(), // amount (1 USDC, 6 decimals)
"0xYourArbitrumAddress".to_string(), // refund_to
RefundType::OriginChain,
"YourSolanaAddress".to_string(), // recipient
RecipientType::DestinationChain,
"2025-12-31T23:59:59Z".to_string(), // deadline (ISO 8601)
);
let quote = one_click_api::get_quote(&config, quote_request).await?;
```
Save `quote.quote.depositAddress` (and `quote.quote.depositMemo` if present). You will use these for deposit and status checks.
Transfer tokens to the `depositAddress` (on the origin chain) from the quote response. The swap begins automatically upon receipt.
Save your transaction hash for optional submission and tracking.
Submitting the transaction hash lets the service detect your deposit faster and start processing sooner.
```typescript TypeScript theme={null}
await OneClickService.submitDepositTx({
depositAddress: quote.quote.depositAddress!,
txHash: '0xYourTransactionHash',
});
```
```go Go theme={null}
submitRequest := *openapiclient.NewSubmitDepositTxRequest(
"0xYourTransactionHash",
*quote.Quote.DepositAddress,
)
_, _, err = apiClient.OneClickAPI.
SubmitDepositTx(authCtx).
SubmitDepositTxRequest(submitRequest).
Execute()
if err != nil {
fmt.Fprintf(os.Stderr, "SubmitDepositTx error: %v\n", err)
}
```
```rust Rust theme={null}
use one_click_sdk_rs::models::SubmitDepositTxRequest;
let submit_request = SubmitDepositTxRequest::new(
"0xYourTransactionHash".to_string(),
quote.quote.deposit_address.clone().unwrap_or_default(),
);
one_click_api::submit_deposit_tx(&config, submit_request).await?;
```
Poll until `status` reaches a terminal state (`SUCCESS`, `REFUNDED`, or `FAILED`).
```typescript TypeScript theme={null}
const status = await OneClickService.getExecutionStatus(quote.quote.depositAddress!);
console.log(status.status);
```
```go Go theme={null}
status, _, err := apiClient.OneClickAPI.
GetExecutionStatus(authCtx).
DepositAddress(*quote.Quote.DepositAddress).
Execute()
if err != nil {
fmt.Fprintf(os.Stderr, "GetExecutionStatus error: %v\n", err)
panic(err)
}
fmt.Println(*status.Status)
```
```rust Rust theme={null}
let status = one_click_api::get_execution_status(
&config,
quote.quote.deposit_address.as_deref().unwrap_or_default(),
).await?;
println!("{:?}", status.status);
```
| Status | Description |
| -------------------- | --------------------------------------------- |
| `PENDING_DEPOSIT` | Awaiting your token deposit |
| `KNOWN_DEPOSIT_TX` | Deposit transaction detected |
| `PROCESSING` | Swap being executed |
| `SUCCESS` | Tokens delivered to destination address |
| `INCOMPLETE_DEPOSIT` | Deposit below required amount |
| `REFUNDED` | Swap failed, funds returned to refund address |
| `FAILED` | Swap encountered an error |
# Swap Types
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/swap-types
Every quote request includes a `swapType` that sets how the `amount` field is read and how your deposit is handled. Open the option that fits your use case below, each one has a full example request, with the highlighted lines showing what makes it different.
`slippageTolerance` is in **basis points** (`100` = 1%) across every swap type below.
You commit to sending an exact `amount` of `originAsset`; the quote returns the output you'll receive.
```json {3,8} theme={null}
{
"dry": false,
"swapType": "EXACT_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:wrap.near",
"depositType": "INTENTS",
"destinationAsset": "nep141:usdt.tether-token.near",
"amount": "1000000000000000000000000",
"recipient": "user.near",
"recipientType": "INTENTS",
"refundTo": "user.near",
"refundType": "INTENTS",
"deadline": "2025-01-01T00:00:00.000Z"
}
```
`amount` is the **1 NEAR** you intend to send (in yoctoNEAR).
```json theme={null}
{
"amountIn": "1000000000000000000000000",
"amountOut": "10000000"
}
```
`amountOut` is the output you'll receive for sending exactly `amount`.
**Deposit handling**
* Deposit **below** `amountIn` → refunded by the `deadline`.
* Deposit **above** `amountIn` → swap proceeds; the excess is refunded to `refundTo`.
The example routes through depositType `INTENTS`; `ORIGIN_CHAIN` and `DESTINATION_CHAIN` also work (see the [Quickstart](./quickstart/making-a-request#request-token)). `CONFIDENTIAL_INTENTS` is also supported.
You commit to receiving an exact `amount` of `destinationAsset`; the quote returns the input required. Slippage applies to the **input** side.
```json {3,8} theme={null}
{
"dry": false,
"swapType": "EXACT_OUTPUT",
"slippageTolerance": 100,
"originAsset": "nep141:wrap.near",
"depositType": "INTENTS",
"destinationAsset": "nep141:usdt.tether-token.near",
"amount": "10000000",
"recipient": "user.near",
"recipientType": "INTENTS",
"refundTo": "user.near",
"refundType": "INTENTS",
"deadline": "2025-01-01T00:00:00.000Z"
}
```
`amount` is the **10 USDT** you want to end up with. The response returns `amountIn` (the input to send, with slippage baked in) and `minAmountIn` (the minimum actually needed).
**Deposit handling**
* Deposit **below** `minAmountIn` → refunded by the `deadline`.
* Deposit **above** `amountIn` → swap proceeds; the excess is refunded to `refundTo`.
`amountIn` looks higher than `minAmountIn` by roughly your slippage. That gap is a **buffer to guarantee execution**, not a worse price — anything unused is refunded.
The example routes through depositType `INTENTS`; `ORIGIN_CHAIN` and `DESTINATION_CHAIN` also work (see the [Quickstart](./quickstart/making-a-request#request-token)). `CONFIDENTIAL_INTENTS` is also supported.
Still one known `originAsset` through one deposit address, but the deposit **amount can vary** within a band. Use it when you don't know the exact amount at quote time — for example, sweeping a wallet whose balance is still settling.
```json {3,8} theme={null}
{
"dry": false,
"swapType": "FLEX_INPUT",
"slippageTolerance": 100,
"originAsset": "nep141:wrap.near",
"depositType": "INTENTS",
"destinationAsset": "nep141:usdt.tether-token.near",
"amount": "1000000000000000000000000",
"recipient": "user.near",
"recipientType": "INTENTS",
"refundTo": "user.near",
"refundType": "INTENTS",
"deadline": "2025-01-01T00:00:00.000Z"
}
```
`slippageTolerance` applies to **both** sides, so the quote comes back as a band:
```json theme={null}
{
"amountIn": "1000000000000000000000000",
"minAmountIn": "990000000000000000000000",
"amountOut": "10000000",
"minAmountOut": "9900000"
}
```
**Deposit handling** (for the 1 NEAR → \~10 USDT quote above, at 1% slippage)
* Deposit **0.99 NEAR or more** → swapped; you receive at least 9.9 USDT.
* Deposit **above the quoted 1 NEAR** → still swapped (the quote is not a cap).
* Deposit **below 0.99 NEAR** → refunded after the `deadline`, as long as the total received stays under `minAmountIn`.
The example routes through depositType `INTENTS`; `ORIGIN_CHAIN` and `DESTINATION_CHAIN` also work (see the [Quickstart](./quickstart/making-a-request#request-token)). `CONFIDENTIAL_INTENTS` is **not** supported for `FLEX_INPUT`.
Fixes **only** `destinationAsset` and `recipient` — there's no fixed origin asset, chain, amount, or up-front rate. It's a standing **deposit-and-sweep** account: set `originAsset` to `1cs_v1:any` and `amount` to `"0"`.
```json {3,5,8} theme={null}
{
"dry": false,
"swapType": "ANY_INPUT",
"slippageTolerance": 100,
"originAsset": "1cs_v1:any",
"depositType": "INTENTS",
"destinationAsset": "nep141:usdt.tether-token.near",
"amount": "0",
"recipient": "user.near",
"recipientType": "INTENTS",
"refundTo": "user.near",
"refundType": "INTENTS",
"deadline": "2025-01-01T00:00:00.000Z"
}
```
**Deposit handling**
* Deposits arrive in **any supported token** into an Intents account and accumulate. `depositType` must be `INTENTS` or `CONFIDENTIAL_INTENTS`.
* They're periodically converted into `destinationAsset` and withdrawn to `recipient` once the pool clears a **\$1,000 USD** threshold.
* Each conversion is quoted at sweep time, so there's no fixed rate when you create the quote.
* The `deadline` is checked only at creation — the collector then runs **indefinitely**, so one quote keeps aggregating without being refreshed.
* There are **no refunds**: a failed swap retries every 5 minutes rather than returning funds, so set `refundTo` to an address you control.
`ANY_INPUT` is available to **authorized partners only** — requests without a valid partner are rejected. Get access via the [Partner Dashboard](https://partners.near-intents.org/).
The most common use of `ANY_INPUT` is fee aggregation. For the end-to-end setup steps such as getting a collection address, wiring it into `appFees.recipient`, and tracking withdrawals, see [Fee Configuration → Fee Aggregation](./fee-config#fee-aggregation).
# Verify Quote Signatures
Source: https://docs.near-intents.org/integration/distribution-channels/1click-api/verify-quote-signature
Confirm quote and status payloads are signed by 1Click
1Click signs quote payloads so partners can verify the payload origin and detect tampering before using fields like `depositAddress` in 1click quote response payloads. This can help to
* Prevent man-in-the-middle tampering on transport or proxy layers.
* Ensure a quote/status payload was produced by the 1Click API.
* Detect unexpected field mutation before showing the quote or executing swaps.
## What is signed
The signed message is a Base58-encoded SHA-256 hash of a deterministic JSON object from the 1click quote payload response. The JSON is serialized with stable key ordering (`json-stable-stringify`), then hashed with SHA-256 and Base58-encoded.
The signed message input is:
```typescript theme={null}
stringify({ ...quoteRequest, ...quoteResponse, timestamp });
```
Both dry and non-dry quotes can be verified to have come from 1Click. The difference is that non-dry quotes include extra execution fields (for example `depositAddress`) in the signed payload.
## Use the TypeScript SDK (recommended)
If you integrate with our TypeScript SDK, use `verifyQuoteSignature()` directly:
```typescript theme={null}
import { verifyQuoteSignature } from "@defuse-protocol/one-click-sdk-typescript";
const quoteResponse = await fetch("https://1click.chaindefuser.com/v0/quote", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(quoteRequest),
}).then((r) => r.json());
const isValid = verifyQuoteSignature(quoteResponse);
if (!isValid) {
throw new Error("Invalid quote signature");
}
```
The `verifyQuoteSignature()` function requires `@defuse-protocol/one-click-sdk-typescript` version 0.1.24 or later.
Both include `signature` and `timestamp`, and both should be verified before consuming the quote payload.
# Confidential Example
Source: https://docs.near-intents.org/integration/market-makers/confidential-example
Migrate the AMM Solver to support confidential intents
This guide walks through the changes needed to upgrade the [example AMM Solver](https://github.com/hairy-pointer/near-intents-amm-solver/tree/feat/confidential-amm-solver-mode) from public intents to confidential intents. If you haven't already, read the [public Example Solver](./example) guide first to understand the baseline implementation.
***
## Overview
Migrating to confidential intents requires changes in four areas:
| Area | Change |
| ------------------------ | ----------------------------------------------------------- |
| **Configuration** | Add private relay URL, contract, salt, and treasury account |
| **Token identifiers** | Convert public asset IDs to confidential `imt:` format |
| **Nonce generation** | Switch from deterministic nonces to versioned nonces |
| **WebSocket connection** | Connect to the private relay with acknowledgement support |
The core quoting logic and AMM pricing remain unchanged — the same `token_diff` intent structure works for both public and confidential swaps.
***
## Configuration
### Environment variables
Add the confidential intents configuration to your environment file:
```bash theme={null}
# Solver mode
SOLVER_MODE=confidential
# Private relay connection (contact Defuse team for access)
PRIVATE_RELAY_WS_URL=wss://your-private-relay-url.chaindefuser.com/ws
# Confidential intents contract (used in signed payloads)
PRIVATE_INTENTS_CONTRACT=intents.far
PRIVATE_INTENTS_CONTRACT_SALT=e110f317
# Treasury account for asset wrapping
PRIVATE_TREASURY_ACCOUNT_ID=51e8f94d77b5e90dc9852ca6113771e11e8382ce69473a75e313e41665de7cbe
# 1Click API for balance queries and liquidity management
ONE_CLICK_BASE_URL=https://1click.chaindefuser.com
# Stable identifier for guaranteed delivery
SOLVER_INSTANCE_ID=my-solver-1
# Partner JWT (used for both relay auth and 1Click API)
PARTNER_JWT=your_partner_jwt_here
```
`PRIVATE_RELAY_WS_URL`, `PRIVATE_INTENTS_CONTRACT`, `PRIVATE_INTENTS_CONTRACT_SALT`, `PRIVATE_TREASURY_ACCOUNT_ID`, and `ONE_CLICK_BASE_URL` are production constants shared by all solver operators. Only `SOLVER_INSTANCE_ID` and `PARTNER_JWT` are solver-specific.
### Solver mode
Create a mode toggle to switch between public and confidential:
```typescript theme={null}
export enum SolverMode {
PUBLIC = 'public',
CONFIDENTIAL = 'confidential',
}
export const solverMode = process.env.SOLVER_MODE === 'confidential'
? SolverMode.CONFIDENTIAL
: SolverMode.PUBLIC;
export const isConfidentialMode = solverMode === SolverMode.CONFIDENTIAL;
```
***
## Token identifiers
### Converting public to private asset IDs
Confidential assets wrap the public token ID with the treasury account:
```typescript theme={null}
const privateTreasuryAccountId = process.env.PRIVATE_TREASURY_ACCOUNT_ID;
export function privateAssetIdentifier(assetId: string): string {
return `imt:${privateTreasuryAccountId}:${assetId}`;
}
// Example:
// Input: "nep141:wrap.near"
// Output: "imt:51e8f94d...7cbe:nep141:wrap.near"
```
The solver uses these wrapped identifiers when:
* Subscribing to quote requests
* Checking token pair support
* Building `token_diff` intents
For 1Click API balance queries, use the **public** asset identifiers (without the `imt:` prefix). The API strips the prefix from response keys. See the [Balance queries](#balance-queries) section for details.
### Token configuration
Update the tokens configuration to conditionally use private identifiers:
```typescript theme={null}
export const publicTokens = [
`nep141:${process.env.AMM_TOKEN1_ID}`,
`nep141:${process.env.AMM_TOKEN2_ID}`
];
export const tokens = isConfidentialMode
? publicTokens.map(token => privateAssetIdentifier(token))
: publicTokens;
```
***
## Nonce generation
### Versioned nonces
Confidential intents require nonces that encode the contract salt and deadline. Use `VersionedNonceBuilder` from the intents SDK:
```typescript theme={null}
import { VersionedNonceBuilder } from '@defuse-protocol/intents-sdk';
public generateVersionedNonce(deadline: Date): string {
const saltHex = process.env.PRIVATE_INTENTS_CONTRACT_SALT;
const salt = Buffer.from(saltHex, 'hex');
return VersionedNonceBuilder.encodeNonce(salt, deadline);
}
```
The salt must be exactly 4 bytes. The production salt `e110f317` is a shared constant used by all solvers — do not change it. See the [main confidential intents page](/integration/market-makers/confidential-intents#versioned-nonces) for more details.
### Choosing the nonce strategy
In the quoter service, select the nonce based on the solver mode:
```typescript theme={null}
const quoteDeadlineMs = params.min_deadline_ms + quoteDeadlineExtraMs;
const deadline = new Date(Date.now() + quoteDeadlineMs);
// Use versioned nonces for confidential, deterministic for public
const nonce = isConfidentialMode
? this.intentsService.generateVersionedNonce(deadline)
: currentState.nonce;
```
Unlike public intents where the nonce only changes after a trade settles, confidential intents use a fresh nonce for each quote. This removes the throughput limitation of one trade per nonce.
***
## Intent signing
### Recipient contract
Confidential intents sign against a different contract ID:
```typescript theme={null}
export const intentsContract = process.env.INTENTS_CONTRACT || 'intents.near';
export const privateIntentsContract = process.env.PRIVATE_INTENTS_CONTRACT || '';
export const activeIntentsContract = isConfidentialMode
? privateIntentsContract
: intentsContract;
```
The `recipient` field in the signed payload uses this active contract:
```typescript theme={null}
const messageStr = JSON.stringify(message);
const recipient = activeIntentsContract; // "intents.far" for confidential
const nonce = isConfidentialMode
? this.intentsService.generateVersionedNonce(deadline)
: currentState.nonce;
const quoteHash = serializeIntent(messageStr, recipient, nonce, 'nep413');
const signature = await nearService.signMessage(quoteHash);
```
### Intent structure
The `token_diff` intent structure is identical for both modes — only the asset identifiers and recipient change:
```typescript theme={null}
const message: IMessage = {
signer_id: nearService.getIntentsAccountId(),
deadline: deadline.toISOString(),
intents: [
{
intent: 'token_diff',
diff: {
// Confidential asset identifiers
[params.defuse_asset_identifier_in]: params.exact_amount_in
? params.exact_amount_in
: amount,
[params.defuse_asset_identifier_out]: `-${
params.exact_amount_out ? params.exact_amount_out : amount
}`,
},
},
],
};
```
***
## WebSocket connection
### Private relay URL
Configure the WebSocket to connect to the private relay with an instance ID for guaranteed delivery:
```typescript theme={null}
const publicRelayWsUrl = process.env.RELAY_WS_URL || 'wss://solver-relay-v2.chaindefuser.com/ws';
const privateRelayWsUrl = process.env.PRIVATE_RELAY_WS_URL || '';
const solverInstanceId = process.env.SOLVER_INSTANCE_ID?.trim();
function withSolverInstanceId(url: string): string {
if (!solverInstanceId) return url;
const relayUrl = new URL(url);
relayUrl.searchParams.set('instance_id', solverInstanceId);
return relayUrl.toString();
}
export const wsRelayUrl = isConfidentialMode
? withSolverInstanceId(privateRelayWsUrl)
: publicRelayWsUrl;
```
### Authentication
Both relays require a Partner JWT in the connection headers:
```typescript theme={null}
const partnerJwt = process.env.PARTNER_JWT?.trim();
export const wsRelayOptions: ClientOptions | undefined = partnerJwt
? {
headers: {
Authorization: `Bearer ${partnerJwt}`,
},
}
: undefined;
```
Then pass the options when creating the WebSocket:
```typescript theme={null}
this.wsConnection = wsRelayOptions
? new WebSocket(wsRelayUrl, wsRelayOptions)
: new WebSocket(wsRelayUrl);
```
***
## Guaranteed delivery
### Quote status acknowledgements
The private relay uses an acknowledgement mechanism to guarantee delivery of quote status updates. When subscribing to `quote_status_extended`, pass a third parameter to enable acknowledgements:
```typescript theme={null}
private getSubscribeParams(eventKind: RelayEventKind) {
if (isConfidentialMode && eventKind === RelayEventKind.QUOTE_STATUS_EXTENDED) {
// [eventKind, filter, enableAcknowledgements]
return [eventKind, null, true];
}
return [eventKind];
}
```
### Processing with acknowledgements
Each `quote_status` event includes a sequence number. The solver must acknowledge receipt before processing:
```typescript theme={null}
private async acknowledgeQuoteStatus(
params: Record,
logger: LoggerService
): Promise {
if (!isConfidentialMode) {
return true; // No acknowledgement needed for public relay
}
if (typeof params.subscription !== 'string' || typeof params.seq !== 'number') {
logger.debug('Skipping quote status without subscription id and seq');
return false;
}
try {
await this.sendRequestToRelay(
RelayMethod.ACKNOWLEDGE,
[params.subscription, params.seq],
logger
);
return true;
} catch (error) {
logger.error('Error acknowledging quote status', error);
return false;
}
}
```
Call this before processing the quote status:
```typescript theme={null}
case RelayEventKind.QUOTE_STATUS_EXTENDED:
if (!(await this.acknowledgeQuoteStatus(req.params, logger))) {
return;
}
await this.processQuoteStatus(req.params.data);
break;
```
The `instance_id` in the WebSocket URL enables the relay to track which events have been acknowledged. If the solver disconnects, unacknowledged events are redelivered on reconnect.
***
## Balance queries
### 1Click API integration
Confidential balances are not visible on the public NEAR chain. Query them through the 1Click API instead.
The 1Click API returns balances with the `imt::` prefix **stripped**. When querying balances, pass the **public** asset identifiers (e.g., `nep141:wrap.near`), not the IMT-wrapped versions. The response will use these same public identifiers as keys.
```typescript theme={null}
import { AccountService, UserAuthService, OpenAPI } from '@defuse-protocol/one-click-sdk-typescript';
private userToken: { accessToken: string; expiresAtMs: number } | null = null;
private async getBalancesFromOneClick(publicTokenIds: string[]): Promise {
// Authenticate and configure the SDK
const userToken = await this.getOneClickUserToken();
OpenAPI.TOKEN = userToken;
// Query using PUBLIC asset IDs (not IMT-wrapped)
const response = await AccountService.getBalances(publicTokenIds);
const balancesByTokenId = new Map(
response.balances.map(({ tokenId, available }) => [tokenId, available])
);
return publicTokenIds.map(tokenId => balancesByTokenId.get(tokenId) ?? '0');
}
```
### Authentication
The 1Click API requires an authenticated user token. Generate one by signing an intent:
```typescript theme={null}
import { createIntentSignerNEP413, IntentsSDK, VersionedNonceBuilder } from '@defuse-protocol/intents-sdk';
private async getOneClickUserToken(): Promise {
// Return cached token if still valid
if (this.userToken && this.userToken.expiresAtMs > Date.now()) {
return this.userToken.accessToken;
}
const signer = createIntentSignerNEP413({
accountId: this.nearService.getIntentsAccountId(),
signMessage: async (_payload, hash) => {
const signature = await this.nearService.signMessage(hash);
return {
publicKey: signature.publicKey.toString(),
signature: Buffer.from(signature.signature).toString('base64'),
};
},
});
const sdk = new IntentsSDK({ referral: 'solver', env: 'production' });
const { signed } = await sdk
.intentBuilder()
.setDeadline(new Date(Date.now() + 5 * 60_000))
.setNonceRandomBytes(VersionedNonceBuilder.createTimestampedNonceBytes(new Date()))
.buildAndSign(signer);
const auth = await UserAuthService.authenticate({ signedData: signed });
this.userToken = {
accessToken: auth.accessToken,
expiresAtMs: Date.now() + auth.expiresIn * 1000 - 60_000,
};
return this.userToken.accessToken;
}
```
### Unified balance method
Switch between on-chain and 1Click queries based on mode. Note that for confidential mode, you need to convert IMT-wrapped token IDs back to public format for the API call:
```typescript theme={null}
public async getBalances(tokenIds: string[]): Promise {
if (isConfidentialMode) {
// Convert IMT-wrapped IDs to public format for the API
const publicTokenIds = tokenIds.map(id => this.toPublicAssetId(id));
return this.getBalancesFromOneClick(publicTokenIds);
}
return this.getBalancesOnContract(tokenIds);
}
// Strip the IMT prefix to get the public asset identifier
private toPublicAssetId(imtTokenId: string): string {
const prefix = `imt:${privateTreasuryAccountId}:`;
if (imtTokenId.startsWith(prefix)) {
return imtTokenId.slice(prefix.length);
}
return imtTokenId;
}
```
***
## Solver response format
When responding to confidential quote requests, solvers must return their signed intents in the `private_signed_data` bundle. This structure contains up to three signed intents:
```typescript theme={null}
interface PrivateSignedData {
shield?: SignedData; // Optional: shield public liquidity to Treasury
swap: SignedData; // Required: the token_diff intent for the swap
recover?: SignedData; // Required if shield present: fallback burn if swap fails
solver_id?: string; // Your solver identifier
}
```
`SignedData` is the same signed-payload shape used everywhere else in the protocol (see [publish\_intent](/integration/market-makers/message-bus/rpc#publish_intent)):
```typescript theme={null}
interface SignedData {
standard: 'nep413' | 'erc191' | 'raw_ed25519';
payload: { recipient: string; nonce: string; message: string };
public_key: string;
signature: string;
}
```
For the full rules on when each of `shield`/`swap`/`recover` is required (not just their types), see [Confidential Intents → Solver response format](/integration/market-makers/confidential-intents#solver-response-format).
Each of `shield`, `swap`, and `recover` is signed the same way, by the solver's own NEAR key, using the same `near-api-js` signing flow the [Example Solver](/integration/market-makers/example#assembly-and-signing) uses for public `token_diff` intents (build the message, sign it, bs58-encode the result into `public_key`/`signature`). The only thing that changes per intent is the `message` content, `swap` signs a `token_diff`, `shield`/`recover` sign whatever transfer/burn intent your Treasury integration expects.
Here's what a fully populated `private_signed_data` bundle looks like on the wire, shielding public liquidity before the swap:
```json theme={null}
{
"quote_output": { "amount_out": "300" },
"private_signed_data": {
"shield": {
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hfrNi8/We0ieTmcMBti1YE=",
"message": "{\"deadline\":\"2026-07-16T12:05:00.000Z\",\"intents\":[{\"intent\":\"transfer\",\"tokens\":{\"nep141:ft1.near\":\"500\"},\"receiver_id\":\"\",\"memo\":\"\"}],\"signer_id\":\"your-solver.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:5tk3UyFcAgnd6D4ZAuzEdZqMrneRSiTqe48ptjbjYHwiCy2vTw38uDB3KusW2cEsF3TGcqZXoQmRaeNs2erhPpqu"
},
"swap": {
"standard": "nep413",
"payload": {
"recipient": "intents.far",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hcQLaHzX2s1fNKhBDblXT4=",
"message": "{\"deadline\":\"2026-07-16T12:05:00.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:ft2.near\":\"-300\",\"nep141:ft1.near\":\"500\"}},{\"intent\":\"imt_burn\",\"minter_id\":\"\",\"tokens\":{\"nep141:ft1.near\":\"500\"},\"memo\":\"your-solver.near\"}],\"signer_id\":\"your-solver.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:WQXG37prMyT4f1vp6JSvamsjqDR5fSnDiinSPaCoq9sPcDgFGPRiMWX7csqqudDbzc8i6wrfpemgpVX2wQDmwww"
},
"recover": {
"standard": "nep413",
"payload": {
"recipient": "intents.far",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hcQLaHzX2s1fNKhBDblXT4=",
"message": "{\"deadline\":\"2026-07-16T12:05:00.000Z\",\"intents\":[{\"intent\":\"imt_burn\",\"minter_id\":\"\",\"tokens\":{\"nep141:ft1.near\":\"500\"},\"memo\":\"your-solver.near\"}],\"signer_id\":\"your-solver.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:2erhPpquWQXG37prMyT4f1vp6JSvamsjqDR5fSnDiinSPaCoq9sPcDgFGPRiMWX7csqqudDbzc8i"
},
"solver_id": "your-solver.near"
}
}
```
* **`shield`** signs a `transfer` intent on the **public** contract (`recipient: "intents.near"`), moving your liquidity into the Treasury account. `memo` carries the encrypted recipient the Private PoA Bridge needs to mint the matching IMT on FAR.
* **`swap`** signs against the **private** contract (`recipient: "intents.far"`) and bundles two intents together: the `token_diff` (the actual swap) plus an `imt_burn` that unshields the received funds immediately instead of leaving them shielded. Its `nonce` must exactly match `recover`'s.
* **`recover`** also signs against `intents.far`, a single `imt_burn` for the amount that was shielded, using the same `nonce` as `swap` so only one of the two can ever execute.
### Building the response
When quoting, construct the `private_signed_data` bundle with your signed swap intent:
```typescript theme={null}
// Build the swap intent (token_diff)
const swapIntent = await this.buildSignedSwapIntent(params, deadline);
// Return the quote response with private_signed_data
// quote_output uses the same shape as public quoting: amount_out for
// exact_amount_in requests, amount_in for exact_amount_out requests
const quoteResponse = {
quote_output: {
amount_out: calculatedAmount,
},
private_signed_data: {
swap: swapIntent.signedData,
solver_id: process.env.SOLVER_ID,
},
};
```
If you need to shield public liquidity for the swap, include all three intents:
```typescript theme={null}
const quoteResponse = {
quote_output: { amount_out: calculatedAmount },
private_signed_data: {
shield: shieldIntent.signedData, // Transfer to Treasury
swap: swapIntent.signedData, // The actual swap
recover: recoverIntent.signedData, // Fallback burn (same nonce as swap)
solver_id: process.env.SOLVER_ID,
},
};
```
The `recover` intent must share the same nonce as the `swap` intent. This ensures only one of them can execute — either the swap succeeds, or the recover burns the shielded tokens back to public.
***
## Depositing liquidity
Before quoting confidential swaps, deposit liquidity from public Intents into your confidential balance.
### Using the deposit script
The example solver includes a script for shielding liquidity:
```bash theme={null}
NODE_ENV=local \
ONE_CLICK_ASSET_ID=nep141:wrap.near \
ONE_CLICK_AMOUNT=100000000000000000000000 \
npm run one-click:deposit-confidential
```
Run this for each token in your pair:
```bash theme={null}
# Deposit wNEAR
NODE_ENV=local \
ONE_CLICK_ASSET_ID=nep141:wrap.near \
ONE_CLICK_AMOUNT=100000000000000000000000 \
npm run one-click:deposit-confidential
# Deposit USDT
NODE_ENV=local \
ONE_CLICK_ASSET_ID=nep141:usdt.tether-token.near \
ONE_CLICK_AMOUNT=1000000 \
npm run one-click:deposit-confidential
```
Amounts are in the token's smallest unit. For 24-decimal tokens like wNEAR, `100000000000000000000000` equals 0.1 wNEAR.
### Withdrawing liquidity
To move liquidity back to public Intents:
```bash theme={null}
NODE_ENV=local \
ONE_CLICK_ASSET_ID=nep141:wrap.near \
ONE_CLICK_AMOUNT=100000000000000000000000 \
npm run one-click:withdraw-confidential
```
***
## Running the solver
With liquidity deposited, start the solver in confidential mode:
```bash theme={null}
NODE_ENV=local npm start
```
The solver will:
1. Connect to the private relay with your instance ID
2. Subscribe to confidential quote requests
3. Query balances from the 1Click API
4. Respond with signed quotes using versioned nonces
5. Acknowledge quote status events for guaranteed delivery
***
## Quick reference
| Public Intents | Confidential Intents |
| ------------------------------------------- | --------------------------------------------- |
| `SOLVER_MODE=public` | `SOLVER_MODE=confidential` |
| `wss://solver-relay-v2.chaindefuser.com/ws` | Private relay URL (contact Defuse team) |
| `intents.near` | `intents.far` |
| `nep141:wrap.near` | `imt::nep141:wrap.near` |
| Deterministic nonce | Versioned nonce with salt |
| On-chain balance query | 1Click API balance query |
| No acknowledgements | `quote_status_extended` with acknowledgements |
***
## Next steps
Learn more about the confidential intents architecture
Deep dive into the acknowledgement protocol
# Confidential Intents
Source: https://docs.near-intents.org/integration/market-makers/confidential-intents
Solve for private liquidity on the confidential relay
Confidential Intents extend the NEAR Intents protocol with privacy-preserving swaps. Market makers can provide liquidity on a private chain where balances and swap details are shielded from public view.
***
## How it works
Confidential Intents use a two-chain architecture:
1. **NEAR (Public)** — The public blockchain. `intents.near` is the smart-contract ledger that credits deposited balances.
2. **FAR (Private)** — A private NEAR fork where the `intents.far` contract executes swaps with shielded balances
FAR is a permissioned instance of the NEAR protocol operated by a small validator set with no public networking. Balances and swap details on FAR are not visible to the public — the RPC is private and reachable only through authenticated channels.
**Shield (public → private):** Tokens are transferred to the Treasury account on NEAR. The Private PoA Bridge processes this deposit and mints equivalent IMT tokens on FAR.
**Unshield (private → public):** IMT tokens are burned on FAR. The PoA Bridge processes the burn request and releases the backing tokens from the Treasury on NEAR.
The bridge operates on a request-driven model — it processes deposits and burns via RPC requests rather than actively detecting on-chain events.
Market makers quote against their private IMT liquidity on FAR. The swap settles entirely on FAR via a `token_diff` intent, invisible to public indexers.
### Asset identifiers
Confidential assets are represented as **IMT (Intents Multi-Token)** tokens on FAR. Each IMT is backed 1:1 by the corresponding tokens locked in the Treasury smart-contract account on the public chain.
The token ID format prefixes the public asset ID with a system account:
```
imt::nep141:
```
For example, wrapped NEAR on the confidential chain:
```
imt:51e8f94d77b5e90dc9852ca6113771e11e8382ce69473a75e313e41665de7cbe:nep141:wrap.near
```
This account ID (`PRIVATE_TREASURY_ACCOUNT_ID` in solver configs) is a production constant shared by all participants.
***
## Private Relay
Confidential Intents use a separate **Private Relay** (`PRIVATE_RELAY_WS_URL`) instead of the public Message Bus. The private relay:
* Broadcasts quote requests for confidential swaps (asset IDs are IMT-wrapped)
* Collects signed quotes from connected solvers
* Uses `QUOTE_STATUS_EXTENDED` events (vs `QUOTE_STATUS` on the public relay)
* Verifies signatures against the public `intents.near` contract, but reads balances from FAR
The private relay does **not** settle intents directly — settlement is handled by the Private PoA Bridge, which mints/burns IMT tokens across the public⇄private boundary.
The private relay uses the same Partner JWT authentication as the public relay. Contact the Defuse team for access to the private relay URL and credentials.
***
## Versioned nonces
Confidential intents require a **versioned nonce** format that encodes the contract salt and deadline. This differs from public intents where solvers typically use deterministic nonces based on reserves.
The nonce is constructed using `VersionedNonceBuilder` from the `@defuse-protocol/intents-sdk`:
```typescript theme={null}
import { VersionedNonceBuilder } from '@defuse-protocol/intents-sdk';
const salt = Buffer.from('e110f317', 'hex'); // 4-byte contract salt
const deadline = new Date(Date.now() + quoteDeadlineMs);
const nonce = VersionedNonceBuilder.encodeNonce(salt, deadline);
```
The contract salt (`PRIVATE_INTENTS_CONTRACT_SALT`) is a production constant. Using the wrong salt will cause intent verification to fail.
***
## Solver response format
When quoting confidential swaps, solvers return signed intents in the `private_signed_data` field:
| Intent | Required | Purpose |
| --------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `shield` | No | Transfer of solver's public liquidity to the Treasury (triggers IMT mint on FAR) |
| `swap` | Yes | Must contain exactly one `token_diff`. May optionally include an `imt_burn` if the solver wants output released immediately rather than staying shielded |
| `recover` | If `shield` present | Fallback `imt_burn` if the swap fails (shares the swap's nonce — only one can land) |
A quote with a `shield` intent but no `recover` intent will be rejected. The recover intent prevents solver liquidity from being stranded if settlement fails.
Solvers should only act on the `quote_settle_successful` event before releasing funds.
### Unshield notifications
When a solver's funds are unshielded (private → public), the relay sends an `UNSHIELDED` status notification via the dedicated `shield_status` stream. Subscribe to this stream separately from `quote_status` to receive these notifications:
```typescript theme={null}
// Subscribe to shield status updates
await this.sendRequest('subscribe', ['shield_status', null, true]);
```
The `shield_status` event payload contains:
* `quote_hash`: The quote identifier
* `status`: `"unshielded"` when funds have been released to public
```json Event theme={null}
{
"jsonrpc": "2.0",
"method": "subscribe",
"params": {
"quote_hash": "00000000000000000000000000000000",
"status": "unshielded"
}
}
```
`shield_status` supports the same [Guaranteed Delivery](/integration/market-makers/message-bus/guaranteed-delivery) acknowledgement/redelivery mechanics as `quote_status`, opt in the same way by passing the guaranteed-delivery flag on `subscribe`.
If your solver needs to check its own confidential balance rather than just watch for shield events, that's a separate flow: it queries `GET /v0/account/balances` on the 1Click API, which requires a **User-Session** token. See [Authenticating end users](/integration/distribution-channels/1click-api/authentication#authenticating-end-users-confidential-intents) for how to get one, and [Confidential Example → Authentication](/integration/market-makers/confidential-example#authentication) for it wired into a solver.
***
## Shielding and unshielding liquidity
Before quoting confidential swaps, market makers must **shield** (deposit) liquidity from the public NEAR chain into their private balance on FAR.
### Shield (deposit into confidential)
Transfer tokens from your public Intents balance to your confidential balance:
* `depositType`: `INTENTS`
* `recipientType`: `CONFIDENTIAL_INTENTS`
* `refundType`: `INTENTS`
```json theme={null}
{
"dry": false,
"swapType": "EXACT_INPUT",
"originAsset": "nep141:wrap.near",
"destinationAsset": "nep141:wrap.near",
"amount": "1000000000000000000000000",
"depositType": "INTENTS",
"recipient": "your-solver.near",
"recipientType": "CONFIDENTIAL_INTENTS",
"refundTo": "your-solver.near",
"refundType": "INTENTS"
}
```
### Unshield (withdraw to public)
Transfer tokens from your confidential balance back to public Intents:
* `depositType`: `CONFIDENTIAL_INTENTS`
* `recipientType`: `INTENTS`
* `refundType`: `CONFIDENTIAL_INTENTS`
```json theme={null}
{
"dry": false,
"swapType": "EXACT_INPUT",
"originAsset": "nep141:wrap.near",
"destinationAsset": "nep141:wrap.near",
"amount": "1000000000000000000000000",
"depositType": "CONFIDENTIAL_INTENTS",
"recipient": "your-solver.near",
"recipientType": "INTENTS",
"refundTo": "your-solver.near",
"refundType": "CONFIDENTIAL_INTENTS"
}
```
Use the same asset for both `originAsset` and `destinationAsset` when shielding or unshielding. These are liquidity movements, not swaps, so `amount` is just the amount you're moving, not something you're pricing.
The [example solver repository](https://github.com/hairy-pointer/near-intents-amm-solver/tree/feat/confidential-amm-solver-mode) includes runnable scripts for depositing and withdrawing confidential liquidity via the 1Click API.
***
## Next steps
Detailed walkthrough of solving for confidential intents
Compare with the public intents implementation
# Example Solver
Source: https://docs.near-intents.org/integration/market-makers/example
Understand how the AMM Solver example works
The [Quickstart](./quickstart) tutorial explains how to set up an [example AMM Solver](https://github.com/defuse-protocol/near-intents-amm-solver),
lets dive into understanding how it works: from connecting to the Message Bus through to settlement.
***
## Architecture
The project is organized into focused services, each handling one part of the workflow:
| Service | File | Responsibility |
| -------------------- | ---------------------------------------------- | --------------------------------------------------------------------------- |
| WebSocket connection | `src/services/websocket-connection.service.ts` | Connects to the Message Bus, subscribes to events, routes incoming messages |
| Quoter | `src/services/quoter.service.ts` | Evaluates quote requests, calculates pricing, builds and signs intents |
| Cron | `src/services/cron.service.ts` | Refreshes token balances from the Verifier contract on a 15-second interval |
The WebSocket service receives a quote request, hands it to the quoter, and the quoter responds with a signed intent. Meanwhile, the cron service keeps balance data current so the quoter always knows what it can fill.
***
## Message Bus connection
The WebSocket connection service (`src/services/websocket-connection.service.ts`) manages the link to the Message Bus. On connect, it subscribes to `"quote"` and `"quote_status"`.
On `"quote"`, pass `tokens_in` / `tokens_out` for the configured pair. Filter shape: [WebSocket `subscribe`](/integration/market-makers/message-bus/websocket#subscribe).
```typescript theme={null}
import WebSocket from 'ws';
const tokens = [
`nep141:${process.env.AMM_TOKEN1_ID}`,
`nep141:${process.env.AMM_TOKEN2_ID}`,
];
const ws = new WebSocket("wss://solver-relay-v2.chaindefuser.com/ws", {
headers: {
Authorization: `Bearer ${process.env.PARTNER_JWT}`,
},
});
ws.onopen = () => {
// Subscribe to quote requests
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "subscribe",
params: ["quote", { tokens_in: tokens, tokens_out: tokens }],
}));
// Subscribe to quote status updates
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 2,
method: "subscribe",
params: ["quote_status"],
}));
};
```
The WebSocket endpoint requires a Partner JWT for authentication. See the [Quickstart](./quickstart) for how to obtain one.
***
## Processing requests
When a `quote` event arrives, the WebSocket service checks whether the requested token pair matches the solver's configured pair. If it does, the request is passed to the quoter service for evaluation.
Each quote request contains the following parameters:
```typescript theme={null}
interface IQuoteRequestData {
quote_id: string;
defuse_asset_identifier_in: string;
defuse_asset_identifier_out: string;
exact_amount_in?: string;
exact_amount_out?: string;
min_deadline_ms: number;
}
```
The quoter service (`src/services/quoter.service.ts`) handles the core decision-making. For each incoming request, it:
1. **Validates the deadline** — rejects requests with unreasonable timeframes
2. **Checks reserves** — looks up current balances for both tokens
3. **Calculates the price** — uses a constant-product AMM formula with the configured margin
4. **Signs the response** — creates a `token_diff` intent and signs it with the configured NEAR key
***
## Building and signing intents
Once the quoter has computed a price, it constructs a `token_diff` intent — a signed statement declaring which tokens the solver is willing to give and receive.
### Token diff structure
A `token_diff` intent expresses net token changes from the solver's perspective:
```typescript theme={null}
{
intent: "token_diff",
diff: {
// Positive values = tokens you receive
"nep141:usdc.near": "1000",
// Negative values = tokens you give
"nep141:usdt.near": "-1000",
}
}
```
### Assembly and signing
The solver constructs the intent message directly and signs it using `near-api-js`. The message includes the solver's account ID, a deadline, and the `token_diff` intent:
```typescript theme={null}
import bs58 from 'bs58';
interface IMessage {
signer_id: string;
deadline: string;
intents: { intent: 'token_diff'; diff: Record }[];
}
const message: IMessage = {
signer_id: nearService.getIntentsAccountId(),
deadline: new Date(Date.now() + quoteDeadlineMs).toISOString(),
intents: [
{
intent: 'token_diff',
diff: {
// Token you're receiving (positive = incoming)
[params.defuse_asset_identifier_in]: params.exact_amount_in
? params.exact_amount_in
: amount,
// Token you're giving (negative = outgoing)
[params.defuse_asset_identifier_out]: `-${
params.exact_amount_out ? params.exact_amount_out : amount
}`,
},
},
],
};
```
The message is then serialized and signed. The example solver uses the NEP-413 signing standard on NEAR:
```typescript theme={null}
const messageStr = JSON.stringify(message);
const nonce = currentState.nonce;
const recipient = intentsContract; // "intents.near"
// Serialize the intent using Borsh for signing
const quoteHash = serializeIntent(messageStr, recipient, nonce, 'nep413');
// Sign with the NEAR key
const signature = await nearService.signMessage(quoteHash);
```
Every intent requires a [unique nonce](../verifier-contract/intent-types-and-execution#nonce-structure). The example solver uses a deterministic approach — it hashes the current token reserves with SHA-256, so the nonce only changes when the solver's balances change (i.e. after a trade settles):
```typescript theme={null}
import { createHash } from 'crypto';
const generateDeterministicNonce = (input: string): string => {
const hash = createHash('sha256');
hash.update(input);
return hash.digest('base64');
};
// Called with the current reserves:
const nonce = generateDeterministicNonce(
`reserves:${reserves.join(':')}`
);
```
In the example the nonce updates only after a trade settles, which results in a maximum throughput of roughly **1 swap per second**.
Consider changing it for an incrementing counter, pending submission tracking, or multiple signing accounts to improve parallelism.
This avoids fetching the contract salt on every request. The nonce is recomputed whenever the cron service refreshes balances.
Learn more about the nonce structure in the [Intent Types and Execution](/integration/verifier-contract/intent-types-and-execution#nonce-structure) docs.
Ensure your account has sufficient balance in the Verifier contract for the tokens you're offering. The intent will fail if you don't have enough tokens deposited.
***
## Quote response
After building and signing the intent, the solver sends a `quote_response` back through the WebSocket. The response includes the quote output (the calculated amount) and the full signed data:
```typescript theme={null}
const quoteResp: IQuoteResponseData = {
quote_id: params.quote_id,
quote_output: {
amount_in: params.exact_amount_out ? amount : undefined,
amount_out: params.exact_amount_in ? amount : undefined,
},
signed_data: {
standard: 'nep413',
payload: {
message: messageStr,
nonce,
recipient,
},
signature: `ed25519:${bs58.encode(signature.signature)}`,
public_key: `ed25519:${bs58.encode(signature.publicKey.data)}`,
},
};
```
Note that the response includes the `quote_id` from the incoming request — this is how the Message Bus links the quote to the original request.
The WebSocket service then sends this response to the relay:
```typescript theme={null}
await this.sendRequestToRelay(
RelayMethod.QUOTE_RESPONSE,
[quoteResp],
logger
);
```
Under the hood, `sendRequestToRelay` wraps the response in a JSON-RPC message:
```typescript theme={null}
const request = {
id: this.requestCounter++,
jsonrpc: '2.0',
method: 'quote_response',
params: [quoteResp],
};
ws.send(JSON.stringify(request));
```
The `quote_output` field tells the Message Bus which side of the trade the solver is quoting. If the request specified `exact_amount_in`, the solver responds with `amount_out` (how much it will give). If the request specified `exact_amount_out`, it responds with `amount_in` (how much it wants to receive).
***
## Monitoring
### Settlements
The solver subscribes to `quote_status` events to learn when its quotes are selected and settled on-chain. The WebSocket service routes incoming messages based on the subscription type:
```typescript theme={null}
switch (subscription.eventKind) {
case RelayEventKind.QUOTE:
this.processQuote(req.params.data, req.params.metadata);
break;
case RelayEventKind.QUOTE_STATUS:
this.processQuoteStatus(req.params.data);
break;
}
```
When a `quote_status` event arrives, the solver checks whether the settled quote hash matches one of its own cached quotes. If it does, it triggers a balance refresh so that future quotes reflect the updated reserves:
```typescript theme={null}
private async processQuoteStatus(data: IPublishedQuoteData) {
// data contains: { quote_hash, intent_hash, tx_hash }
const quote = this.cacheService.get(data.quote_hash);
if (!quote) {
// Not one of our quotes, skip
return;
}
// Our quote was settled — refresh balances
await this.quoterService.updateCurrentState();
}
```
### Balances
A cron service (`src/services/cron.service.ts`) refreshes token balances from the Verifier contract every 15 seconds. It calls the `mt_batch_balance_of` method on the intents contract to get the solver's current reserves. After a successful trade, the settlement handler also triggers an immediate refresh. This ensures the quoter always has accurate reserve data when calculating prices.
***
## Customization
The example uses a constant-product AMM formula, but any pricing logic can be used. The quoter service is the place to start — replace the `getAmountOut` and `getAmountIn` functions with a custom strategy, whether that is pulling prices from external APIs, using order books, or applying custom spread models.
A few additional areas to customize:
* **Support more token pairs** — add additional token IDs in the configuration
* **Add position limits** — cap how much of a token the solver can allocate
* **Implement risk controls** — set minimum trade sizes, maximum exposure, or rate limits
The `src/configs/` directory is a good starting point for customization. Each config file maps to a specific concern — tokens, margins, WebSocket URLs, and more.
For production deployments, consider running your solver in TEE (Trusted Execution Environment) mode, which provides additional security guarantees. See the [repository README](https://github.com/defuse-protocol/near-intents-amm-solver) for TEE setup instructions.
***
## Confidential Intents
The example solver also supports **Confidential Intents** — privacy-preserving swaps where balances and trade details are shielded from public view. If you're ready to solve for private liquidity, see the [Confidential Intents](./confidential-intents) guide to learn how to migrate.
# Market Makers
Source: https://docs.near-intents.org/integration/market-makers/introduction
Fulfill cross-chain swap intents as a liquidity provider
Market Makers compete to fulfill user [Swap intents](../distribution-channels/introduction). They listen for swap requests on the [Message Bus](./message-bus/introduction), evaluate whether they can fill the request, and respond with signed quotes.
![NEAR Intents Market Makers]()
![NEAR Intents Market Makers]()
***
## How it works
A user sends a [quote request](../distribution-channels/1click-api/quickstart/making-a-request#request-token) to the [Message Bus](/integration/market-makers/message-bus/introduction), a WebSocket relay that broadcasts the request to all connected solvers.
Each solver checks whether they can fulfill the swap. If they can, they compute pricing, and return a signed quote as response.
Multiple solvers can respond to the same request with different prices. The Message Bus collects responses and returns the top quotes to the user application.
After the user chooses a quote, the Message Bus matches the requested intent with the selected quote and submits it to the [Verifier contract](/integration/verifier-contract/introduction) where the swap settles on-chain.
The NEAR Intents protocol can operate without the Message Bus. Frontends can use other quoting mechanisms, and market makers can index the NEAR blockchain directly to find intents to fill.
***
## Next steps
Set up and run a solver that automatically responds to quote requests
Understand the code necessary to make a solver respond to quotes
Solve for private liquidity with shielded balances
Learn about the Message Bus architecture and how it works
# Guaranteed Delivery
Source: https://docs.near-intents.org/integration/market-makers/message-bus/guaranteed-delivery
Recover missed quote_status events after a disconnect
**Early access.** Guaranteed delivery is live in production, but no solver has exercised it yet. It should behave as described. If you see missing messages, duplicate floods, or subscribe errors, let us know in the shared support channels.
Guaranteed delivery lets your solver recover `quote_status` events it would otherwise miss while disconnected.
The [`quote_status`](/integration/market-makers/message-bus/websocket#quote_status-events) stream notifies your solver when one of its quotes is executed, carrying `quote_hash`, `intent_hash`, and `tx_hash`. Without guaranteed delivery, any event published while your WebSocket is disconnected is lost.
With it, the relay keeps a server-side queue for each solver instance. Events wait while you are offline, then replay when you reconnect, for up to 7 days.
***
## Opt in
Guaranteed delivery requires an authenticated solver connection (JWT). Complete these three steps:
Connect with an `instance_id` query parameter:
```
wss://solver-relay-v2.chaindefuser.com/ws?instance_id=
```
The relay finds your queue by this ID on every reconnect, and creates it the first time you subscribe with the guaranteed flag.
Use a fixed value from your deploy config (`prod-1`, `prod-2`), not a random one generated at startup.
IDs are scoped to your solver account, so two solvers using the same `instance_id` never collide. The relay gives each one a separate queue:
```
QS__
```
* **Use the same value across restarts and reconnects.** A new value gives you a new, empty queue.
* **One value per instance.** Two instances sharing an ID fight over one queue, and each message goes to only one of them, chosen arbitrarily.
* **One live connection per ID.** Don't open two at once for redundancy.
Open the WebSocket with your `instance_id`, then send a `subscribe` request for `quote_status`. Set the third positional parameter to `true`; the second parameter (filters) must be empty.
```typescript theme={null}
import WebSocket from "ws";
const ws = new WebSocket(
"wss://solver-relay-v2.chaindefuser.com/ws?instance_id=",
{ headers: { Authorization: `Bearer ${process.env.PARTNER_JWT}` } },
);
ws.on("open", () => {
ws.send(
JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "subscribe",
params: ["quote_status", null, true],
}),
);
});
```
The response returns your subscription ID:
```json theme={null}
{ "jsonrpc": "2.0", "id": 1, "result": "" }
```
The request is rejected without an authenticated Partner JWT and the `instance_id` from Step 1.
If you already subscribe to `quote_status`, this replaces that call.
Messages arrive as `event` notifications carrying a `seq`:
```json theme={null}
{
"jsonrpc": "2.0",
"method": "event",
"params": {
"subscription": "",
"data": { "quote_hash": "...", "intent_hash": "...", "tx_hash": "..." },
"seq": 12345
}
}
```
Handle each event by acknowledging it with your subscription ID and its `seq`, then running your settlement logic:
```typescript theme={null}
// `seen` and `subscriptionId` live at module scope so they survive reconnects.
// Bound `seen` in production (e.g. an LRU or a time window) so it does not grow forever.
const seen = new Set();
let subscriptionId: string | undefined;
function handleMessage(ws: WebSocket, raw: WebSocket.RawData) {
const msg = JSON.parse(raw.toString());
// The subscribe reply from Step 2 ({ "id": 1, "result": "" }).
// It echoes back our request id (1), so store its result as the subscription id.
if (msg.result && msg.id === 1) {
subscriptionId = msg.result;
return;
}
// Event delivered for our subscription.
if (msg.params?.subscription !== subscriptionId) return;
const { seq, data } = msg.params;
// 1. Acknowledge before doing any work.
ws.send(
JSON.stringify({
jsonrpc: "2.0",
id: Date.now(),
method: "acknowledge",
params: [subscriptionId, seq],
}),
);
// 2. Skip duplicates (redeliveries can repeat a seq).
if (seen.has(seq)) return;
seen.add(seq);
// 3. Now run your settlement logic.
handleQuoteStatus(data);
}
// Wire it to the socket from Step 2:
ws.on("message", (raw) => handleMessage(ws, raw));
```
**Acknowledge first, process second.** Redelivery fires after 5 seconds, which is too short for settlement logic. Persist or queue the message locally, acknowledge it, then do the work.
Deduplicate by `seq` or `quote_hash`. Redeliveries happen on reconnect, so you will sometimes receive the same message twice.
***
## After a reconnect
A subscription only lasts as long as the connection it was created on. When you reconnect, that old subscription is gone, so you have to send `subscribe` again. Doing so gives you a new subscription ID, and from that point on your acks must use the new ID, not the old one.
As soon as you re-subscribe, the relay replays your backlog in one burst: every message published while you were offline, plus any messages it had already sent you but that you hadn't acknowledged before the connection dropped.
Wrap the connection in a function so a drop reconnects and re-subscribes on its own. This reuses `handleMessage` from Step 3, and keeps `seen` across reconnects so the replayed backlog is still deduplicated:
```typescript theme={null}
function connect() {
const ws = new WebSocket(
"wss://solver-relay-v2.chaindefuser.com/ws?instance_id=",
{ headers: { Authorization: `Bearer ${process.env.PARTNER_JWT}` } },
);
// Re-subscribe on every connect; a reconnect always needs a fresh subscribe (Step 2).
ws.on("open", () => {
ws.send(
JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "subscribe",
params: ["quote_status", null, true],
}),
);
});
// Receive, acknowledge, and deduplicate each event (Step 3).
ws.on("message", (raw) => handleMessage(ws, raw));
// On drop, reconnect. The relay replays everything you missed once you re-subscribe.
ws.on("close", () => setTimeout(connect, 1000));
}
connect();
```
***
## Limits
| Property | Value |
| -------------------------------- | ------------------------------------------------------------------- |
| Redelivery window (ack deadline) | 5 seconds |
| Max unacknowledged in flight | 256 (delivery pauses past this until you catch up) |
| Retention / max offline | Up to 7 days |
| Queue expiry | Dropped after 7 days idle |
| First opt-in | Not retroactive; tracking starts at your first guaranteed subscribe |
***
## Errors
### Subscribe rejected
| Error | Cause |
| ------------------------------------------------------- | ------------------------------------------------- |
| `guaranteed delivery needs instance_id to be specified` | No `instance_id` query parameter |
| `guaranteed delivery needs an authenticated partner` | Connection isn't authenticated with a Partner JWT |
| `guaranteed delivery is only available on quote_status` | `guaranteed: true` set on another stream |
### Acknowledge
| Error | Cause / action |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `no pending message with seq N` | Double-ack, or an ack from before a reconnect. Harmless; don't retry, don't alert. |
| `subscription '...' not found` | Old subscription ID after reconnect. Re-subscribe and ack with the new one. |
| `acknowledge is only supported for quote_status subscriptions` | The subscription ID belongs to a different stream |
# Overview
Source: https://docs.near-intents.org/integration/market-makers/message-bus/introduction
Off-chain bus communicating market makers and users
The Message Bus is a system component that optimizes price discovery between users and market makers. It handles communication and submits settlement transactions to the Verifier contract.
![Message Bus Architecture]()
![Message Bus Architecture]()
The protocol can operate without the Message Bus:
* **Frontends** can use any quoting mechanism to compose and publish signed intents
* **Market makers** can index the NEAR blockchain directly to find intents to fill
***
## How it works
1. **User requests a quote** - A frontend sends a quote request to the Message Bus
2. **Market makers receive the request** - The Message Bus broadcasts the request to all connected solvers via WebSocket
3. **Market makers respond** - Solvers evaluate the trade and respond with signed intents
4. **User accepts a quote** - The frontend displays options to the user, who selects and signs their intent
5. **Settlement** - The Message Bus bundles the matching intents and submits them to the Verifier contract
***
## Next steps
Read the API documentation for the Message Bus
Subscribe and respond to quote requests in real-time
# API Reference
Source: https://docs.near-intents.org/integration/market-makers/message-bus/rpc
Request quotes and publish intents via JSON-RPC
NEAR Intents exposes an RPC endpoint to request quotes, publish signed intents, and check intent status on the Message Bus.
**Endpoint:** `POST https://solver-relay-v2.chaindefuser.com/rpc`
## Authentication
This endpoint requires a JWT authentication token. Include the token in the `X-API-Key` header:
```bash theme={null}
X-API-Key:
```
To obtain an API key, register through the [Partner Portal](https://partners.near-intents.org).
Developers searching to integrate swap functionality should use the [1Click Swap API](../../distribution-channels/1click-api/about-1click-api) instead.
***
## quote
Request price quotes from connected solvers. The Message Bus forwards the request to all solvers, waits up to 3000ms, and returns all available options.
Only one of `exact_amount_in` or `exact_amount_out` should be provided, not both.
Asset to trade from (e.g., `nep141:ft1.near`)
Asset to trade to (e.g., `nep141:ft2.near`)
Amount of input token for exchange
Amount of output token for exchange
Minimum validity time for offers (in milliseconds). Shorter times may yield better prices.
```json theme={null}
{
"id": 1,
"jsonrpc": "2.0",
"method": "quote",
"params": [
{
"defuse_asset_identifier_in": "nep141:ft1.near",
"defuse_asset_identifier_out": "nep141:ft2.near",
"exact_amount_in": "1000",
"min_deadline_ms": 60000
}
]
}
```
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": [
{
"quote_hash": "00000000000000000000000000000000",
"defuse_asset_identifier_in": "nep141:ft1.near",
"defuse_asset_identifier_out": "nep141:ft2.near",
"amount_in": "1000",
"amount_out": "2000",
"expiration_time": "2024-10-01T12:10:27Z"
}
]
}
```
Response fields:
* `quote_hash` - Quote response hash
* `defuse_asset_identifier_in` - Asset to trade from
* `defuse_asset_identifier_out` - Asset to trade to
* `amount_in` - Input amount (exact if specified, proposed otherwise)
* `amount_out` - Output amount (exact if specified, proposed otherwise)
* `expiration_time` - Expiration timestamp of the offer
***
## publish\_intent
Submit a signed user intent for execution. Supported signature standards: `nep413`, `erc191`, `raw_ed25519`.
`public_key` and `signature` come from signing the intent message with the NEAR key you registered on the Verifier contract (`add_public_key`, see the [Quickstart](/integration/market-makers/quickstart)'s "Deposit liquidity" step), not from a value you construct by hand. The [Example Solver](/integration/market-makers/example#assembly-and-signing) walks through the real signing code (`near-api-js`'s `signMessage`, then bs58-encoding the result with an `ed25519:` prefix). For the full field-by-field spec of every supported standard (including `erc191` and `raw_ed25519` below), see [Signing Intents](/integration/verifier-contract/signing-intents).
Quote response hashes from solvers
* `standard` - `"nep413"`
* `payload.message` - Stringified intent payload
* `payload.nonce` - Unique nonce
* `payload.recipient` - `"intents.near"`
* `payload.callbackUrl` - Optional, for some wallets
* `signature` - Signature of the payload
* `public_key` - Signer's public key
```json theme={null}
{
"id": 1,
"jsonrpc": "2.0",
"method": "publish_intent",
"params": [
{
"quote_hashes": ["00000000000000000000000000000000"],
"signed_data": {
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hfrNi8/We0ieTmcMBti1YE=",
"message": "{\"deadline\":\"2024-10-14T12:53:40.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:ft1.near\":\"300\",\"nep141:ft2.near\":\"-500\"}}],\"signer_id\":\"user.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:5tk3UyFcAgnd6D4ZAuzEdZqMrneRSiTqe48ptjbjYHwiCy2vTw38uDB3KusW2cEsF3TGcqZXoQmRaeNs2erhPpqu"
}
}
]
}
```
Quote response hashes from solvers
* `standard` - `"erc191"`
* `payload` - Stringified intent payload
* `signature` - Signature of the payload
```json theme={null}
{
"id": 1,
"jsonrpc": "2.0",
"method": "publish_intent",
"params": [
{
"quote_hashes": ["00000000000000000000000000000000"],
"signed_data": {
"standard": "erc191",
"payload": "{\"deadline\":\"2024-10-14T12:53:40.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:ft1.near\":\"300\",\"nep141:ft2.near\":\"-500\"}}],\"signer_id\":\"0x1dda60d784483fbb54304c68830d42a706327c6d\"}",
"signature": "0x8a1b7e...c1b"
}
}
]
}
```
Quote response hashes from solvers
* `standard` - `"raw_ed25519"`
* `payload` - Stringified intent payload
* `signature` - Signature of the payload
* `public_key` - Signer's public key
```json theme={null}
{
"id": 1,
"jsonrpc": "2.0",
"method": "publish_intent",
"params": [
{
"quote_hashes": ["00000000000000000000000000000000"],
"signed_data": {
"standard": "raw_ed25519",
"payload": "{\"deadline\":\"2024-10-14T12:53:40.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:ft1.near\":\"300\",\"nep141:ft2.near\":\"-500\"}}],\"signer_id\":\"user.near\"}",
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:5tk3UyFcAgnd6D4ZAuzEdZqMrneRSiTqe48ptjbjYHwiCy2vTw38uDB3KusW2cEsF3TGcqZXoQmRaeNs2erhPpqu"
}
}
]
}
```
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"status": "OK",
"intent_hash": "00000000000000000000000000000000"
}
}
```
Response fields:
* `status` - `"OK"` or `"FAILED"`
* `reason` - Error reason (if failed)
* `intent_hash` - Intent identifier
***
## publish\_intents
Submit multiple signed intents in one call. If any fail, the relay automatically requotes and retries the failed ones rather than failing the whole batch.
Quote response hashes from solvers, one set per intent being published
Array of signed intents, same shape as `signed_data` in [publish\_intent](#publish_intent)
When `true`, automatically requests a fresh quote and retries any intent that fails to publish, instead of just reporting the failure
```json theme={null}
{
"id": 1,
"jsonrpc": "2.0",
"method": "publish_intents",
"params": [
{
"quote_hashes": ["00000000000000000000000000000000"],
"signed_datas": [
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hfrNi8/We0ieTmcMBti1YE=",
"message": "{\"deadline\":\"2024-10-14T12:53:40.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:ft1.near\":\"300\",\"nep141:ft2.near\":\"-500\"}}],\"signer_id\":\"user.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:5tk3UyFcAgnd6D4ZAuzEdZqMrneRSiTqe48ptjbjYHwiCy2vTw38uDB3KusW2cEsF3TGcqZXoQmRaeNs2erhPpqu"
}
],
"requote": true
}
]
}
```
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"status": "OK",
"intent_hash": "00000000000000000000000000000000"
}
}
```
Response fields are the same as [publish\_intent](#publish_intent).
***
## get\_status
Check the status of an intent's execution.
Intent identifier
```json theme={null}
{
"id": 1,
"jsonrpc": "2.0",
"method": "get_status",
"params": [
{
"intent_hash": "00000000000000000000000000000000"
}
]
}
```
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"intent_hash": "00000000000000000000000000000000",
"status": "SETTLED",
"status_details": "Settled in block 123456789",
"data": {
"hash": "8yFNEk7GmRcM3NMJihwCKXt8ZANLpL2koVFWWH1MEEj"
},
"filled_amounts": ["300"]
}
}
```
Response fields:
* `intent_hash` - Intent identifier
* `status` - Execution status (see status values below)
* `status_details` - Human-readable detail on the current status (e.g. failure reason for `NOT_FOUND_OR_NOT_VALID`)
* `data.hash` - NEAR transaction hash (if available)
* `filled_amounts` - Amounts actually filled per leg, in the order the intent's diffs were specified (useful when a `token_diff` only partially fills)
| Status | Description |
| ------------------------ | ------------------------------------------------ |
| `PENDING` | Intent received, awaiting execution |
| `TX_BROADCASTED` | Transaction sent to the Verifier contract |
| `SETTLED` | Successfully settled on-chain |
| `NOT_FOUND_OR_NOT_VALID` | Intent not received, expired, or execution error |
# WebSocket Reference
Source: https://docs.near-intents.org/integration/market-makers/message-bus/websocket
Subscribe and respond to quote requests in real-time
NEAR Intents exposes a WebSocket endpoint for market makers (solvers) to receive and respond to quote requests in real-time.
**Endpoint:** `wss://solver-relay-v2.chaindefuser.com/ws`
## Authentication
This endpoint requires a Partner JWT, sent as an `Authorization: Bearer` header on the WebSocket handshake request (not `X-API-Key`, that header is only for the [REST RPC endpoint](/integration/market-makers/message-bus/rpc#authentication)):
```
Authorization: Bearer
```
To obtain a Partner JWT, register through the [Partner Portal](https://partners.near-intents.org).
***
## subscribe
Subscribe to quote requests or quote status events.
Subscription name: `"quote"` or `"quote_status"`
Optional quote filters. Second positional param. Omit, `null`, or `{}` = no filter. Set fields are ANDed; empty array on a field = no restriction for that field.
Put the `defuse_asset_identifier` values for the tokens you support in `tokens_in` and `tokens_out` (same IDs as on quote events).
| Field | Type | Keep the quote if |
| ------------ | ---------- | ------------------------------------------------------------ |
| `tokens_in` | `string[]` | input token (`defuse_asset_identifier_in`) is in this list |
| `tokens_out` | `string[]` | output token (`defuse_asset_identifier_out`) is in this list |
Also optional: `params[2]` `guaranteed` (see [Guaranteed Delivery](/integration/market-makers/message-bus/guaranteed-delivery)).
For `"quote_status"` with [guaranteed delivery](/integration/market-makers/message-bus/guaranteed-delivery), leave filters empty (`null` or `{}`).
Native NEAR pair:
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"method": "subscribe",
"params": [
"quote",
{
"tokens_in": ["nep141:usdt.tether-token.near", "nep141:wrap.near"],
"tokens_out": ["nep141:usdt.tether-token.near", "nep141:wrap.near"]
}
]
}
```
Cross-chain assets (still `nep141:` IDs on the bus):
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"method": "subscribe",
"params": [
"quote",
{
"tokens_in": [
"nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near"
],
"tokens_out": [
"nep141:eth-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48.omft.near",
"nep141:eth-0xdac17f958d2ee523a2206206994597c13d831ec7.omft.near"
]
}
]
}
```
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": "00000000-0000-0000-0000-000000000000"
}
```
Response fields:
* `result` - Subscription ID used for receiving events and unsubscribing
### `quote` events
After subscribing to `"quote"`, you'll receive events like this:
```json Event theme={null}
{
"jsonrpc": "2.0",
"method": "subscribe",
"params": {
"subscription": "00000000-0000-0000-0000-000000000000",
"quote_id": "00000000-0000-0000-0000-000000000000",
"defuse_asset_identifier_in": "nep141:ft1.near",
"defuse_asset_identifier_out": "nep141:ft2.near",
"exact_amount_in": "1000",
"min_deadline_ms": 60000,
"min_wait_ms": 1900,
"max_wait_ms": 3000,
"protocol_fee_included": false
}
}
```
Only one of `exact_amount_in` or `exact_amount_out` will be specified in each request.
Event fields:
* `quote_id` — Identifier for this auction; include it in your `quote_response`
* `defuse_asset_identifier_in` / `defuse_asset_identifier_out` — Token pair
* `exact_amount_in` or `exact_amount_out` — Fixed side of the trade
* `min_deadline_ms` — Minimum validity time your signed offer should support
* `min_wait_ms` / `max_wait_ms` — Auction collection window (see [Auction timing](#auction-timing-min_wait_ms--max_wait_ms))
* `protocol_fee_included` — When `true`, this is typically a router sub-leg auction with a shorter accept window
### Auction timing (`min_wait_ms` / `max_wait_ms`)
Each quote request opens a short auction on the relay. **You do not set these fields when responding** — they are chosen by the quote requester (or by the router for multi-hop sub-legs) and appear on the inbound event.
| Field | Meaning |
| ------------- | -------------------------------------------------------------------------------------------- |
| `min_wait_ms` | Mandatory collection window. The relay will not close the auction early before this elapses. |
| `max_wait_ms` | Hard deadline. The auction always ends by then, even if no early close happened. |
**Timeline**
1. The auction starts when the relay publishes the quote request.
2. From `0 → min_wait_ms`, the relay collects responses and does not settle early.
3. After `min_wait_ms`, if any responses have arrived, the relay may close after a short **grace period** (or immediately for certain whitelisted solvers).
4. At `max_wait_ms`, the auction always closes.
5. Once closed, the quote is removed. Late `quote_response` calls fail with `quote not found or already finished`.
**Effective windows solvers see**
| Request kind | How to recognize it | Effective collect window |
| ----------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Top-level auction | `protocol_fee_included` absent or `false` | `min_wait_ms` is floored to **at least 300ms**, then up to **\~300ms** grace if results exist |
| Router sub-leg | `protocol_fee_included: true` (often `partner_id: router-solver`) | **No 300ms floor.** Grace is **\~50ms**. FastQuote legs often use `min_wait_ms: 1`, so the accept window is roughly **\~51ms** total |
`max_wait_ms` is still the upper bound in both cases. When responses arrive quickly, the auction often ends around `min_wait_ms + grace`, not only at `max_wait_ms`.
Router FastQuote legs (`protocol_fee_included: true`, `min_wait_ms: 1`) require end-to-end response latency well under \~50ms. A \~50ms WebSocket round trip is enough to miss the window even if your handler itself finishes in under 1ms.
### `quote_status` events
After subscribing to `"quote_status"`, you'll receive settlement notifications:
```json Event theme={null}
{
"jsonrpc": "2.0",
"method": "subscribe",
"params": {
"quote_hash": "00000000000000000000000000000000",
"intent_hash": "00000000000000000000000000000000",
"tx_hash": "8yFNEk7GmRcM3NMJihwCKXt8ZANLpL2koVFWWH1MEEj"
}
}
```
`quote_status` events published while your connection is down are lost by default. To recover missed events after a disconnect, opt into [Guaranteed Delivery](/integration/market-makers/message-bus/guaranteed-delivery).
***
## quote\_response
Respond to a quote request with a signed intent. A unique `id` is required in the JSON-RPC message.
`signed_data` is produced by signing your `token_diff` intent with the NEAR key you registered on the Verifier contract, it's not something you construct by hand. See the [Example Solver](/integration/market-makers/example#assembly-and-signing) for the real signing code, and [publish\_intent](/integration/market-makers/message-bus/rpc#publish_intent) for the exact `signed_data` shape.
Quote request identifier from the event
* `amount_out` - Proposed amount for `exact_amount_in` requests
* `amount_in` - Proposed amount for `exact_amount_out` requests
Signed intent data (same format as `publish_intent`)
Optional hashes of other quotes needed to fulfill this intent
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"method": "quote_response",
"params": [
{
"quote_id": "00000000-0000-0000-0000-000000000000",
"quote_output": {
"amount_out": "300"
},
"signed_data": {
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAEiS6N1S/hcQLaHzX2s1fNKhBDblXT4=",
"message": "{\"deadline\":\"2024-10-14T12:53:40.000Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:ft2.near\":\"-300\",\"nep141:ft1.near\":\"500\"}}],\"signer_id\":\"solver.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:WQXG37prMyT4f1vp6JSvamsjqDR5fSnDiinSPaCoq9sPcDgFGPRiMWX7csqqudDbzc8i6wrfpemgpVX2wQDmwww"
}
}
]
}
```
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": "OK"
}
```
Response fields:
* `result` - `"OK"` when the quote response is accepted
***
## unsubscribe
Unsubscribe from a subscription.
Subscription ID returned by `subscribe`
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"method": "unsubscribe",
"params": ["00000000-0000-0000-0000-000000000000"]
}
```
```json theme={null}
{
"jsonrpc": "2.0",
"id": 1,
"result": "OK"
}
```
Response fields:
* `result` - `"OK"` when unsubscribed successfully
# Quickstart
Source: https://docs.near-intents.org/integration/market-makers/quickstart
Become a market maker on NEAR Intents
In this guide, you will set up and run an example solver that connects to the [Message Bus](/integration/market-makers/message-bus/introduction), receives live quote requests, and automatically responds to the ones it can fill.
To become a Market Maker you will need to request an API Key through the [Partner Portal](https://partners.near-intents.org) and go through KYC/KYB
***
## Getting started
* Node.js v20.18+ with npm
* A NEAR **mainnet** account
The [AMM Solver example](https://github.com/defuse-protocol/near-intents-amm-solver) uses a simple constant-product AMM formula to price quotes
```bash theme={null}
git clone https://github.com/defuse-protocol/near-intents-amm-solver.git
cd near-intents-amm-solver
npm install
```
Create your environment file from the provided example:
```bash theme={null}
cp env/.env.example env/.env.local
```
Open `env/.env.local` and fill your NEAR account credentials, the token pair you want to market-make, and your desired fee margin.
```bash theme={null}
# Your NEAR account credentials
NEAR_ACCOUNT_ID=your-solver.near
NEAR_PRIVATE_KEY=ed25519:your_private_key_here
# The token pair you want to market-make
AMM_TOKEN1_ID=usdt.tether-token.near
AMM_TOKEN2_ID=wrap.near
# Network and mode
NEAR_NETWORK_ID=mainnet
TEE_ENABLED=false
# Your solver will take this percentage from the quoted price as profit (0.3 = 0.3% = 30 bps)
MARGIN_PERCENT=0.3
```
The Message Bus WebSocket endpoint (`wss://solver-relay-v2.chaindefuser.com/ws`) requires authentication. To get your credentials:
1. Sign up at [partners.near-intents.org](https://partners.near-intents.org)
2. Request access through the partner portal
3. Complete KYC/KYB verification as part of the application process
Once approved, add your Partner JWT to `env/.env.local`:
```bash theme={null}
# Partner JWT for relay authentication
PARTNER_JWT=your_partner_jwt_here
```
The example solver automatically uses this token for WebSocket authentication — no code changes required.
Never commit your private key or Partner JWT to version control. The `.env.local` file is already in `.gitignore`, but double-check before pushing any changes.
Your solver can only fill swaps if it has token balances inside the Verifier contract (`intents.near`).
You need to do two things: register your solver's public key on the contract, and deposit tokens.
```bash theme={null}
npx near-cli-rs contract call-function as-transaction intents.near add_public_key \
json-args '{"public_key":"ed25519:YOUR_PUBLIC_KEY"}' \
prepaid-gas '100.0 Tgas' attached-deposit '1 yoctoNEAR' \
sign-as SOLVER_ACCOUNT_ID network-config mainnet sign-with-keychain send
```
Replace `YOUR_PUBLIC_KEY` with the public key that corresponds to the private key in your `.env.local` file, and `SOLVER_ACCOUNT_ID` with your actual NEAR account ID.
* [near.com](https://near.com/) - a web interface for swapping and depositing tokens
The solver needs balances for both tokens in the configured pair. For example, if you are market-making USDT/wNEAR, it needs both `usdt.tether-token.near` and `wrap.near` deposited into the contract.
Since the environment file is named `.env.local`, set `NODE_ENV=local` so the app picks it up:
```bash theme={null}
NODE_ENV=local npm start
```
On startup, the solver connects to the Message Bus WebSocket, subscribes to quote events, and begins polling the Verifier contract for current token balances every 15 seconds. Log output confirms the connection and initial reserves.
Check the health endpoint to confirm the solver is running:
```bash theme={null}
curl http://localhost:3000
```
```json theme={null}
{"ready": true}
```
In the logs, look for:
* Connection confirmed - successful WebSocket connection to the Message Bus
* Quote requests - incoming swap requests being evaluated
* Quote responses - signed quotes being sent back for pairs your solver supports
The solver only responds to requests for the configured token pair. If a request comes in for a different pair, or if reserves are too low to fill it, the solver skips it.
If quote requests are not appearing, that is normal during low-activity periods. The solver sends responses when matching requests arrive.
***
## Next steps
Now that the solver is running, read the [Example Solver](/integration/market-makers/example) guide to understand how the code works — from WebSocket connection through intent signing and settlement — and learn how to customize the pricing logic for your own strategy.
The example solver also supports **Confidential Intents** for solving against private liquidity. See the [Confidential Intents](/integration/market-makers/confidential-intents) guide to learn how to enable confidential mode.
# Solver Terms of Use
Source: https://docs.near-intents.org/integration/market-makers/solver-terms-of-use
Terms of use governing Solver access to the Solver Services
**NEAR INTENTS SOLVER TERMS OF USE**
**Last Updated: 15 July 2026**
**Please read these Solver Terms carefully.** These Terms are between you, and any entity you represent (the “**Solver**” or “**You**”), and Intents Technology Ltd., a BVI company (“**Intents Technology**,” “**We**,” “**Us**,” or “**Our**”), governing access and use of the Solver Services.
By registering as a Solver, completing KYC/KYB, accepting these Terms, connecting to the Solver Bus or an auction interface, using an API key, or submitting any Quote, fill, or Settlement, you accept these Terms as of the earliest such action (**“Effective Date”**). If a click-acceptance appears at onboarding, that click is required for API-key issuance and may be recorded. If you act for an entity, you confirm you have authority to bind it. If not, you must stop.
These Terms are for your technical connectivity to intent flow, auction, and settlement messaging. They are not regulated financial services; they are technical connectivity only. Intents Technology does not stand in the Transaction, does not provide liquidity, capital, credit, guarantees, or execution services, and does not guarantee any order flow or outcome. Use is at your sole risk.
If you also use the Services in another capacity – for example, as an end user of a Front-End Interface or as an integrator of the 1ClickSwap API – that use is governed by the separate terms applicable to that capacity, while these Terms govern your activity as a Solver.
**PURPOSE AND SCOPE**
**Nature of the Solver Services.** Intents Technology provides the Solver Bus and related relay infrastructure that carries End-User intent flow, quote requests, and Settlement instructions. A Quote request triggers message forwarding and, if selected and signed, publish/settlement messages on-chain. Your counterparty is always the End-User and the referenced intent. Intents Technology is never your trading counterparty.
**Role and Status.** You are an independent participant acting as your own principal for your own liquidity. You are not Intents Technology’s agent, partner, employee, or counterparty. Technical relays, forwarding, or routing do not create any broader relationship.
**Technical Actions.** In providing the Solver Services, Intents Technology relays and routes instructions between the Solver and the End-User and may collect or allocate Capture Share and fees as described in Sections 6.9 and 9. Intents Technology does not hold the Solver's or the End-User's private keys, does not pool, commingle, or re-use them, and nothing in the Solver Services creates any custodial, trust, or agency relationship between Intents Technology and the Solver. Settlement occurs on-chain through the Verifier, which holds settled balances and is subject to the governance and administrative mechanisms described in Section 7.7.
**Separation; Limited Technical Operation.** The Protocol, any Third-Party Interface, and any Third-Party Component are separate, and Intents Technology does not operate them or choose winning solvers. Intents Technology only controls the 1Click components it operates, including the Solver Bus. The PoA Bridge is separate and subject to its own terms; nothing here extends those terms to Intents Technology services.The PoA Bridge is operated by Intents Technology, and the Solver’s use of it in connection with the Solver Services is governed by these Terms (see Section 7.8), without prejudice to any separate terms of service that may apply to direct or standalone use of the PoA Bridge.
**1. DEFINITIONS**
For these Terms, these capitalized terms have the meanings below. Undefined terms have the meanings assigned in these Terms.
**“1Click Service”** means Intents Technology’s backend message-relay and settlement-messaging infrastructure for protocol intent routing and settlement.
**“Affiliate”** means an entity that controls, is controlled by, or is under common control with another Party.
**“API Key”** means the credential(s), including any X-API-Key token, issued after KYC/KYB to authenticate the Solver to the Solver API and Solver Bus.
**“Bona fide chain-level settlement failure”** means a chain halt, consensus failure, finality failure, protocol exploit, Verifier unavailability, or network condition that broadly prevents settlement and is not caused by the Solver, its Affiliates, or its controls.
**“Capture Share”** means the portion of Quote Improvement that is retained or allocated as described in Section 6.9, and that is not paid to the Solver.
**“Commercial Agreement”** means a separate written agreement governing a Solver’s onboarding, connection, or use of the Solver Services.
**“Confidential Information”** means information disclosed between the Parties that is designated or reasonably should be understood as confidential.
**“Confidential Intents Protocol”** means the smart contracts on the NEAR Private Shard that route and settle confidential intents and are not operated by Intents Technology.
**“Data”** means operational, technical, account, onboarding, KYC/KYB, compliance, request, response, wallet, IP, Quote, fill, Settlement, latency, error, telemetry, audit, and usage data.
**“Documentation”** means sample code, instructions, specifications, and other materials Intents Technology makes available to use and access the Solver Services.
**“Effective Date”** means the date the Solver first accepts these Terms.
**“End-User”** means any person or entity that posts or transacts an Intent through the Protocol or a Front-End Interface against which a Solver may quote, fill, or settle.
**“Fade”** means selection by the Solver and then failing, materially delaying, rejecting, or settling a Transaction materially worse than quoted, except for a bona fide chain-level settlement failure, latency, or Intents Technology infrastructure error. “Fade,” “Fades,” and “Fading” are equivalent forms.
**“Firm Quote”** means a Quote that becomes binding on the selected Solver under Section 6.3, subject only to the published tolerance band and a Bona fide chain-level settlement failure.
**“Force Majeure Event”** has the meaning given in Section 22.1.
**“Front-End Interface”** means any website or application that provides user-facing access to the Protocol or the 1Click Service, whether operated by Intents Technology (a **“First-Party Interface**”, such as near.com) or by a third party (a “**Third-Party Interface**”).
**“Indemnified Parties”** has the meaning given in Section 18.1.
**“Indicative Quote”** means a non-binding, non-reserved quote returned at the quoting stage, used as a reference point (including slippage tolerance).
**“Intent”** means any intent, bridge, swap, or transaction order posted on the Protocol and routed to Solvers through the Solver Bus.
**“Intellectual Property”** means patents, copyright, trade secrets, trademarks, service marks, moral rights, and other proprietary rights.
**“Intents Protocol”** means the NEAR Protocol smart contracts that route and settle intents via the solver network and are not controlled by Intents Technology.
**“Liquidity”** means the digital assets, inventory, and capital the Solver provides and controls, including in the Verifier, to quote, fill, and settle as principal.
**“NEAR Private Shard”** means the NEAR Protocol fork with restricted visibility used for confidential intents.
**“Party”** means either Intents Technology or the Solver individually, and together the “Parties.”
**“Performance Standards”** means the reliability and eligibility thresholds for continued access, including those in Section 6.10.
**“PoA Bridge”** means the Proof-of-Authority bridge developed and operated by Intents Technology and governed by its own separate terms of use, which is not a Third-Party Component., the Solver’s use of which in connection with the Solver Services is governed by these Terms (see Section 7.8) without prejudice to any separate terms of service that may apply to its direct or standalone use, and which is not a Third-Party Component.
**“Privacy Policy”** means the privacy policy linked from the Solver Portal or other Intents Technology URL, as at the Effective Date \[PRIVACY POLICY URL], which governs Data collection and processing for these Terms.
**“Prohibited Jurisdictions”** means jurisdictions Intents Technology bars under these Terms, including Afghanistan, Belarus, Central African Republic, Cuba, DRC, Guinea-Bissau, Haiti, Iran, Libya, Mali, Myanmar, Nicaragua, North Korea, Russia, Crimea, Donetsk, Luhansk, Zaporizhzhia, Kherson, Sevastopol, Somalia, South Sudan, Sudan, Syria, Venezuela, Yemen, Zimbabwe, and any similar addition.
**“Protocol”** means, together, the Intents Protocol and the Confidential Intents Protocol.
**“Protocol Event”** means chain halt, consensus failure, hard fork, validator failure, protocol upgrade or migration, exploit, or material settlement/finality change on a Protocol network not caused by the affected Party’s wilful act.
**“Quote”** means any price, timing, or availability indication the Solver submits in response to an Intent.
**“Quote Improvement”** means the difference where a Transaction fills at a price more favourable to the End-User than the Indicative Quote.
**“Quoting Layers”** means any protocol or third-party quoting, routing, or selection layer; **“Quoting Layer”** means any one such layer.
**“Settlement”** means the on-chain execution and completion of a Transaction via the Verifier (including via execute\_intents on intents.near or intents.far).
**“Solver”** means an independent third-party agent or system that receives, quotes, fills, or settles Intents on the Protocol as principal for its own account.
**“Solver Access Fee”** means any access fee Intents Technology charges the Solver, described in Section 9, which may be zero.
**“Solver API”** means Intents Technology’s interface, methods, and tools, including JSON-RPC, for receiving Intents, submitting Quotes, and effecting Settlement.
**“Solver Bus”** means Intents Technology’s relay for quote requests, Quote options, and publish/settlement messaging to connected Solvers.
**“Solver Portal”** means the NEAR Intents Partners Portal at [https://partners.near-intents.org/](https://partners.near-intents.org/) (or any successor URL), through which solvers register, complete onboarding and KYC/KYB, accept these Terms, manage API Keys, and access integration tools.
**“Solver Services”** means technical access, tools, relay infrastructure, Solver API, Solver Bus, Solver Portal, and support enabling Solver participation in intent flow, auction, and Settlement.
**“Solver System”** means software and infrastructure the Solver operates to receive Intents, submit Quotes, and manage inventory and Settlement.
**“Solver Wallet”** means a blockchain wallet or account controlled exclusively by the Solver through its private keys.
**“Third-Party Components”** means third-party networks, protocols, software, infrastructure, and services supporting the Solver Services or Protocol, none operated or controlled by Intents Technology.
**“Transaction”** means any Intent, bridge, swap, or other transaction order that the Solver quotes, fills, or settles through the Solver Services.
**“Verifier”** means the on-chain Protocol contract (including intents.near on NEAR Protocol and intents.far on the NEAR Private Shard) that maintains Liquidity and settles Intents.
**2. ACCESS, ONBOARDING AND MANDATORY KYC/KYB**
**2.1 Access and API Keys.** Intents Technology grants the Solver non-exclusive access via API Keys for the Solver Services. The Solver must (a) keep each API Key secure; (b) not transfer, share, or expose any API Key; and (c) be liable for all activity under it and notify Intents Technology promptly of any actual or suspected compromise, loss, or misuse.
**2.2 Solver Onboarding and Solver Portal.** The Solver must register in the Solver Portal, accept these Terms, and keep onboarding information accurate and current. The Solver alone is responsible for its account, credentials, and API Keys. Intents Technology may refuse, suspend, or revoke registration for inaccurate, incomplete, or unverifiable information.
**2.3 Mandatory KYC/KYB as Condition of Access.** KYC on principals and KYB on the Solver are conditions to API Key issuance and any quoting, filling, or Settlement. They are a security and compliance control for Intents Technology, not a regulated onboarding service or delegation for End-Users. No Solver may access the auction or Settlement without current, verifiable KYC/KYB; ongoing refresh and re-verification are required. If standing lapses or cannot be verified, Intents Technology may immediately suspend access and freeze routing.
**2.4 Documentation.** Documentation is for operational guidance only, may change at any time, and does not form part of these Terms. If conflicting, these Terms prevail.
**2.5 Modifications and Updates.** Intents Technology may modify, update, or discontinue any part of the Solver Services, including APIs, auction logic, endpoints, and parameters, at any time. The Solver must adopt updates within a reasonable period. Intents Technology may deprecate prior versions and restrict access of any Solver that fails to migrate.
**2.6 Support.** Any support or developer relations Intents Technology provides is discretionary and without service-level commitments.
**2.7 Monitoring.** Intents Technology may collect and process usage Data to protect integrity, security, enforce limits, and investigate conduct prohibited in Section 5. Such processing is governed by the Privacy Policy. Intents Technology may monitor but has no duty to do so.
**2.8 Rate Limits and Message Limits.** Intents Technology may set, change, enforce, and suspend rate and message limits, including anti-spam controls. It may throttle or restrict access that exceeds limits or threatens the integrity or performance of the Solver Services, Bus, or Protocol.
**3. LICENSE AND INTELLECTUAL PROPERTY**
**3.1 License Grant.** Subject to the Solver’s continuous compliance with these Terms, Intents Technology grants the Solver a limited, non-exclusive, non-sublicensable, non-transferable, revocable license to access and use the Solver Services solely to participate as a Solver — to receive Intents, submit Quotes, and fill and settle Transactions as principal for its own account. This license does not permit the Solver to incorporate, embed, resell, or expose the Solver API, the Solver Bus, or any other part of the Solver Services in or through any product, service, or interface made available to any third party. All rights not expressly granted are reserved.
**3.2 Third-Party Software.** The Solver Services may include or interoperate with third-party or open-source software subject to separate license terms, which govern to the extent of any conflict with these Terms as to that software. Intents Technology makes no warranty in respect of any such software, and the Solver’s use of it is at its own risk.
**3.3 Intellectual Property Rights.** As between the Parties, Intents Technology and its licensors own and retain all right, title, and interest, including all Intellectual Property rights, in and to the Solver Services, the Solver API, the Solver Bus, the Solver Portal, the Documentation, the 1Click Service, and all related technology and all improvements, modifications, and derivatives; and the Solver owns and retains all such right, title, and interest in and to the Solver System. Nothing in these Terms transfers any ownership of, or grants any license under, the Intellectual Property of either Party except the limited license in Section 3.1. The Solver shall not remove, obscure, or alter any proprietary notice on any element of the Solver Services or Documentation.
**3.4 Feedback.** If the Solver provides any suggestions, comments, ideas, or other feedback relating to the Solver Services (“**Feedback**”), Intents Technology may use, reproduce, modify, and exploit it for any purpose without restriction, attribution, or compensation. The Solver grants Intents Technology a perpetual, irrevocable, worldwide, royalty-free license to do so, represents that it has the right to grant that license, and, to the extent permitted by law, waives all moral rights in the Feedback. Intents Technology is under no obligation to use any Feedback.
**3.5 Marks and Public Statements.** The Solver may identify Intents Technology solely as the provider of the technical connectivity infrastructure it uses, and only in a manner that accurately describes the relationship. The Solver shall not use any name, logo, or mark of Intents Technology, the Protocol, or NEAR in any manner that implies partnership, sponsorship, endorsement, or any relationship beyond that limited technology-provider relationship, and shall, where it refers to Intents Technology, disclaim that Intents Technology is its counterparty, backer, or trading venue. The Solver shall not represent that it is “the official solver,” or that it is “endorsed,” “approved,” “certified,” “partnered,” or “backed” by Intents Technology or NEAR, or that Intents Technology guarantees it any order flow, auction wins, priority, or profitability.
**4. SOLVER OBLIGATIONS**
**4.1 General Obligations.** The Solver shall not, and shall not permit any third party to:
1. sell, resell, sublicense, or provide access to the Solver Services, or operate a proxy, wrapper, or intermediary exposing them to any third party;
2. use the Solver Services to build, train, or operate a competing product or benchmark;
3. reverse engineer, decompile, disassemble, or otherwise derive the source code, structure, or logic of the Solver Services, except where law explicitly permits it;
4. interfere with, disrupt, degrade, or attempt unauthorised access to the Solver Services, Solver Bus, auction, Protocol, or another Solver;
5. use pending Intents, order flow, quote requests, or routing data for anything other than producing, submitting, honouring, and settling its own Quotes;
6. settle outside Solver Wallets controlled by the Solver, or use mixers, tumblers, or proxy wallets that conceal the settling wallet;
7. use the Solver Services in breach of sanctions, export-control, or anti-money-laundering law; or
8. fail to maintain reasonable safeguards against fraud, abuse, or unlawful use of its access.
**4.2 No Counterparty Relationship.** These Terms are only between the Parties. Intents Technology is not the Solver’s trading counterparty and has no liability for any Transaction the Solver quotes, fills, or settles. The Solver is solely responsible for all Transactions and related settlement obligations.
**4.3 Compliance Screening and Cooperation.** The Solver must run ongoing KYT/AML/CTF on counterparties, wallets, and intent flow at its cost and reject non-compliant flow. Sanctions reporting is the Solver’s responsibility as principal. Intents Technology’s Bus filtering is access control only and can be changed or withdrawn. The Solver must respond to lawful requests within five (5) business days.
**4.4 Security Obligations and Incident Response.** The Solver must secure its API keys, private keys, wallets, and signing infrastructure and notify Intents Technology within twenty-four (24) hours of any incident affecting access or Settlement. Intents Technology may treat it as a security incident and halt routing immediately. No public statement is allowed without prompt notice unless disclosure is legally required immediately.
**4.5 Operational Resilience.** The Solver must maintain baseline continuity, recovery, incident-response, key-management, access-control, and monitoring controls for its trading infrastructure. This is in addition to, and does not limit, Section 4.4.
**4.6 Records, Audit and Evidence.** The Solver must keep books, logs, wallet, settlement, compliance, and incident records for at least seven (7) years. It must promptly provide records and attestations on request for lawful purposes. Intents Technology may suspend access during review. No silence or review by Intents Technology is approval.
**4.7 No Delegation; No Sub-Solver Access.** The Solver may not delegate access to receive flow, submit Quotes, hold API Keys, operate the Solver System, or settle Transactions without Intents Technology’s prior written consent. Any approved delegate is fully the Solver’s responsibility.
**4.8 Regulatory and Ownership-Change Notification.** The Solver shall immediately notify Intents Technology of any change in ownership, control, beneficial ownership, directors, officers, jurisdiction, place of business, sanctions status, licensing, insolvency, or compliance programme that materially affects eligibility, risk, or ability to perform under these Terms.
**4.9 Prohibited Representations.** The Solver must not:
1. state or imply it operates, controls, or maintains the 1Click Service, the Solver Bus, or any part of the Solver Services;
2. guarantee uptime, availability, performance, or execution quality of any Solver Service or interface;
3. describe Intents Technology as a broker, dealer, exchange, trading venue, market-maker, intermediary, order-flow provider, custodian, counterparty, payment provider, clearing house, fiduciary, or similar market intermediary;
4. represent that Intents Technology guarantees flow, auction wins, ranking, routing, priority, or profitability to the Solver; or
5. make any false, misleading, or deceptive statement about Intents Technology, the Protocol, or the Solver Services.
**5. MARKET CONDUCT AND PROHIBITED TRADING PRACTICES**
These rules are private access conditions for a technical relay. They are not exchange, venue, surveillance, or investor-protection standards, and Intents Technology gives no fair-market guarantees.
**5.1 Good-Faith Quoting Standard.** Every Quote the Solver submits through the Solver Bus must be made in good faith, be backed by available or sourceable Liquidity, and represent a price and timing it intends and can settle if selected. A Quote submitted without settlement intent or capacity is a material breach.
**5.2 Prohibited Trading Conduct.** The Solver shall not engage in, attempt, or facilitate any of the following in connection with the Solver Services, the auction, or any Transaction:
1. wash trading, self-dealing, or matched trading, including quoting against, filling, or settling its own Intents or Intents originated, controlled, funded, or coordinated by the Solver, any of its Affiliates, or any person acting in concert with it, and any conduct intended to inflate the Solver’s volume, fill, selection-eligibility, or reliability statistics;
2. spoofing, quote-stuffing, layering, or phantom liquidity, including submitting Quotes not intended to be honoured to influence the auction or price;
3. collusion, quote-fixing, bid-rigging, or the coordination or allocation of flow, quoting, or auction outcomes with any other solver or person;
4. front-running, sandwiching, back-running, or any other extraction of maximal extractable value (MEV) on Intent flow, including on the basis of information obtained through the Solver Bus; and
5. the manipulation, attempted manipulation, or distortion of any reference price, index, oracle, or market in which the Solver hedges, quotes, or settles, or which is used to price or settle any Transaction.
The execution of confidential Intents on the NEAR Private Shard does not exempt the Solver from Section 5, and applies equally to confidential and non-confidential Transactions.
**5.3 Misuse of Order-Flow Data.** The Solver shall not use pending Intents, quote requests, order flow, or routing for front-running, sandwiching, MEV extraction, unrelated model development, resale, or trading by a third party. It shall not sell, license, share, or disclose it. Retention is limited to what is necessary to quote and settle and to meet legal, regulatory, tax, audit, sanctions, AML/CFT, dispute-resolution, and recordkeeping obligations.
**5.4 Monitoring, Audit and Enforcement.** Intents Technology may monitor telemetry, review conduct, and enforce these Terms. If Intents Technology reasonably believes a breach is occurring or imminent, Intents Technology may throttle, suspend, restrict, or terminate. Good-faith determination is sufficient, and remedies are cumulative with Sections 6.10, 8.2, and 19.
**6. QUOTING AND SETTLEMENT MECHANICS**
**6.1 Indicative Quotes; Non-Binding at Quoting Stage.** At the quoting stage, a Quote returned through the Solver Bus is non-binding and non-reserved, serving only as a reference point, including for slippage tolerance. It is not an offer and does not guarantee availability, selection, or settlement at the stated terms. This does not affect the Solver’s binding honour and settlement obligation under Section 6.3 once selected.
**6.2 Auction Selection on Independent Logic.** A winning Solver is selected by deterministic logic in the Protocol or Quoting Layers. Intents Technology exercises no case-by-case discretion over selection, execution, acceptance, or settlement. Its routing logic is pre-set technical access control, not negotiated order handling, and may use quoted price, latency, and historical reliability. No best-execution, best-price, or best-routing duty applies. Intents Technology may add, change, or remove gates and filters, including ONE\_CLICK\_API\_ONLY.
**6.3 Honour and Settlement Obligation.** If selected, the Solver must fill and settle at quoted terms within response and settlement windows, except where the Transaction is outside the published tolerance band or a bona fide chain-level settlement failure occurs. This obligation is only for Intents Technology and does not entitle you to guaranteed flow, ranking, revenue, or opportunity. Upon selection, the Quote is a Firm Quote regardless of its pre-selection form. End-Users cannot enforce Section 6.3; your duties to counterparts arise only from your principal role.
**6.4 Anti-Fade and Anti-Last-Look.** The Solver must not Fade, use hold windows, re-quotes, last-look, or asymmetric rejection that worsens adverse fills while preserving favourable fills. Settlement may be declined only for bona fide chain-level failure or tolerance-band deviation. Inventory, market movement, stale pricing, latency, internal limits, manual review, and delayed screening are not valid excuses. Any exception is access-control only and revocable. A Fade or Settlement default is a material breach under Section 6.10, Section 6.5, and Section 18, with no End-User loss proof required.
**6.5 Settlement-Default Monetary Remedy.** On any Fade or Settlement default, or breach of Sections 6.3 or 6.4, the Solver indemnifies Intents Technology and the Indemnified Parties for related losses, costs, and expenses, including investigation, replacement-settlement, user support, regulatory response, legal, and infrastructure costs, whether direct or third-party asserted.
**6.6 No Guarantee of Flow, Wins, Priority or Profitability; No Best Execution Owed to the Solver.** Intents Technology does not guarantee flow, auction wins, selection, ranking, routing, or profitability. It owes no best-execution, best-price, or best-routing duty to any person. Section 6.3 is only a Solver-to-Intents Technology obligation, and gate application remains Intents Technology’s unilateral access-control choice.
**6.7 No Order-Flow Sale; No Payment for Order Flow.** No fee, status, support, agreement, or operational accommodation creates any right to flow, routing, ranking, allocation, or eligibility. Intents Technology does not sell, buy, or receive payment for order flow, and owes no duty to route or expose any Intent to the Solver.
**6.8 Settlement Finality and Recovery.** Settlement is final on-chain via the Verifier and governed by network mechanics outside Intents Technology’s control. Intents Technology cannot reverse, retry, refund, recover, or unwind failed, partial, delayed, or locked Settlement. As principal, the Solver bears all related settlement risk. Bus or infrastructure issues are not Fades by default and do not create Intents Technology liability under Sections 14.1 and 17. PoA Bridge Settlements remain subject to PoA Bridge terms.Settlements or transfers involving the PoA Bridge are also subject to Section 7.8.
**6.9 Quote Improvement and Capture Share.** Where a filled Transaction settles better than the Indicative Quote, the positive difference ("Quote Improvement") does not accrue to the Solver, which receives only the net result of its own fills as principal. Capture Share, and the treatment of any amounts retained or allocated, are addressed in Section 9.
**6.10 Performance Standards.** Intents Technology may set, publish, and modify Performance Standards in its sole discretion, which may include minimum settlement-success or honour rates, maximum Fade, fill-failure, or error rates, latency targets, price-deviation limits, and a published tolerance band. If the Solver fails any Performance Standard, Intents Technology may throttle, deprioritise, deselect, suspend, restrict, or terminate access, with or without notice, including by automated deprioritisation or deselection for threshold breaches, with remedies cumulative. The Solver must maintain liquidity sufficient to honour the Transactions it quotes and fills; Intents Technology may assess the Solver’s liquidity, capitalisation, and reliability for access, and does not guarantee order flow, wins, ranking, priority, or volume.
**7. LIQUIDITY, ASSETS AND CUSTODY**
**7.1 Solver-Provided Liquidity.** The Solver provides and maintains its own Liquidity, at its own cost and under its own control, including in the on-chain Verifier, to quote, fill, and settle Transactions as principal. Intents Technology supplies no Liquidity, capital, credit, balance sheet, or financing of any kind, and is under no obligation to ensure the Solver has or maintains sufficient Liquidity for any Transaction.
**7.2 Self-Custody; Keys and Wallets.** Each Solver Wallet is exclusively controlled by the Solver. Intents Technology is not a fiduciary, trustee, custodian, or agent for any Solver digital asset and bears no liability for losses from incorrect, inaccessible, lost, or compromised keys or wallets. The Solver accepts the volatility and key-loss risk.
**7.3 Custody of Keys; Self-Custody by the Solver.** Intents Technology does not request, hold, or control the Solver's private keys and does not take custody of the Solver's wallet. The Solver self-custodies and is solely responsible for its keys, wallet, and assets. Assets transacted through the Services settle on-chain and, where applicable, are held in the Verifier smart contract rather than by Intents Technology; the Verifier is subject to the governance and administrative mechanisms described in Section 7.7. Intents Technology relays messages and collects or allocates Capture Share, fees, and related amounts as described in Sections 6.9 and 9.
**7.4 Assumption of Market, Inventory, Settlement and Gas Risk.** The Solver bears all market, inventory, hedging, network, execution, and settlement risk as principal. Intents Technology bears none. No insurance, guarantee fund, compensation, or deposit-protection scheme is available here or for any Transaction, as further set out in Section 22.9.
**7.5 Key Compromise as Notifiable Incident.** Any compromise, suspected compromise, or loss of control of the Solver’s private keys, Solver Wallets, or signing infrastructure affecting or potentially affecting Settlement is a notifiable security incident under Section 4.4. Intents Technology may halt routing to the Solver without notice and has no obligation to make it whole for this event.
**7.6 Reserved Collateral.** Intents Technology may require the Solver, as a condition of continued access, to post and maintain a performance bond, on-chain security deposit, or other collateral, or to hold or stake a specified amount of NEAR or other digital assets, in an amount and form it specifies, against which it may set off Settlement-default losses, indemnity claims, and fee-avoidance amounts. No such security is required as at the Effective Date unless stated in the Documentation, the Solver Portal, or a Commercial Agreement.
**7.7 Protocol and Verifier Governance.** The Verifier and the underlying Protocol are subject to administrative roles, governance procedures, and upgrade mechanisms defined in the smart-contract code, which may, among other things, modify fees and fee parameters, pause or upgrade the contracts, transfer or otherwise affect balances held in the Verifier (including the Solver’s Liquidity), or grant or modify administrative roles. These powers are governed by the underlying Protocol and are not controlled by Intents Technology; any such action may take effect on-chain without prior individual notice. The Solver bears the risk of, and Intents Technology is not responsible for, any losses, fee changes, or asset movements resulting from such actions.
**7.8 Bridging and Cross-Chain Transfers.** Moving the Solver’s Liquidity or other assets onto or off any blockchain network, including funding, rebalancing, depositing, or withdrawing inventory in connection with quoting, filling, or settling Transactions, may require those assets to be routed through one or more cross-chain bridges, which may include the PoA Bridge (developed and operated by Intents Technology or its Affiliates) and third-party bridges operated by independent parties under their own terms. The Solver acknowledges and agrees that:
(a) while a deposit, withdrawal, or transfer is in progress, the Solver’s assets may be held, locked, or controlled within the relevant bridge’s infrastructure (including, in the case of the PoA Bridge, by its validators or authorities) until the transfer completes;
(b) bridging is inherently higher-risk than on-chain settlement and may result in processing delays; failed, partial, or stuck transfers; smart-contract failure, bug, or exploit; validator, authority, or relayer failure, downtime, compromise, or misconduct; chain reorganisation or consensus failure; changes to fees or to supported assets and networks; and the irreversible and permanent loss of assets sent to an incorrect or unsupported address or network, or with a missing or incorrect memo, tag, or metadata, all of which the Solver bears as principal under Section 7.4;
(c) the PoA Bridge and any other bridge are provided “as is” and “as available”, without warranty of any kind, and, to the maximum extent permitted by applicable law, Intents Technology does not guarantee, and has no liability in respect of, the availability, uptime, continuity, accuracy, finality, or performance of any bridge, or any loss, delay, failure, lock-up, or asset movement arising from or in connection with bridging;
(d) Intents Technology has no obligation to reverse, retry, refund, or recover any bridged deposit, withdrawal, or Settlement, although it may attempt to assist with recovery in its sole discretion;
(e) any of the Solver’s Liquidity or assets in transit through, or dependent on, a bridge is not available for Settlement until the transfer completes, and the Solver remains solely responsible for maintaining Liquidity sufficient to honour the Transactions it quotes and fills notwithstanding any bridging delay or failure;
(f) the Solver’s use of and reliance on the PoA Bridge in connection with the Solver Services is governed by these Terms, including the disclaimers in Section 16 and the limitations of liability in Section 17, without prejudice to any separate terms of service that may apply to direct or standalone use of the PoA Bridge; and
(g) bridging and cross-chain transfers are subject to applicable sanctions, screening, and KYT/AML controls and may be delayed, blocked, frozen, or rejected on that basis, and the Solver remains responsible for its own compliance under Sections 4.3 and 11.
**8. ACCEPTABLE USE**
**8.1 Prohibited Conduct.** In addition to the obligations set out elsewhere in these Terms, the Solver shall not, and shall not permit any third party to:
1. flood, spam, or overload the Solver Services, the Solver Bus, the auction, or the Protocol with quote requests, messages, or traffic, or otherwise consume resources in a manner that degrades or threatens the integrity or performance of any of them;
2. front-run, sandwich, back-run, or extract MEV in connection with Intent flow, as further addressed in Section 5;
3. grief, manipulate, collude with, disrupt, or otherwise interfere with any other solver, the auction, any bridge operator, or any Settlement infrastructure;
4. circumvent, disable, or attempt to circumvent or disable any rate-limit, access-control, fee-metering, authentication, or security mechanism of the Solver Services;
5. use the Solver Services for any illegal or fraudulent purpose, including money laundering, terrorist financing, sanctions evasion, tax evasion, market abuse, or fraud;
6. use the Solver Services to circumvent any sanctions, export-control, or trade-control restriction; or
7. introduce any malware, or take any action that damages, impairs, or disables the Solver Services, the Solver Bus, the auction, the Protocol, or any related infrastructure.
**8.2 Remedies.** Intents Technology may, in its sole discretion and without prior notice or liability, throttle, suspend, restrict, deprioritise, or terminate the Solver’s access, in whole or in part, in response to any actual or suspected breach of these Terms, including any breach of this Section 8 or of Section 5, or in its sole and absolute discretion for any other reason. These remedies are cumulative with all other rights and remedies of Intents Technology under these Terms, including the access-eligibility suspension and termination rights in Section 6.10, and the termination rights in Section 19.
**9. SOLVER ECONOMICS AND FEES**
**9.1 Applicability.** The fee and economics framework for the Solver is in this Section 9 and any Commercial Agreement. If there is a conflict, the Commercial Agreement governs.
**9.2 Nature of Solver Economics; No Revenue Entitlement.** These Terms create no partnership, joint venture, profit-sharing, revenue-sharing, or securities-like arrangement. The Solver keeps only spread on filled Transactions, net of protocol fee, and its own gas, hedging, and operating costs. Intents Technology does not rebate, share, or guarantee revenue.
**9.3 Protocol Fee and Capture Share.** A protocol fee may be deducted on each Transaction at the Verifier and directed to a Protocol recipient. Intents Technology does not deduct, collect, hold, receive, or remit it. Capture Share, by contrast, may be collected or retained by, or allocated to, Intents Technology. The Solver has no entitlement to, or interest in, any Quote Improvement or Capture Share, and receives only the net result of its own fills as principal. Protocol governance may change fee levels, with no lower economic cap.
**9.4 Reserved Solver Access Fee.** Intents Technology may charge a metered Solver Access Fee for technical access (authentication and relay capacity). It is a Solver-paid infrastructure charge, not a commission, spread split, payment for order flow, or End-User charge. As of the Effective Date, it may be zero. If charged, it is objective-metric based, paid to Intents Technology, non-refundable except manifest error, and changes only prospectively.
**9.5 Fee Calculation and Finality.** Protocol fee, Capture Share, and Access Fee are calculated automatically and final, except manifest error. Access Fee parameters change only prospectively and apply to future Settlements.
**9.6 No Payment Administration; No Money Transmission.** Intents Technology does not collect, hold, transmit, convert, or distribute any fiat or digital asset for fees. Metering and deductions are for the Solver’s own obligation only.
**9.7 Non-Refundable.** Fees and Capture Share already charged, deducted, allocated, or accrued are non-refundable except manifest error, including where based on settled volume or access period. As principal, the Solver bears settlement-failure and partial-fill risk.
**9.8 Tax.** The Solver handles all taxes and duties on its activity and fee payments. Amounts due to Intents Technology are exclusive of VAT, GST, sales, use, and consumption taxes. If required, the Solver gross-ups and remits withholding and provides documentation.
**9.9 Fee Avoidance.** The Solver must not manipulate, interfere with, or misstate any fee calculation or its captured spread to reduce payable fees. Any such attempt is a material breach and may lead to suspension or termination.
**9.10 Additional Costs Borne by the Solver.** In addition to the protocol fee, Capture Share, and any Solver Access Fee, the Solver bears all related gas, network, bridge, Protocol, smart-contract, third-party, confidential-intents, yield-protocol, and withdrawal or redemption fees. The Solver has no rights against Intents Technology or any other person in respect of these additional costs, and they do not reduce, offset, or create any claim against the protocol fee, Capture Share, or any Solver Access Fee.
**9.11 Fee and Performance Transparency.** Intents Technology may, at its discretion, provide reporting on Solver activity, including fills, captured spread, protocol-fee and Capture-Share deductions, and Performance Standards, and guarantees neither its scope, accuracy, nor continuity, and provides no revenue reporting. The Solver may submit good-faith queries on any deduction or figure through the designated channel, and Intents Technology will respond within a reasonable time without suspending, deferring, or changing the Solver’s obligations; the finality in Section 9.5 remains.
**10. SPECIAL ASSET TYPES AND DISCLAIMERS**
**10.1 Confidential Intents.** Some Intents route through the Confidential Intents Protocol on the NEAR Private Shard, which Intents Technology does not operate or control. Confidential Intents are at your sole risk and remain subject to Sections 4.3, 5, and 11.
**10.2 Real-World Assets (RWAs).** Some Transactions may involve tokenised real-world assets with legal treatment that differs by asset and jurisdiction. Intents Technology makes no representation on their legal characterisation, enforceability, backing, or regulatory status. The Solver is solely responsible for the legal and licensing requirements.
**10.3 Fiat Onramps and Offramps.** Fiat legs are provided by third parties under their own terms. Intents Technology does not provide, operate, or control any fiat onramp or offramp and does not touch, hold, or transmit fiat. The Solver owns any fiat-leg obligations for any Transactions it fills.
**10.4 Yield-Bearing Assets and Yield Access.** The Solver may quote, fill, or settle yield-bearing arrangements at its own risk and under the third-party terms. Intents Technology does not operate or guarantee these assets or yield, and makes no rate or continuation representation.
**10.5 Solver’s Obligations Regarding Special Assets.** The Solver must not misrepresent any asset it quotes, fills, or settles. It is solely responsible for legal and eligibility analysis of each asset. Any asset-classification change is the Solver’s risk.
**11. ELIGIBILITY AND PROHIBITED JURISDICTIONS**
**11.1 Prohibited Jurisdictions.** The Solver Services are not available to, and may not be accessed or used by, any person located, resident, established, or organised in, or owned or controlled by any person in, any Prohibited Jurisdiction. The Solver represents and warrants that neither it nor any of its principals or beneficial owners is located, resident, established, or organised in, or subject to the jurisdiction of, any Prohibited Jurisdiction.
**11.2 Sanctions Compliance.** The Solver represents, warrants, and covenants that neither it, nor any of its principals, directors, officers, or beneficial owners, is identified on any sanctions or restricted-party list maintained by the United States (including the U.S. Office of Foreign Assets Control), the European Union, the United Kingdom, or the United Nations, or is owned or controlled by any such person. The Solver shall not use any virtual private network, proxy, mixer, tumbler, or other means to conceal its location or identity or to circumvent any restriction in this Section 11, and shall not knowingly quote, fill, or settle any Intent that it knows, or where screening data available to it indicates, originates from a Prohibited Jurisdiction or from a sanctioned or restricted person.
**11.3 Organisation, Capacity and Authority.** The Solver, if an entity, represents and warrants that it is duly organised, validly existing, and in good standing under the laws of its jurisdiction of organisation and has full power and authority to enter into and perform these Terms. Where the Solver is an individual, it represents and warrants that it is at least eighteen (18) years of age and has full legal capacity to enter into these Terms.
**11.4 Solver Responsibility.** The Solver is solely responsible for ensuring that it, its principals, and its beneficial owners meet the eligibility requirements of this Section 11 on the Effective Date and on a continuing basis, and shall cease accessing and using the Solver Services immediately on ceasing to meet any such requirement.
**12. REGULATORY STATUS AND COMPLIANCE**
**12.1 Regulatory Status of Intents Technology.** Intents Technology is not licensed, registered, authorised, or regulated as a financial intermediary for these Services. The Solver Services are non-discretionary message-relay infrastructure only. Intents Technology is not a broker, dealer, exchange, trading venue, market-maker, clearing house, custody provider, money-transmission business, payment-service provider, investment adviser, or fiduciary, does not match as principal, underwrite, guarantee, clear, or otherwise take the other side of any Transaction, and does not exercise case-by-case discretion over selection, pricing, execution, acceptance, rejection, or settlement.
**12.2 Solver Compliance and Self-Determination.** The Solver is principal and solely responsible for all licences and registrations needed to quote, fill, and settle in each applicable jurisdiction, including any dealer, broker, MSB, or VASP/CASP status. Intents Technology is not a substitute for your compliance obligations. Describe Intents Technology as non-discretionary technical infrastructure only in filings, and notify it promptly if any inquiry names or implicates it.
**12.3 Front-End Interface Terms.** Any Third-Party Interface, integration, or external dependency through which Intents are posted or originated is provided by the relevant operator under its own terms, and Intents Technology assumes no responsibility or liability for it or for any act or omission of its operator.
**12.4 No Representations as to Characterisation.** Intents Technology makes no representation as to how any court, regulator, tax authority, or other body may characterise the Solver Bus, auction, Solver Services, or Solver activity. The Solver bears all risk and consequences of any adverse characterisation and waives claims against Intents Technology and the Indemnified Parties except where prohibited by law. This does not limit required regulator or law-enforcement cooperation.
**13. REPRESENTATIONS AND WARRANTIES**
**13.1 Mutual.** Each Party represents and warrants that: (a) it has full right, power, and authority to enter into and perform these Terms; (b) execution and performance of these Terms do not and will not violate any other agreement to which it is a party or by which it is bound; and (c) these Terms constitute a legal, valid, and binding obligation enforceable against it in accordance with their terms.
**13.2 Solver Specific.** The Solver further represents, warrants, and covenants, on the Effective Date and on a continuing basis each time it submits a Quote, fills, or settles a Transaction, that:
1. it holds and maintains all required licences, registrations, and consents for its activity in each jurisdiction where it operates or serves residents;
2. it understands and assumes the technical, financial, market, inventory, hedging, settlement, gas, and counterparty risk of acting as a principal on the Protocol;
3. it is solvent, not in bankruptcy or equivalent restructuring, and can pay its debts as they fall due;
4. it, its directors, officers, beneficial owners, and controllers are not sanctioned or in a Prohibited Jurisdiction and maintain AML/CFT controls appropriate to its activity;
5. there is no material enforcement action, investigation, litigation, or order materially affecting its ability to perform under these Terms;
6. it provides its own Liquidity and controls its private keys and Solver Wallets;
7. it acts as a principal for its own account and not as an agent, partner, employee, or counterparty of Intents Technology;
8. it has sufficient capital and inventory to honour and settle Transactions it commits to fill, and will provide evidence of adequacy on reasonable request under Section 4.6; and
9. its quoting logic, pricing models, and Solver System are its own.
**14. NO SERVICE LEVELS; EXPERIMENTAL INFRASTRUCTURE**
**14.1 No Uptime Commitment.** Solver Services are provided “as is” and “as available.” Intents Technology does not warrant uptime, throughput, latency, or error-free operation, and provides no SLA. It may modify, suspend, throttle, deprecate, or discontinue any part at any time.
**14.2 Experimental and Evolving Infrastructure.** The Solver acknowledges ongoing development and change in the Services, Solver Bus, auction mechanism, Protocol, and supporting networks. Intents Technology may modify architecture, endpoints, parameters, formats, routing logic, and settlement messaging at any time, and the Solver bears the risk.
**14.3 No Duty to Monitor; Reservation of Right to Police Conduct.** Intents Technology has no duty to monitor or validate your system, Quote, fill, or Settlement. It may monitor and enforce, including under Section 2.7, Section 5; exercising or withholding those rights creates no duty or liability.
**14.4 Settlement Finality and Recovery.** Finality, irreversibility, recovery, partial execution, and lock-up are covered in Section 6.8. All such risk is on the Solver as principal.
**14.5 No Performance Guarantees.** Intents Technology does not guarantee execution speed, settlement success, auction outcomes, pricing, slippage, or Third-Party Component/PoA Bridge performance. Any figures or benchmarks are indicative only and create no warranty.
**15. CONFIDENTIALITY**
**15.1 Confidentiality Obligations.** Each Party that receives Confidential Information (the “**Recipient**”) of the other Party (the “**Discloser**”) must protect that Confidential Information with at least reasonable care, use it only to perform these Terms, and disclose it only to personnel with a need to know and equivalent confidentiality obligations.
**15.2 Exclusions.** These duties do not apply if the information is public without breach, was already known or rightfully received from a third party without restriction, or was independently developed.
**15.3 Compelled Disclosure.** If legal process requires disclosure, the Recipient may disclose required information and must notify the Discloser promptly, cooperate for protective relief, and disclose only what is legally required.
**15.4 Order-Flow and Quoting Confidentiality; Survival.** Solver logic, pricing models, inventory positions, and Solver Bus intent flow, order flow, and routing data are Confidential Information. You may use it only to quote, fill, and settle and only as permitted in Section 5.3. Any front-running, value extraction, or model training from this data is a material breach. These duties survive three (3) years; trade secrets survive while qualifying as such.
**16. DISCLAIMER OF WARRANTIES AND ASSUMPTION OF RISK**
**16.1 Third-Party Components.** Solver Services depend on blockchain networks, smart contracts, software, oracles, validators, bridges, relayers, liquidity sources, and other Third-Party Components not operated by Intents Technology. The Solver Services, Solver Bus, Solver API, Documentation, and all Third-Party Components are provided “as is” and “as available” with all faults, and all implied warranties are expressly excluded, including merchantability, fitness, title, non-infringement, and accuracy. PoA Bridge terms are separate and no warranty is provided.The disclaimers and assumptions of risk in this Section 16 apply equally to the PoA Bridge, and no warranty is provided in respect of it (see Section 7.8).
**16.2 No Reliance on Price Data.** Price, quote, rate, timing, availability, and other data is technical and informational, may be incomplete, delayed, inaccurate, or non-executable, and is not financial advice or a guarantee. The Solver is sole principal and sole decision-maker on pricing, valuation, hedging, and execution.
**16.3 Release.** To the maximum extent permitted by applicable law, the Solver releases, waives, and forever discharges Intents Technology and its Affiliates, and their respective directors, officers, employees, agents, and representatives, from any and all claims, demands, damages, losses, liabilities, and causes of action of every kind, known or unknown, arising out of or relating to the Solver’s access to or use of the Solver Services, the Protocol, the Solver Bus, the PoA Bridge, or any Transaction. The Solver expressly waives any benefit of any statute, rule, or common-law principle that would otherwise preserve claims unknown to it at the time of this release, and grants this release with full awareness that it may later discover facts in addition to or different from those it now knows or believes.
**17. LIMITATION OF LIABILITY**
**17.1 Exclusion of Indirect and Trading Losses.** To the maximum extent allowed by law, Intents Technology and its Affiliates are not liable for indirect, special, incidental, exemplary, punitive, or consequential damages, including trading losses, execution dispersion, slippage, failed/reverted/delayed transactions, inventory or hedging losses, lost profits or revenue, data loss/corruption, and goodwill loss, regardless of theory or notice, and even if such remedies fail their essential purpose.
**17.2 Aggregate Liability Cap.** Neither Party excludes liability for fraud, fraudulent misrepresentation, death, personal injury from negligence, or liabilities that law forbids limiting. Otherwise, Intents Technology’s total liability is capped at the greater of USD \$1,000 and the total Solver Access Fees plus other infrastructure-access fees paid in the prior twelve (12) months. This is an aggregate cap across all claims, incidents, and theories.
**18. INDEMNITY**
**18.1 Solver Indemnity.** The Solver indemnifies Intents Technology and its Affiliates, directors, officers, employees, agents, and representatives (the “**Indemnified Parties**”) against any and all claims, demands, actions, losses, liabilities, damages, fines, penalties, costs, and expenses (including reasonable legal fees), and any inquiry, investigation, request, or subpoena from regulators or law-enforcement, arising out of these Terms or related use, including:
1. the Solver’s access to or use of the Solver Services, the Solver Bus, the Solver API, the PoA Bridge, or the Protocol;
2. the Solver’s breach or alleged breach of these Terms, including any representation, warranty, or covenant;
3. the Solver’s violation or alleged violation of any applicable law, regulation, or third-party right, including any anti-money-laundering, counter-terrorist-financing, sanctions, or export-control law;
4. any infringement or misappropriation of the Intellectual Property or other rights of any third party by the Solver, the Solver System, or the Solver’s quoting logic;
5. any claim brought by the Solver’s trading counterparties, intent originators, End-Users, or any other party arising out of or relating to the Solver’s Quotes, fills, Settlements, Settlement failures, Fades, or market conduct;
6. the Solver’s failure to obtain or maintain any required KYC, KYB, transaction-screening (KYT), sanctions-screening, or market-conduct compliance;
7. any claim arising out of the Solver’s market manipulation or other prohibited trading conduct, its Settlement default, or the characterisation by any authority of the Solver’s market-making or other activity under any regulatory, licensing, tax, or other legal regime; and
8. any tax, withholding, interest, or penalty for which the Solver is responsible under these Terms.
**18.2 Control of Defense.** Intents Technology will notify the Solver of indemnified claims as promptly as possible. Delay does not relieve the Solver unless prejudiced. Intents Technology may defend and settle at the Solver’s expense with counsel of its choice, and may take sole control if allegations could create criminal, regulatory, or reputational exposure. The Solver cannot settle without Intents Technology’s prior written consent if it affects any Indemnified Party.
**19. TERM AND TERMINATION**
**19.1 Term.** These Terms commence on the Effective Date and continue until terminated in accordance with this Section.
**19.2 Termination by the Solver.** The Solver may terminate at any time by ceasing all quoting, filling, and Settlement activity, disconnecting from the Solver Bus, stopping all Solver Service use, and giving written notice.
**19.3 Termination by Intents Technology.** Intents Technology may suspend, restrict, or terminate the Solver’s access and these Terms, in whole or in part, at any time, for any reason or no reason, with or without notice, and without liability.
**19.4 Immediate Remedies.** Without limiting Section 19.3, Intents Technology may suspend or terminate without notice where it determines there is or likely will be prohibited conduct under Section 5, a Fade/default, failure to meet the Performance Standards in Section 6.10, sanctions or prohibited-jurisdiction risk, KYC/KYB lapse, false onboarding data, insolvency, inability to perform, or any materially risk-increasing conduct.
**19.5 Effect of Termination; In-Flight Settlements.** On termination, all licences end and the Solver must stop access immediately, including deleting or destroying credentials. No additional payment is owed by Intents Technology. New routing may be frozen while completing in-flight Settlements already selected. Existing Access Fees are non-refundable; Intents Technology may set off against amounts due. Settlement-default and in-flight consequences remain under Section 6.5 and this Section 19.
**19.6 Survival.** Survival includes all accrued rights and liabilities and Sections 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 20, 21, 22, or any term that by its nature is intended to survive.
**20. GOVERNING LAW AND DISPUTES**
**20.1 Governing Law.** These Terms and any related dispute are governed by the laws of the British Virgin Islands.
**20.2 Informal Resolution.** Before arbitration, the Parties must attempt good-faith informal resolution for at least thirty (30) days after exchanging a notice of the dispute and relief sought. If unresolved, either Party may arbitrate. This does not bar an emergency or equitable application under Section 20.7.
**20.3 Arbitration.** Except for Section 20.7, disputes are finally resolved by BVIIAC arbitration in the British Virgin Islands before one arbitrator in English. Awards are final and binding and enforceable in any competent court. Venue and forum objections are waived as permitted.
**20.4 Emergency Arbitrator.** Either Party may seek emergency interim or conservatory relief before the tribunal is constituted under BVIIAC emergency provisions. That request does not waive arbitration.
**20.5 Class Action Waiver.** Disputes proceed only individually to the maximum lawful extent. Neither Party may pursue class, collective, consolidated, or representative proceedings. If unenforceable as to any claim, only that claim is severed.
**20.6 Limitation Period.** Claims must be filed within twelve (12) months after accrual unless law provides longer. This does not reduce claims under Section 3, Section 15, Section 18, or breaches of Sections 5, 11, or 12 where law allows a longer period.
**20.7 Injunctive Relief.** The Solver may seek injunctive or equitable relief only in BVI courts and submits exclusively to their jurisdiction for that purpose. Intents Technology may also seek such relief in BVI or other competent courts where the Solver is present, and may enforce any arbitral award or judgment there.
**21. NO THIRD-PARTY BENEFICIARIES**
These Terms benefit only the Parties and their permitted successors and assigns. Except for the Indemnified Parties and Affiliates of Intents Technology, no other person has enforcement or reliance rights under these Terms. End-Users, originators, counterparties, downstream platforms, solvers, or liquidity providers cannot assert claims against Intents Technology here. The Solver’s relationships with them are its own.
**22. GENERAL**
**22.1 Force Majeure.** Neither Party is liable for delays or failures from a **Force Majeure Event** beyond reasonable control, including Act of God, disasters, epidemics, war, terrorism, unrest, strikes, government action, law changes, or Protocol Events. This does not excuse the Solver’s duty under Sections 6.3 and 6.4, whose sole excuse is bona fide chain-level failure. Each Party may use reasonable mitigation; neither has a duty to redesign, reroute, subsidise, backstop, recover, retry, or continue operations. Either party may terminate with notice if Force Majeure lasts beyond thirty (30) days.
**22.2 Commercial Agreements.** If a Commercial Agreement governs, it prevails for its scope. If not, these Terms apply in full.
**22.3 Data.** Each Party complies with data-protection law and role allocations based on actual processing. Intents Technology may process Data for operations, security, monitoring, enforcement, and legal compliance as in the Privacy Policy. On request, confidential and personal data may be deleted or returned unless retention is required by law or for legal, tax, audit, security, dispute, or backup purposes. Intents Technology may retain required data, including indefinitely where lawful.
**22.4 Notices.** Intents Technology may notify Solver via the Solver Portal, registered account email, or public channels; notice is effective when sent or posted. The Solver must notify Intents Technology via the designated legal channel in the Portal or Documentation, or \[NOTICE CONTACT] if none. Law-enforcement or regulatory requests should use the designated portal or another channel specified by Intents Technology.
**22.5 Assignment.** The Solver may not assign, transfer, or delegate without Intents Technology’s prior written consent; any prohibited transfer is void. Intents Technology may assign or delegate freely, including to successors or Affiliates. Confidentiality and indemnity obligations continue for successors and assignees.
**22.6 Severability.** If any provision is invalid or unenforceable, it is modified to the minimum required or severed; the remainder stays in force.
**22.7 No Waiver.** Delay or partial use of a right does not waive any right. Waivers are valid only in writing for the specific purpose.
**22.8 No Fiduciary Duties.** Nothing here creates any fiduciary, trustee, agency, partnership, or advisory relationship. Intents Technology owes no fiduciary duty or extra-contractual duties beyond these Terms, including no duty of care, loyalty, or best execution.
**22.9 No Insurance or Compensation Scheme.** Solver Services are not covered by deposit-insurance or investor-compensation schemes. Intents Technology provides no insurance, guarantee, underwriting, backstop, indemnity, or compensation; the Solver bears all loss risk as principal.
**22.10 No Advice.** Documentation, reporting, metrics, and communications are not legal, tax, accounting, financial, investment, or regulatory advice. The Solver must obtain its own advice for its activities.
**22.11 Entire Agreement.** These Terms and incorporated documents are the entire agreement on the subject matter and supersede prior understandings and representations. A Commercial Agreement prevails only as provided in Section 22.2, and the Solver has not relied on any extra-term statements.
**22.12 Security Incidents.** For any actual or suspected incident, vulnerability, exploit, or compromise, Intents Technology may suspend access, halt routing, or impose controls to protect the ecosystem. Actions may be taken with or without notice, and Intents Technology has no liability for resulting losses.
**22.13 Changes to these Terms.** Intents Technology may change these Terms at any time on notice. It may give notice by posting the updated Terms in the Solver Portal, sending an email to the Solver's registered account email, by an in-service or API notification, or by any other reasonable means. The Solver may review the current version of these Terms at any time in the Solver Portal or the Documentation. The version in effect at the time of the Solver's access to or use of the Solver Services applies, and the updated Terms bind the Solver in respect of access or use on or after the date indicated in the updated Terms. If the Solver does not agree to the updated Terms, it must stop accessing and using the Solver Services, disconnect from the Solver Bus, and cease all quoting, filling, and Settlement. The Solver's continued access to or use of the Solver Services after that date constitutes acceptance of the updated Terms.
# Account Abstraction
Source: https://docs.near-intents.org/integration/verifier-contract/account-abstraction
How the Verifier contract identifies users and manages account keys
Users do not need to create a NEAR account to use NEAR Intents. The Verifier contract supports wallets across [all supported chains](/resources/chain-support). When a user signs with their existing wallet, the Verifier derives an account from their public key. The user retains sole control via their existing private keys.
Under the hood, the Verifier identifies users via a NEAR `AccountId`, which can be either a Named account (like `alice.near`) or an Implicit account derived from a public key. The Verifier maintains its own mapping of account IDs to public keys, allowing it to verify signed intents from any supported wallet.
### NEAR's multi-key model
On NEAR, each account can hold [multiple access keys](https://docs.near.org/protocol/access-keys). There are two types:
* **Full Access Keys** — grant complete account control (transfer tokens, manage keys, deploy contracts)
* **Function Call Keys** — restricted to calling specific contracts, safe to share with applications
Keys can be added or removed at any time, giving accounts flexible, multi-key security. The Verifier contract builds on this model — when you register a public key with the Verifier, it associates that key with your account ID so it can verify your signed intents.
## Account types
### Named accounts
Named accounts are human-readable identifiers like `alice.near`.
To start using a named account with the Verifier, you must register a public key by calling `add_public_key` on `intents.near` from that named NEAR account. This tells the Verifier which keys are authorized to sign intents on behalf of your account.
Others can still deposit or transfer funds to your named account before you register a key - you just won't be able to sign intents until you do.
### Implicit accounts
Users from other chains don't need to create a NEAR account. When they sign with their existing wallet, the Verifier automatically derives an implicit account ID from their public key. No registration, no new wallet — they can start using NEAR Intents immediately.
There is a 1-to-1 relationship between the public key's signing curve and the resulting account format:
| Curve | Account Format | Example |
| ----- | ------------------------------------- | ------------------------------------------------------------------ |
| EdDSA | 64-character hex (Implicit NEAR) | `8c5cba35f5b4db9579c39175ad34a9275758eb29d4866f395ed1a5b5afcb9ffc` |
| ECDSA | Ethereum-style address (Implicit Eth) | `0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3` |
For example, users logging in with a Cosmos (ECDSA) wallet will have an *Implicit Eth address* in `intents.near`, whereas Solana or TON (EdDSA) wallets will yield *Implicit NEAR addresses*.
It's not feasible to differentiate these addresses by chain, since only the signature and public key are known. Even when differentiating based on the signing standard (NEP-413, EIP-712), ambiguity remains when importing the same seed phrase into multiple wallets.
## Account keys
Once an account is created, you can add multiple public keys to authorize actions on that account. Each key has full control and can add or remove other keys—either directly via NEAR transactions or via signed intents.
Public keys and signatures must use specific encoding formats depending on the curve type. See [Signing Intents](/integration/verifier-contract/signing-intents) for the full encoding requirements table.
### Adding a public key via transaction
Here is an [example transaction](https://nearblocks.io/txns/FBTRk6jRUSW3E1SjBfYbA71DhN5xTX1yE2foy98TafrM#execution) for adding a public key to a Named Account.
```bash theme={null}
near contract call-function as-transaction \
intents.near add_public_key json-args '{
"public_key": "ed25519:"
}' prepaid-gas '100.0 Tgas' attached-deposit '1 yoctoNEAR' \
sign-as network-config mainnet sign-with-keychain send
```
```typescript theme={null}
import { Account, JsonRpcProvider, teraToGas, KeyPairString } from "near-api-js";
const accountId = "your-account.near";
const privateKey = "ed25519:3D4YudU..." as KeyPairString;
const provider = new JsonRpcProvider({ url: "https://rpc.fastnear.com" });
const account = new Account(accountId, provider, privateKey);
await account.callFunction({
contractId: "intents.near",
methodName: "add_public_key",
args: {
public_key: "ed25519:",
},
gas: teraToGas("100"),
deposit: 1n, // 1 yoctoNEAR
});
```
See contract interaction example in [near-api-examples](https://github.com/near-examples/near-api-examples/blob/main/near-api-js/examples/contract-interaction.ts) repository.
### Adding a public key via signed intent
You can also submit a signed intent to add a public key:
```json theme={null}
{
"signer_id": "",
"intents": [
{
"intent": "add_public_key",
"public_key": ""
}
]
}
```
## Authentication flow for frontends
Wallets store private keys and allow key rotation. For the Verifier to verify signatures, it needs to know which keys are associated with which "named" accounts. Therefore, `intents.near` maintains a mapping of `account_ids` to their `public_keys` (each account can have multiple public keys registered).
### Step-by-step flow
Prompt your user to connect their wallet, establishing a session and providing their account ID or address.
For Named accounts only: check whether the public key is registered with the Verifier contract. If not, register it by calling `add_public_key` on `intents.near`. Implicit accounts skip this step — their account ID is derived directly from their public key.
The wallet signs the intent payload. The signed intent is published to the Solver Relay, which coordinates with market makers to settle on-chain via `execute_intents`.
### Key rotation
When a user removes a Full Access Key from their NEAR account, it should also be unregistered on `intents.near` by calling `remove_public_key(public_key)` from that NEAR account.
You can automate this by adding a `FunctionalKey` to the account on NEAR and calling it whenever you detect that a key has been deleted on-chain.
## Real transaction examples
View these key management transactions on NEAR mainnet:
| Operation | Transaction |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| Add public key | [FBTRk6jR...](https://nearblocks.io/txns/FBTRk6jRUSW3E1SjBfYbA71DhN5xTX1yE2foy98TafrM#execution) |
| Remove public key | [69XiJcRt...](https://nearblocks.io/txns/69XiJcRtipZ2i8bkHHgCaSAkswd8Lt6VxiJuM8dKq9qn#execution) |
# Balances and Token IDs
Source: https://docs.near-intents.org/integration/verifier-contract/deposits-and-withdrawals/balances
How to check your balance and identify tokens in the Verifier contract
## Multi Token Standard (NEP-245)
After a successful deposit, the Verifier contract manages tokens using the [Multi Token Standard (NEP-245)](https://nomicon.io/Standards/Tokens/MultiToken/Core). This enables uniform handling of all supported token types.
## Token ID format
Each token is identified by a string-based token ID, prefixed with its standard type.
| Token Type | Prefix | Example |
| ---------------------- | --------- | -------------------------------- |
| Fungible (NEP-141) | `nep141:` | `nep141:wrap.near` |
| Non-fungible (NEP-171) | `nep171:` | `nep171:coolnfts.near:rock.near` |
| Multi Token (NEP-245) | `nep245:` | `nep245:mygame.near:shield.near` |
## Checking your balance
After a successful deposit, query your balance using [mt\_balance\_of](https://near.github.io/intents/defuse_nep245/trait.MultiTokenCore.html#tymethod.mt_balance_of), which adheres to the NEP-245 standard.
```bash theme={null}
near contract call-function as-read-only intents.near mt_balance_of \
json-args '{"account_id": "your-account.near", "token_id": "nep141:wrap.near"}' \
network-config mainnet now
```
```typescript theme={null}
import { JsonRpcProvider } from "near-api-js";
const provider = new JsonRpcProvider({ url: "https://rpc.fastnear.com" });
const balance = await provider.callFunction({
contractId: "intents.near",
method: "mt_balance_of",
args: {
account_id: "your-account.near",
token_id: "nep141:wrap.near",
},
});
console.log(balance);
```
See contract interaction example in [near-api-examples](https://github.com/near-examples/near-api-examples/blob/main/near-api-js/examples/contract-interaction.ts) repository.
| Parameter | Description |
| ------------ | ---------------------------------------------------------------------------------------------------------- |
| `account_id` | The NEAR account to check the balance of. |
| `token_id` | The token ID with its standard prefix (e.g., `nep141:wrap.near`). See [Token ID format](#token-id-format). |
### Batch balance query
To check multiple token balances at once, use [mt\_batch\_balance\_of](https://near.github.io/intents/defuse_nep245/trait.MultiTokenCore.html#tymethod.mt_batch_balance_of):
```bash theme={null}
near contract call-function as-read-only intents.near mt_batch_balance_of \
json-args '{"account_id": "your-account.near", "token_ids": ["nep141:wrap.near", "nep141:usdt.tether-token.near"]}' \
network-config mainnet now
```
```typescript theme={null}
const balances = await provider.callFunction({
contractId: "intents.near",
method: "mt_batch_balance_of",
args: {
account_id: "your-account.near",
token_ids: [
"nep141:wrap.near",
"nep141:usdt.tether-token.near",
],
},
});
console.log(balances);
```
Response:
```json theme={null}
[
"3000004000004000006",
"10"
]
```
Balances are returned in the smallest unit of each token (e.g., yoctoNEAR for wrapped NEAR).
# Deposits
Source: https://docs.near-intents.org/integration/verifier-contract/deposits-and-withdrawals/deposits
Depositing fungible and non-fungible tokens into the Verifier contract
Before you can swap or transfer tokens on the Verifier contract, you need to deposit them. Depositing moves tokens from your NEAR account into the contract's internal ledger, where they can be used for [intents](/integration/verifier-contract/intent-types-and-execution).
The contract accepts:
* [NEP-141](https://nomicon.io/Standards/Tokens/FungibleToken/Core) fungible tokens
* [NEP-171](https://nomicon.io/Standards/Tokens/NonFungibleToken/Core) non-fungible tokens
* [NEP-245](https://nomicon.io/Standards/Tokens/MultiToken/Core) multi tokens
Do not send native NEAR directly to the Verifier contract.
You must wrap your NEAR into wNEAR first as the contract does not accept native NEAR. See ["Using NEAR Tokens"](/integration/verifier-contract/deposits-and-withdrawals/near-token) for more details.
## Depositing fungible tokens (NEP-141)
The Verifier contract implements the [FungibleTokenReceiver](https://docs.near.org/primitives/ft) interface, part of the [NEP-141 standard](https://nomicon.io/Standards/Tokens/FungibleToken/Core).
To deposit tokens, call `ft_transfer_call` ([function signature](https://github.com/near/near-sdk-rs/blob/611e01ebf6c226f4e1e820a2f50f4a9acf8f1215/examples/fungible-token/ft/src/lib.rs#L103)) on the token contract, with an `msg` parameter specifying who will own the tokens.
Any NEP-141 token can be deposited. For a list of NEP-141 token contract addresses deposited into the Verifier contract, run:
```bash theme={null}
curl -s https://1click.chaindefuser.com/v0/tokens | jq -r '.[] | select(.blockchain == "near") | [.symbol, (.price | tostring), .contractAddress] | @tsv' | column -t -s $'\t'
```
### How to deposit tokens
Replace `` with the token's contract address and adjust the `amount` for the token's decimal precision.
```bash theme={null}
near call ft_transfer_call \
'{"receiver_id": "intents.near", "amount": "", "msg": ""}' \
--deposit 0.000000000000000000000001 \
--gas 100000000000000 \
--useAccount your-account.near \
--networkId mainnet
```
```typescript theme={null}
import { Account, JsonRpcProvider, teraToGas, KeyPairString } from "near-api-js";
const accountId = "your-account.near";
const privateKey = "ed25519:3D4YudU..." as KeyPairString;
const provider = new JsonRpcProvider({ url: "https://rpc.fastnear.com" });
const account = new Account(accountId, provider, privateKey);
await account.callFunction({
contractId: "",
methodName: "ft_transfer_call",
args: {
receiver_id: "intents.near",
amount: "",
msg: "",
},
gas: teraToGas("100"),
deposit: 1n, // 1 yoctoNEAR
});
```
See contract interaction example in [near-api-examples](https://github.com/near-examples/near-api-examples/blob/main/near-api-js/examples/contract-interaction.ts) repository.
| Parameter | Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `` | The NEP-141 token contract you're depositing from (e.g., `wrap.near` for wNEAR, `eth.bridge.near` for ETH). Any NEP-141 token can be deposited. |
| `receiver_id` | Always `intents.near` (the Verifier contract). |
| `amount` | The amount in the token's smallest unit. Each token has different decimals (e.g., wNEAR has 24, USDC has 6). |
| `msg` | Controls token ownership after deposit. See [The `msg` parameter](#the-msg-parameter) below. |
| `--deposit` | 1 yoctoNEAR, required by the NEP-141 standard for `ft_transfer_call`. |
| `--gas` | Depends on the `msg` content. Should be calculated to cover the cross-contract call to the Verifier contract plus any promises triggered by the deposit (e.g., `execute_intents`). 100 TGas is sufficient for a simple deposit. |
### The `msg` parameter
The `msg` parameter supports three formats:
Leave `msg` empty or omit it to assign ownership to the transaction sender.
```json theme={null}
{
"receiver_id": "intents.near",
"amount": "1000",
"msg": ""
}
```
Specify an account ID to assign ownership to a different account.
```json theme={null}
{
"receiver_id": "intents.near",
"amount": "1000",
"msg": "bob.near"
}
```
Use a JSON object for advanced options:
| Field | Description |
| ----------------- | ---------------------------------------------------------------------------------------------------- |
| `receiver_id` | Account ID taking ownership |
| `execute_intents` | List of intents to execute after deposit |
| `refund_if_fails` | When `false` (default), executes intents as a detached promise, decoupling failures from the deposit |
```json theme={null}
{
"receiver_id": "intents.near",
"amount": "1000",
"msg": "{\"receiver_id\": \"charlie.near\", \"execute_intents\": [...], \"refund_if_fails\": false}"
}
```
The `msg` field is always a string, even when it contains a JSON-encoded object. Proper character escaping is required.
## Real transaction examples
View these deposit transactions on NEAR mainnet:
| Operation | Transaction |
| ------------------------- | ----------------------------------------------------------------------------------------------- |
| Deposit tokens | [DWv4AkrL...](https://nearblocks.io/txns/DWv4AkrLxnbJV6paqSFR3Tt42SdVAtunBbEi2XATdXTW#enhanced) |
| Deposit + execute intents | [Bn3iC9B1...](https://nearblocks.io/txns/Bn3iC9B1uUJrX59x7cfxngY1E159HspzTCyyDVwx5DMJ) |
| Deposit + swap + withdraw | [BMFcWFRe...](https://nearblocks.io/txns/BMFcWFReAzbH8okweUio2nNTuVXtMr1hXeaaNR4UhEzS) |
## Depositing non-fungible tokens (NEP-171)
The Verifier contract implements the [NonFungibleTokenReceiver](https://docs.near.org/primitives/nft) interface ([NEP-171](https://nomicon.io/Standards/Tokens/NonFungibleToken/Core) standard).
To transfer NFTs to the Verifier, use `nft_transfer_call` with the same `msg` format rules as fungible tokens.
## Depositing multi tokens (NEP-245)
The Verifier contract implements the [MultiTokenReceiver](https://nomicon.io/Standards/Tokens/MultiToken/Core) interface ([NEP-245](https://nomicon.io/Standards/Tokens/MultiToken/Core) standard).
To deposit multi tokens, use `mt_batch_transfer_call` with the same `msg` format rules as fungible tokens.
# Using NEAR Tokens
Source: https://docs.near-intents.org/integration/verifier-contract/deposits-and-withdrawals/near-token
How to use NEAR tokens with NEAR Intents
The Verifier contract only accepts [NEP-141](https://nomicon.io/Standards/Tokens/FungibleToken/Core) tokens, so native NEAR must be wrapped before depositing. The [`wrap.near`](https://nearblocks.io/address/wrap.near) contract converts NEAR to wNEAR at a 1:1 ratio.
See [wNEAR docs](https://github.com/near/core-contracts/tree/master/w-near) for a detailed reference guide.
If you're using the [1Click Swap
API](/integration/distribution-channels/1click-api/about-1click-api) or
another managed integration, wrapping is handled for you - skip this guide.
## Wrap and deposit
If you're integrating directly with the Verifier contract, you must wrap your NEAR first before depositing:
Call `near_deposit` on the `wrap.near` contract, attaching the amount of NEAR you want to wrap. This example wraps 0.01 NEAR:
```bash theme={null}
near call wrap.near near_deposit '{}' \
--deposit 0.01 \
--gas 30000000000000 \
--useAccount your-account.near \
--networkId mainnet
```
```typescript theme={null}
import { Account, JsonRpcProvider, teraToGas, nearToYocto, KeyPairString } from "near-api-js";
const accountId = "your-account.near";
const privateKey = "ed25519:3D4YudU..." as KeyPairString;
const provider = new JsonRpcProvider({ url: "https://rpc.fastnear.com" });
const account = new Account(accountId, provider, privateKey);
await account.callFunction({
contractId: "wrap.near",
methodName: "near_deposit",
args: {},
gas: teraToGas("30"),
deposit: nearToYocto("0.01"),
});
```
See contract interaction example in [near-api-examples](https://github.com/near-examples/near-api-examples/blob/main/near-api-js/examples/contract-interaction.ts) repository.
Call `ft_transfer_call` on `wrap.near` to deposit your wNEAR. wNEAR has 24 decimals, so 0.01 wNEAR = `10000000000000000000000`.
```bash theme={null}
near call wrap.near ft_transfer_call \
'{"receiver_id": "intents.near", "amount": "10000000000000000000000", "msg": ""}' \
--deposit 0.000000000000000000000001 \
--gas 100000000000000 \
--useAccount your-account.near \
--networkId mainnet
```
```typescript theme={null}
await account.callFunction({
contractId: "wrap.near",
methodName: "ft_transfer_call",
args: {
receiver_id: "intents.near",
amount: "10000000000000000000000",
msg: "",
},
gas: teraToGas("100"),
deposit: 1n, // 1 yoctoNEAR
});
```
See contract interaction example in [near-api-examples](https://github.com/near-examples/near-api-examples/blob/main/near-api-js/examples/contract-interaction.ts) repository.
In the Verifier contract, wrapped NEAR is identified as `nep141:wrap.near`.
See [Deposits](/integration/verifier-contract/deposits-and-withdrawals/deposits) for details on the `msg` parameter and other deposit options.
# Withdrawals
Source: https://docs.near-intents.org/integration/verifier-contract/deposits-and-withdrawals/withdrawals
How to withdraw tokens from the Verifier contract
After a successful [deposit](/integration/verifier-contract/deposits-and-withdrawals/deposits), tokens are assigned to your account in the Verifier contract. You retain full ownership and control, and can withdraw at any time.
## Withdrawal methods
There are two ways to withdraw tokens:
1. **Direct function call** on the Verifier contract
2. **Signed intent** submitted via `execute_intents`
When using direct function calls, the token ID is used **without** a prefix (e.g., `wrap.near`).
When using signed intents, the token ID is prefixed (e.g., `nep141:wrap.near`).
## Withdrawing fungible tokens (NEP-141)
The Verifier contract exposes [ft\_withdraw](https://near.github.io/intents/defuse/tokens/nep141/trait.FungibleTokenWithdrawer.html#tymethod.ft_withdraw) for direct withdrawals and [FtWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.FtWithdraw.html) for intent-based withdrawals.
### Via direct function call
Replace `` with the token's contract address and adjust the `amount` for the token's decimal precision.
```bash theme={null}
near call intents.near ft_withdraw \
'{"token": "", "receiver_id": "your-account.near", "amount": ""}' \
--deposit 0.000000000000000000000001 \
--gas 100000000000000 \
--useAccount your-account.near \
--networkId mainnet
```
```typescript theme={null}
import { Account, JsonRpcProvider, teraToGas, KeyPairString } from "near-api-js";
const accountId = "your-account.near";
const privateKey = "ed25519:3D4YudU..." as KeyPairString;
const provider = new JsonRpcProvider({ url: "https://rpc.fastnear.com" });
const account = new Account(accountId, provider, privateKey);
await account.callFunction({
contractId: "intents.near",
methodName: "ft_withdraw",
args: {
token: "",
receiver_id: "your-account.near",
amount: "",
},
gas: teraToGas("100"),
deposit: 1n, // 1 yoctoNEAR
});
```
See contract interaction example in [near-api-examples](https://github.com/near-examples/near-api-examples/blob/main/near-api-js/examples/contract-interaction.ts) repository.
| Parameter | Description |
| ------------- | ------------------------------------------------------------------------------------------------------------ |
| `token` | The token contract to withdraw (e.g., `wrap.near` for wNEAR). No prefix for direct calls. |
| `receiver_id` | The NEAR account that will receive the withdrawn tokens. |
| `amount` | The amount in the token's smallest unit. Each token has different decimals (e.g., wNEAR has 24, USDC has 6). |
| `--deposit` | 1 yoctoNEAR, required for the withdrawal call. |
| `--gas` | 100 TGas to cover the cross-contract call. |
### Via signed intent
Submit a signed [FtWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.FtWithdraw.html) intent through `execute_intents`. Withdraw intents (`ft_withdraw`, `nft_withdraw`, `mt_withdraw`) use unprefixed token IDs (e.g., `usdc.near`). Token prefixes like `nep141:` are only used in `transfer` and `token_diff` intents.
Your public key must be registered with the Verifier contract before you can submit signed intents. For named accounts, call `add_public_key` on `intents.near`. Implicit accounts skip this step. See [Account Abstraction](/integration/verifier-contract/account-abstraction) for details.
```json theme={null}
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgNPJFViEQRhPvveC+P9xRwOXFW/IK5w=",
"message": "{\"deadline\":\"2025-05-20T13:29:34.360380Z\",\"intents\":[{\"intent\":\"ft_withdraw\",\"token\":\"wrap.near\",\"receiver_id\":\"alice.near\",\"amount\":\"1000\"}],\"signer_id\":\"user1.test.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:5op5APf9YaRznvMVwZBw6GGk9ychU3QtNRKJSxuVajHFMQths4ZZMRoAENU1zWhjinqz8KuLNyM9589c86opopyT"
}
```
See [Intent Types and Execution](/integration/verifier-contract/intent-types-and-execution) for the full signed intent format and how to submit intents.
## Real transaction examples
View these withdrawal and intent transactions on NEAR mainnet:
| Operation | Transaction |
| ------------------------- | ----------------------------------------------------------------------------------------------- |
| Withdraw by transaction | [3E8TDSLq...](https://nearblocks.io/txns/3E8TDSLq2Xn8JZEAdbeX8NGS7Ps6f1EwLeoFxhT7YY3G#enhanced) |
| Deposit + swap + withdraw | [BMFcWFRe...](https://nearblocks.io/txns/BMFcWFReAzbH8okweUio2nNTuVXtMr1hXeaaNR4UhEzS) |
| Execute intents | [FxpbspXj...](https://nearblocks.io/txns/FxpbspXjRQg3gDii18ibp3w7yvbe7MWaDHQfVqVfq7xN#enhanced) |
## Withdrawal functions by token type
| Token Type | Direct Function | Intent |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| NEP-141 (Fungible) | [ft\_withdraw](https://near.github.io/intents/defuse/tokens/nep141/trait.FungibleTokenWithdrawer.html#tymethod.ft_withdraw) | [FtWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.FtWithdraw.html) |
| NEP-171 (NFT) | [nft\_withdraw](https://near.github.io/intents/defuse/tokens/nep171/trait.NonFungibleTokenWithdrawer.html#tymethod.nft_withdraw) | [NftWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.NftWithdraw.html) |
| NEP-245 (Multi Token) | [mt\_withdraw](https://near.github.io/intents/defuse/tokens/nep245/trait.MultiTokenWithdrawer.html#tymethod.mt_withdraw) | [MtWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.MtWithdraw.html) |
| Native NEAR | N/A | [NativeWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.NativeWithdraw.html) |
## Withdrawing non-fungible tokens (NEP-171)
To withdraw NFTs from the Verifier contract, use [nft\_withdraw](https://near.github.io/intents/defuse/tokens/nep171/trait.NonFungibleTokenWithdrawer.html#tymethod.nft_withdraw) for direct calls or [NftWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.NftWithdraw.html) for intent-based withdrawals, following the same patterns as fungible token withdrawals above.
## Refunds on failed withdrawals
**Important:** This section applies to all withdrawal types except `NativeWithdraw`, since native NEAR transfers cannot fail.
A refund restores your balance when a withdrawal fails on the target smart contract. The behavior depends on the `msg` parameter in your withdrawal request.
### How `msg` affects refunds
The [withdraw function](https://near.github.io/intents/defuse/tokens/nep141/trait.FungibleTokenWithdrawer.html#tymethod.ft_withdraw) has a `msg` parameter from the [NEP-141 standard](https://nomicon.io/Standards/Tokens/FungibleToken/Core):
| `msg` Value | Transfer Method | Refund on Failure? |
| --------------------------------- | ------------------ | :----------------: |
| Not specified or `null` | `ft_transfer` | ✅ |
| Any string value (including `""`) | `ft_transfer_call` | ❌ |
An empty string (`""`) still counts as a specified `msg` value and will use `ft_transfer_call` with no refund. Only omitting `msg` entirely or setting it to `null` enables refund protection.
This same logic applies to Multi Token and NFT transfers with their corresponding functions: `nft_transfer`, `nft_transfer_call`, `mt_transfer`, and `mt_transfer_call`.
### Why refunds don't always work
Due to the asynchronous and sharded nature of the NEAR blockchain, refunds can only be processed when `ft_transfer` is used (i.e., when `msg` is not specified or is `null`).
The refund issue occurs when an asynchronous call to another smart contract (e.g., a USDC contract) fails. If an error happens within the Verifier contract itself, your balance won't change.
### Summary
| Withdrawal Request | `msg` Parameter | Refund Possible? |
| ------------------------------------------- | :-------------: | :--------------: |
| `FtWithdraw` intent or `ft_withdraw` call | No (or `null`) | ✅ |
| `FtWithdraw` intent or `ft_withdraw` call | Yes, as string | ❌ |
| `MtWithdraw` intent or `mt_withdraw` call | No (or `null`) | ✅ |
| `MtWithdraw` intent or `mt_withdraw` call | Yes, as string | ❌ |
| `NftWithdraw` intent or `nft_withdraw` call | No (or `null`) | ✅ |
| `NftWithdraw` intent or `nft_withdraw` call | Yes, as string | ❌ |
**Recommendation:** To ensure a successful withdrawal with refund protection, avoid specifying `msg` or set it explicitly to `null`. For programmable actions on the receiving contract, perform them from your own account using `ft_transfer_call`.
# Events
Source: https://docs.near-intents.org/integration/verifier-contract/events
Events emitted by the Verifier smart contract for tracking on-chain actions
The Verifier smart contract emits [events](https://github.com/near/NEPs/blob/master/neps/nep-0297.md) to log information about every intent execution and balance change. You can use these events to track on-chain actions, build indexers, and verify intent outcomes.
* For intent types that trigger these events, see [Intent Types and Execution](/integration/verifier-contract/intent-types-and-execution).
* To preview events before execution, see [Simulating Intents](/integration/verifier-contract/simulating-intents).
## Event structure
Based on [NEP-297](https://github.com/near/NEPs/blob/master/neps/nep-0297.md), NEAR events are prefixed with the string `EVENT_JSON`. The Verifier contract emits events using the DIP-4 standard, which wraps event data in a JSON object with `standard`, `version`, `event`, and `data` fields.
Here is a `token_diff` event emitted after a successful trade:
```json theme={null}
EVENT_JSON:{
"standard": "dip4",
"version": "0.3.0",
"event": "token_diff",
"data": [
{
"account_id": "charlie.near",
"intent_hash": "5GpL6PsUQVHFYAk5FWEwBUaEQqcZkc2SjTvPYHgHAnx8",
"diff": {
"nep141:usdc.near": "-100",
"nep141:usdt.near": "100"
}
}
]
}
```
| Field | Description |
| ---------- | -------------------------------------------------------- |
| `standard` | Always `"dip4"`. |
| `version` | DIP-4 version (currently `"0.3.0"`). |
| `event` | Event name (e.g., `"token_diff"`, `"intents_executed"`). |
| `data` | Array of event-specific payloads. |
## Intent events
These events are directly related to [submitted intents](/integration/verifier-contract/intent-types-and-execution). See the [full list of available events](https://near.github.io/intents/defuse_core/events/enum.DefuseEvent.html).
| Event | Description |
| -------------------- | --------------------------------------------------------- |
| `public_key_added` | Emitted when a public key is added to an account. |
| `public_key_removed` | Emitted when a public key is removed from an account. |
| `transfer` | Emitted when a transfer between two accounts executes. |
| `token_diff` | Emitted when a `token_diff` intent executes successfully. |
| `intents_executed` | Emitted after successfully executing the listed intents. |
| `ft_withdraw` | Emitted when a fungible token withdrawal intent is made. |
| `nft_withdraw` | Emitted when an NFT withdrawal intent is made. |
| `mt_withdraw` | Emitted when a multi-token withdrawal intent is made. |
| `native_withdraw` | Emitted when a native NEAR withdrawal intent is made. |
| `storage_deposit` | Emitted when a storage deposit intent is submitted. |
For withdrawal events, it is often difficult to emit only on success because the outcome depends on cross-contract calls.
## Multi Token events
Multi Token events indicate changes in the internal balances of the Verifier contract. See the [available events](https://near.github.io/intents/defuse_nep245/enum.MtEvent.html).
| Event | Description |
| ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| [`mt_mint`](https://near.github.io/intents/defuse_nep245/struct.MtMintEvent.html) | Emitted when the balance of a given account increases (due to deposits). |
| [`mt_burn`](https://near.github.io/intents/defuse_nep245/struct.MtBurnEvent.html) | Emitted when the balance of a given account decreases (due to withdrawals). |
| [`mt_transfer`](https://near.github.io/intents/defuse_nep245/struct.MtTransferEvent.html) | Emitted when tokens move between accounts (after executing intents like `token_diff`). |
### Why "mint" and "burn"?
You can think of the Verifier as a set of isolated balances that can increase, decrease, or move between accounts. Although balances are conserved and simply moved between accounts, from the Verifier contract's perspective:
* **Increasing** token amounts is equivalent to minting
* **Decreasing** token amounts is akin to burning
This design stems from how all tokens use the [Multi Token standard](/integration/verifier-contract/deposits-and-withdrawals/balances) for storage inside the Verifier smart contract.
# Intent Types and Execution
Source: https://docs.near-intents.org/integration/verifier-contract/intent-types-and-execution
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 function](https://near.github.io/intents/defuse/intents/trait.Intents.html#tymethod.execute_intents) `execute_intents`.
This page covers how intents are structured, wrapped into signed payloads, and the [available intent types](#available-intent-types) you can submit.
* For cryptographic signing details, see [Signing Intents](/integration/verifier-contract/signing-intents).
* To test intents before submitting, see [Simulating Intents](/integration/verifier-contract/simulating-intents).
## Ordering and atomicity
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](https://docs.near.org/smart-contracts/anatomy/crosscontract) originating from the Verifier will finish in order.
**Example of potential ordering issues:**
1. Intent 1: Perform a [storage deposit](https://nomicon.io/Standards/StorageManagement) on `usdc.near`
2. Intent 2: Withdraw native NEAR to `usdc.near`
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.
## Intent structure
Intents are submitted as JSON objects in a payload. Here's an example [Transfer](https://near.github.io/intents/defuse_core/intents/tokens/struct.Transfer.html) intent for wNEAR tokens from Alice to Bob:
```json theme={null}
{
"intent": "transfer",
"receiver_id": "bob.near",
"tokens": {
"nep141:wrap.near": "10"
}
}
```
The intent does not mention Alice because *the signer* of the intent defines which account performs the transfer.
## Payload structure
The intent is wrapped in a payload with these required fields:
| Field | Description |
| -------------------- | --------------------------------------- |
| `signer_id` | Signer account ID. |
| `verifying_contract` | Contract address receiving the intents. |
| `deadline` | Timestamp in ISO 8601 format. |
| `nonce` | 256-bit unique value (see below). |
| `intents` | Array of intents to execute. |
```json theme={null}
{
"signer_id": "alice.near",
"verifying_contract": "intents.near",
"deadline": "2025-05-21T12:23:04.252814Z",
"nonce": "Vij2xgAlKBKzAMcLzEqKQRhRHXp3ThAEFTYtBmfhzvE=",
"intents": [
{
"intent": "transfer",
"receiver_id": "bob.near",
"tokens": {
"nep141:wrap.near": "10"
}
}
]
}
```
### Nonce structure
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`](/integration/verifier-contract/simulating-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](https://github.com/near/intents/tree/main/defuse#nonces) for implementation details.
You can fetch the current salt in two ways:
1. **Via [`simulate_intents`](/integration/verifier-contract/simulating-intents)** — the response includes the current salt alongside simulation results.
2. **Directly via `current_salt`** — a dedicated view method on the Verifier contract:
```bash cURL theme={null}
curl -s \
-H 'Content-Type: application/json' \
-d '{
"jsonrpc": "2.0",
"id": "dontcare",
"method": "query",
"params": {
"request_type": "call_function",
"finality": "final",
"account_id": "intents.near",
"method_name": "current_salt",
"args_base64": "e30="
}
}' | jq -r '.result.result | implode'
```
The response is a hex string representing the 4-byte salt prefix, for example `"252812b3"`.
## Signed intent format
To create a valid, signed intent for the `execute_intents` function, wrap the payload in a message string and sign it. See [Signing Intents](/integration/verifier-contract/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:
```json theme={null}
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgNPJFViEQRiSQad02gXP6pv9IQRCFeg=",
"message": "{\"deadline\":\"2025-05-21T10:34:04.254392Z\",\"intents\":[{\"intent\":\"transfer\",\"receiver_id\":\"bob.near\",\"tokens\":{\"nep141:usdc.near\":\"10\"}}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:2o7Cg7N8bEAKtEDbC9Nja8Ks1bJ9Nunh5Ems51G8oV6n96ckUVFeT81vr3TouE47R24HJSrLyxdeBEbvWeuizVBZ"
}
```
The `recipient` field prevents replay attacks on other copies of the Verifier.
All signed examples on this page use the same test key (`ed25519:C3jX...`). In production, each signer uses their own key pair.
## Available intent types
The following [intents](https://near.github.io/intents/defuse_core/intents/enum.Intent.html) can be submitted to the Verifier contract.
Rust `PascalCase` names are converted to `snake_case` in JSON. For example, `TokenDiff` becomes `token_diff`.
### add\_public\_key
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.
Public keys can also be added [via transactions](/integration/verifier-contract/account-abstraction).
| Parameter | Description |
| ------------ | ----------------------------------------------------------- |
| `public_key` | The public key to add to the account (e.g., `ed25519:...`). |
```json theme={null}
{
"intent": "add_public_key",
"public_key": "ed25519:5TagutioHgKLh7KZ1VEFBYfgRkPtqnKm9LoMnJMJugxm"
}
```
The `message` field contains the intent JSON above, serialized as a single line with escaped quotes.
```json theme={null}
[
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzwKyKBC58QRjK3paApkNO6LU77m306Vw=",
"message": "{\"deadline\":\"2025-05-21T08:04:27.483198Z\",\"intents\":[{\"intent\":\"add_public_key\",\"public_key\":\"ed25519:5TagutioHgKLh7KZ1VEFBYfgRkPtqnKm9LoMnJMJugxm\"}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:M6gK8WMNBL9vnkuScshNuKF5Yro5gQNRLpTTbruadR54AQvi53xWw8NizyCRbdM3j6y9XZ7MJy4DtQ1JLDz4xGQ"
}
]
```
### remove\_public\_key
Removes a public key from an account. Can also be done [via transactions](/integration/verifier-contract/account-abstraction).
| Parameter | Description |
| ------------ | ------------------------------------------ |
| `public_key` | The public key to remove from the account. |
```json theme={null}
{
"intent": "remove_public_key",
"public_key": "ed25519:5TagutioHgKLh7KZ1VEFBYfgRkPtqnKm9LoMnJMJugxm"
}
```
The `message` field contains the intent JSON above, serialized as a single line with escaped quotes.
```json theme={null}
[
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzAAxeFUp9QRi4FmMX9Jj6kmrjkUTtltk=",
"message": "{\"deadline\":\"2025-05-21T08:24:47.536976Z\",\"intents\":[{\"intent\":\"remove_public_key\",\"public_key\":\"ed25519:5TagutioHgKLh7KZ1VEFBYfgRkPtqnKm9LoMnJMJugxm\"}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:3E11skwith3ub3w22FnUdcqYzDFy698qBnP8FEPjZyZKbFtqUZK17AXGSLiwnHXppGrV8wbbGafX8fqXUvefoE8p"
}
]
```
### transfer
Transfers tokens from the signer to a specified account within the Verifier contract.
Transfers can also be done [via direct blockchain transactions](https://near.github.io/intents/defuse_nep245/trait.MultiTokenCore.html#tymethod.mt_transfer).
| Parameter | Description |
| ------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `receiver_id` | The account to receive the tokens. |
| `tokens` | Map of token IDs to amounts in [Multi Token format](/integration/verifier-contract/deposits-and-withdrawals/balances). |
| `memo` | Optional memo for the transfer. |
```json theme={null}
{
"intent": "transfer",
"receiver_id": "bob.near",
"tokens": {
"nep141:usdc.near": "10"
}
}
```
The `message` field contains the intent JSON above, serialized as a single line with escaped quotes.
```json theme={null}
[
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgNPJFViEQRhm1GXQz/Vt+TS0PazCsJQ=",
"message": "{\"deadline\":\"2025-05-21T10:34:04.254392Z\",\"intents\":[{\"intent\":\"transfer\",\"receiver_id\":\"bob.near\",\"tokens\":{\"nep141:usdc.near\":\"10\"}}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:4nY7kjYV11djwsZ9UmezX1eoVMnzTg2wN6jT67o5vyWnibQ7g34zti8wc9imafbAzH5v4rqmksiextQCas14uxm5"
}
]
```
### Withdrawal intents
These intents move tokens from the Verifier contract to an arbitrary address:
* [FtWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.FtWithdraw.html) - Fungible tokens
* [NftWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.NftWithdraw.html) - Non-fungible tokens
* [MtWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.MtWithdraw.html) - Multi tokens
* [NativeWithdraw](https://near.github.io/intents/defuse_core/intents/tokens/struct.NativeWithdraw.html) - Native NEAR
See [Withdrawals](/integration/verifier-contract/deposits-and-withdrawals/withdrawals) for details.
| Parameter | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `token` | 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](/integration/verifier-contract/deposits-and-withdrawals/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:
```json theme={null}
{
"intent": "ft_withdraw",
"token": "usdc.near",
"receiver_id": "bob.near",
"amount": "1000"
}
```
The `message` field contains the intent JSON above, serialized as a single line with escaped quotes.
```json theme={null}
[
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgNPJFViEQRiRYtwetaXk8zFqV//Lq3c=",
"message": "{\"deadline\":\"2025-05-21T10:45:30.098925Z\",\"intents\":[{\"intent\":\"ft_withdraw\",\"token\":\"usdc.near\",\"receiver_id\":\"bob.near\",\"amount\":\"1000\"}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:XYNGWVRyGFGRVZAAn62k9r8qthzbj4a5Ct9eCjrSUW9hXpPRaBvqpLKXpaeBgsekfLFiTLdXMEitrbsZAmMmdmU"
}
]
```
### storage\_deposit
Makes an [NEP-145](https://nomicon.io/Standards/StorageManagement#nep-145) `storage_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:
```json theme={null}
{
"intent": "storage_deposit",
"contract_id": "usdc.near",
"account_id": "bob.near",
"amount": "1250000000000000000000"
}
```
The `message` field contains the intent JSON above, serialized as a single line with escaped quotes.
```json theme={null}
[
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgNPJFViEQRhA/qs878LtXEL9iIjJC14=",
"message": "{\"deadline\":\"2025-05-21T11:06:28.803408Z\",\"intents\":[{\"intent\":\"storage_deposit\",\"contract_id\":\"usdc.near\",\"account_id\":\"bob.near\",\"amount\":\"1250000000000000000000\"}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:4rAYXBa9UY6Zw32dKcGrXgydParzzdygEwdAaaKRg9TxXSP9541rikLWhVCtJqFHJh4Rcvpp2YrbRQ4LBaay7Xa6"
}
]
```
### token\_diff
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](/integration/market-makers/message-bus/introduction) or any off-chain channel, then submitted together:
```json theme={null}
{
"intent": "token_diff",
"diff": {
"nep141:usdc.near": "-10",
"nep141:usdt.near": "10"
}
}
```
```json theme={null}
{
"intent": "token_diff",
"diff": {
"nep141:usdc.near": "10",
"nep141:usdt.near": "-10"
}
}
```
The `message` field contains the intent JSON above, serialized as a single line with escaped quotes.
```json theme={null}
[
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgMh0PGuHQRiOD4cMhPLCgZfb8bCmR7s=",
"message": "{\"deadline\":\"2025-05-21T11:30:25.042157Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"-10\",\"nep141:usdt.near\":\"10\"}}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:2tKuCpxqtx6YUY6LRkQGeqmAizA8CKhkFtYdsHsAGRjwm4tFcPHHhBRGtuQAAbAkUkwJ6n2UptTP4Mpot1cTvf2u"
},
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgMh0PGuHQRhE5M+mHoAocV57AzeIPuQ=",
"message": "{\"deadline\":\"2025-05-21T11:30:25.054132Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"10\",\"nep141:usdt.near\":\"-10\"}}],\"signer_id\":\"bob.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:gTrJn3CaESvDJ765SDZ7JdkXupeGApjU6t66XpwrCXKM5K7b4VEeZXxL6NSL7i5zJ2Dn1aracg9xubktcPLwHEq"
}
]
```
As described in the [Introduction](/integration/verifier-contract/introduction), there are many ways to bundle these intents together for submission—the [Message Bus](/integration/market-makers/message-bus/introduction), third parties, or any off-chain communication channel.
## Next steps
Learn how to sign intents for different wallet types
Test intents before submitting them on-chain
Deposit and withdraw tokens from the Verifier
Monitor intent execution via on-chain events
# Verifier Contract
Source: https://docs.near-intents.org/integration/verifier-contract/introduction
The on-chain settlement layer for NEAR Intents
![NEAR Intents Verifier Contract]()
![NEAR Intents Verifier Contract]()
The Verifier Smart Contract (`intents.near`) is the on-chain settlement layer for NEAR Intents. Deposited tokens are credited to accounts in the contract's ledger. Swaps and transfers update those records; tokens leave the contract only on withdrawal through [token bridges](/integration/bridging/overview). Intents Technology does not custody these balances — control stays with the keys that can sign for each account.
The typical flow is:
1. **Deposit** tokens to `intents.near`. The contract credits your account in its on-chain ledger. *(See [Deposits](/integration/verifier-contract/deposits-and-withdrawals/deposits))*
2. **Swap or transfer** by submitting intents. Users express their "intent" to perform a transaction (e.g., exchange USDT for USDC, or transfer tokens to another user). Intents can be submitted directly or bundled together by a third party like the Message Bus for atomic execution. *(See [Intent Types](/integration/verifier-contract/intent-types-and-execution))*
3. **Withdraw** tokens to your NEAR account or external chain. For external chain asset transfer, the Verifier settles the withdrawal through the appropriate token bridge, delivering tokens to the destination address. *(See [Withdrawals](/integration/verifier-contract/deposits-and-withdrawals/withdrawals))*
## Who is this documentation for?
Most applications integrating token swaps do not need to interact with the Verifier contract directly. The [1Click Swap API](/integration/distribution-channels/1click-api/about-1click-api) handles intent creation, market maker coordination, and execution.
This section is for developers who need lower-level control and want to:
* Interact with the Verifier smart contract directly
* Create payloads for the [Message Bus](/integration/market-makers/message-bus/introduction) (a matching system that brings together quotes from market makers with transaction requests)
## Prerequisites
Before working directly with the Verifier contract, you should have:
* A [NEAR account](https://docs.near.org/tutorials/protocol/create-account) (named account like `yourname.near` or implicit account)
* Tokens to deposit (fungible tokens like USDC, USDT, or wrapped NEAR)
* Basic understanding of [NEAR transactions](https://docs.near.org/concepts/protocol/transactions) and [cross-contract calls](https://docs.near.org/smart-contracts/anatomy/crosscontract)
* Familiarity with JSON and digital signatures
If you're new to NEAR, start with the [NEAR documentation](https://docs.near.org/) to understand accounts, transactions, and the basics of smart contract interaction.
## Deployment
The Verifier smart contract is deployed at [`intents.near`](https://nearblocks.io/address/intents.near).
There is no testnet deployment. Use small amounts for testing purposes.
## Source code
The contract is open source. You can find it on GitHub:
View the source code for the Verifier smart contract
The former name of the smart contract is "Defuse". You may still see this name in some places in the codebase. It is planned to be updated in the future.
## Next steps
Learn about account identification and key management
Learn how to deposit and withdraw tokens
Explore available intent types and how to structure them
Understand how to sign intents for different wallet types
# Signing Intents
Source: https://docs.near-intents.org/integration/verifier-contract/signing-intents
How to sign intents for different wallet types and signing standards
After creating intents, they must be signed before submission to the Verifier contract via the `execute_intents` function. The Verifier supports [multiple signature standards](#signature-types) to enable signing from NEAR, Ethereum, TRON, Solana, Stellar, TON, and passkey-based wallets.
* For intents structure before signing, see [Intent Types and Execution](/integration/verifier-contract/intent-types-and-execution).
* For key management, see [Account Abstraction](/integration/verifier-contract/account-abstraction).
**Encoding Requirements for the Verifier Contract**
| Curve | Public Key | Signature |
| --------- | ----------------------- | -------------------------- |
| Ed25519 | 32 bytes | 64 bytes |
| Secp256k1 | 64 bytes (uncompressed) | 65 bytes (r \|\| s \|\| v) |
| P256 | 64 bytes (uncompressed) | 64 bytes (r \|\| s) |
**Important:** Compressed public keys are not supported for ECDSA curves (Secp256k1, P256). Public keys must be in uncompressed format (raw 64-byte x || y coordinates without prefix bytes).
Signatures must be in raw concatenated byte format, not DER-encoded.
Every public key registered to an account can sign intents on its behalf. See [Account Abstraction](/integration/verifier-contract/account-abstraction) for key management details.
## Signature types
Different wallets use different signing standards. To allow users to sign with their existing wallet, the Verifier supports [multiple verification methods](https://near.github.io/intents/defuse_core/payload/multi/enum.MultiPayload.html) — each corresponding to a specific wallet ecosystem (e.g., ERC-191 for MetaMask, Raw Ed25519 for Phantom). Each signed intent conforms to the [MultiPayload](https://near.github.io/intents/defuse_core/payload/multi/enum.MultiPayload.html) enum.
### NEP-413
The [NEP-413 standard](https://github.com/near/NEPs/blob/master/neps/nep-0413.md) is an off-chain message signing standard recognized by NEAR wallets.
| Field | Description |
| ------------------- | --------------------------------------------------------------------------------- |
| `standard` | `"nep413"`. |
| `payload.recipient` | Contract address (e.g., `intents.near`). Prevents replay on other contracts. |
| `payload.nonce` | Base64-encoded 256-bit nonce. |
| `payload.message` | Serialized JSON payload string containing `signer_id`, `deadline`, and `intents`. |
| `public_key` | Signer's public key. Encoded as key type prefix + base58 (e.g., `ed25519:...`). |
| `signature` | Cryptographic signature. Encoded as key type prefix + base58. |
```json theme={null}
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzgNPJFViEQRgYyS7p2NEiYTTY4XmT8go=",
"message": "{\"deadline\":\"2025-05-21T10:34:04.254392Z\",\"intents\":[{\"intent\":\"transfer\",\"receiver_id\":\"bob.near\",\"tokens\":{\"nep141:usdc.near\":\"10\"}}],\"signer_id\":\"alice.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:2ns3eCikZFxFA6e9ApunuDG4XwJUPrB8q82fYViBKjheqiDYcCmLN9RnB9NhoEvCdNoS3L3qYD9FAnKd7UkTnuij"
}
```
### ERC-191
Compliant with the [ERC-191 standard](https://eips.ethereum.org/EIPS/eip-191) for off-chain message signing (Ethereum wallets like MetaMask).
| Field | Description |
| ----------- | --------------------------------------------------------------------------------- |
| `standard` | `"erc191"`. |
| `payload` | Serialized JSON payload string. The `signer_id` is the Ethereum address. |
| `signature` | Secp256k1 signature. Encoded as key type prefix + base58 (e.g., `secp256k1:...`). |
There is no `public_key` field because it can be recovered from the secp256k1 signature and data.
Ethereum clients shift the recovery byte (`v`) based on chain ID. The Verifier contract expects `v ∈ {0, 1}`, so clients must normalize the recovery byte before submission.
```json theme={null}
{
"standard": "erc191",
"payload": "{\"signer_id\":\"0xca67C1Bb3FD69857E5edaF6aA1c65371bF46A464\",\"verifying_contract\":\"intents.near\",\"deadline\":\"2025-05-26T13:24:16.983Z\",\"nonce\":\"Vij2xgAlKBKzwGNqwogWQxiy87p9jW5Omfg+L9bXBDw=\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"-1000\",\"nep141:usdt.near\":\"1000\"}},{\"intent\":\"ft_withdraw\",\"token\":\"usdt.near\",\"receiver_id\":\"bob.near\",\"amount\":\"1000\"}]}",
"signature": "secp256k1:BoR53NKKJ2GfP8bETk427Xav8VMpUcZovLzXeq2EsUD7NnPH2sSmxWFEkDUrguJHHkiu3GwEQxxMo2Rm2ZTDHFygU"
}
```
### TIP-191
Compliant with [TIP-191](https://github.com/tronprotocol/tips/blob/master/tip-191.md), TRON's off-chain message signing standard. TIP-191 is fully compatible with ERC-191.
| Field | Description |
| ----------- | --------------------------------------------------------------------------------- |
| `standard` | `"tip191"`. |
| `payload` | Serialized JSON payload string. The `signer_id` is the TRON address. |
| `signature` | Secp256k1 signature. Encoded as key type prefix + base58 (e.g., `secp256k1:...`). |
Like ERC-191, there is no `public_key` field because it can be recovered from the secp256k1 signature and data. The same [recovery byte normalization](#erc-191) applies.
### Raw Ed25519
Used by [Phantom wallet for Solana off-chain message signing](https://docs.phantom.com/solana/signing-a-message).
| Field | Description |
| ------------ | --------------------------------------------------------------------------------------------- |
| `standard` | `"raw_ed25519"`. |
| `payload` | Serialized JSON payload string. Note: `deadline` uses a Unix `timestamp` instead of ISO 8601. |
| `public_key` | Signer's public key. Encoded as key type prefix + base58. |
| `signature` | Ed25519 signature. Encoded as key type prefix + base58. |
```json theme={null}
{
"standard": "raw_ed25519",
"payload": "{\"signer_id\":\"alice.near\",\"verifying_contract\":\"intents.near\",\"deadline\":{\"timestamp\":1732035219},\"nonce\":\"Vij2xgAlKBKzwGNqwogWQxi9ZuGDNBXlmdy9g3MQSMk=\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"-1000\",\"nep141:usdt.near\":\"998\"}}]}",
"public_key": "ed25519:9aqyNsCRrDkq9SceVRCdW1Zs9BmEP8ieJQRJim8iRLF",
"signature": "ed25519:9RHRenkbYN6cfWXkou47sjAf1PuTc6nYM8amHADApfqio8dcMQu28cgfz6wkktBFoE8J7FsZ3rxifFdMdzTTJi6"
}
```
### WebAuthn (Passkey)
For use with [passkeys](https://en.wikipedia.org/wiki/WebAuthn) and the [Web Authentication standard](https://w3c.github.io/webauthn/). The [signature](https://near.github.io/intents/defuse_webauthn/enum.Signature.html) can use either [Ed25519 or P256 (secp256r1)](https://www.iana.org/assignments/cose/cose.xhtml#algorithms).
| Field | Description |
| -------------------- | ---------------------------------------------------------------------------------------- |
| `standard` | `"webauthn"`. |
| `payload` | Serialized JSON payload string. |
| `public_key` | Signer's public key. Encoded as key type prefix (`p256` or `ed25519`) + base58. |
| `signature` | Cryptographic signature. Encoded as key type prefix (`p256` or `ed25519`) + base58. |
| `client_data_json` | WebAuthn client data JSON. Contains `type`, `challenge` (base64 URL-safe), and `origin`. |
| `authenticator_data` | Authenticator assertion data. Encoded as base64, URL-safe. |
```json theme={null}
{
"standard": "webauthn",
"payload": "{\"signer_id\":\"0x3602b546589a8fcafdce7fad64a46f91db0e4d50\",\"verifying_contract\":\"intents.near\",\"deadline\":\"2025-03-30T00:00:00Z\",\"nonce\":\"A3nsY1GMVjzyXL3mUzOOP3KT+5a0Ruy+QDNWPhchnxM=\",\"intents\":[{\"intent\":\"transfer\",\"receiver_id\":\"bob.near\",\"tokens\":{\"nep141:usdc.near\":\"1000\"}}]}",
"public_key": "p256:2V8Np9vGqLiwVZ8qmMmpkxU7CTRqje4WtwFeLimSwuuyF1rddQK5fELiMgxUnYbVjbZHCNnGc6fAe4JeDcVxgj3Q",
"signature": "p256:3KBMZ72BHUiVfE1ey5dpi3KgbXvSEf9kuxgBEax7qLBQtidZExxxjjQk1hTTGFRrPvUoEStfrjoFNVVW4Abar94W",
"client_data_json": "{\"type\":\"webauthn.get\",\"challenge\":\"4cveZsIe6p-WaEcL-Lhtzt3SZuXbYsjDdlFhLNrSjjk\",\"origin\":\"https://defuse-widget-git-feat-passkeys-defuse-94bbc1b2.vercel.app\"}",
"authenticator_data": "933cQogpBzE3RSAYSAkfWoNEcBd3X84PxE8iRrRVxMgdAAAAAA=="
}
```
### TonConnect
Follows the [standard for data signing](https://docs.tonconsole.com/academy/sign-data) on TON.
| Field | Description |
| -------------- | --------------------------------------------------------------------------------- |
| `address` | TON wallet address. |
| `domain` | Domain associated with the signing request. |
| `timestamp` | ISO 8601 timestamp of the signing request. |
| `payload.type` | `"text"`. |
| `payload.text` | Serialized JSON payload string containing `signer_id`, `deadline`, and `intents`. |
| `public_key` | Signer's public key. Encoded as key type prefix + base58. |
| `signature` | Ed25519 signature. Encoded as key type prefix + base58. |
```json theme={null}
{
"address": "EXvSRnDlYHziOJRm1MqGLgQB3EN7319eZLYWVinpoPv7LkBd",
"domain": "example.com",
"timestamp": "2025-01-01T00:00:00Z",
"payload": {
"type": "text",
"text": "{\"signer_id\":\"alice.near\",\"verifying_contract\":\"intent.near\",\"deadline\":\"2025-05-26T15:19:43.617898Z\",\"nonce\":\"ZnbiFf4tP4cn65XLuZ6T1H6/Vr3o6ucNftdx3pInLnc=\",\"intents\":[{\"intent\":\"ft_withdraw\",\"token\":\"usdc.near\",\"receiver_id\":\"bob.near\",\"amount\":\"1000\"}]}"
},
"public_key": "ed25519:G4HVCaJg9vZb2srcLoWxR9grQ3tGLNFMVrZBhTtBi4Q1",
"signature": "ed25519:5cwYdTNeGy1mApo9RNor9hSXvcG6GbvVm6di6kuf4frnARtVWRpJoPtvFKHMbt7uDGDtgFfn6bPDFGPK5jamqBwC"
}
```
### SEP-53
Compliant with [SEP-53](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0053.md), Stellar's standard for signing arbitrary messages using Stellar key pairs.
| Field | Description |
| ------------ | ------------------------------------------------------------------------------- |
| `standard` | `"sep53"`. |
| `payload` | Serialized JSON payload string. |
| `public_key` | Signer's public key. Encoded as key type prefix + base58 (e.g., `ed25519:...`). |
| `signature` | Ed25519 signature. Encoded as key type prefix + base58. |
## Adding more signature types
To support additional key or signature types, contact the NEAR Intents team via [Telegram](https://t.me/near_intents).
# Simulating Intents
Source: https://docs.near-intents.org/integration/verifier-contract/simulating-intents
Test intents without modifying blockchain state using the simulate_intents function
The [`simulate_intents`](https://near.github.io/intents/defuse/intents/trait.Intents.html#tymethod.simulate_intents) function runs intent code **without** modifying the Verifier contract's state. It accepts the same [`MultiPayload`](https://near.github.io/intents/defuse_core/payload/multi/enum.MultiPayload.html) input as `execute_intents`.
* For intent structure and types, see [Intent Types and Execution](/integration/verifier-contract/intent-types-and-execution).
* For signing intents before simulation, see [Signing Intents](/integration/verifier-contract/signing-intents).
## When to use simulations
Verify that your intent's digital signature format is valid before executing
Ensure a withdrawal will work before committing to it
See the fees that will be paid to the Verifier contract for a trade
## Example simulation
Here's a valid, signed intent to trade 100 USDC for 100 USDT between Charlie and Drake:
```json theme={null}
{
"signed": [
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzwJcGrQQYQhiLk1HU5AVNH1M3PhtxosE=",
"message": "{\"deadline\":\"2025-05-23T07:40:13.735337Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"-100\",\"nep141:usdt.near\":\"100\"}}],\"signer_id\":\"charlie.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:617X6QMiwFohRHqEuFwZ8aGU6Gn8PsH1DM3grArCYSKSvLz4wBPPGLzLPX3SLstLB331ESGPUToaPkUE7DvgefUu"
},
{
"standard": "nep413",
"payload": {
"recipient": "intents.near",
"nonce": "Vij2xgAlKBKzwJcGrQQYQhjtxxGCsZQhM2DP7btPexE=",
"message": "{\"deadline\":\"2025-05-23T07:40:13.753085Z\",\"intents\":[{\"intent\":\"token_diff\",\"diff\":{\"nep141:usdc.near\":\"100\",\"nep141:usdt.near\":\"-100\"}}],\"signer_id\":\"drake.near\"}"
},
"public_key": "ed25519:C3jXhkGhEx88Gj7XKtUziJKXEBMRaJ67bWFkxJikVxZ2",
"signature": "ed25519:3mLCEKyhofYLVakC9qgyb2FWh4L3jQxnUNyBHxYMTC13bo9y4AeqRh29dDYC4ZAQk4Z4mA2QZL8y7KGGKp5Pc3S1"
}
]
}
```
Calling `simulate_intents` produces:
```json theme={null}
{
"intents_executed": [
{
"intent_hash": "5GpL6PsUQVHFYAk5FWEwBUaEQqcZkc2SjTvPYHgHAnx8",
"account_id": "charlie.near",
"nonce": "Vij2xgAlKBKzwJcGrQQYQhiLk1HU5AVNH1M3PhtxosE="
},
{
"intent_hash": "4ejradLAAPBhBVAn6tBYExpuj2VCn5f5VEBfVajNXiXk",
"account_id": "drake.near",
"nonce": "Vij2xgAlKBKzwJcGrQQYQhjtxxGCsZQhM2DP7btPexE="
}
],
"logs": [
"EVENT_JSON:{\"data\":[{\"account_id\":\"charlie.near\",\"diff\":{\"nep141:usdc.near\":\"-100\",\"nep141:usdt.near\":\"100\"},\"intent_hash\":\"5GpL6PsUQVHFYAk5FWEwBUaEQqcZkc2SjTvPYHgHAnx8\"}],\"event\":\"token_diff\",\"standard\":\"dip4\",\"version\":\"0.3.0\"}",
"EVENT_JSON:{\"data\":[{\"account_id\":\"drake.near\",\"diff\":{\"nep141:usdc.near\":\"100\",\"nep141:usdt.near\":\"-100\"},\"intent_hash\":\"4ejradLAAPBhBVAn6tBYExpuj2VCn5f5VEBfVajNXiXk\"}],\"event\":\"token_diff\",\"standard\":\"dip4\",\"version\":\"0.3.0\"}",
"EVENT_JSON:{\"data\":[{\"account_id\":\"charlie.near\",\"intent_hash\":\"5GpL6PsUQVHFYAk5FWEwBUaEQqcZkc2SjTvPYHgHAnx8\",\"nonce\":\"Vij2xgAlKBKzwJcGrQQYQhiLk1HU5AVNH1M3PhtxosE=\"},{\"account_id\":\"drake.near\",\"intent_hash\":\"4ejradLAAPBhBVAn6tBYExpuj2VCn5f5VEBfVajNXiXk\",\"nonce\":\"Vij2xgAlKBKzwJcGrQQYQhjtxxGCsZQhM2DP7btPexE=\"}],\"event\":\"intents_executed\",\"standard\":\"dip4\",\"version\":\"0.3.0\"}"
],
"min_deadline": "2025-05-23T07:40:13.735337Z",
"state": {
"fee": 100,
"current_salt": "252812b3"
}
}
```
## Response fields
| Field | Description |
| -------------------------------- | --------------------------------------------------------------------------------------------------- |
| `intents_executed` | Array of intent events collected during simulation. |
| `intents_executed[].intent_hash` | Unique hash identifying the intent. |
| `intents_executed[].account_id` | NEAR account that signed the intent. |
| `intents_executed[].nonce` | Base64-encoded [nonce](https://github.com/near/intents/tree/main/defuse#nonces) used by the intent. |
| `logs` | Array of DIP-4 event JSON strings that would be emitted during execution. |
| `min_deadline` | Earliest deadline among all intents in the batch. |
| `state.fee` | Current fee in pips. |
| `state.current_salt` | Current 4-byte [salt](https://github.com/near/intents/tree/main/defuse#salt) value (hex-encoded). |
Fees are expressed in pips—100 pips equals 0.01%.
Use `current_salt` from the simulation response when constructing [versioned nonces](https://github.com/near/intents/tree/main/defuse#nonces). A nonce is only valid if its embedded salt matches one of the salts in the contract's registry.
Simulation outputs may include additional data in future updates. Contact the NEAR Intents team if your application requires more detailed output.
## Accuracy of simulations
Simulated results are designed to closely match actual execution outcomes through extensive testing.
However, due to the asynchronous nature of the NEAR blockchain, it's not possible to simulate intents exactly as they would execute in reality.
To date, simulation and execution results have always matched. If you discover a case where they differ, please contact the NEAR Intents team and report it as a bug.
Simulations reflect only side effects within the Verifier contract and **exclude** those from external asynchronous calls.
# Supported Assets
Source: https://docs.near-intents.org/resources/asset-support
All tokens supported by NEAR Intents, sourced live from the 1Click API.
The list below is sourced live from the [1Click API](https://1click.chaindefuser.com/v0/tokens) and reflects currently supported tokens. The list is continuously expanding — [join our Telegram](https://t.me/near_intents) for announcements.
# Supported Chains
Source: https://docs.near-intents.org/resources/chain-support
Supported chains, address formats, and signing standards
The list of supported chains is continuously expanding. Check this page regularly for updates or [join our Telegram community](https://t.me/near_intents) for announcements.
## Supported Networks
![]()
Arbitrum
![]()
ADI
![]()
Aurora
![]()
Base
![]()
Bera
![]()
BNB Chain
![]()
Ethereum
![]()
Gnosis
![]()
Optimism
![]()
Plasma
![]()
Polygon
![]()
Avalanche
![]()
Monad
![]()
![]()
XLayer
![]()
Scroll
### Address Format
* `0x`-prefixed hexadecimal (42 characters)
* Example: `0x85F17Cf997934a597031b2E18a9aB6ebD4B9f6a4`
### Signing Standard
* ERC-191 (all EVM wallets: MetaMask, Rabby, Rainbow, WalletConnect)
✅ Fully supported with all EVM wallets
## Supported Networks
![]()
Bitcoin
![]()
Dogecoin
![]()
Zcash
![]()
Bitcoin Cash
![]()
Litecoin
![]()
Dash
### Bitcoin
**Address Types:**
* **Legacy** - Starts with `1`
* Example: `1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa`
* **P2SH** - Starts with `3`
* Example: `3J98t1WpEZ73CNmYviecrnyiWrnqRhWNLy`
* **Bech32** - Starts with `bc1`
* Example: `bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kygt080`
* **Taproot** - Starts with `bc1p`
* Example: `bc1p5cyxnuxmeuwuvkwfem96llyr29s8l68p7z6zgt7zdkv3g7zv3qvqz6z8h7`
**Signing Standard:**
* BIP-322 (Bitcoin Knots, Bitcoin Core, Sparrow)
✅ All address types supported
### Dogecoin
**Address Types:**
* **P2PKH/Legacy** - Starts with `D`
* Example: `D9nssC5jR1viPZhWwFvDkjYpJZYJVydN8k`
* **P2SH** - Starts with `A` or `9`
✅ Fully supported
### ZCash
**Address Types:**
* **Transparent** - `t1` or `t3` prefix
* Example: `t1ZCashExample...`
⚠️ Partially supported - Transparent addresses only
### Bitcoin Cash
**Address Types:**
* **Legacy P2PKH** - Starts with `1`
* Example: `1BpEi6DfDAUFd7GtittLSdBeYJvcoaVggu`
* **Legacy P2SH** - Starts with `3`
* Example: `3CWFddi6m4ndiGyKqzYvsFYagqDLPVMTzC`
* **CashAddr P2PKH** - Starts with `q`
* Example: `bitcoincash:qpm2qsznhks23z7629mms6s4cwef74vcwvy22gdx6a`
* **CashAddr P2SH** - Starts with `p`
* Example: `bitcoincash:pqq3728yw0y47sqn6l2na30mcw6zm78dzq5ucqzc37`
✅ All address types supported
### Litecoin
**Address Types:**
* **Legacy** - Starts with `L`
* Example: `LZ3v1o8qK4b7sJ9mH2f5xQp8Pd1cR6TuVa`
* **P2SH** - Starts with `M` or `3`
* Example: `MDf8y1Kq9Tm5sR3aP7uW4cXn2Lb6vZjQhE`
* **Bech32** - Starts with `ltc1q`
* Example: `ltc1q9k3p7u5n0s4y8v2h3w6j5c9r2t0m4k7f5p0d2`
* **Taproot** - Starts with `ltc1p`
* Example: `ltc1p4h7q9m3x5u2n8k6t4v9y3r5c2w7z0l3p5u8y6f0k2d`
✅ Fully supported
## Supported Networks
![]()
Aleo
![]()
Aptos
![]()
Cardano
![]()
NEAR
![]()
Solana
![]()
Stellar
![]()
Sui
![]()
TON
![]()
Tron
![]()
XRP
![]()
Starknet
### Aleo
**Address Format:**
* 63-character Bech32 with `aleo1` prefix
* Example: `aleo1kelm7k8786anyygg788ntlgkx4uqkmkpj7k5ugfuqchd8rnf858sun3qcr`
✅ Fully supported
### Aptos
**Address Format:**
* `0x` followed by 64 lowercase hexadecimal digits
* Example: `0x334f8a73c50a796093399e6a7136092a9cab920b6c8096c13836666cd1a6b7dc`
✅ Fully supported
### Cardano
**Address Types:**
* **Shelley Base** - Full address with staking key
* **Enterprise** - Payment-only address
* Example: `addr1v8wfpcg4qfhmnzprzysj6j9c53u5j56j8rvhyjp08s53s6g07rfjm`
Partially supported
### NEAR Protocol
**Address Types:**
* **Named accounts** - Human-readable (e.g., `alice.near`)
* **Implicit accounts** - 64-character hex (SHA-256 of public key)
* Example: `ed25519:DcA2MzgpJbrUATQLLceocVckhhAqrkingax4oJ9kZ847`
**Signing Standard:**
* NEP-413 (MyNearWallet, Meteor, Sender, Ledger)
✅ Fully supported with native NEAR wallets
### Solana
**Address Format:**
* Base58-encoded Ed25519 public key (typically 44 characters)
* Example: `BYPsjxa3YuZESQz1dKuBw1QSFCSpecsm8nCQhY5xbU1Z`
**Signing Standard:**
* Raw Ed25519 (Phantom, Solflare, Slope)
✅ Fully supported with all major Solana wallets
### Sui
**Address Format:**
* 32-byte hexadecimal address
* Example: `0xcc64b79a3adf4d3c21ad25a97e3ecbe83e659e68964f62e6a1da8a037346a4ce`
✅ Fully supported
### Stellar
**Address Format:**
* 56-character base32 string
* Example: `GBD7QFQVR4QWNEJSHP4VN7RAAUKXTMZ4EJ4EBMCR7CP3HMF7RXEASTD7`
**Signing Standard:**
* SEP-53 (Freighter, Lumens Wallet, SatoshiPay)
✅ Fully supported
### Starknet
**Address Format:**
* 251-bit hexadecimal address starting with `0x`
* Example: `0x033068F6539f8e6e6b131e6B2B814e6c34A5224bC66947c47DaB9dFeE93b35fb`
✅ Fully supported
### TON (The Open Network)
**Address Format:**
* TON addresses (base64-encoded)
* Example: `EQAWzEKcdnykvXfUNouqdS62tvrp32bCxuKS6eQrS6ISgcLo`
**Signing Standard:**
* TON Connect 2.0 (Tonkeeper, EverWallet, HOT Wallet)
✅ Fully supported with TON Connect wallets
### Tron
**Address Format:**
* Base58Check-encoded (starts with `T`)
* Example: `TQ1shhBFTN2TwaRXyH1oLyCz3Yvfbzgmbk`
**Signing Standard:**
* TIP-191 (TronLink, Klever, Trust Wallet)
✅ Fully supported
### XRP Ledger
**Address Types:**
* **Classic** - Starts with `r`
* Example: `rDsbeomae4FXwgQTJp9Rs64Qg9vDiTCdBv`
* **Classic + Destination Tag** - Classic address with numeric tag
* **X-Address** - Starts with `X` (encodes classic address + destination tag)
Classic addresses with destination tags are NOT supported for our 1Click Swap service.
***
## Signing standards reference
NEAR Intents supports multiple signing standards to work with different wallet types and blockchain ecosystems.
| Standard | Compatible Wallets | Status |
| ----------------------- | ------------------------------------------------------------------- | -------------- |
| **NEP-413** | NEAR wallets: MyNearWallet, Meteor, Sender, Ledger-NEAR | ✅ Implemented |
| **ERC-191** | All EVM wallets: MetaMask, Rabby, Rainbow, WalletConnect-compatible | ✅ Implemented |
| **Raw Ed25519** | Solana wallets: Phantom, Solflare, Slope | ✅ Implemented |
| **Passkeys (WebAuthn)** | Browsers/OS: Chrome, Safari, Edge, Firefox, native apps | ✅ Implemented |
| **SEP-53** | Stellar wallets: Freighter, Lumens Wallet, SatoshiPay | ✅ Implemented |
| **TIP-191** | TRON wallets: TronLink, Klever, Trust Wallet | ✅ Implemented |
| **TON Connect** | TON wallets: Tonkeeper, EverWallet, HOT Wallet | ✅ Implemented |
| **BIP-322** | Bitcoin wallets: Sparrow, Bitcoin Knots, Bitcoin Core | ⚙️ In progress |
For technical details on how intent signing works, see [Signing Intents](/integration/verifier-contract/signing-intents).
***
## Token support
Each supported chain provides access to native tokens and popular standards:
| Category | Supported tokens and standards |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| EVM Chains | Native tokens (ETH, BNB, MATIC, etc.); ERC-20 tokens; automatic token detection |
| Bitcoin Networks | BTC (Bitcoin), BCH (Bitcoin Cash), DOGE (Dogecoin), LTC (Litecoin), ZEC (Zcash, transparent only) |
| NEAR Ecosystem | NEAR native token; NEP-141 fungible tokens; bridged assets |
| Other Layer 1 chains | ADA (Cardano), ALEO (Aleo), SOL (Solana) + SPL tokens, SUI native and wrapped tokens, XLM (Stellar) + issued assets, TON + jettons, TRX (Tron) + TRC-20 tokens, XRP (Ripple), STRK (Starknet), Hyperliquid USDC |
### Querying supported tokens
Check supported tokens using the [1Click API](/integration/distribution-channels/1click-api/about-1click-api) `tokens` endpoint:
```bash theme={null}
curl https://1click.chaindefuser.com/v0/tokens
```
***
## Request new chains
Join our [Telegram community @near\_intents](https://t.me/near_intents) and share your request. Our team evaluates new chains based on:
* User demand
* Technical compatibility
* Liquidity availability
* Security audits
We prioritize chains with:
* High transaction volume and user demand
* Strong developer ecosystem
* Existing market maker liquidity
* Compatible signing standards
Yes! If you're a blockchain developer or market maker, we welcome contributions. Contact us via Telegram to discuss integration requirements.
***
## Next steps
Execute your first cross-chain swap in under 5 minutes.
Learn how to integrate NEAR Intents into wallets and applications.
Provide liquidity and fulfill user intents profitably.
Learn about platform fees and how to obtain free API access.
# FAQs
Source: https://docs.near-intents.org/resources/faqs
Frequently Asked Questions
## General
There is no testnet deployment and no plans for one. We recommend testing on NEAR mainnet using separate dev/test NEAR accounts.
Earn routes users into third-party yield protocols through normal 1Click quotes. Receipt tokens can be held in Intents or delivered to a destination-chain wallet. See [Earn](/integration/distribution-channels/1click-api/earn).
Limit Orders rest a confidential swap at a price the user sets. See [Limit Orders](/integration/distribution-channels/1click-api/orders).
## Deposits
The deposit process begins once the transfer transaction on the foreign network has been completed. When the balance of the user's unique deposit address becomes positive, our indexer generates a deposit event and assigns it a `PENDING` status.
The next step is collecting the current tokens in storage. The result of this process will be either a `COMPLETED` or `FAILED` status. Deposits with a `FAILED` status are currently handled manually and eventually updated to the `COMPLETED` status.
On EVM networks, deposits can bypass the `PENDING` status due to faster processing and transfer completion times.
**BTC deposits:** If you want to make a deposit to an account that hasn't yet been connected to the application, this is possible but requires caution. You can request a deposit address by calling the bridge API (`deposit_address`) and specifying the `account_id` parameter. The `account_id` can be a NEAR account, an EVM address, or a SOL address to which you have access.
We recommend starting with a small amount for experimentation. After the deposit is completed, you can connect your wallet and check the tokens.
Only `ft_transfer_call` can be used to deposit NEP-141 tokens from NEAR to `intents.near`:
```javascript theme={null}
::ft_transfer_call({
"receiver_id": "intents.near",
"amount": "1234",
"msg": "{\"receiver_id\": \"\"}"
})
```
Here is an example [receipt](https://nearblocks.io/txns/EwmeXzZJStA6e5JB49vgxNYJDemqeYCFGvPH7zapP1Fw#execution#4tyaF4MnMcNQVqrg3kXzsH9277ErDeCXS9g3c2keV38G).
The `msg` parameter can also be empty, so that funds will be deposited to `sender_id` (i.e. the caller of `ft_transfer_call`). Here is an example of such a [transaction](https://nearblocks.io/txns/HoWpAR8dF5azsUVaQWrBW5VsRve5X4dwr9GGiHWj3R1P#execution).
For EVM chains, NEAR Intents does not impose limitations on how deposits are executed at the smart contract level. Our listeners track the chain for:
* ERC-20 `Transfer` events
* Regular or internal native transfers
to any of the supported deposit addresses.
As long as the resulting transaction emits a valid `Transfer` event (or performs a native value transfer) to the deposit address, it will be detected—even if it originates from a custom contract method (for example, a custom `withdraw()` function instead of `transfer` / `transferFrom`).
This information is not available for Solana because the mechanism of deposit tracking works differently on that chain.
Very small amounts (e.g., 5,000 sats) are considered "dust" and there is special business logic to process such small amounts. This may cause delays in sweeping.
## ETH Connector Migration
Because of the split of ETH-connector, the `aurora` contract now [acts](https://github.com/aurora-is-near/aurora-engine/blob/3416d0d170bf3dcaaac3ad3b9ba751d002ea1b3f/engine/src/contract_methods/connector/mod.rs#L209-L210) as a NEP-141 proxy to `eth.bridge.near`. This leads to some changes:
1. **All new deposits** will be [treated](https://nearblocks.io/txns/ExLxkbRjKbSDSTVozPpSsTfRL8Aqfs8kvLxFLEx4qDzt#enhanced) as `eth.bridge.near`, even if triggered from the `aurora` smart contract—even from inside Aurora Mainnet (example [tx](https://explorer.aurora.dev/tx/0x9c20d9f76443ec3c12f8eb41a65caa0c1391210c539a5924215b9bdf9e0b1fd2?tab=index)). All withdrawals of legacy `aurora` will be received on NEAR as new `eth.bridge.near`.
2. **Migration of already deposited ETH\@NEAR (`aurora`)** can be done permissionlessly by withdrawing from `intents.near` and depositing it back right away. This can be done in a single transaction thanks to [this patch](https://github.com/Near-One/aurora-eth-connector/blob/58d3f39cebcf6266514de3dd04efec5bafb6274e/eth-connector/src/lib.rs#L132-L143) on the eth-connector side.
Users can migrate in two ways:
**Option 1: Via `ft_withdraw()` transaction**
[Example transaction](https://nearblocks.io/txns/GHrRbGsDuv86u72jHNqofZYTUssfuXyYwcJ8mYyLrq2v#enhanced) with the following params:
```json theme={null}
{
"token": "aurora",
"receiver_id": "intents.near",
"amount": "1234",
"memo": "Migrate ETH: aurora -> eth.bridge.near",
"msg": ""
}
```
**Option 2: Via `ft_withdraw` intent**
Use the same parameters as above.
The [front-end](https://app.near-intents.org) automatically detects legacy tokens on your balance and prompts you to sign a migration intent.
# Fees
Source: https://docs.near-intents.org/resources/fees
All fees that apply to NEAR Intents transactions and integrations
## Protocol Fee
* **0.0001% (1 pip)** per transaction
* Collected on-chain by the [`intents.near`](https://nearblocks.io/address/intents.near) smart contract
* Applies to every transfer, swap, or transaction
* Fees are sent to the [`fee_collector`](https://near-intents.org/account?user=near:7066024d3f20f94de601c003163367873cca78507eeca4df66d9be645f197f05)
## Near-Intents.org Fee
* **0.2%** fee on swaps executed through [near-intents.org](https://near-intents.org)
* Collected by the proprietary distribution channel in addition to the protocol fee
* Fees are sent to [`fefundsadmin.sputnik-dao.near`](https://nearblocks.io/address/fefundsadmin.sputnik-dao.near)
## Withdrawal Fees
* **0.1%** fee for **NEAR**, **ZEC**, and **STRK** tokens withdrawn to the **Solana** network
## 1Click Swap API Fees
| Authentication | Fee |
| ------------------- | ----------------------------- |
| **With API key** | Only the 0.0001% protocol fee |
| **Without API key** | Additional **0.2%** fee |
[Apply for an API key](https://partners.near-intents.org/) to avoid the 0.2% unauthenticated fee.
### Quote improvement fee (1Click / NEAR Intents)
**Definition:** If a swap execution gets **filled at a better price than the quoted price**, that difference is split **50/50** between you and the protocol.
**Eligible orders:** Real cross-asset swaps (not same-token moves). Only applies while the quote is still **fresh—within about 30 minutes** of when it was issued.
**Fee calculation:** **Direct 50/50 split** of the measured improvement, or **zero** if execution did not beat the quote.
### Distribution Channel Fees
Developers and distribution channels can add their own fees using the [`appFees`](/integration/distribution-channels/1click-api/fee-config) parameter when requesting quotes.
```json theme={null}
{
"appFees": [{
"recipient": "your-wallet.near",
"fee": 50
}]
}
```
This example charges a 0.5% fee (50 basis points) from the input token.
### Revenue Share
All partners participate in a **50/50 revenue share** by default. Half of the fee amount specified via `appFees` is automatically sent to the 1Click protocol address, and the other half goes to the partner's `recipient` address.
For example, if you set `"fee": 10` (10 basis points), 5 bps go to your partner address and 5 bps go to the 1Click address.
Revenue is shared equally between partners and NEAR Intents, with a 50/50 split.
Learn how to configure and collect fees from your integration
# SHIELD: Proactive Intents Security
Source: https://docs.near-intents.org/security-compliance/proactive-intents-security
How SHIELD proactively raises security posture across guarded NEAR Intents surfaces
SHIELD is the security policy layer behind NEAR Intents and the 1Click stack. It lets integrated services evaluate requests against incident state and shared security posture before continuing execution.
Instead of relying on a single global stop switch, SHIELD is built for scoped response. Today that means request-time decisions such as allow or delay on integrated flows, with broader orchestration expanding over time.
***
## Implementation status
Use this page as both a product direction overview and a status snapshot.
Incident submission and resolution, scoped permissions, security modes, and quote-time evaluation decisions for integrated Shield consumers.
Broader runtime adoption of Shield decisions across additional request paths and operational surfaces.
Multi-surface posture orchestration informed by richer operational, transaction, and chain-health signals.
***
## Architecture
At its core, SHIELD is a dedicated incident and policy service. Authorized producers submit incidents, and integrated consumers query SHIELD to determine how a request should proceed.
This architecture supports graceful degradation by applying scoped policy decisions at request time instead of immediately shutting down the full platform.
One write surface for incident creation and resolution with authentication, scoped authorization checks, and auditable records.
Shared posture represented as coarse modes (`normal`, `paranoid`, `under_attack`) that integrated consumers can apply consistently.
Evaluate endpoints return scoped policy decisions based on incidents, posture, and configured thresholds.
### Guarded surfaces
SHIELD can coordinate security posture across multiple parts of the platform:
Live today for integrated quote-time checks, including scoped delay.
Rolling out as Shield decisions are adopted across additional execution paths and bridge-touching flows.
Vision: solver and liquidity controls can consume the same incident and posture model as integration expands.
Live today through incident public descriptions that support partner-facing degraded-state messaging.
***
## Security Modes
SHIELD defines three operational modes. They are intentionally coarse so they are easy to reason about under pressure.
No friction. This is the default operating state.
Buy time. Add delay windows and increase operational scrutiny while the situation is assessed.
Pause affected functionality and monitor in depth while responders contain the incident.
The modes are designed to be simple on purpose. In an incident, operators benefit from clear posture changes more than they benefit from a large number of fine-grained states.
***
## Partner Permissions
The SHIELD signal bus is open to multiple producers, including partner integrations, on-call operators, internal anomaly detection, and internal tooling. Producers do not inherit capabilities automatically. Each producer receives an explicit permission set.
Typical capabilities include:
Pause a single chain, token, or destination without escalating the whole platform.
Submit an observation for review without forcing a posture change.
Move a scoped surface or the full platform into `paranoid` or `under_attack`.
Inspect status and history without changing platform posture.
These permissions are scoped. The model supports granular scope by chain, bridge, token, address, and security mode. Scope enforcement is rolling out incrementally. As newer request-evaluation paths adopt narrower chain-specific permissions, behavior may vary by integration path.
### Example permission models
An internal on-call operator may be granted `raise mode` at platform scope so they can move the system into `paranoid` or `under_attack` while a real incident unfolds.
A partner integration may be granted per-chain scope, plus read-only access elsewhere, so it can pause a chain it cares about without escalating the global posture.
Capabilities are auditable in both directions. Partners can inspect their own action history, while internal operators can review the full action set by partner, scope, or effect.
***
## Anomaly Engine
SHIELD integrates a first-party anomaly engine as an additional decision input for quote evaluation.
The engine is rule-based and explainable rather than model-driven. It maps observed conditions to concrete decision outcomes.
In current integration, anomaly scoring is applied on quote evaluation under configured thresholds and feature flags.
Elevated outcomes can increase friction (for example delay), while failures are handled defensively.
As integration expands, anomaly inputs can inform more surfaces beyond the current quote-centric path.
***
## Transaction and Account Monitoring
Proactive intent security is not only about chain-level conditions. It is also about identifying when a specific transaction, account, destination, or fund flow looks unusual in the context of the broader system.
SHIELD's policy model is designed to support transaction and account-level targeting across connected chains, including:
Today: integrated quote requests can be delayed based on incident and anomaly outcomes.
Model support exists for scoped controls by recipient, sender, deposit address, and counterparties.
Rolling out: broader use of policy decisions across more end-to-end flow checkpoints.
Vision: apply targeted friction to the transaction, account, route, or destination that needs attention without broad platform degradation.
This remains core to the SHIELD vision: proactive security should react not only to unhealthy chains, but also to suspicious activity tied to individual requests and participant accounts.
In practice, that means NEAR Intents can raise friction for a specific flow of funds while the rest of the system continues operating normally.
***
## Chain Health
Different chains fail in different ways. A proof-of-work chain may lose hashrate. A proof-of-stake chain may stall on finality. An L2 may fall behind its sequencer.
SHIELD is being designed around a normalized health model. The target state is chain-family adapters that emit a shared output at the policy boundary.
Vision: each adapter answers shared practical questions such as block production, finality health, throughput envelope, and anomaly conditions.
Vision: each chain family stays native to its own environment while translating to shared policy semantics.
Common adapter families include:
Metrics such as hashrate and block cadence.
Metrics such as finality, reorgs, and mempool behavior.
Metrics such as block production and validator health.
A family-specific adapter that translates chain-native signals into the shared health model.
Chain-health integration follows the same incident and policy model. As adapters are rolled out, they can feed incidents through shared authorization and audit paths.
***
## Incident API
SHIELD exposes two conceptual surfaces:
A read path for consumers who need a summary of current incidents and degraded conditions.
A write path for authorized producers. Requests are authenticated and scope-checked before incident state is changed.
The public surface is intentionally narrow. Detailed schemas are shared through partner-facing reference materials, while this page explains the purpose of the system and the security model behind it.
Partner-facing reference for pulling active incidents and submitting new ones — endpoints, auth, and scope.
***
## Summary
SHIELD gives NEAR Intents a proactive way to raise security posture before an issue becomes system-wide damage. Today it combines shipped controls with an explicit roadmap:
Incident management, scoped permissions, coarse security modes, and evaluate endpoints used by integrated consumers.
Explicit producer capabilities instead of inherited authority.
Simple postures that operators can apply quickly during an incident.
Progressive expansion from quote-centric safeguards toward broader, surface-specific response across the platform.
# Risk & Compliance
Source: https://docs.near-intents.org/security-compliance/risk-and-compliance
How NEAR Intents implements compliance screening and financial integrity measures
At NEAR Intents, we are deeply committed to implementing best practices in compliance and financial integrity. Transparency, accountability, and adherence to international standards are not just regulatory requirements for us they are guiding principles.
Our goal is to ensure that all transactions routed through NEAR Intents are secure, transparent, and fully aligned with global efforts to combat money laundering, sanctions violations, and other forms of financial crime.
For platform security posture and incident controls, see [Proactive Intents Security](/security-compliance/proactive-intents-security).
## Law Enforcement Requests
For any formal request, law enforcement authorities are required to submit the request and supporting documentation through our designated portal:
[https://app.kodexglobal.com/nearintents/signin](https://app.kodexglobal.com/nearintents/signin)
Please note that we are only able to process requests received through this channel.
If you have any questions, please do not hesitate to contact us.
## Current Implementation
### Real-time compliance screening
NEAR Intents applies automated compliance screening on integrated quote flows against multiple trusted data sources:
Internal AML screening database
Exchange-level compliance data
Third-party AML intelligence
Enhanced screening for non-dry quotes
These checks identify overlap between addresses in the request and addresses flagged in external databases.
Coverage can vary by flow and integration path. The compliance and Shield stack is expanding toward broader, end-to-end enforcement across additional surfaces.
# Security
Source: https://docs.near-intents.org/security-compliance/security
Security audits, bug bounty program, and AML resources
## Audits
NEAR Intents smart contracts have been audited by independent security firms.
Access all security audit reports on Google Drive
## Bug Bounty Program
Found a vulnerability? We offer rewards for responsible disclosure through our bug bounty program.
Submit security vulnerabilities via Hackenproof
## AML/CTF Resources
For Anti-Money Laundering and Counter-Terrorism Financing related requests, use our dedicated AML portal.
Submit AML/CTF inquiries and requests
# Shield Incident API
Source: https://docs.near-intents.org/security-compliance/shield-incident-api
Partner-facing API for pulling active Shield incidents and submitting new ones
This guide covers the partner-facing flow for pulling active Shield incidents and submitting new incidents. It does not cover admin-only incident operations. For the concepts and security model behind incidents, see [Proactive Intents Security](/security-compliance/proactive-intents-security).
For non-programmatic viewing and submitting incidents, use [`https://partners.near-intents.org/shield/console`](https://partners.near-intents.org/shield/console).
* Incidents endpoint: [`https://shield.chaindefuser.com/incident`](https://shield.chaindefuser.com/incident)
* Get a JWT token at [`https://partners.near-intents.org/api-keys`](https://partners.near-intents.org/api-keys) by requesting `key_type: SHIELD`.
* To submit incidents, contact Intents Support so support can grant the required incident permissions.
All requests use:
```http theme={null}
Authorization: Bearer
Accept: application/json
```
## Pull active incidents
Use [`GET https://shield.chaindefuser.com/incident`](https://shield.chaindefuser.com/incident) to check whether Shield currently has active incidents.
```sh theme={null}
curl -sS "https://shield.chaindefuser.com/incident" \
-H "Authorization: Bearer $PARTNER_TOKEN" \
-H "Accept: application/json"
```
When there are no active incidents, Shield returns:
```json theme={null}
{
"status": "operational"
}
```
When incidents are active, Shield returns:
```json theme={null}
{
"status": "incidents",
"incidents": [
{
"scopeType": "chain",
"scopeValue": "eth",
"direction": "withdraw",
"publicDescription": "ETH withdrawals are delayed"
}
]
}
```
Partners with the `status_read` grant receive the full internal incident record, including `id`, `status`, `description`, `createdBy`, `metadata`, and timestamps.
## Submit an incident
Use [`POST https://shield.chaindefuser.com/incident`](https://shield.chaindefuser.com/incident) to open a scoped incident.
```sh theme={null}
curl -sS -X POST "https://shield.chaindefuser.com/incident" \
-H "Authorization: Bearer $PARTNER_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"scopeType": "chain",
"scopeValue": "eth",
"direction": "withdraw",
"description": "ETH withdrawals are temporarily unavailable"
}'
```
Successful response:
```json theme={null}
{
"incident": {
"id": "",
"status": "active",
"scopeType": "chain",
"scopeValue": "eth",
"direction": "withdraw",
"description": "ETH withdrawals are temporarily unavailable",
"publicDescription": null,
"createdBy": "partner-id",
"resolvedBy": null,
"metadata": null,
"createdAt": "2026-06-29T08:00:00.000Z",
"updatedAt": "2026-06-29T08:00:00.000Z",
"resolvedAt": null
}
}
```
## Incident scope
| Field | Required | Values | Notes |
| ------------- | -------- | ------------------------------------- | ---------------------------------------------------------- |
| `scopeType` | Yes | `chain`, `bridge`, `token`, `address` | What kind of surface is affected |
| `scopeValue` | Yes | Scope-specific string | Examples: `eth`, `poa`, `nep141:`, or an address |
| `description` | No | String | Incident context |
# 1ClickSwap API Terms of Use
Source: https://docs.near-intents.org/security-compliance/terms-of-service
Terms of use governing developer access to the 1ClickSwap API
**1CLICKSWAP API TERMS OF USE**
**Last Updated: August 28, 2026**
**BY CLICKING TO ACCEPT, GENERATING AN API KEY, REGISTERING ON THE DEVELOPER PORTAL, OR ACCESSING OR OTHERWISE USING THE 1CLICKSWAP API ("API"), YOU ("DEVELOPER," "YOU," OR "YOUR") ENTER INTO THESE 1CLICKSWAP API TERMS OF USE ("TERMS") WITH INTENTS TECHNOLOGY LIMITED, A COMPANY INCORPORATED IN THE BRITISH VIRGIN ISLANDS ("INTENTS TECHNOLOGY," "WE," "US," OR "OUR") AS OF THAT DATE (THE "EFFECTIVE DATE"). IF YOU ACCEPT ON BEHALF OF AN ENTITY, YOU REPRESENT THAT YOU HAVE AUTHORITY TO BIND IT. THESE TERMS GOVERN YOUR USE OF THE API. IF DEVELOPER AND INTENTS TECHNOLOGY (OR ANY ENTITY DESIGNATED BY INTENTS TECHNOLOGY) HAVE A SEPARATE WRITTEN AGREEMENT GOVERNING ACCESS TO THE API AND SERVICES (A "COMMERCIAL AGREEMENT"), THE COMMERCIAL AGREEMENT CONTROLS TO THE EXTENT OF ANY CONFLICT WITH THESE TERMS.**
**THE API IS BACKEND ROUTING AND SETTLEMENT INFRASTRUCTURE DEVELOPED AND MAINTAINED BY INTENTS TECHNOLOGY. IT IS SEPARATE FROM THE PROTOCOL, ANY FRONT-END INTERFACES, AND THIRD-PARTY COMPONENTS. INTENTS TECHNOLOGY IS NOT LICENSED OR REGULATED BY ANY FINANCIAL REGULATORY AUTHORITY TO PROVIDE REGULATED FINANCIAL SERVICES, AND THE API IS NOT OFFERED AS, AND IS NOT INTENDED TO CONSTITUTE, REGULATED FINANCIAL SERVICES. THE API IS PROVIDED " fAS IS." ALL USE IS ENTIRELY AT YOUR OWN RISK. ANY DISPUTES WILL BE RESOLVED BY FINAL AND BINDING ARBITRATION ON AN INDIVIDUAL BASIS (SEE SECTION 18), AND YOU WAIVE ANY RIGHT TO PARTICIPATE IN A CLASS ACTION.**
## PURPOSE AND SCOPE
**Nature of the 1Click Service.** The 1Click Service simplifies interaction with the Protocol. Instead of requiring Developers or End-Users to manually coordinate multiple blockchain steps (for example, bridging assets to NEAR Protocol, posting intents, and withdrawing assets back to other chains), the 1Click Service automates these routing and settlement steps. The goal is a simplified, "one-click" experience for complex cross-chain transactions.
**What the 1Click Service Is Not.** The 1Click Service is not intended to operate as a wallet, broker, advisor, exchange, custodian, payment service provider, money transmitter, or fiduciary. It does not operate liquidity pools, order books, yield-generating protocols, or trading venues. The 1Click Service does not pool user funds, act as counterparty, or provide financial guarantees, insurance, or underwriting. All Transactions facilitated through the 1Click Service are executed by End-Users through the underlying software and smart contracts, and Intents Technology bears no responsibility for verifying the legality, suitability, or taxation of any Transaction or user activity.
**Technical Actions.** To perform routing and settlement, in the ordinary course of operation, the 1Click Service provides a relay of routing instructions solely to effect user-initiated Transactions. These actions:
* (a) are incidental and necessary to construct and submit transactions (including via Third-Party Components);
* (b) are limited to executing user instructions;
* (c) are transient, programmatic, and self-executing, and take no longer than necessary to complete the Transaction;
* (d) do not involve pooling, rehypothecation, or re-use of user assets;
* (e) do not create any fiduciary, agency, or safekeeping relationship with users; and
* (f) do not at any time give Intents Technology or any affiliated entity beneficial ownership of user assets.
**Separation.** The 1Click Service is separate from the Protocol, any Third-Party Interface, and Third-Party Components. Those components are developed and maintained by third parties and have their own terms, risks, and documentation. Intents Technology maintains the infrastructure necessary to operate the 1Click Service and also develops and operates the PoA Bridge. The PoA Bridge forms part of the infrastructure made available through the 1Click Service, and its use in connection with the API or 1Click Service is governed by these Terms (see Section 7.7), without prejudice to any separate terms of service that may apply to direct or standalone use of the PoA Bridge. Save for the PoA Bridge, Intents Technology does not operate the Protocol, any other Third-Party Components, or any Third-Party Interface. Intents Technology or its Affiliates may operate one or more First-Party Interfaces (such as near.com).
**Limited Technical Operation.** Intents Technology operates or makes available the API, the 1Click Service routing layer, fee-calculation and fee-distribution mechanics, the Developer Portal, and the PoA Bridge. Operating or making available such technology does not make Intents Technology the operator of, and Intents Technology does not control, any blockchain network, the Protocol, any third-party bridge, Solver, liquidity source, or Front-End Interface, except to the extent of a specific technology, interface, parameter, or contract that Intents Technology itself operates or makes available.
## 1. DEFINITIONS
For the purposes of these Terms, the following terms shall have the meanings ascribed to them below. Capitalized terms used but not otherwise defined herein shall have the meanings ascribed to them in the relevant provisions of these Terms.
**"1Click Service" or "1CS"** means the backend routing and settlement service developed and maintained by Intents Technology to assist with routing and settlement of intents via the Protocol.
**"Affiliate"** means any entity that directly or indirectly controls, is controlled by, or is under common control with a respective Party. For purposes of this definition, "control" means the power to direct management and policies, whether through ownership of voting securities, by contract, or otherwise.
**"API"** means the 1ClickSwap application programming interface, including all endpoints, documentation, and tools made available by Intents Technology for integrating with the 1Click Service.
**"API Key"** means the unique credential(s) issued to Developer for authentication and access to the API.
**"AppFee"** means the fee parameter configured by a Registered Developer within its integration with the 1Click Service, as further described in Schedule 1. The AppFee applies to Public Swaps only.
**"Confidential Information"** means all information disclosed by a Party to the other Party, whether orally or in writing, that is designated as confidential or that reasonably should be understood to be confidential given the nature of the information and the circumstances of disclosure.
**"Confidential Intents Protocol"** means the smart contracts deployed on the NEAR Private Shard which enable users to post, match, and settle confidential intents, to be executed by the solver network. The Confidential Intents Protocol is not operated or controlled by Intents Technology.
**"Confidential Swap"** means a Transaction submitted through the API with confidentiality enabled, which is routed through the Confidential Intents Protocol on the NEAR Private Shard.
**"Confidential Infrastructure Fee"** means the Infrastructure Fee that Intents Technology charges and retains in respect of Confidential Swaps, as set out in Section 6.8 and Schedule 1.
**"Public Swap"** means a Transaction submitted through the API for which confidentiality is not enabled.
**"Commercial Agreement"** means any separate written agreement between Developer and Intents Technology (or any entity designated by Intents Technology) governing Developer’s integration with or use of the 1Click Service, as referred to in these Terms. A Commercial Agreement also includes any rates, fee arrangements, rebates, discounts, or other terms agreed through the Developer Portal that are expressly stated to be contractually binding and that the Developer has affirmatively accepted; Documentation and other Developer Portal content that is not expressly stated to be contractually binding does not constitute a Commercial Agreement.
**"Developer Portal"** means the NEAR Intents Partners Portal at [https://partners.near-intents.org/](https://partners.near-intents.org/) (or any successor URL), through which Developers register, manage API Keys, and access integration tools.
**"Developer's Product"** means any application, website, tool, service, or product that Developer offers to its End-Users that employs the API or Services.
**"Documentation"** means any sample code, instructions, requirements, specifications, or other documentation made available by Intents Technology, including (without limitation) at [https://docs.near-intents.org/integration/distribution-channels/1click-api/about-1click-api](https://docs.near-intents.org/integration/distribution-channels/1click-api/about-1click-api), to use and access the Services.
**"End-User"** means any individual or legal entity that accesses, interacts with, or transacts through the Developer's Product.
**"Front-End Interface"** means any website or application that provides user-facing access to the Protocol or the 1Click Service. A Front-End Interface may be operated by Intents Technology or its Affiliates (a "**First-Party Interface**", such as near.com) or by a third party (a "**Third-Party Interface**").
**"Infrastructure Fee"** means the fee charged by or retained by Intents Technology under Schedule 1 in respect of Transaction volume routed through the 1Click Service. The Infrastructure Fee is a single fee , the calculation or amount of which varies depending on (a) whether the Transaction is a Public Swap or a Confidential Swap and (b) for Public Swaps, whether the Developer is a Registered Developer or an Unregistered Developer, as further set out in Schedule 1.
**"Intents Protocol"** means the smart contracts deployed on NEAR Protocol (including, without limitation, the intents.near and intents.far contracts) that enable users to post, match, and settle intents, to be executed by the solver network. The Intents Protocol is not operated or controlled by Intents Technology.
**"Intellectual Property" or "IP"** means a Party's rights in all patents, patent applications, copyrights, copyright applications and registrations, trade secrets, service marks, trademarks, trademark applications, moral rights, and all other proprietary and intellectual property rights.
**“NEAR Private Shard”** means the blockchain, being a fork of NEAR Protocol, which operates to provide a restricted-visibility execution environment for confidential intents and the Confidential Intents Protocol (or such other name as may be designated from time to time).
**"Party"** means either Intents Technology or Developer individually, and together the "Parties."
**"Protocol"** means, together, the Intents Protocol and the Confidential Intents Protocol.
**"Registered Developer"** means a Developer that has completed registration via the Developer Portal and has been issued one or more API Keys with registered access credentials.
**"Services"** means the technical access, tools, infrastructure, and support provided by Intents Technology in connection with the API, the Developer Portal, and the 1Click Service as set forth herein.
**"Solver"** means any third-party agent or automated system that matches, fills, or settles intents on the Protocol. Solvers are independent third parties and are not operated, controlled, or endorsed by Intents Technology.
**"Third-Party Components"** means independent services, applications, or protocols that the 1Click Service may interface with (including, for example, OmniBridge or HOT Bridge), other than services developed, maintained, or operated by Intents Technology. For the avoidance of doubt, the PoA Bridge is developed and operated by Intents Technology and is not a Third-Party Component. Its use in connection with the API or 1Click Service is governed by these Terms (see Section 7.7), without prejudice to any separate terms of service that may apply to direct or standalone use of the PoA Bridge.
**"Transaction"** means any intent, bridge, swap, or other transaction order initiated by an End-User through the Developer's Product via the API.
**"Unregistered Developer"** means a Developer that accesses or uses the API without having completed registration via the Developer Portal.
## 2. ACCESS AND SCOPE OF SERVICES
**2.1 Access and API Keys.** Subject to these Terms, Intents Technology agrees to provide Developer with non-exclusive access to the API via one or more API Keys issued through the Developer Portal. Developer shall safeguard all API Keys and access credentials with reasonable security measures consistent with industry standards and shall not share, publish, or expose API Keys to unauthorized third parties.
**2.2 Developer Portal.** Developer's use of the Developer Portal is governed by these Terms. Developer shall provide accurate, complete, and current information during registration and shall promptly update such information as necessary. Developer is solely responsible for all activity conducted through its Developer Portal account.
**2.3 Documentation.** Intents Technology shall make Documentation available for Developer's use and implementation of the API. Intents Technology reserves the right to update, change, suspend, or discontinue the Documentation, in whole or in part, at any time. Developer acknowledges that updates to the Documentation may affect the Developer's Product and its integration with the API. In the event of any conflict between these Terms and the Documentation, these Terms control. The Documentation is provided for technical implementation and operational guidance only and does not modify the fees, economic entitlements, warranties, limitations of liability, or other legal terms set out in these Terms or any Commercial Agreement.
**2.4 Modifications and Updates.** Intents Technology may modify the API, Documentation, or Services at any time. Developer will promptly implement, or permit Intents Technology to implement, any Intents Technology-supplied update within a commercially reasonable period after it becomes available. Intents Technology may, on reasonable notice, deprecate any feature, functionality, or API version and require Developer to migrate to a supported version. Developer's continued use of the API after any change constitutes acceptance. If Developer fails to implement required updates within the applicable timeframe, Intents Technology may suspend the Services, provided Intents Technology gives advance notice of the update before implementation.
**2.5 Support.** Intents Technology may, in its sole discretion, provide technical support for the API. Intents Technology does not guarantee ongoing development, maintenance, error correction, response times, or availability of any support. Developer is solely responsible for integrating and operating the API within Developer's Product and for supporting its End-Users. Any support provided does not create any service level commitment or modify the disclaimers and limitations in these Terms.
**2.6 Monitoring.** Intents Technology reserves the right to monitor Developer's use of the API to ensure compliance with these Terms, enforce rate limits, detect abuse, and improve the API and Services. Intents Technology may collect usage data (including request metadata, IP addresses, and wallet addresses) (“Data”) for security, compliance, and analytics purposes. Intents Technology’s handling of Data is governed by our Privacy Policy , the terms of which are expressly incorporated herein by reference.
**2.7 Know Your Business (KYB).** Intents Technology retains the right to conduct Know Your Business (KYB) verification on any Developer that registers via the Developer Portal or otherwise accesses the API. Intents Technology may require the Developer to provide identification documents, corporate records, beneficial ownership information, and such other information as Intents Technology reasonably determines necessary. Intents Technology may suspend or terminate Developer's access pending satisfactory completion of KYB procedures.
**2.8 Rate Limits.** Intents Technology may set, publish, modify, and enforce rate limits, request limits, concurrency limits, and other usage controls for the API, as stated in the Documentation, the Developer Portal, API response headers, or other notice. Developer shall not exceed or circumvent such limits, and Intents Technology may throttle, queue, reject, suspend, or restrict requests that exceed them or that threaten the security, availability, or performance of the Services.
**2.9 Confidential Swaps.** The API supports both Public Swaps and Confidential Swaps using the same interface; a Developer enables Confidential Swaps for some or all Transactions by setting the applicable confidentiality parameter. Intents Technology determines which mode applies by default and may set, vary, or change the default mode at any time on a prospective basis. A Developer may elect to make available, through the Developer's Product, Public Swaps only, Confidential Swaps only, or both. Intents Technology may make Confidential Swaps available only to Developers it has approved or whitelisted for that purpose, may impose eligibility, KYB, volume, or other conditions, and may grant, condition, suspend, restrict, or withdraw access to Confidential Swaps, and change the scope of their availability (including by extending Confidential Swaps to additional Developers, whether or not Registered Developers), at any time in its sole discretion. Confidential Swaps are subject to Section 7.1 and to the fees set out in Section 6.8 and Schedule 1.
## 3. LICENSE AND INTELLECTUAL PROPERTY
**3.1 License Grant.** Subject to these Terms, Intents Technology hereby grants Developer a limited, non-exclusive, non-sublicensable, non-transferable, and revocable license to use the API and the Services during the Term solely for the purpose of integrating the API into Developer's Product as set forth herein.
**3.2 Third-Party Software.** Developer acknowledges that any open-source software included in the API and Protocol infrastructure may grant Developer additional rights. If there is a conflict between an open-source license and these Terms regarding open-source code, the applicable open-source license terms supersede the conflicting terms of these Terms.
**3.3 Intellectual Property Rights.** All rights, title, and interest in and to the 1Click Service, API, and Services, including their software, source code (except to the extent any component is expressly released under an open-source license), infrastructure, documentation, and related materials, are and shall remain the exclusive property of Intents Technology or (if applicable) its licensors. Except for the express licenses granted in this Section 3, neither Party is granting or assigning to the other Party any right, title, or interest in or to the other Party's Intellectual Property, and each Party reserves all rights in its Intellectual Property.
**3.4 Feedback.** Intents Technology shall have a perpetual, non-exclusive, royalty-free, worldwide license to incorporate into its Intellectual Property or otherwise use any suggestions, enhancement requests, recommendations, or other feedback it receives from Developer ("**Feedback**"). Developer agrees that Intents Technology has no obligation to Developer in connection with any Feedback, and that Intents Technology is free to use any Feedback without attribution or compensation.
**3.5 Marks and Public Statements.** Subject to these Terms, Intents Technology grants Developer a limited, non-exclusive, non-transferable, non-sublicensable, royalty-free license during the Term to use the names and trademarks of Intents Technology and its licensors solely to identify Intents Technology as the technology provider of the API. Developer shall not use such marks in a manner that implies partnership, sponsorship, or endorsement, or in any advertising, marketing, or promotional materials, without Intents Technology's prior written consent. Developer shall ensure that any public statements regarding the Services accurately describe Intents Technology's role solely as a technology provider and disclaim Intents Technology's responsibility for End-User support or relationships.
## 4. DEVELOPER OBLIGATIONS
**4.1 General Obligations.** Developer hereby covenants to:
* (a) not build, operate, or offer any product or service that exposes the API or any portion thereof for use by third parties as a standalone API service, proxy, wrapper, or gateway;
* (b) except as permitted by the terms of any applicable open-source license, not use the Services to build a competitive product, including for the purpose of benchmarking availability, performance, or functionality;
* (c) not disassemble, decompile, or reverse-engineer the software components of the Services or any of Intents Technology's Intellectual Property;
* (d) not interfere with or disrupt the integrity or performance of the Services or seek to circumvent any functionality of the Services;
* (e) not cache, store, or archive API data for more than twenty-four (24) hours, except for static transaction records strictly required for displaying transaction history to End-Users; nor use any API data to train machine-learning models, artificial intelligence systems, or pricing algorithms; nor sell, rent, or commercialize API data on a standalone basis;
* (f) regularly, diligently, and at their sole cost conduct know-your-customer, know-your-business, and anti-money laundering compliance checks (including sanctions checks), screening, and monitoring of Developer's End-Users as required by applicable laws and regulations;
* (g) implement reasonable, risk-based measures to ensure that neither Developer nor its End-Users are (i) sanctioned persons, (ii) owned or controlled by sanctioned persons, or (iii) located in, organized under, or acting for the benefit of any comprehensively sanctioned jurisdiction, in each case in violation of applicable sanctions laws;
* (h) integrate the API in a manner that ensures every Transaction contains the verifiable, unmasked public wallet address of the originating End-User, and shall not direct traffic through a proxy, mixer, tumbler, or intermediary wallet address that obfuscates the ultimate originator;
* (i) maintain clear, prominent disclosures to its End-Users consistent with these Terms, including (without limitation) disclosures regarding the nature of the 1Click Service, risks of on-chain or software-based activity, absence of performance guarantees, and applicable limitations of liability; and
* (j) implement reasonable safeguards to prevent abusive, illegal, or sanction-circumventing use of the API through Developer's Product.
**4.2 End-User Flow-Down Terms.** Developer must maintain and enforce binding terms of use with its End-Users that are no less protective of Intents Technology than these Terms, and which at a minimum:
* (a) release Intents Technology, its Affiliates, and their respective officers, directors, employees, contractors, and agents from all liability;
* (b) disclaim all warranties from Intents Technology (express, implied, or statutory);
* (c) warn that transactions are irreversible and subject to network fees, slippage, bridging and cross-chain transfer risks, and other on-chain risks;
* (d) require End-Users to assume all risks associated with wallet security, blockchain technology, and digital asset transactions;
* (e) prohibit use of the Developer's Product by persons or entities in Prohibited Jurisdictions or on applicable sanctions lists;
* (f) make clear that Intents Technology does not guarantee pricing, execution, or uptime;
* (g) make clear that End-Users have no direct contractual relationship with, or rights against, Intents Technology;
* (h) include any additional provisions reasonably required by Intents Technology from time to time; and
* (i) do not make any representations, warranties, guarantees, or performance commitments on behalf of Intents Technology.
“Prohibited Jurisdictions” means Afghanistan, Belarus, the Central African Republic, Cuba, the Democratic Republic of Congo, Guinea-Bissau, Haiti, Iran, Libya, Mali, Myanmar (Burma), Nicaragua, North Korea (DPRK), Russia, the Crimea, Donetsk, Luhansk, Zaporizhzhia and Kherson regions of Ukraine, Somalia, South Sudan, Sudan, Syria, Venezuela, Yemen, Zimbabwe, and any other country which Intents Technology may bar from all or part of the Services from time to time.
Developer is solely responsible for ensuring its End-User terms comply with this Section 4.2 and all applicable laws. Intents Technology shall have no liability to any End-User arising from or in connection with the Developer's Product.
**4.3 End-User Relationship.** These Terms govern the relationship between Intents Technology and Developer exclusively. Intents Technology has no direct relationship with, or liability to, any End-User. Developer acts as the sole interface for End-Users and bears full responsibility for their use of the Services through Developer's Product.
**4.4 Compliance Screening and Cooperation.** Upon Intents Technology's request, Developer shall promptly complete reasonable compliance and due diligence procedures, including KYC/KYB and sanctions screening, as applicable. Intents Technology may audit Developer's compliance, request updated information, and suspend or terminate access immediately if Developer fails any initial or ongoing screening. Developer shall reasonably cooperate with Intents Technology in responding to any lawful governmental or regulatory request, including by preserving relevant records and providing requested information within five (5) business days. Failure to comply with this Section 4.4 constitutes a material breach.
**4.5 Security Obligations and Incident Response.** Developer shall implement reasonable administrative, physical, and technical safeguards consistent with industry standards to protect the API, access credentials, and End-User data, and shall ensure its integration does not compromise the integrity or security of the API. In the event of an actual or suspected security incident involving the API or Services, Developer shall notify Intents Technology within twenty-four (24) hours, reasonably cooperate with mitigation and remediation efforts, and shall not make any public statement or regulatory notification regarding the incident without Intents Technology's prior written consent unless required by law.
**4.6 UK Financial Promotion.** If Developer makes the API or Services available to End-Users who are residents of the United Kingdom, Developer represents and warrants that it has all necessary licenses and authorizations, if any, to do so and shall ensure that its End-User terms and product disclosures include language to the effect that (a) the Services are provided as a tool for End-Users to interact with the Protocol on their own initiative, with no endorsement or recommendation of cryptocurrency trading activities; (b) Intents Technology is not recommending that End-Users or potential End-Users engage in cryptoasset trading activity; and (c) End-Users should not regard the Services as involving any form of recommendation, invitation, or inducement to deal in cryptoassets.
**4.7 Prohibited Representations.** Developer shall not:
* (a) represent or imply that the 1Click Service is operated by Developer or by any Front-End Interface;
* (b) make any performance guarantees, uptime commitments, or service-level representations regarding the 1Click Service or the API;
* (c) represent that Intents Technology is a broker, exchange, custodian, financial institution, money transmitter, payment service provider, or fiduciary; or
* (d) make any representation regarding Intents Technology, the 1Click Service, or the API that is false, misleading, or inconsistent with these Terms.
## 5. ACCEPTABLE USE
**5.1 Prohibited Conduct.** Developer shall not, and shall not permit its End-Users or any third party acting through Developer’s Product to:
* (a) use the API to flood, spam, or otherwise generate excessive or abusive intent volume that degrades the performance, availability, or reliability of the 1Click Service or the Protocol for other users;
* (b) use the API to facilitate front-running, sandwich attacks, back-running, or other forms of maximal extractable value (MEV) extraction that exploit transaction ordering, timing, or routing through the 1Click Service;
* (c) use the API to grief, manipulate, or interfere with solvers, bridge operators, or other infrastructure participants;
* (d) use the API to circumvent, disable, or interfere with any rate-limiting, access-control, fee-calculation, or security mechanism of the 1Click Service;
* (e) use the API for any illegal purpose, including money laundering, terrorist financing, tax evasion, or fraud;
* (f) use the API to circumvent sanctions, export controls, or trade restrictions; or
* (g) engage in any activity that could damage, disable, overburden, or impair the 1Click Service infrastructure or the Protocol.
**5.2 Remedies.** Intents Technology may, without prior notice and without liability, throttle, suspend, restrict, or terminate Developer’s access to the API if Intents Technology reasonably determines that Developer has violated this Section 5 or any other term of these Terms. Intents Technology’s remedies under this Section are cumulative and do not limit any other remedies available under these Terms or at law.
## 6. INFRASTRUCTURE FEES
**6.1 Applicability.** The terms of this Section 6 and Schedule 1 govern the fee structure applicable to Developer's use of the API. For the avoidance of doubt, if Developer has entered into a Commercial Agreement, the terms of such Commercial Agreement shall control to the extent they conflict with this Section 6 or Schedule 1.
**6.2 Nature of Fees.** All fees under these Terms are infrastructure charges for access to and use of the 1Click Service infrastructure. The Infrastructure Fee is consideration charged by Intents Technology for access to and use of the 1Click Service infrastructure. The Developer’s portion of an AppFee is a contractual amount administered and distributed through the 1Click Service and is not revenue of Intents Technology. Nothing in these Terms creates a partnership, joint venture, profit participation, securities return, or income-participation arrangement between the Parties, and any description in the Documentation of a “revenue share” refers only to the mechanical allocation of the AppFee between the Infrastructure Fee and the Developer’s portion. Intents Technology provides routing and settlement infrastructure; it does not share revenue with, or owe any revenue to, Developer. The Developer’s entitlement under Schedule 1 (in respect of Public Swaps) is limited to its portion of the AppFee (being the AppFee less the Infrastructure Fee), which is the Developer’s own pricing configuration and not revenue of Intents Technology.
**6.3 Fee Calculation and Finality.** All fees are calculated by the 1Click Service's automated logic and are final and binding absent manifest error. Fee amounts, rates, and parameters are determined at the 1CS level and may be modified, updated, or replaced by Intents Technology at any time on a prospective basis. Changes will apply to Transactions authorized after the change becomes effective.
**6.4 Non-Refundable.** All Infrastructure Fees charged by or through the 1Click Service are non-refundable. Fees may apply even if a Transaction fails, is reverted, or does not complete as expected.
**6.5 Tax.** Developer is solely responsible for determining, collecting, reporting, and remitting all applicable taxes arising from fees received under these Terms. Developer agrees to indemnify Intents Technology for any withholding tax, interest, or penalties incurred by Intents Technology resulting from Developer's failure to comply with applicable tax laws. Intents Technology will not withhold taxes from distributions to Developer unless strictly required by a binding order from a governmental authority of competent jurisdiction.
**6.6 Fee Avoidance.** Developer agrees not to circumvent, disable, or interfere with any fee-calculation, metering, or collection mechanism of the 1Click Service. Intents Technology reserves the right to limit, suspend, or permanently terminate Developer’s access for actual or suspected fee avoidance or attempted evasion.
**6.7 Quote Improvement and Capture Share.** Where a Transaction fills at a price more favourable to the End-User than the indicative quote (the difference being “**Quote Improvement**”), a portion of that Quote Improvement (currently fifty percent (50%), as set out in the fee documentation available at [https://docs.near-intents.org/resources/fees](https://docs.near-intents.org/resources/fees)) may be retained by or allocated to Intents Technology, solvers, quoting layers, or distribution channels (the “**Capture Share**”). The Capture Share is a fee retained for operating, routing, and settlement services and may be modified prospectively as set out in that fee documentation. Developer acknowledges that the combined operation of any slippage tolerance and the Capture Share may produce an asymmetric outcome: the End-User bears unfavourable price variance within the applicable slippage tolerance, while all or part of any favourable variance may be retained as the Capture Share. Intents Technology does not represent that any Transaction will execute at the indicative quote, at the best available price, or at a price producing a symmetric distribution of outcomes. Developer shall disclose the existence and operation of Quote Improvement, the Capture Share, and this asymmetric treatment to its End-Users.
**6.8 Fees for Confidential Swaps.** In respect of Confidential Swaps, Intents Technology sets, charges, and retains the Confidential Infrastructure Fee, as further set out in Schedule 1. The AppFee mechanism in Section 6.2 and Schedule 1 does not apply to Confidential Swaps, and there is no default revenue share, AppFee split, or Developer entitlement in respect of Confidential Swaps. The Confidential Infrastructure Fee is determined solely by Intents Technology, is borne by the End-User and deducted from the Transaction at the settlement level, and is charged and retained by Intents Technology for its own account as consideration for access to and use of the 1Click Service infrastructure. Intents Technology may set the Confidential Infrastructure Fee as a fixed amount or on any other basis, may set different fees for different routes, assets, networks, volumes, Developers, or other factors, and may introduce, increase, reduce, waive, or remove the Confidential Infrastructure Fee at any time on a prospective basis. No portion of the Confidential Infrastructure Fee is allocated, distributed, or owed to the Developer. Any fee reduction, rebate, discount, or revenue share in respect of Confidential Swaps, if any, is determined by Intents Technology in its sole discretion and, where offered, is governed solely by a Commercial Agreement; Intents Technology is under no obligation to offer any, and the Developer has no entitlement to any such arrangement except as expressly set out in a Commercial Agreement. For the avoidance of doubt, configuring, setting, transmitting, or otherwise using any parameter made available through the API (including any rebate, fee, or fee-destination parameter) does not create, evidence, or entitle the Developer to any rebate, revenue share, or other payment, and any such entitlement arises only under a Commercial Agreement.
## 7. SPECIAL ASSET TYPES AND DISCLAIMERS
Developer acknowledges and agrees that Transactions routed through the API may involve the following special categories, each of which carries distinct risks and is subject to the additional terms set forth in this Section 7.
**7.1 Confidential Intents.** The API supports Confidential Swaps, being confidential intents that operate on a separate execution environment known as the NEAR Private Shard. Intents Technology makes no warranty that confidential intents will provide complete or uninterrupted confidentiality. Confidentiality depends on technical assumptions and the correct operation of third-party validator nodes, and may be compromised by advances in cryptography, node failures or collusion, software vulnerabilities, on-chain settlement analysis, regulatory disclosure requirements, or other factors outside Intents Technology's control. Confidential Swaps remain subject to applicable transaction screening/blocking/freezing, sanctions compliance, and KYT controls; confidential execution does not exempt Transactions from legal requirements. Confidential Swaps are made available only as described in Section 2.9, and the fees for Confidential Swaps are as set out in Section 6.8 and Schedule 1.
**7.2 Real-World Assets (RWAs).** The API may facilitate access to Real-World Assets issued, structured, backed, and administered by independent third-party RWA issuers. Intents Technology does not issue, back, guarantee, underwrite, or sponsor any RWA, and does not verify or audit any issuer's asset backing, reserves, collateralization, or redemption mechanisms. Intents Technology does not act as a broker, dealer, investment adviser, custodian, or distributor of any RWA. RWAs may be classified as securities, asset-referenced tokens, derivatives, or other regulated instruments in one or more jurisdictions. Developer is solely responsible for determining the regulatory treatment of any RWA accessible through Developer's Product and for ensuring its End-Users are appropriately warned.
**7.3 Fiat Onramps and Offramps.** The API may interface with third-party fiat-to-crypto and crypto-to-fiat conversion services. Intents Technology does not handle, hold, transmit, custody, or access fiat funds at any point. Intents Technology does not perform any fiat-to-crypto or crypto-to-fiat conversion. Where the API presents a fiat-to-crypto or crypto-to-fiat flow, the transaction comprises two distinct legs: (a) a fiat leg, performed entirely by the third-party provider; and (b) a crypto leg, routed through the Protocol for on-chain execution and settlement. Intents Technology's role is limited to the crypto leg. Intents Technology does not act as a money transmitter, payment service provider, broker, or financial intermediary with respect to fiat services. Developer's End-Users' relationships with fiat providers are governed by those providers' own terms.
**7.4 Yield-Bearing Assets.** The API may facilitate access to yield-bearing assets, including tokens that generate yield through staking, lending, liquidity provision, or real-world income. All yield-bearing assets are created, issued, and managed by independent third parties. Intents Technology does not issue, manage, guarantee, or underwrite any yield-bearing asset or the yield generated thereby, and does not operate any staking, lending, or yield-generation protocol. Intents Technology makes no warranty or guarantee regarding the rate, amount, timing, or continuity of any yield, or the preservation of principal.
**7.5 Yield Access (Including "Earn" or "1ClickEarn").** The API may enable access to yield-generating opportunities through features such as "Earn" or "1ClickEarn." Intents Technology's role is limited to providing routing functionality and does not include discretionary management or investment decision-making. Intents Technology makes no warranty or guarantee regarding yield rates, return of principal, or the solvency of any third-party protocol.
**7.6 Developer's Obligations Regarding Special Assets.** Developer shall ensure that its End-User terms include appropriate disclosures and risk warnings in respect of each category of special asset type that is accessible through Developer's Product. Developer shall not make representations regarding any special asset type that are inconsistent with this Section 7.
**7.7 Bridging and Cross-Chain Transfers.** Depositing assets into, or withdrawing or transferring assets to or from, certain blockchain networks in connection with a Transaction may require assets to be routed through one or more cross-chain bridges, which may include the PoA Bridge (developed and operated by Intents Technology or its Affiliates) and third-party bridges such as OmniBridge or HOT Bridge operated by independent parties under their own terms. Developer acknowledges and agrees that:
* (a) while a deposit, withdrawal, or transfer is in progress, assets may be held, locked, or controlled within the relevant bridge's infrastructure (including, in the case of the PoA Bridge, by its validators or authorities) until the transfer completes;
* (b) bridging is inherently higher-risk than on-chain settlement and may result in processing delays; failed, partial, or stuck transfers; smart-contract failure, bug, or exploit; validator, authority, or relayer failure, downtime, compromise, or misconduct; chain reorganisation or consensus failure; changes to fees or to supported assets and networks; and the irreversible and permanent loss of assets sent to an incorrect or unsupported address or network, or with a missing or incorrect memo, tag, or metadata, in each case borne by the Developer and its End-Users;
* (c) the PoA Bridge and any other bridge are provided "AS IS" and "AS AVAILABLE", without warranty of any kind, and, to the maximum extent permitted by applicable law, Intents Technology does not guarantee, and shall have no liability in respect of, the availability, uptime, continuity, accuracy, finality, or performance of any bridge, or any loss, delay, failure, lock-up, or asset movement arising from or in connection with bridging;
* (d) Intents Technology has no obligation to reverse, retry, refund, or recover any bridged Transaction, although it may attempt to assist with recovery in its sole discretion;
* (e) the Developer's and its End-Users' use of and reliance on the PoA Bridge in connection with the API or 1Click Service is governed by these Terms, including the disclaimers in Section 14 and the limitations of liability in Section 15, without prejudice to any separate terms of service that may apply to direct or standalone use of the PoA Bridge;
* (f) bridging and cross-chain transfers are subject to applicable transaction screening, sanctions, and KYT/AML controls and may be delayed, blocked, frozen, or rejected on that basis; and
* (g) Developer is solely responsible for ensuring that its End-User terms include appropriate disclosures and risk warnings regarding bridging, cross-chain transfers, and the PoA Bridge consistent with Sections 4.2 and 7.6, and shall not make any representation regarding any bridge that is inconsistent with this Section 7.
## 8. DEVELOPER PORTAL
**8.1 Account Registration.** To access the API, Developer must register on the Developer Portal and provide accurate identification and business information as required. Developer is responsible for maintaining the confidentiality of its account credentials and for all activities that occur under its account.
**8.2 Acceptable Use.** Developer shall use the Developer Portal solely for purposes authorized under these Terms. Developer shall not:
* (a) access or attempt to access another Developer's account or API Keys;
* (b) use the Developer Portal to distribute malware or engage in any malicious activity;
* (c) probe, scan, or test the vulnerability of the Developer Portal; or
* (d) interfere with the proper functioning of the Developer Portal.
**8.3 Data Accuracy.** Developer shall ensure that all information provided through the Developer Portal is accurate, complete, and current. Intents Technology may rely on such information for compliance, billing, and communication purposes and shall have no liability for consequences arising from inaccurate Developer-provided information.
## 9. ELIGIBILITY AND PROHIBITED LOCALITIES
**9.1 Prohibited Jurisdictions.** The API is not intended for use by persons or entities located in, established in, or resident of the following jurisdictions (or any other jurisdiction on applicable sanctions lists): Afghanistan, Belarus, Central African Republic, Cuba, Democratic Republic of Congo, Guinea-Bissau, Haiti, Iran, Libya, Mali, Myanmar (Burma), Nicaragua, North Korea (DPRK), Russia, the Crimea, Donetsk, Luhansk, Zaporizhzhia, and Kherson regions, and the city of Sevastopol, of occupied Ukraine, Somalia, South Sudan, Sudan, Syria, Venezuela (including certain SDNs connected with the Maduro regime), Yemen, or Zimbabwe, and such other jurisdictions as Intents Technology may in its sole and absolute discretion decide.
**9.2 Sanctions Compliance.** Developer must not use the API if it is on, or controlled by a party on, any U.S., EU, UK, or UN sanctions list. Developer must not use any technology (including VPNs) to circumvent these restrictions.
**9.3 Age and Capacity.** Developer represents that it is either: (a) an entity duly organised and validly existing under applicable law; or (b) an individual who is at least 18 years of age (or the age of legal majority in the applicable jurisdiction) and has the legal capacity to enter into a binding agreement. If Developer is an individual under the age of 18, Developer must not use the API.
**9.4 Developer Responsibility.** Developer is solely responsible for ensuring that its End-Users comply with eligibility requirements and are not located in Prohibited Jurisdictions or on applicable sanctions lists.
## 10. REGULATORY STATUS AND COMPLIANCE
**10.1 Regulatory Status.** Intents Technology is not licensed or regulated by any financial regulatory authority to provide regulated financial services, and the API is not offered as, and is not intended to constitute, regulated financial services.
**10.2 Developer Compliance.** It is Developer's responsibility to determine whether its use of the API, and any services it offers through the Developer's Product, are permitted under the laws and regulations applicable to Developer and its End-Users. Developer is solely responsible for ensuring compliance with all laws and regulations applicable to it (including sanctions, AML/CFT, consumer protection, tax, and securities/derivatives rules or any other applicable law or regulation).
**10.3 Front-End Interface Terms.** If the API is accessed by End-Users through a Front-End Interface, such End-Users may also be subject to that Front-End Interface’s terms of service. Intents Technology shall have no liability for any losses, damages, or claims arising from or related to third-party Front-End Interfaces, integrations, or external dependencies used in connection with the Services.
**10.4 No Representations.** Intents Technology makes no representations regarding how any authority may characterize the 1Click Service or related activities under applicable laws or regulations. Developer bears the risk that authorities may take positions inconsistent with Intents Technology's view, and, to the maximum extent permitted by applicable law, Developer waives, releases, and covenants not to sue Intents Technology for any claims arising from such positions or actions.
## 11. REPRESENTATIONS AND WARRANTIES
**11.1 Mutual.** Each Party represents and warrants that it has full power and authority to enter into these Terms.
**11.2 Developer Specific.** Developer represents and warrants that:
* (a) it holds all necessary regulatory licenses, permissions, and registrations required to operate the Developer’s Product in each jurisdiction in which it operates, and will comply with all laws applicable to its receipt or use of the API and the Services;
* (b) it is a sophisticated party with sufficient knowledge and experience in blockchain technologies and digital assets to understand the inherent risks (including volatility, smart contract failures, and regulatory uncertainty) associated with the Services, and it voluntarily assumes such risks;
* (c) it is not insolvent, in bankruptcy proceedings, or unable to pay its debts as they become due;
* (d) neither Developer nor its beneficial owners are included on any sanctions list maintained by the United States, European Union, United Kingdom, or United Nations, and Developer is currently in compliance with all applicable anti-money laundering and counter-terrorist financing laws; and
* (e) it has not been the subject of any enforcement action, investigation, or proceeding by any governmental authority in connection with its use of blockchain technology or digital assets that would materially affect its ability to perform its obligations under these Terms.
## 12. NO SERVICE LEVELS; EXPERIMENTAL INFRASTRUCTURE
**12.1 No Uptime Commitment.** The API and Services are provided "AS IS" and "AS AVAILABLE." Intents Technology does not guarantee, and shall have no liability in respect of, availability, uptime, continuity, or error-free operation of the API, the 1Click Service, or any related infrastructure. Intents Technology does not undertake to provide maintenance, support, or any service-level commitments of any kind.
**12.2 Experimental and Evolving Infrastructure.** Developer acknowledges that the 1Click Service is experimental infrastructure that may be upgraded, modified, interrupted, suspended, or discontinued at any time without notice. Intents Technology reserves the right to modify the architecture, endpoints, parameters, and functionality of the API at its sole discretion.
**12.3 No Duty to Monitor.** Intents Technology has no obligation to monitor, review, or audit individual Transactions processed through the API. Developer acknowledges that Intents Technology does not verify the legality, suitability, or taxation of any user activity.
**12.4 Transaction Finality and Recovery.** Transactions routed through the API are subject to the finality, settlement, and execution mechanics of the underlying Protocol, solvers, bridges, and blockchain networks, none of which are controlled by Intents Technology. Intents Technology has no obligation to reverse, retry, refund, or recover any Transaction that fails, is delayed, settles at an unexpected price, or does not complete. Where a Transaction involves a Third-Party Component that fails mid-execution, the Developer and its End-Users bear the risk of partial execution, asset loss, or permanent lock-up. Where a Transaction involves the PoA Bridge, the terms, disclaimers, and limitations applicable to the PoA Bridge are as set out in these Terms (including Section 7.7); Intents Technology’s liability in respect of the PoA Bridge is governed by these Terms, including this Section 12 and Sections 7.7, 14, and 15. Intents Technology may, in its sole discretion, attempt to assist with recovery but has no obligation to do so. Without limiting the foregoing, Intents Technology will not consider a recovery request that it reasonably determines arises from Developer or End-User error where the USD value of the affected assets, as reasonably determined by Intents Technology at the time of the relevant transfer, was less than USD 300. Requests at or above this threshold remain entirely discretionary. Where Intents Technology elects to provide recovery assistance, it generally aims to complete the recovery process within 14 days after approving the request and receiving all required information. This target is indicative only, is subject to technical, legal and commercial feasibility, and does not constitute a commitment that recovery will be successful or completed within that timeframe.
**12.5 No Performance Guarantees.** Intents Technology makes no guarantees regarding Transaction execution speed, success rates, pricing accuracy, slippage, or the availability or performance of any Third-Party Component or the PoA Bridge. Execution results may differ from estimates due to market conditions, network congestion, and other factors outside Intents Technology's control.
**12.6 Quote and Execution Mechanics.** Price information made available through the API is indicative only and non-binding. An indicative quote may be generated, ranked, and transmitted through one or more layers (which may include the wallet, application, or aggregator interface through which an End-User accesses the Developer’s Product, one or more downstream aggregators, the 1CS routing layer, and the solver network) (the “**Quoting Layers**”), each of which may apply its own ranking and selection criteria. Solvers and Quoting Layers compete for routing priority and may submit indicative pricing, timing, or availability that proves more favourable than the conditions ultimately available at execution. Execution is a separate process undertaken after a Transaction is authorised and may involve one or more auctions, solicitations, or matching steps among solvers; the indicative quote is not reserved or locked, except as a reference point for any applicable slippage tolerance, and a Transaction may fill at a different price subject to that tolerance. Except to the extent non-waivable applicable law requires otherwise, Intents Technology does not undertake “best execution,” “best price,” or any equivalent standard, and makes no representation that any Quoting Layer or execution process maximises value to the End-User. Except for technology, interfaces, parameters, or contracts that Intents Technology itself operates or makes available, Intents Technology does not operate, control, or audit third-party solvers or Quoting Layers.
## 13. CONFIDENTIALITY
Each Party will use reasonable care to protect the other Party's Confidential Information and may disclose it only to its Affiliates, employees, contractors, professional advisors, auditors, and service providers who have a legitimate need to know and are bound by confidentiality obligations at least as protective as these Terms. Confidential Information may be disclosed if required by law, subpoena, court order, or governmental authority, provided the recipient gives advance notice to the discloser where legally permitted and reasonably cooperates, at the discloser's expense, in any effort to contest the disclosure. These obligations do not apply to information that is publicly available through no fault of the recipient, was lawfully known to the recipient without restriction before disclosure, was lawfully received from a third party without breach of confidentiality, or was independently developed without use of the Confidential Information. This Section 13 survives termination of these Terms for three (3) years.
## 14. DISCLAIMER OF WARRANTIES AND ASSUMPTION OF RISK
**14.1 Third-Party Components.** Developer expressly acknowledges and agrees that the functionality, performance, and availability of the API depends on decentralized blockchain networks, open-source software, third-party infrastructure, oracles, validators, liquidity sources, and other network participants, which are outside the control of Intents Technology. Intents Technology makes no representation or warranty of any kind regarding their operation, availability, security, accuracy, or continued compatibility, including in relation to transaction finality, network fees, congestion, forks, or other consensus-related events. For the avoidance of doubt, the disclaimers and assumptions of risk in this Section 14 apply equally to the PoA Bridge, without prejudice to any separate terms of service that may apply to direct or standalone use of the PoA Bridge.
**14.2 No Reliance on Price Data.** Any price data, exchange rates, or token values provided via the API are for informational purposes only. Intents Technology does not control, and accepts no liability for: (a) execution quality; (b) liquidity conditions; (c) order routing; (d) slippage; (e) network timing delays; or (f) any dispersion between price data provided by the API and actual executable prices on-chain. Developer shall not represent to End-Users that price data guarantees an executable price.
**14.3 Release.** To the fullest extent permitted by law, Developer hereby releases and forever discharges Intents Technology, its Affiliates, and their respective officers, directors, employees, contractors, and agents from any and all claims, losses, liabilities, or damages arising out of or related to Developer's access to or use of the API, the Services, or the PoA Bridge.
## 15. LIMITATION OF LIABILITY
**15.1** TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL INTENTS TECHNOLOGY OR ITS AFFILIATES BE LIABLE FOR ANY INDIRECT, SPECIAL, INCIDENTAL, EXEMPLARY, PUNITIVE, OR CONSEQUENTIAL DAMAGES OF ANY KIND, INCLUDING BUT NOT LIMITED TO DAMAGES FOR TRADING LOSSES, EXECUTION DISPERSION, SLIPPAGE, FAILED TRANSACTIONS, LOSS OF PROFITS, GOODWILL, USE, DATA, OR OTHER INTANGIBLE LOSSES; DAMAGES ARISING OUT OF OR RELATING TO THE USE OR INABILITY TO USE THE SERVICES (INCLUDING THE POA BRIDGE); INTERRUPTION OR WORK STOPPAGE; DATA LOSS OR CORRUPTION; FAILURE TO CONNECT; HACKING, TAMPERING, OR UNAUTHORIZED ACCESS; OR ANY BUGS, VIRUSES, OR HARMFUL CODE, REGARDLESS OF THE LEGAL THEORY AND EVEN IF INTENTS TECHNOLOGY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
**15.2** NOTHING IN THESE TERMS EXCLUDES OR LIMITS LIABILITY THAT CANNOT BE EXCLUDED OR LIMITED UNDER APPLICABLE LAW (INCLUDING LIABILITY FOR FRAUD, WILFUL MISCONDUCT, OR DEATH OR PERSONAL INJURY CAUSED BY NEGLIGENCE). SUBJECT TO THE FOREGOING, INTENTS TECHNOLOGY'S TOTAL AGGREGATE LIABILITY TO DEVELOPER FOR ANY AND ALL CLAIMS AND DAMAGES ARISING OUT OF OR RELATED TO THESE TERMS SHALL NOT EXCEED THE GREATER OF: (A) USD \$1,000.00; OR (B) THE INFRASTRUCTURE FEES ACTUALLY RETAINED BY INTENTS TECHNOLOGY FROM DEVELOPER'S TRANSACTIONS DURING THE TWELVE (12) MONTHS IMMEDIATELY PRECEDING THE EVENT GIVING RISE TO THE CLAIM.
## 16. INDEMNITY
**16.1 Developer Indemnity.** Developer shall indemnify, defend, and hold harmless Intents Technology, its Affiliates, and their respective directors, officers, employees, contractors, and agents (together, the "**Indemnified Parties**") from and against all claims, demands, actions, proceedings, damages, losses, liabilities, costs, and expenses (including reasonable legal fees) arising out of or related to:
* (a) Developer's access to or use of the API, the Services, or the PoA Bridge;
* (b) Developer's breach of these Terms;
* (c) Developer's violation of any applicable law, rule, or regulation (including AML/CFT and sanctions laws);
* (d) Developer's violation of any rights of a third party;
* (e) any act, omission, claim, demand, or proceeding brought by any End-User of Developer's Product or by any downstream platform, counterparty, or third party arising from or related to the Developer's Product, Developer's integration with the API, Developer's representations or omissions, Developer's user interface, or any other aspect of Developer's business;
* (f) any failure by Developer to maintain End-User terms that comply with Section 4.2;
* (g) any claim that Developer's Product infringes any third-party Intellectual Property right; and
* (h) any tax liability, penalty, or assessment arising from Developer's failure to comply with applicable tax laws.
**16.2 Control of Defense.** The Indemnified Parties may, at their sole discretion, assume the defense and control of any matter subject to indemnification by Developer. Developer agrees to cooperate with any such defense.
## 17. TERM AND TERMINATION
**17.1 Term.** These Terms commence on the Effective Date and continue until terminated.
**17.2 Termination by Developer.** Developer may terminate at any time by ceasing use of the Services and providing written notice to Intents Technology.
**17.3 Termination by Intents Technology.** Intents Technology may suspend or terminate these Terms, any rights granted herein, and/or Developer's access to the API at any time, for any reason or no reason, with or without notice to Developer.
**17.4 Immediate Remedies.** Intents Technology may, without liability, immediately suspend, restrict, or revoke Developer's API Keys and access to the Services, or terminate these Terms, if:
* (a) Developer breaches any provision of these Terms;
* (b) Developer becomes insolvent or ceases operations;
* (c) Intents Technology reasonably suspects Developer has violated applicable laws (including, without limitation, AML and sanctions laws);
* (d) Intents Technology determines Developer's use of the Services creates a security vulnerability, operational instability, reputational harm, or regulatory risk for Intents Technology;
* (e) Developer fails to satisfy or maintain compliance with KYB or other compliance procedures; or
* (f) Intents Technology determines, in its sole discretion, that termination or suspension is necessary for legal, regulatory, operational, or security reasons.
**17.5 Effect of Termination.** Upon termination: (a) all licenses granted by Intents Technology immediately expire; (b) Developer shall immediately cease use of the API and delete all API Keys; and (c) Intents Technology shall pay out the Developer’s accrued portion of the AppFee in respect of Public Swaps (being the AppFee less the Infrastructure Fee) in accordance with Schedule 1, except that Intents Technology may withhold payout if termination was for cause (including fraud, sanctions violations, or breach).
**17.6 Survival.** Sections 1, 3 (Intellectual Property), 4 (Developer Obligations), 5 (Acceptable Use), 6 (Infrastructure Fees, solely for fees accrued prior to termination), 7 (Special Asset Disclaimers), 10 (Regulatory Status and Compliance), 11 (Representations and Warranties), 12 (No Service Levels), 13 (Confidentiality), 14 (Disclaimer of Warranties), 15 (Limitation of Liability), 16 (Indemnity), 18 (Governing Law), 19 (No Third-Party Beneficiaries), 20 (General), and Schedule 1 (in respect of fees accrued, payout, fee disputes, and additional fees only), shall survive termination of this Agreement.
## 18. GOVERNING LAW AND DISPUTES
**18.1 Governing Law.** These Terms are governed by and construed in accordance with the laws of the British Virgin Islands, without regard to conflict-of-law principles.
**18.2 Informal Resolution.** Before initiating arbitration, the Parties agree to use reasonable good-faith efforts to resolve any dispute informally within thirty (30) days of written notice.
**18.3 Arbitration.** If not resolved informally, any dispute arising out of or in connection with these Terms shall be referred to and finally resolved by arbitration administered by the BVI International Arbitration Centre under the BVIIAC Administered Arbitration Rules in force when the relevant notice of arbitration is submitted (“**BVIIAC Rules**”), which Rules are deemed to be incorporated by reference. The seat of arbitration shall be the British Virgin Islands. The tribunal shall consist of a single arbitrator appointed in accordance with the BVIIAC Rules. The language of the arbitration shall be English.
**18.4 Emergency Arbitrator.** Either Party may apply for emergency relief under the emergency arbitrator provisions of the BVIIAC Rules before the constitution of the tribunal. The Parties agree that the Emergency Arbitrator shall have the power to order any interim or conservatory measure that the tribunal could order, including injunctions, asset preservation orders, and orders to maintain the status quo.
**18.5 Class Action Waiver.** ANY ARBITRATION WILL BE ON AN INDIVIDUAL BASIS; CLASS ARBITRATION AND CLASS ACTIONS ARE WAIVED. Nothing in these Terms waives any right or remedy that cannot be waived under applicable law. If any portion of this Section 18.5 is held unenforceable, that portion shall be severed to the minimum extent necessary and the remainder of these Terms, including the agreement to arbitrate, shall remain in full force and effect.
**18.6 Limitation Period.** Any claim arising out of or related to these Terms must be commenced within twelve (12) months after the cause of action accrues. Any claim not brought within such period is permanently barred.
**18.7 Injunctive Relief.** Notwithstanding the foregoing, either Party may seek interim or injunctive relief from the courts of the British Virgin Islands where necessary to prevent imminent harm, preserve the status quo, or protect Intellectual Property or Confidential Information, pending final resolution by arbitration. In addition, Intents Technology may seek interim, conservatory, emergency, or injunctive relief in any other court of competent jurisdiction, including where Developer or its relevant assets, systems, or data are located.
## 19. NO THIRD-PARTY BENEFICIARIES
Nothing in these Terms shall be deemed to create any third-party beneficiary rights in any person or entity, including (without limitation) End-Users of the Developer's Product, downstream platforms, counterparties, solvers, liquidity providers, or any other person or entity. No End-User, counterparty, or downstream platform shall have any right to enforce any term of these Terms.
## 20. GENERAL
**20.1 Force Majeure.** Neither Party shall be liable for any delay or failure in performance resulting from events beyond its reasonable control (each, a “**Force Majeure Event**”), including acts of God, government actions, war, labour disputes, power or network failures, blockchain network outages, smart contract bugs or exploits, regulatory action, sanctions designations, third-party service disruptions, and Protocol Events. A “Protocol Event” means any chain halt, consensus failure, hard fork, validator set failure, protocol-level upgrade or migration, smart contract vulnerability or exploit, or material change to the finality or settlement mechanics of any blockchain network on which the Protocol operates, in each case to the extent not caused by the affected Party’s wilful act or omission. If a Force Majeure Event (including a Protocol Event) continues for more than thirty (30) days and materially prevents performance, either Party may terminate these Terms on written notice without liability (other than for accrued obligations).
**20.2 Commercial Agreements.** Where Developer has entered into a Commercial Agreement, such agreement shall prevail over these Terms to the extent of any inconsistency.
**20.3 Data.** The 1Click Service does not request, store, or have access to private keys. Intents Technology may process limited operational metadata (including logs and diagnostics) to operate and improve the Services and to address abuse, security, or legal compliance. On-chain activity is public by design. To the extent that either Party processes personal data (including pseudonymous data such as public wallet addresses, IP addresses, or device identifiers) in connection with the Services, the Parties agree that: (a) each Party is an independent controller of any personal data it processes in connection with these Terms, and neither Party processes personal data on behalf of the other unless the Parties execute a separate data processing agreement; (b) each Party shall comply with all applicable data protection laws (including, where applicable, the EU General Data Protection Regulation, the UK Data Protection Act 2018, and the Swiss Federal Act on Data Protection) in respect of its own processing activities; (c) Intents Technology’s processing of operational metadata under Section 20.3 is carried out for the legitimate purposes of operating, securing, and improving the Services, and Intents Technology shall implement appropriate technical and organisational measures to protect such data; (d) Developer is solely responsible for providing any required notices to, and obtaining any required consents from, End-Users in respect of personal data collected or processed through Developer’s Product; and (e) Developer shall not transmit to Intents Technology any personal data beyond what is strictly necessary for the operation of the API, and shall not use the API to process special category data. If either Party reasonably determines that the processing arrangements require a separate data processing agreement, the Parties shall negotiate such agreement in good faith. Upon termination, each Party shall, within a reasonable period, delete or return the other Party’s Confidential Information and personal data in its possession or control, except that each Party may retain copies required for legal, tax, audit, regulatory, security, or compliance purposes, and Intents Technology may retain operational metadata, logs, and compliance records for as long as reasonably necessary to operate, secure, and defend the Services and to comply with applicable law.
**20.4 Notices.**
Intents Technology may provide any notice to you under these Terms using commercially reasonable means, including using public communication channels and/or via Developer Portal Notification. Notices we provide by using public communication channels will be effective upon posting. If you have any questions about these Terms, please contact us at [legal@near.com](mailto:legal@near.com).
Law enforcement requests should be directed to the [law enforcement request portal on Kodex](https://app.kodexglobal.com/nearintents/signin).
**20.5 Assignment.** Developer may not assign or transfer these Terms without Intents Technology’s prior written consent. Intents Technology may freely assign or transfer these Terms, in whole or in part, without Developer’s consent. These Terms bind and benefit the Parties and their permitted successors and assigns.
**20.6 Severability.** If any provision of these Terms is held invalid or unenforceable, the remaining provisions will continue in full force.
**20.7 No Waiver.** No waiver by Intents Technology of any term shall be deemed a further or continuing waiver.
**20.8 No Fiduciary Duties.** These Terms do not create any fiduciary, agency, partnership, joint venture, or employment relationship between the Parties. To the fullest extent permitted by applicable law, any fiduciary duties that might otherwise arise are irrevocably disclaimed, waived, and eliminated. Intents Technology owes no duties to Developer or any End-User beyond those expressly stated in these Terms.
**20.9 No Insurance or Compensation Scheme.** The Services are not covered by any deposit protection scheme, government insurance programme, investor compensation fund, or other insurance arrangement. Intents Technology does not maintain insurance for the benefit of Developer or any End-User against losses arising from the use of the API or Services.
**20.10 Entire Agreement.** These Terms (including all Schedules) constitute the entire agreement between the Parties regarding the API and supersede all prior or contemporaneous communications, except as modified by any Commercial Agreement.
**20.11 Security Incidents.** In the event of a material security incident affecting the API or Services as provisioned to the Developer, Intents Technology will use commercially reasonable efforts to notify affected Developers via email or Developer Portal notification within a reasonable timeframe. Intents Technology may, in its sole discretion, suspend, pause, or restrict access to the API or Services during any security incident. Intents Technology has no obligation to make Developer or any End-User whole for losses resulting from a security incident, and nothing in this Section 20.11 creates any liability not otherwise established by these Terms.
**20.12 Changes to these Terms.** Intents Technology may change these Terms at any time on notice. It may give notice by posting the updated Terms in the Developer Portal, sending an email to any address the Developer has provided, by a Developer Portal notification, or by any other reasonable means. The Developer may review the current version of these Terms at any time in the Developer Portal. The version in effect at the time of the Developer's access to or use of the API applies, and the updated Terms bind the Developer in respect of access or use on or after the date indicated in the updated Terms. If the Developer does not agree to the updated Terms, it must stop accessing and using the API and the Services. The Developer's continued access to or use of the API or Services after that date constitutes acceptance of the updated Terms.
## SCHEDULE 1 — INFRASTRUCTURE FEE SCHEDULE
## 1. GENERAL
1.1 All fees under this Schedule are infrastructure charges for access to and use of the 1Click Service infrastructure. No fee described in this Schedule constitutes revenue sharing, profit participation, or any form of income allocation. References to Sections in this Schedule are references to sections of this Schedule unless stated otherwise. This Schedule governs fees for Public Swaps (Sections 2 to 5) and for Confidential Swaps (Section 6).
1.2 All fees are calculated by the 1Click Service's automated logic and are final and binding. In the case of manifest error, Intents Technology may refund any excess fees collected.
1.3 All fees are non-refundable.
1.4 Intents Technology may modify, update, or replace any fee parameter, rate, threshold, or mechanic set forth in this Schedule at any time on a prospective basis.
1.5 A protocol or smart contract fee may be levied by the smart contracts underlying the Protocol itself. Such fees are in addition to the fees described in this Schedule and are not within the scope of this Schedule, as they are independent to the 1Click Service.
1.6 Developer acknowledges that the on-chain verifier smart contract underlying the Protocol is governed by a decentralized autonomous organization and by administrative roles defined in the smart-contract system. Such roles may have authority to modify protocol fee parameters, change fee-recipient addresses, pause or unpause functionality, lock accounts, transfer or withdraw balances under applicable contract procedures, and otherwise administer the verifier smart contract. The protocol fee parameter is bounded by code only at not greater than one hundred percent (100%), and there is no lower economic cap in these Terms. Such changes may take effect on-chain without prior individual notice. These powers are governed by the underlying protocol and are not controlled by Intents Technology, and Intents Technology does not guarantee that any protocol-governance action will align with the interests of Developer or any End-User.
1.7 The Infrastructure Fees may be directed by the 1Click Service to a designated fee recipient in connection with NEAR ecosystem infrastructure, development and growth activities.
## 2. UNREGISTERED DEVELOPER FEE STRUCTURE
2.1 Unregistered Developers are subject to an Infrastructure Fee of not less than 20 basis points on all Public Swap Transaction volume routed through the 1Click Service via the Developer’s Product, or such other level as is specified in the Documentation from time to time.
2.2 Intents Technology may modify the Infrastructure Fee applicable to Unregistered Developers from time to time, with prospective effect only. The Unregistered Developer Infrastructure Fee may be modified to include different rates, thresholds, or parameters based on various factors including (without limitation) the transaction route, asset type, volume, or the specific integration partner or channel through which the transaction is sourced.
## 3. REGISTERED DEVELOPER FEE STRUCTURE
3.1 Registered Developers are subject to the following fee structure in respect of Public Swaps:
* (a) Section 2 of this Schedule shall not apply to Registered Developers (save as set out in Section 3.1(f) below);
* (b) the Developer shall configure a fee parameter within its integration with the 1Click Service, currently referred to as the "**AppFee**" (or any successor, replacement, or functionally equivalent parameter). The AppFee is determined by the Developer, implemented by the 1Click Service, and forms part of the Developer's own pricing configuration for End-User's access to the Protocol via the Developer's Product through the 1Click Service. The AppFee may be configured with different rates, thresholds, or parameters based on various factors including (without limitation) the transaction route, asset type, or volume;
* (c) the 1Click Service shall charge an Infrastructure Fee equal to 50% of the AppFee (or such other percentage or rate as the Parties may agree in writing, as reflected in the Developer Portal or a Commercial Agreement);
* (d) the Developer shall not impose any additional front-end fees, surcharges, pre-charges, or other fees or charges of any kind on End-Users in connection with Public Swap Transactions routed through the 1Click Service, whether directly or indirectly, that are separate from or in addition to the AppFee. Intents Technology shall have the right to audit, verify, and monitor compliance with this restriction, and the Developer shall cooperate with any such audit or verification;
* (e) the Developer shall set the AppFee within 14 days of the date on which the Developer’s Product first routes Transactions through the 1Click Service. Failure to set the AppFee within this period shall entitle Intents Technology to apply the Infrastructure Fee applicable to Unregistered Developers from time to time under Section 2 until such time as the AppFee is set; and
* (f) Intents Technology reserves the right to switch the Developer to the Unregistered Developer Infrastructure Fee under Section 2 in its sole and absolute discretion, without notice, for any reason or no reason, including, without limitation, if any of the following circumstances arise: (i) the Developer sets the AppFee below 10 basis points; (ii) the Developer levies any front-end or similar fees in breach of Section 3.1(d) above; (iii) the Developer fails to set the AppFee within the period specified in Section 3.1(e) above; or (iv) the Developer commits any other material breach of these Terms.
3.2 The fee structure set out in this Section 3 may be overridden by a separate Commercial Agreement.
## 4. DISTRIBUTION MECHANICS
4.1 Where a Registered Developer has set an AppFee, the Developer’s portion of the AppFee (being the AppFee less the Infrastructure Fee) will, where technically feasible, be distributed automatically to the wallet address designated by Developer (the "**Developer Wallet**") as fees accrue, at a frequency determined by Intents Technology and/or the underlying infrastructure.
4.2 If automatic distribution is not implemented, distribution may occur periodically, including on a monthly basis, as determined by Intents Technology. In such cases, Intents Technology shall have no obligation to distribute the Developer’s share of AppFee if the accrued distributable amount for the applicable period is less than USD \$1,000.00 (the "**Payout Threshold**"). Amounts below the Payout Threshold shall roll over to the subsequent period. The applicable distribution mechanics, including (without limitation) frequency and method, may be varied by agreement between the Parties as reflected in the Developer Portal or a Commercial Agreement.
4.3 The Developer’s share of AppFee may be distributed to Developer in NEAR tokens, stablecoins native to NEAR Protocol (including USDC or USDT on NEAR), or another digital asset determined at the API level from time to time. Fees may be converted, in whole or in part, into a single digital asset prior to distribution. The timing, frequency, exchange route, and method of conversion are determined solely by Intents Technology. Intents Technology assumes no liability for exchange rates, execution timing, or any loss of value resulting from market volatility or illiquidity between fee collection and conversion.
**4.4 Payment Administration.** To the extent the 1Click Service receives, records, converts, aggregates, holds, or distributes any Developer portion of an AppFee, Intents Technology acts solely as a limited payment administrator for the purpose of calculating and distributing that amount under these Terms. No trust, escrow, fiduciary relationship, custodial account, agency, partnership, or deposit-taking arrangement is created. Developer has a contractual right only to receive its portion of the AppFee in accordance with this Schedule, subject to the Payout Threshold, conversion mechanics, withholding, set-off, compliance review, and the other rights of Intents Technology under these Terms.
## 5. DEVELOPER WALLET
5.1 To receive its share of AppFee, Developer must designate a Developer Wallet and is solely responsible for providing and maintaining accurate wallet details.
5.2 Developer acknowledges and agrees that:
* (a) the Developer Wallet must be controlled exclusively by Developer through private keys under its control;
* (b) neither the 1Click Service nor Intents Technology acts as fiduciary, trustee, or agent with respect to any digital assets;
* (c) no responsibility or liability is assumed for loss of digital assets resulting from an incorrect, inaccessible, or compromised wallet address; and
* (d) digital assets are inherently experimental and volatile, and no representation or warranty is given as to merchantability, fitness for purpose, regulatory status, legality, blockchain functionality, or value.
## 6. CONFIDENTIAL INFRASTRUCTURE FEES
6.1 This Section 6 applies to Confidential Swaps. The fee structure in Sections 2 to 5 (including the AppFee mechanism and any revenue share or distribution) does not apply to Confidential Swaps.
6.2 Intents Technology sets, charges, and retains the Confidential Infrastructure Fee in respect of each Confidential Swap. The Confidential Infrastructure Fee is determined solely by Intents Technology, is borne by the End-User, and is deducted from the Transaction at the settlement level and retained by Intents Technology for its own account.
6.3 The Confidential Infrastructure Fee may be a fixed amount, a percentage, or determined on any other basis, and Intents Technology may set different Confidential Infrastructure Fees for different routes, assets, networks, volumes, Developers, or other factors. Intents Technology may introduce, increase, reduce, waive, or remove the Confidential Infrastructure Fee, and modify any rate, threshold, parameter, or mechanic, at any time on a prospective basis. The current Confidential Infrastructure Fee (if any) may be set out in the Documentation or the Developer Portal.
6.4 No AppFee is configured for Confidential Swaps, and no portion of the Confidential Infrastructure Fee is allocated, distributed, or owed to the Developer. Sections 4 (Distribution Mechanics) and 5 (Developer Wallet) do not apply to Confidential Swaps. There is no default revenue share or rebate in respect of Confidential Swaps; any rebate, discount, or revenue share, if any, is determined by Intents Technology in its sole discretion and governed solely by a Commercial Agreement.
6.5 Confidential Swaps remain subject to the general provisions of this Schedule (including Sections 1, 7, and 8) and to Section 6.7 of these Terms.
## 7. ADDITIONAL FEES (EXCLUSIONS)
7.1 Developer acknowledges that, in addition to the fees set forth in this Schedule, End-Users and/or Developer may be subject to: (a) network (“gas”) fees; (b) bridge fees; (c) protocol-level fees charged by or through the Protocol or any smart contract; (d) solver fees, spreads, rebates, routing incentives, or third-party economic arrangements; (e) front-end or interface fees; (f) third-party service provider fees (including fiat onramp/offramp provider fees); (g) fees for any Confidential Intents processing (including, without limitation, withdrawals, deposits, and/or swaps, via the 1Click Service or otherwise, in each case other than the Confidential Infrastructure Fee, which is charged as an Infrastructure Fee under Section 6 of this Schedule) on the NEAR Private Shard; (h) fees associated with yield-bearing asset protocols; (i) any other fees, charges, or costs arising from Third-Party Components or the underlying Protocol; (j) withdrawal fees (including network- or asset-specific withdrawal fees); (k) any Quote Improvement or Capture Share retained or allocated in connection with a Transaction (as described in Section 6.7); and (l) any other fee, charge, cost, or economic arrangement of any kind that is not expressly designated as an Infrastructure Fee or AppFee under this Schedule.
7.2 Such additional fees are separate from and not subject to the Infrastructure Fee mechanics in this Schedule. Developer has no right, title, interest, or claim in or to any such additional fees.
## 8. FEE TRANSPARENCY
8.1 Intents Technology shall make available to Registered Developers, via the Developer Portal or a designated partner dashboard, reporting functionality that enables the Developer to view aggregate Infrastructure Fees charged in respect of Transactions routed from the Developer’s Products. The scope, format, and frequency of such reporting shall be determined by Intents Technology in its sole discretion and may be updated from time to time.
8.2 If Developer has a good-faith query regarding the calculation of any Infrastructure Fee, Developer may raise such query in writing to Intents Technology, and Intents Technology shall use reasonable efforts to respond within thirty (30) days.
# Treasury Addresses
Source: https://docs.near-intents.org/security-compliance/treasury-addresses
Official treasury and refill addresses for NEAR Intents and HOT Bridge
For transparency and AML compliance, below are the treasury and refill addresses used by **NEAR Intents** and **HOT Bridge**, listed by network.
## Treasury Addresses
### EVM Chains
Arbitrum, Avalanche, ADI, Aurora, Base, Bera, BNB, Ethereum, Gnosis, Optimism, Plasma, Polygon
| Entity | Address |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **NEAR Intents** | [`0x2CfF890f0378a11913B6129B2E97417a2c302680`](https://blockscan.com/address/0x2CfF890f0378a11913B6129B2E97417a2c302680) |
| **HOT Bridge** | [`0x233c5370CCfb3cD7409d9A3fb98ab94dE94Cb4Cd`](https://blockscan.com/address/0x233c5370CCfb3cD7409d9A3fb98ab94dE94Cb4Cd) |
### Bitcoin & Forks
| Network | NEAR Intents Treasury |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Bitcoin (BTC)** | [`1C6XJtNXiuXvk4oUAVMkKF57CRpaTrN5Ra`](https://www.blockchain.com/btc/address/1C6XJtNXiuXvk4oUAVMkKF57CRpaTrN5Ra) |
| **Bitcoin Cash (BCH)** | [`1LxByjYMdnogW9Nc73srT4NCbS8oPVaXvZ`](https://www.blockchain.com/explorer/addresses/bch/1LxByjYMdnogW9Nc73srT4NCbS8oPVaXvZ) |
| **Dash (DASH)** | [`XxA9DbXaFpF4GFY8KUNX7eAxhZPsWtcKhc`](https://chainz.cryptoid.info/dash/address.dws?XxA9DbXaFpF4GFY8KUNX7eAxhZPsWtcKhc.htm) |
| **Dogecoin (DOGE)** | [`DRmCnxzL9U11EJzLmWkm2ikaZikPFbLuQD`](https://blockchair.com/dogecoin/address/DRmCnxzL9U11EJzLmWkm2ikaZikPFbLuQD) |
| **Litecoin (LTC)** | [`LQjEMkuiA2pCwFeUPwsu6ktzUubBVLsahX`](https://litecoinspace.org/address/LQjEMkuiA2pCwFeUPwsu6ktzUubBVLsahX) |
| **Zcash (ZEC)** | [`t1Ku2KLyndDPsR32jwnrTMd3yvi9tfFP8ML`](https://mainnet.zcashexplorer.app/address/t1Ku2KLyndDPsR32jwnrTMd3yvi9tfFP8ML) |
### Layer 1 Chains
| Network | NEAR Intents Treasury | HOT Bridge Treasury |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Aleo (ALEO)** | [`aleo1kelm7k8786anyygg788ntlgkx4uqkmkpj7k5ugfuqchd8rnf858sun3qcr`](https://aleoscan.io/address?a=aleo1kelm7k8786anyygg788ntlgkx4uqkmkpj7k5ugfuqchd8rnf858sun3qcr) | – |
| **NEAR** | [`intents.near`](https://nearblocks.io/address/intents.near) | – |
| **Solana (SOL)** | [`HWjmoUNYckccg9Qrwi43JTzBcGcM1nbdAtATf9GXmz16`](https://explorer.solana.com/address/HWjmoUNYckccg9Qrwi43JTzBcGcM1nbdAtATf9GXmz16) | [`8sXzdKW2jFj7V5heRwPMcygzNH3JZnmie5ZRuNoTuKQC`](https://explorer.solana.com/address/8sXzdKW2jFj7V5heRwPMcygzNH3JZnmie5ZRuNoTuKQC) |
| **TON** | [`UQAfoBd_f0pIvNpUPAkOguUrFWpGWV9TWBeZs_5TXE95_trZ`](https://tonscan.org/address/UQAfoBd_f0pIvNpUPAkOguUrFWpGWV9TWBeZs_5TXE95_trZ) | [`EQANEViM3AKQzi6Aj3sEeyqFu8pXqhy9Q9xGoId_0qp3CNVJ`](https://tonviewer.com/EQANEViM3AKQzi6Aj3sEeyqFu8pXqhy9Q9xGoId_0qp3CNVJ) |
| **Stellar (XLM)** | [`GDJ4JZXZELZD737NVFORH4PSSQDWFDZTKW3AIDKHYQG23ZXBPDGGQBJK`](https://stellar.expert/explorer/public/account/GDJ4JZXZELZD737NVFORH4PSSQDWFDZTKW3AIDKHYQG23ZXBPDGGQBJK) | [`CCLWL5NYSV2WJQ3VBU44AMDHEVKEPA45N2QP2LL62O3JVKPGWWAQUVAG`](https://stellar.expert/explorer/public/contract/CCLWL5NYSV2WJQ3VBU44AMDHEVKEPA45N2QP2LL62O3JVKPGWWAQUVAG) |
| **Sui (SUI)** | [`0x00ea18889868519abd2f238966cab9875750bb2859ed3a34debec37781520138`](https://suivision.xyz/account/0x00ea18889868519abd2f238966cab9875750bb2859ed3a34debec37781520138) | – |
| **Aptos (APT)** | [`0xd1a1c1804e91ba85a569c7f018bb7502d2f13d4742d2611953c9c14681af6446`](https://aptoscan.com/account/0xd1a1c1804e91ba85a569c7f018bb7502d2f13d4742d2611953c9c14681af6446) | – |
| **Starknet (STRK)** | [`0x03b79b882cd0310822ebf3fe2be44a828f8939e699f8fd55a69cd70473f69090`](https://voyager.online/contract/0x03b79b882cd0310822ebf3fe2be44a828f8939e699f8fd55a69cd70473f69090) | – |
| **TRON (TRX)** | [`TX5XiRXdyz7sdFwF5mnhT1QoGCpbkncpke`](https://tronscan.org/#/address/TX5XiRXdyz7sdFwF5mnhT1QoGCpbkncpke) | – |
| **XRP Ledger** | [`r9R8jciZBYGq32DxxQrBPi5ysZm67iQitH`](https://xrpscan.com/account/r9R8jciZBYGq32DxxQrBPi5ysZm67iQitH) | – |
| **Cardano (ADA)** | [`addr1v8wfpcg4qfhmnzprzysj6j9c53u5j56j8rvhyjp08s53s6g07rfjm`](https://cardanoscan.io/address/61dc90e115026fb9882311212d48b8a47949535238d972482f3c291869) | – |
### Additional EVM Networks
| Network | NEAR Intents Treasury |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Monad (MON)** | [`0x233c5370ccfb3cd7409d9a3fb98ab94de94cb4cd`](https://monad.socialscan.io/address/0x233c5370ccfb3cd7409d9a3fb98ab94de94cb4cd) |
| **XLayer (LRX)** | [`0x233c5370ccfb3cd7409d9a3fb98ab94de94cb4cd`](https://xlayerscan.com/address/0x233c5370ccfb3cd7409d9a3fb98ab94de94cb4cd) |
***
## Refill Addresses
These addresses are used for operational refills across networks.
| Network | Refill Address |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **EVM Chains** | [`0xbb2f33f73ccc2c74e3fb9bb8eb75241ac15337e0`](https://blockscan.com/address/0xbb2f33f73ccc2c74e3fb9bb8eb75241ac15337e0) |
| **Aleo** | [`aleo1wnnhcqljnagj8wgacqfyq98v63czc700hlyt24xacu9et07ekspsv5rrg4`](https://aleoscan.io/address?a=aleo1wnnhcqljnagj8wgacqfyq98v63czc700hlyt24xacu9et07ekspsv5rrg4) |
| **Solana** | [`9WL2A89YBr6X47ABKYNzPentWiBA3H8tpaiuf5CaYHx6`](https://solscan.io/account/9WL2A89YBr6X47ABKYNzPentWiBA3H8tpaiuf5CaYHx6) |
| **TON** | [`EQDgTfO4pJ8LxznVfC0mHsGl94bQBU4KFcJfliAIHebQU2G4`](https://tonviewer.com/EQDgTfO4pJ8LxznVfC0mHsGl94bQBU4KFcJfliAIHebQU2G4) |
| **Sui** | [`0x1f6cd55584e6d0c19ae34bfc48b1bd9b1b8a166987e34052cfea7f3c795c6d76`](https://suiscan.xyz/mainnet/account/0x1f6cd55584e6d0c19ae34bfc48b1bd9b1b8a166987e34052cfea7f3c795c6d76) |
| **Aptos** | [`0x107b277f8ac97230f1e53cf3661b3f05a40c5a02d1d2b74fe77826b62b4d1c43`](https://aptoscan.com/account/0x107b277f8ac97230f1e53cf3661b3f05a40c5a02d1d2b74fe77826b62b4d1c43) |
| **TRON** | [`TNzQzT8wDF1GVevMqehVDY51ucxxrNfCap`](https://tronscan.org/#/address/TNzQzT8wDF1GVevMqehVDY51ucxxrNfCap) |
| **Cardano** | [`addr1v92k8ex6m7yykq6j0psqlrxxeq23220g9x8yeqd4g65qq3shttpln`](https://cardanoscan.io/address/615563e4dadf884b035278600f8cc6c8151529e8298e4c81b546a80046) |
| **Litecoin** | [`LVUMGpKvAzC4C8KprqyUDWpk6oPd4rKFV9`](https://litecoinspace.org/address/LVUMGpKvAzC4C8KprqyUDWpk6oPd4rKFV9) |
| **Bitcoin Cash** | [`12WV95gFkfqQ7VQ6dJXYk7TNcxRicq13wx`](https://www.blockchain.com/explorer/addresses/bch/12WV95gFkfqQ7VQ6dJXYk7TNcxRicq13wx) |
| **Starknet** | [`0x066a994a555be47297bac7347d3611afa0b8fc58b77bed7d9e7f7459da6ecc7a`](https://voyager.online/contract/0x066a994a555be47297bac7347d3611afa0b8fc58b77bed7d9e7f7459da6ecc7a) |