Skip to main content
In NEAR, users control their accounts using access keys, which can be full-access keys or function-call keys. Full-access keys allow complete control over the account, while function-call keys restrict actions to specific contracts. This system enables secure sharing of permissions and simplifies user interactions with applications.

​
Access Keys

In most blockchains, users control their accounts by holding a single private key (a secret only they know) and using it to sign transactions. Access keys In NEAR we distinguish two types of Access Keys:
  1. Full-Access Keys: Have full control over the account, and should never be shared
  2. Function-Call Keys: Can only sign calls for specific contracts, and are meant to be shared
In addition, a key of either type can be created as a gas key: a key that carries its own prepaid gas balance and multiple independent nonces, built for sending many transactions in parallel. Every account in NEAR can hold multiple keys, and keys can be added or removed, allowing a fine-grained control over the account’s permissions.

​
Function-Call Keys

Function-Call keys can only sign transactions calling a specific contract, and do not allow to attach NEAR tokens to the call. They are defined by three attributes:
  1. receiver_id: The only contract which the key allows to call, no other contract can be called with this key
  2. method_names (Optional): The contract’s methods the key allows to call. If omitted, all contract’s methods can be called
  3. allowance (Optional): The amount of NEAR allowed to be spent on gas. If omitted, the key can consume unlimited gas
Function Call Keys are meant to be shared with applications, so third-parties can make contract calls in your name. This is useful in multiple scenarios as we will see below.
Function-Call keys are secure to share, as they only permit calls to a specific contract and prohibit NEAR token transfers

​
Full-Access Keys

As the name suggests, Full-Access keys have full control of an account, meaning they can be used to sign transactions doing any action in your account’s behalf:
  1. Transfer NEAR Ⓝ
  2. Delete your account or create sub-accounts of it
  3. Add or remove Access Keys
  4. Deploy a smart contract in the account
  5. Call methods on any contract
You should never share your Full-Access, otherwise you are giving total control over the account.
Implicit accounts already have a Full-Access Key by default, while for named accounts their first Full-Access Key is added on creation

​
Gas Keys

Gas keys (NEP-611) are access keys designed for sending many transactions in parallel. They were introduced in nearcore 2.13 (protocol version 86) and differ from regular access keys in two ways:
  1. Prepaid gas balance: a gas key holds its own NEAR balance, and transactions signed with it pay gas from that balance instead of the account’s main balance
  2. Parallel nonces: a gas key has up to 1,024 independent nonces (called nonce lanes), so many transactions can be in flight at once without nonce collisions
A gas key can have either FullAccess or FunctionCall permission, with one restriction: a function-call gas key cannot set an allowance — its prepaid balance already serves as the gas budget. This makes gas keys ideal for programmatic senders — relayers, bots, exchanges, or a fleet of agents operating one account — which previously had to juggle many separate access keys just to avoid nonce collisions, and risked draining the account’s main balance on gas.

​
Lifecycle of a Gas Key

A gas key is managed with the same actions as any other key, plus two new actions to move NEAR in and out of its balance:
  1. Create: an AddKey action with a gas-key permission creates the key, specifying its number of nonces (num_nonces, between 1 and 1,024). The key is always created with zero balance
  2. Fund: a TransferToGasKey action moves NEAR from the account’s balance into the gas key’s balance. It can be used repeatedly to top up the key
  3. Use: transactions signed with the gas key specify a nonce_index selecting which nonce lane to use, and consume gas from the key’s balance
  4. Withdraw: a WithdrawFromGasKey action moves NEAR from the key’s balance back to the account. Only the account itself can withdraw
  5. Delete: a DeleteKey action removes the key. Any remaining balance is burned, so the action fails if the key holds more than 1 NEAR — withdraw first, then delete
Deleting a gas key burns whatever balance is left on it — this is a protocol-level protection against spam attacks, not a bug. Always WithdrawFromGasKey before deleting. The deletion (and likewise DeleteAccount) fails if more than 1 NEAR would be burned, protecting you from losing significant funds by accident.

​
How Gas Keys Pay for Transactions

When a transaction is signed with a gas key:
  • The gas costs (both burned gas and gas prepaid for function calls) are charged to the gas key’s balance
  • Any attached NEAR (deposits, transfers) is still paid from the account’s main balance
  • Gas refunds for unspent gas return to the gas key’s balance, so the key sustains itself between top-ups, while balance refunds go to the account
If the gas key’s balance cannot cover a transaction’s gas, the transaction is rejected. If the gas is covered but the account cannot pay the attached deposit at execution time, the transaction fails and the burned gas is still charged to the gas key.

​
Using Nonce Lanes

