Native Accounts

The agent’s addresses

Turn methods on

const current = await api.getPolicy(agentId);
if (current.policy === null || current.revision === null) throw new Error("policy_not_ready");

const generated = await api.generateIntent({
  type: "policy_update",
  agent_id: agentId,
  expected_revision: current.revision,
  policy: {
    ...current.policy,
    native: {
      near: { sign_message: ["app.example.com"], transfer: false, call: [] },
      evm: {
        sign_typed_data: [
          { name: "Exchange", version: "1", chain_id: 1337, verifying_contract: "0x0000000000000000000000000000000000000000" },
        ],
        sign_message: false,
        sign_transaction: false,
      },
      solana: { sign_in: ["app.example.com"], sign_message: false, sign_transaction: false },
    },
  },
});
// The owner signs it like any other owner intent. See Owner Signing.

• Omitted means every method is off. When native is present, every key in it is required except solana.sign_in, evm.sign_intent, solana.sign_intent and solana.sign_transfer, which may be left out (off). An empty list is off.
• Lists hold up to 256 unique NEAR accounts (near.sign_message, near.call), up to 256 unique lowercase hosts, with their port if they have one (solana.sign_in), or up to 64 domain entries, unique by domain (evm.sign_typed_data).
• intents.near and intents.far can never be listed for the NEAR key. A policy that lists them is refused with validation_failed. The EVM and Solana keys reach them only through sign-intent.
• Transactions are checked before anything is signed. native/evm/sign-transaction takes one serialized unsigned EIP-2718 typed or EIP-155 legacy transaction whose chain id is that of chain. native/solana/sign-transaction takes one legacy or v0 transaction message. Anything else is refused with validation_failed, so neither route signs a message.
• Every grant on the agent can use a method once it is on. Revoking a grant stops only that grant.
• The wallet provider enforces the switches too, so changing native is an on-chain policy change. A NEAR owner signs it as nep366, the API pays the gas, and the policy cooldown applies. A method works once the revision is APPLIED and provider_policy_synced is true.
• The owner’s preview.summary names every method the policy switches on and says which of the account’s money rules they skip.

What applies

Sign a message (NEAR)

Sign a message

curl -X POST "$NEAR_INTENTS_AGENT_API_URL/v1/agents/$AGENT_ID/native/near/sign-message" \
  -H "X-API-Key: $NEAR_INTENTS_AGENT_API_KEY" \
  -H "X-Grant-Token: $GRANT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Log in to app.example.com",
    "recipient": "app.example.com",
    "nonce": "<32 random bytes, base64>"
  }'

const assistant = api.forGrant(process.env.GRANT_TOKEN!);

const signature = await assistant.nativeNearSignMessage(agentId, {
  message, // exactly as the relying party issued it
  recipient: "app.example.com",
  nonce, // the relying party's 32 random bytes, base64
});
// Send `signature` back to the relying party.

{
  "correlation_id": "op_...",
  "near_account_id": "AGENT_NEAR_ACCOUNT",
  "public_key": "ed25519:...",
  "signature": "base64, 64 bytes",
  "nonce": "the nonce you sent",
  "recipient": "app.example.com"
}

Verify a signature (relying party)

1. recipient is its own account or domain, and nonce is one it issued, unused.
2. The signature (base64) verifies with public_key over the NEP-413 payload: the exact message it issued, the decoded 32-byte nonce, recipient, and no callback URL.
3. public_key controls near_account_id: a full-access key on that account, read at final. For an implicit account that doesn’t exist on-chain yet, the account ID is the hex of that key.

Send NEAR and call contracts

curl -X POST "$NEAR_INTENTS_AGENT_API_URL/v1/agents/$AGENT_ID/native/near/transfer" \
  -H "X-API-Key: $NEAR_INTENTS_AGENT_API_KEY" \
  -H "X-Grant-Token: $GRANT_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "to": "bob.near", "amount": "1000000000000000000000" }'

const transfer = await assistant.nativeNearTransfer(agentId, {
  to: "bob.near",
  amount: "1000000000000000000000", // yoctoNEAR
});

const call = await assistant.nativeNearCall(agentId, {
  receiver_id: "app.example.near",
  method_name: "register",
  args: { name: "agent" },
});

