Native Accounts

Besides its NEAR Intents balance, every agent has its own keys outside NEAR Intents: a NEAR account, one EVM address for every EVM chain and a Solana address. With them the agent can prove its identity to another service, send NEAR, call a NEAR contract, and sign EVM and Solana messages and transactions. Every method is off until the owner switches it on in the policy’s native block. Each one has its own route under POST /v1/agents/{agent_id}/native/….

Native methods are for advanced users. The account’s policy does not protect them: destinations, budget, timelock_ms, schedule and owner_approval don’t apply. A NEAR transfer can go to any account. A signed EVM or Solana transaction, or EVM typed data such as a permit, can move everything at that address. Switch on only what the agent needs, for services the owner trusts.

The agent’s addresses

GET /v1/agents/{agent_id}/wallet returns the agent’s addresses.

Field	What it is
`near_account_id`	The agent’s NEAR account. It holds the NEAR Intents balance, signs NEP-413 messages, and sends native NEAR transfers and calls.
`evm_account_id`	The agent’s EVM address. It is the same on every EVM chain. `null` until the wallet provider reports it.
`solana_account_id`	The agent’s Solana address. `null` until the wallet provider reports it.

The EVM and Solana keys are separate keys. Nothing they sign can reach the NEAR Intents balance. The NEAR Intents contracts (intents.near, intents.far) can never be signed for, called or sent to, so the NEAR key can’t reach it either. The EVM routes take a chain: ethereum, polygon, base, arbitrum, optimism, bsc, avalanche, hyperevm or hood. The address is the same on all of them.

Turn methods on

The owner adds native to the policy. Read the current policy, set native, and send the complete policy as a policy_update:

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_message: false, sign_transaction: false },
    },
  },
});
// The owner signs it like any other owner intent. See Owner Signing.

Switch	Type	Route it opens
`near.sign_message`	NEAR accounts or domains	`native/near/sign-message`, for the listed recipients only
`near.transfer`	`true` or `false`	`native/near/transfer`
`near.call`	NEAR accounts	`native/near/call`, to the listed contracts only
`evm.sign_typed_data`	EIP-712 domains, each with optional `primary_types`	`native/evm/sign-typed-data`, under the listed domains only, and only the message types an entry’s `primary_types` lists
`evm.sign_message`	`true` or `false`	`native/evm/sign-message`
`evm.sign_transaction`	`true` or `false`	`native/evm/sign-transaction`
`solana.sign_message`	`true` or `false`	`native/solana/sign-message`
`solana.sign_transaction`	`true` or `false`	`native/solana/sign-transaction`

Omitted means every method is off. When native is present, every key in it is required. An empty list is off.
Lists hold up to 256 unique NEAR accounts (near.sign_message, near.call) or up to 64 domain entries, unique by domain (evm.sign_typed_data).
intents.near and intents.far can never be listed. A policy that lists them is refused with validation_failed.
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 they skip the account’s money rules.

Show the owner a warning before they sign a policy that switches on any native method, for example: “Native methods are for advanced users and are not protected by this account’s policy: destinations, budget, timelock, schedule and owner approval don’t apply. A NEAR transfer can go to any account. A signed EVM or Solana transaction, or EVM typed data such as a permit, can move everything at that address. Only switch on what the agent needs, for services you trust; a service may treat an identity signature as you logging in.”

What applies

Every native request needs a live grant token (X-Grant-Token) and an applied policy, and is refused while the agent is frozen. The policy switch is the whole fence.

Rule	Applies to native requests
The `native` switch	Yes
Live grant, applied policy, `frozen`	Yes
`destinations`	No
`budget`	No
`timelock_ms`	No. Native requests run at once.
`schedule`	No
`owner_approval`	No
`assets`, `limits`, `max_actions_per_hour`	NEAR transfers and calls only. The wallet provider treats native NEAR as wNEAR, so `assets` must allow `nep141:wrap.near` (or be `"any"`) and its `limits` cap the amount or deposit.

