Skip to main content
NEAR supports implicit accounts with 64-character hexadecimal IDs derived locally from an ED25519 public key. An account can be created with no initial deposit; the creator pays a 0.007 NEAR creation charge through gas fees, plus the other transaction fees.
See the NEAR account model for account types, access keys, and permissions.

Implicit Accounts

An ED25519 implicit account ID is the 64-character lowercase hexadecimal encoding of its 32-byte public key. Exchanges can derive deposit addresses locally before creating the accounts on-chain. The corresponding private key signs transactions after account creation.

Generate a key pair and account ID

These examples generate an ED25519 key pair and derive the account ID locally; they do not create the account on-chain.
The CLI saves the credentials to ~/.near-credentials/implicit.
This Python example derives the account ID from a public key:

Create the account on-chain

Deriving an address locally does not create the account on-chain. Before the account can send transactions, including meta-transactions, it must be created on-chain and its creation charge paid. The first transfer to the address creates the account, including a transfer of 0 NEAR. The sender pays the 0.007 NEAR creation charge through gas fees, plus other transaction fees. See account creation costs. For example, this transaction created the implicit account f44f3... by sending a zero-deposit transfer using the command:
Once created on-chain, an implicit account can send transactions using its access key. See Sending Withdrawals for CLI and SDK examples.

Key management and recovery

Backup keys can provide signing authority if another key is lost or deleted. Recovery depends on the access keys and contract permissions that remain available.

Loss of FullAccess key

Loss of the only FullAccess private key removes the ability to sign transactions with that key. Only if the account had a smart contract with a recovery method implemented - which is not the default - can the account potentially be recovered after losing the FullAccess key.

Loss of FunctionCall access key

Function call keys do not have the authority to perform native transfers or replace other keys on the account. Deleting a FunctionCall access key revokes its on-chain permissions to call methods on a specific smart contract. Be careful when removing these keys, specially if they are the only remaining access keys for the account.

Frequently Asked Questions

See Account IDs for address formats and derivation.
User can have one or multiple NEAR Accounts. Each account lives on a single shard, can hold a smart contract, and store multiple keys for signing transactions.You can read more about NEAR accounts here
Account creation has a 0.007 NEAR creation charge, collected through gas fees.NEAR supports zero-balance accounts: an account can be created with an initial deposit of 0 NEAR, while the creator still pays the creation charge and transaction fees.
Accounts pay for their own stored data. For accounts using 770 bytes or less, the creation charge covers this storage, so no additional storage balance is required.Accounts using more than 770 bytes must reserve a balance to cover all their stored data, including the first 770 bytes, at 10^19 yoctoNEAR (0.00001 NEAR) per byte. Query the current price using protocol_config; see storage staking.Deleting stored data reduces the storage requirement, making any balance no longer needed for storage available.Creation charges and transaction gas are separate from the balance retained for storage; see account creation costs.An account can remain active with a zero balance if it meets the storage requirements above. Explicit deletion removes its native account state. Recreating the account starts with fresh state.
An account can have arbitrarily many keys, as long as it has enough tokens for their storage.
Account keys support ed25519, secp256k1, and ML-DSA-65, with different encodings and signing rules. The transaction examples use ED25519. Consult the cryptographic definitions for your node version when implementing other key types.