• PROCESSING until two RPC operators agree that NEAR has finalized the transaction and that it is exactly the request: signed by the agent’s account, to the named recipient or contract, with the amount, method, arguments, gas (when given) and deposit asked for. details.provider_status does not change this.
• SUCCESS once they agree, with details.tx_hash.
• FAILED with native_transaction_failed when the finalized transaction failed. failure_reason has the chain’s reason. A transaction the provider reports as broadcast and reverted keeps its real details.tx_hash and provider_status onchain_tx_failed, and reads FAILED once the chain confirms it. Nothing it asked for happened, and it is never resent.
• NEEDS_REVIEW when automatic settlement stopped: native_transaction_mismatch (the finalized transaction is not the request) or native_transaction_unconfirmed (NEAR still does not know it 30 minutes after dispatch), among others. See Idempotency and review.

Sign EVM typed data

const signed = await assistant.nativeEvmSignTypedData(agentId, {
  chain: "hyperevm",
  typed_data: { domain, types, primaryType: "Agent", message }, // types.EIP712Domain may be omitted
});
// Hand `signed.signature` to the service that asked for it.

• Field for field. A request’s domain must equal one listed entry: the same fields present, with the same values. A missing or extra field makes it another domain, which is refused.
• Spelling. chainId may be a number, a decimal string or a hex string. Addresses and salts compare lowercase.
• types.EIP712Domain may be omitted, and the API derives it. When you send it, it must declare exactly the domain’s fields, in EIP-712 order (name, version, chainId, verifyingContract, salt), with their standard types.
• primaryType is the message type. EIP712Domain is refused.
• message is at most 65536 bytes as canonical JSON. A larger one is refused with validation_failed.

Limit the message types

{ "name": "HyperliquidSignTransaction", "version": "1", "chain_id": 42161,
  "verifying_contract": "0x0000000000000000000000000000000000000000",
  "primary_types": ["HyperliquidTransaction:Withdraw"] }

• primary_types is optional: 1 to 32 unique strings, each 1 to 256 characters, case-sensitive, never EIP712Domain. An empty list is invalid. Omitted means any message type under the domain.
• A request matches when its domain equals the entry’s domain field for field, and either the entry has no primary_types or the request’s primaryType is listed. Otherwise it is refused with native_method_denied.
• One entry per domain. Entries are unique by domain, so one domain listed twice with different types is refused. Give one entry all its types.

Sign EVM messages and transactions

Sign Solana messages and transactions

Sign NEAR Intents payloads (EVM and Solana)

The sign-intent rules

"sign_intent": {
  "receivers": ["treasury.near"],
  "one_click_deposits": true,
  "withdrawals": [{ "chain": "base", "address": "0x0000000000000000000000000000000000000001" }],
  "max_slippage_bps": 100
}

What the payload must be

• Intents. intents holds only transfer intents (intent, receiver_id, tokens, and optionally memo, msg and min_gas), or none. Anything else, such as add_public_key, token_diff or a withdrawal, is refused with intents_type_forbidden, and source.pointer names the intent.
• Signer. signer_id is the signing key’s Intents account: the lowercase 0x EVM address (wallet.evm_account_id, lowercased; a checksummed spelling is refused), or the lowercase hex of the 32-byte key behind wallet.solana_account_id. Otherwise intents_signer_mismatch.
• Contract. verifying_contract is intents.near or intents.far, and no receiver may be either of them (intents_contract_forbidden).
• Deadline. An RFC 3339 UTC time ending in Z, still ahead and at most 300 seconds after the API’s clock. A payload that pays only 1Click deposits (below) may be due up to 96 hours ahead, which is the deadline 1Click writes into the payloads it generates. Otherwise intents_deadline_invalid. Anyone who holds a signed payload can publish it until then, so sign one that is due soon.
• Nonce. Base64 of 32 bytes.
• Receivers. Every receiver_id must be a listed receiver, or one of at most 2 1Click deposit addresses per payload whose signed quote in one_click_quotes passes the checks below. Otherwise policy_destination_denied (403), with the reason in detail, before the wallet provider is called.

1Click deposits