Each of the key’s num_nonces lanes keeps its own independent nonce. A transaction signed with a gas key picks a lane through a nonce_index field (from 0 to num_nonces - 1), and only that lane’s nonce advances. Two transactions on different lanes can never conflict, so a sender can run one lane per worker and submit transactions concurrently — with a single key to manage. You can inspect a gas key’s lanes with the view_gas_key_nonces RPC query, and gas keys appear in view_access_key with their balance and num_nonces.
Tooling supportYou can create and manage gas keys with the NEAR CLI (near account add-key ... grant-gas-key-full-access, fund-gas-key, withdraw-from-gas-key, view-gas-key-nonces) and from your app with the near-kit (TypeScript) and near-kit-rs (Rust) libraries — both cover creating, funding, withdrawing, signing on a nonce lane, and reading a key’s lanes via view_gas_key_nonces. Contracts can also add and fund gas keys through batch-promise host functions — though only the account’s own transactions can withdraw from one.
Gas keys also work with meta transactions: the new DelegateV2 action lets a user sign a delegate action on a gas key’s nonce lane, enabling relayers to sponsor gas end to end.

​
Signature Schemes

Independently of its permission level, every access key is a cryptographic key pair belonging to one of NEAR’s supported signature schemes. A public key is written as <scheme>:<base58-data>, where the prefix identifies the scheme — for example ed25519:CQLP1o1F3Jbdttek3GoRJYhzfT.... ed25519 is the default scheme, used by most wallets and tooling and by NEAR implicit accounts. secp256k1 is used mainly for chain signatures and Ethereum-compatible flows. A single account can hold keys from different schemes at the same time.

​
Post-Quantum Keys (ML-DSA-65)

ml-dsa-65 is a post-quantum signature scheme, standardized by NIST as FIPS 204 (Module-Lattice-Based Digital Signature Algorithm, security category 3). Unlike ed25519 and secp256k1 — whose security a large enough quantum computer could break — ml-dsa-65 is designed to stay secure against quantum attacks, so an account protected by an ml-dsa-65 key cannot be taken over by forging its signature. You add and use an ml-dsa-65 key exactly like any other key: it can be a full-access or a function-call key, and it signs transactions the same way.
Post-quantum keys are stored by hashAn ml-dsa-65 public key is large — 1952 bytes, versus 32 for ed25519 — and its signatures are 3309 bytes. To keep accounts cheap to store, NEAR does not keep the full public key on-chain; instead it stores a 32-byte SHA3-256 hash of it — the same size as an ed25519 public key — which keeps the per-key storage cost close to that of a classical key.
Because only the hash is stored, listing an account’s keys returns the hash, not the full key, for ml-dsa-65 entries. When you query an account’s keys (for example with view_access_key_list), ml-dsa-65 keys appear with an ml-dsa-65-hash: prefix instead of ml-dsa-65::
To recognize one of your own post-quantum keys in such a list, derive the same handle from your public key: it is the SHA3-256 hash of the domain-separation tag near:ml-dsa-65-pubkey-hash:v1 followed by the raw 1952-byte public key. Hashing the key without that prefix will not match the returned value. To look up a specific key directly with view_access_key, pass the full ml-dsa-65: public key and the network hashes it for you. You can create and manage ml-dsa-65 keys today with the NEAR CLI, and from your app with the near-kit (TypeScript) and near-kit-rs (Rust) libraries. Contracts can add them via near-sdk-rs with no code changes.
Post-quantum support currently covers transaction signing and access keys. Validator (staking) keys, block production, and implicit account addresses continue to use ed25519.

​
Limited Access Key Caveats

​
Account with Only Function-Call Keys

If an account has no full-access keys and only function-call keys, it becomes effectively restricted:
  • It cannot transfer NEAR, delete itself, or manage its own keys
  • It can only perform the specific contract calls defined by the key’s receiver_id and method_names
This is useful for creating restricted sub-accounts (e.g. for chain signatures), but be aware the account cannot be recovered or reconfigured through standard transactions.
Creating a sub-account with only a single function-call key means that account will never be able to remove itself, transfer NEAR out, or add new keys — unless the target contract provides a method to do so.

​
Allowance Exhaustion

The allowance field defines how much NEAR the key can spend on gas fees:
  • If set to a specific amount and fully consumed → the key becomes unusable and no new transactions can be signed
  • If set to 0 or omitted → unlimited allowance (the key has no gas budget restriction)
If an account has only function-call keys and the allowance runs out, the account is permanently locked from initiating any transaction. Either use unlimited allowance (0) or ensure the account is topped up with NEAR before the allowance is exhausted.

​
Locked Accounts

If you remove all keys from an account, then the account will become locked, meaning that no external actor can perform transactions in the account’s name. In practice, this means that only the account’s smart contract can transfer assets, create sub-accounts, or update its code. Locking an account is very useful when one wants to deploy a contract, and let the community be assured that only the contract is in control of the account.
An account could still add keys to itself through a smart contract, effectively allowing the contract to unlock the account. Notice that this can only be done if the contract is deployed before the account is locked