Every native request is recorded in the agent’s history (GET /v1/agents/{agent_id}/history) as type native, signatures included. See History. Native signatures share the API’s delegated signing limit: by default 4 at once per server and 2 per partner account. More answer rate_limited (429), retryable.

Sign a message (NEAR)

An agent can sign a NEP-413 message with its NEAR key, which is how a site or dApp logs in a NEAR account (signMessage). The service, the relying party, issues a message and a random 32-byte nonce and names itself as the recipient. Your backend has the API sign exactly those, and the relying party checks the signature. It moves no money. Turn it on by listing the relying party in native.near.sign_message. An entry is a NEAR account or a domain (printable ASCII, up to 128 characters), matched exactly, with no wildcard.

This route signs a NEP-413 message only. It never signs a transaction or an intent, and never for the NEAR Intents contracts (intents.near, intents.far), in any letter case.

Sign a message

Your backend receives message, recipient and nonce from the relying party and sends them unchanged with the grant token. The API key alone is refused with agent_grant_required.

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.

Field	Description
`message`	What the relying party asks the agent to sign, up to 32768 characters
`recipient`	The relying party’s NEAR account or domain. It must be listed in `native.near.sign_message`.
`nonce`	The relying party’s 32 random bytes, base64 (44 characters)
`encoding`	Optional. `utf8` (default) or `hex`, for raw bytes. The decoded text is signed unchanged, including a leading byte order mark.

callback_url is not supported. The response is 200. It answers at once, with nothing to poll. correlation_id names the history record.

{
  "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"
}

The API verifies the signature against the NEP-413 payload before it returns it.

Verify a signature (relying party)

The relying party checks, in order:

recipient is its own account or domain, and nonce is one it issued, unused.
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.
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.

Then it marks the nonce as used. The native accounts examples contain a complete login request builder and verifier in TypeScript. A signature already issued stays valid for the relying party until it expires the nonce, even after the owner removes the recipient.

Turn it off

Remove an entry from a list, set a switch to false, or omit native to turn every method off. Each is an on-chain policy change, like turning it on. Freezing the agent stops every native route at once (wallet_frozen). Revoking a grant stops only that grant. Deleting the agent doesn’t sweep funds at its EVM or Solana address to the owner, and native NEAR left in its NEAR account goes to the sponsor. Move them first. See Deleting an agent.

Errors

signing_recipient_forbidden is checked first, before the grant and the policy.

Code	HTTP	What it means
`agent_grant_required`	403	No live grant token on the request
`policy_not_ready`	409	The latest policy revision isn’t in force yet
`wallet_frozen`	409	The owner froze the agent
`native_method_denied`	403	The `native` block doesn’t switch this method on, or doesn’t list this contract or EIP-712 domain, or the matching domain entry’s `primary_types` doesn’t list the request’s `primaryType`. Ask the owner to enable it with `policy_update`.
`signing_policy_denied`	403	`near/sign-message` for a recipient not listed in `native.near.sign_message`. Ask the owner to add it with `policy_update`.
`signing_recipient_forbidden`	403	The recipient is `intents.near` or `intents.far`. Never allowed, whatever the policy says.
`native_contract_forbidden`	403	A transfer to, or call of, `intents.near` or `intents.far`. Use the NEAR Intents actions instead.
`insufficient_balance`	409	The agent’s NEAR account doesn’t cover the transfer or deposit
`idempotency_conflict`	409	The same `Idempotency-Key` with a different body
`authorization_stale`	409	The grant, key, owner or policy changed while the request was in flight. Send it again.
`rate_limited`	429	Too many signatures at once. Retryable after `Retry-After`.

See Status & Errors for the error format and every other code.

Agent API

Quickstart

Guides

Trust & Verification

API Reference

The agent’s addresses

Turn methods on

What applies

Sign a message (NEAR)

Sign a message

Verify a signature (relying party)

Turn it off

Errors

​The agent’s addresses

​Turn methods on

​What applies

​Sign a message (NEAR)

​Sign a message

​Verify a signature (relying party)

​Turn it off

​Errors

The agent’s addresses

Turn methods on

What applies

Sign a message (NEAR)

Sign a message

Verify a signature (relying party)

Turn it off

Errors