• carries 1Click’s valid signature, and is live. A deposit with no quote, or a quote that is unsigned, altered or a dry run, is refused with policy_destination_denied. A quote for an address the payload does not pay, or two quotes for one address, is validation_failed (/one_click_quotes/{i}/quote/depositAddress);
• pays out where the owner allowed. With one_click_deposits: to the payload’s signer_id or to a listed receiver, inside NEAR Intents (recipientType is the contract’s account type). With a withdrawals entry: to a listed address on the chain 1Click lists the quote’s destinationAsset on (recipientType DESTINATION_CHAIN). The chain comes from 1Click’s token listing, never from the quote request. If the listing cannot be read, the request is refused with provider_unavailable;
• refunds the signing key (refundTo is the signer_id), with refundType and depositType equal to the contract’s account type: INTENTS for intents.near, CONFIDENTIAL_INTENTS for intents.far;
• has no rebates, customRecipientMsg, virtualChainRecipient or virtualChainRefundRecipient;
• loses no more at minAmountOut than max_slippage_bps allows, by 1Click’s signed USD amounts. 1Click’s fee and slippage both count, and appFees and slippageTolerance are not read. Request slippage clearly below the cap, such as 50 under a cap of 100: a quote at exactly the cap is refused, because fees and spread push it over;
• is paid by one transfer of exactly the quote’s amountIn of its originAsset, due no later than the quote’s deadline. On intents.far the token is the confidential imt:51e8f94d77b5e90dc9852ca6113771e11e8382ce69473a75e313e41665de7cbe:<originAsset> token, which is how 1Click generates it.

Use it end to end

curl -X POST "$NEAR_INTENTS_AGENT_API_URL/v1/agents/$AGENT_ID/native/evm/sign-intent" \
  -H "X-API-Key: $NEAR_INTENTS_AGENT_API_KEY" \
  -H "X-Grant-Token: $GRANT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "payload": "<the payload string, JSON-escaped>", "one_click_quotes": [<the 1Click quote answer>] }'

const assistant = api.forGrant(process.env.GRANT_TOKEN!);

const { signed_data } = await assistant.nativeEvmSignIntent(agentId, {
  payload: intent.payload, // exactly the text 1Click generated
  one_click_quotes: [quote], // 1Click's /v0/quote answer, unchanged
});
// Solana key: assistant.nativeSolanaSignIntent(agentId, { payload })

import { randomBytes } from "node:crypto";

const wallet = await api.getWallet(agentId);
const payload = JSON.stringify({
  signer_id: wallet.evm_account_id!.toLowerCase(),
  verifying_contract: "intents.near",
  deadline: new Date(Date.now() + 120_000).toISOString(), // at most 300 s ahead
  nonce: randomBytes(32).toString("base64"),
  intents: [{ intent: "transfer", receiver_id: "treasury.near", tokens: { "nep141:usdc.near": "1000000" } }],
});
const { signed_data } = await assistant.nativeEvmSignIntent(agentId, { payload });

The answer

{ "standard": "erc191", "payload": "…", "signature": "secp256k1:<base58>" }

{ "standard": "raw_ed25519", "payload": "…", "public_key": "ed25519:<base58>", "signature": "ed25519:<base58>" }

Sign in with Solana

const login = await assistant.nativeSolanaSignIn(agentId, {
  domain: "app.example.com",
  statement: "Sign in to Example",
  uri: "https://app.example.com",
  version: "1",
  chain_id: "mainnet",
  nonce: "kR3x9aPq7Lm2", // the service's own nonce
  issued_at: new Date().toISOString(),
  expiration_time: new Date(Date.now() + 5 * 60_000).toISOString(),
});
// Give the service login.signed_message (UTF-8), login.signature and login.account_id.

Send a Solana transfer

const signed = await assistant.nativeSolanaSignTransfer(agentId, {
  unsigned_tx, // base64 of versionedTx.message.serialize()
  recipient: "RecipientWalletAddress",
});

• a legacy or version 0 message with no address lookup tables, so every account is in it;
• signed by the agent only, which is also the fee payer, with no account appearing twice;
• exactly one transfer: a System Program Transfer from the agent to recipient, or one SPL Token or Token-2022 TransferChecked with the agent as authority into the associated token account of recipient for that mint.

The signature

{
  "correlation_id": "op_...",
  "chain": "hyperevm",
  "account_id": "0x...",
  "signature": "0x..."
}

Idempotency and review

• Stop polling, and never send it again under a new key. It may have run.
• After the review is resolved, read the status with refresh=true. See NEEDS_REVIEW.

History

Turn it off

Errors