NEAR accounts are identified by a unique address, which can take multiple forms: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.
- Implicit address, which are 64 characters long (e.g.
fb9243ce...) - Named address, which act as domains (e.g.
alice.near,sub.account.testnet) - An ethereum-like account (e.g.
0x85f17cf997934a597031b2e18a9ab6ebd4b9f6a4) - Deterministic address, which start with
0s(e.g.0s85f17cf997934a597031b2e18a9ab6ebd4b9f6a4)
Valid Account IDs
Valid Account IDs
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 (.,-,_)
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 addressImplicit 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...
🧑💻 Technical: How to obtain a key-pair
🧑💻 Technical: How to obtain a key-pair
The simplest way to obtain a public / private key that represents an account is using the NEAR CLIor using the
near-seed-phrase library:🧑💻 Technical: How to derive an implicit account from a public key
🧑💻 Technical: How to derive an implicit account from a public key
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.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:
- The
registraraccount can create top-level accounts (e.g.near,sweat,kaiching). - The
nearaccount can create sub-accounts such asbob.nearoralice.near bob.nearcan create sub-accounts of itself, such asapp.bob.near- Accounts cannot create sub-accounts of other accounts
nearcannot createapp.bob.nearaccount.nearcannot createsub.another-account.near
- Accounts have no control over their sub-account, they are different entities
.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.
🧑💻 Technical: How Are Named Accounts Created?
🧑💻 Technical: How Are Named Accounts Created?
In NEAR, named accounts are created using the If we then want to create a sub-account of
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):alice.testnet - which we control - we can simply trigger the CreateAccount action ourselves:
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 / testnetEthereum-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 with0s 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.
🧑💻 Technical: How is the address derived?
🧑💻 Technical: How is the address derived?
The deterministic account ID is computed by:
- Constructing a
DeterministicAccountStateInitstruct 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)
- Borsh-encoding that struct into bytes
- Applying the formula:
'0s' + keccak256(bytes)[12:32].hex()
🧑💻 Technical: How are deterministic accounts created?
🧑💻 Technical: How are deterministic accounts created?
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 aDeterministicStateInitaction referencing a code hashpromise_batch_action_state_init_by_account_id— creates the action referencing an existing account’s codeset_state_init_data_entry— adds a key-value entry to the account’s initial storagecurrent_contract_code— returns the calling contract’s own code hash, useful for deploying clones
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.