- 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)
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.