Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.near.org/llms.txt

Use this file to discover all available pages before exploring further.

NEAR accounts are identified by a unique address, which can take multiple forms:
  1. Implicit address, which are 64 characters long (e.g. fb9243ce...)
  2. Named address, which act as domains (e.g. alice.near, sub.account.testnet)
  3. An ethereum-like account (e.g. 0x85f17cf997934a597031b2e18a9ab6ebd4b9f6a4)
  4. Deterministic address, which start with 0s (e.g. 0s85f17cf997934a597031b2e18a9ab6ebd4b9f6a4)
In NEAR, accounts can actually be any string as long as they meet the following criteria:
  • It must have at least 2 characters and can go up to 64 characters
  • It can only use lowercase letters (a-z), digits (0-9), and separators (., -, _)
This means that all root, some-unique-string, something-to-remember-later, 0x85f17...., fb9243ce and user.name are all valid account IDs.However, users can only create accounts that are either a named address, an implicit address, or an ethereum-like address
Searching to create an account?You have multiple ways to create an account, you can create a web wallet, create a mobile wallet through telegram or choose any of the available NEAR wallets.

Implicit Address

Implicit accounts are denoted by a 64 character address, which corresponds to a unique public/private key-pair. Who controls the private key of the implicit account controls the account. For example:
  • The private key: ed25519:4x1xiJ6u3sZF3NgrwPUCnHqup2o...
  • Corresponds to the public key: ed25519:CQLP1o1F3Jbdttek3GoRJYhzfT...
  • And controls the account: a96ad3cb539b653e4b869bd7cf26590690e8971...
Implicit accounts always exist, and thus do not need to be created. However, in order to use the account you will still need to fund it with NEAR tokens (or get a relayer to pay your transaction’s gas).
In NEAR, you can delete the private key of an implicit account, which effectively locks the account and prevents anyone to control it
The simplest way to obtain a public / private key that represents an account is using the NEAR CLI
near account create-account fund-later use-auto-generation save-to-folder ~/.near-credentials/implicit

# The file "~/.near-credentials/implicit/8bca86065be487de45e795b2c3154fe834d53ffa07e0a44f29e76a2a5f075df8.json" was saved successfully

cat ~/.near-credentials/implicit/8bca86065be487de45e795b2c3154fe834d53ffa07e0a44f29e76a2a5f075df8.json
or using the near-seed-phrase library:
import { generateSeedPhrase } from "near-seed-phrase";
const { seedPhrase, publicKey, secretKey } = generateSeedPhrase();
You can derive the implicit account address from a public key by removing the ed25519: prefix, decoding the resulting Base58 string into bytes, and then converting those bytes into a hexadecimal string.
// vanilla js
import { decode } from 'bs58';
Buffer.from(decode(publicKey.replace('ed25519:', ''))).toString('hex')

// or using near-api-js
import { utils } from 'near-api-js';
utils.keyToImplicitAddress(publicKey);

Named Address

Users can register named accounts (e.g. bob.near) which are easy to remember and share. An awesome feature of named accounts is that they can create sub-accounts of themselves, effectively working as domains:
  1. The registrar account can create top-level accounts (e.g. near, sweat, kaiching).
  2. The near account can create sub-accounts such as bob.near or alice.near
  3. bob.near can create sub-accounts of itself, such as app.bob.near
  4. Accounts cannot create sub-accounts of other accounts
    • near cannot create app.bob.near
    • account.near cannot create sub.another-account.near
  5. Accounts have no control over their sub-account, they are different entities
Anyone can create a .near or .testnet account, you just need to call the create_account method of the corresponding top-level account - testnet on testnet, and near on mainnet.
In NEAR, named accounts are created using the CreateAccount action. Both testnet and near accounts expose the function create_account, which triggers CreateAccount to create sub-accounts of themselves.For example, if we want to create the account alice.testnet with 0.1 NEAR, we would need to call the create_account method of testnet using an existing account (e.g. funding-account.testnet):
near call testnet create_account '{"new_account_id": "alice.testnet", "new_public_key": "ed25519:<data>"}' --useAccount funding-account.testnet --networkId testnet
If we then want to create a sub-account of alice.testnet - which we control - we can simply trigger the CreateAccount action ourselves:
near create-account sub-acc.new-acc.testnet --useAccount new-acc.testnet
Note: if you want the accounts to have some initial balance, you can add the --deposit <amount in NEAR> flag to the command above
Creating Named AccountsIf you are not going through an intermediary (i.e. the CLI, or a wallet), then you can create an implicit account, fund it, and call create_account on near / testnet

Ethereum-like Address

NEAR also supports Ethereum-like accounts which are identified by a hexadecimal address (e.g. 0x85f17cf997934a597031b2e18a9ab6ebd4b9f6a4). These accounts are automatically created when a user signs in on a NEAR application using an Ethereum wallet such as MetaMask.

Deterministic Address

Deterministic accounts are a special type of account whose address is derived deterministically from their initial contract code and state. They are identified by an address starting with 0s followed by 40 lowercase hexadecimal characters (42 characters total). For example: 0s85f17cf997934a597031b2e18a9ab6ebd4b9f6a4 The key property of a deterministic account is that its address is computed from its initial state, meaning you can know the account’s address before it is even created. This is useful for protocols and applications that need to reference a contract address before deployment.
The deterministic account ID is computed by:
  1. Constructing a DeterministicAccountStateInit struct containing:
    • Code: a reference to the contract code via a code hash or an existing account ID
    • Initial data: a key-value mapping pre-populating the contract’s storage (max 4 MiB per key/value)
  2. Borsh-encoding that struct into bytes
  3. Applying the formula: '0s' + keccak256(bytes)[12:32].hex()
This guarantees that two accounts with identical code and initial state will always have the same address.
Deterministic accounts are created using the DeterministicStateInit action — not the standard CreateAccount action. The protocol validates that the supplied account ID matches the hash of the provided initial state.Smart contracts can build this action using the following host functions:
  • promise_batch_action_state_init — creates a DeterministicStateInit action referencing a code hash
  • promise_batch_action_state_init_by_account_id — creates the action referencing an existing account’s code
  • set_state_init_data_entry — adds a key-value entry to the account’s initial storage
  • current_contract_code — returns the calling contract’s own code hash, useful for deploying clones
Any NEAR attached beyond the required storage deposit is refunded to the sender.
Deterministic accounts cannot be deleted and certain account modifications available to regular accounts are restricted. Once created, the deployed code and pre-initialized storage are permanent.