Account Abstraction

Users don’t need to create a NEAR account to use NEAR Intents. The Verifier contract supports wallets across all supported chains. When a user signs with their existing wallet, the Verifier automatically creates an account that only they can control using their existing private keys. No new wallet, no seed phrase — just sign and trade. 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. 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 for the full encoding requirements table.

Adding a public key via transaction

Here is an example transaction for adding a public key to a Named Account.

NEAR CLI
NEAR API JS

near contract call-function as-transaction \
  intents.near add_public_key json-args '{
    "public_key": "ed25519:<base58>"
  }' prepaid-gas '100.0 Tgas' attached-deposit '1 yoctoNEAR' \
  sign-as <ACCOUNT_ID> network-config mainnet sign-with-keychain send

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:<base58>",
  },
  gas: teraToGas("100"),
  deposit: 1n, // 1 yoctoNEAR
});

See contract interaction example in near-api-examples repository.

Adding a public key via signed intent

You can also submit a signed intent to add a public key:

{
  "signer_id": "<ACCOUNT_ID>",
  "intents": [
    {
      "intent": "add_public_key",
      "public_key": "<PUBLIC_KEY_OF_USER>"
    }
  ]
}

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

Connect wallet

Prompt your user to connect their wallet, establishing a session and providing their account ID or address.

Check key registration

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.

Sign and submit intents

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…
Remove public key	69XiJcRt…

Verifier Contract

Deposits & Withdrawals

Intents

NEAR’s multi-key model

Account types

Named accounts

Implicit accounts

Account keys

Adding a public key via transaction

Adding a public key via signed intent

Authentication flow for frontends

Step-by-step flow

Key rotation

Real transaction examples

Verifier Contract

Deposits & Withdrawals

Intents

​NEAR’s multi-key model

​Account types

​Named accounts

​Implicit accounts

​Account keys

​Adding a public key via transaction

​Adding a public key via signed intent

​Authentication flow for frontends

​Step-by-step flow

​Key rotation

​Real transaction examples

NEAR’s multi-key model

Account types

Named accounts

Implicit accounts

Account keys

Adding a public key via transaction

Adding a public key via signed intent

Authentication flow for frontends

Step-by-step flow

Key rotation

Real transaction examples