NEAR Protocol provides a unique approach to account identification. Named accounts in NEAR are natively supported and are a fundamental part of the protocol’s design.

In NEAR, an account ID is a human-readable name, similar to an email address. Account IDs can be hierarchical, meaning they can be subnames of other accounts, akin to subdomains.

For example, if there’s an account with ID “example.near”, you can create a subaccount under this account, like “sub.example.near”. In this hierarchy, only the “example.near” account can create subaccounts that end with “.example.near”.

However, the account IDs are not managed by smart contracts. The NEAR protocol itself handles the creation, deletion, and management of these accounts. Accounts and their associated state (like account balance and contract state) are stored in the NEAR Protocol’s underlying state trie, a merkle tree that is used for storing the blockchain’s state.

The “near” contract you mentioned might be application-specific contracts that work on top of the basic account system.

NEAR account has follow features:

1. Native supported named account. NEAR name is supported by protocol itself, not smart contract. An account can create its immediate sub-account. For example, near can create alice.near, alice.near can create hi.alice.near. Currently we can create .near account because the account near has deployed a contract that allow anybody to create its sub-account. Specially, top-level account registrar is the only account that can create other top-level account with length < 32, registrar doesn t deploy any contract and it is controlled by NEAR Fundation. A implicit account is calculated by a private key, essentially, it is also a top-level account with a length of 64. When you transfer $NEAR to a implicit account, it will auto created if not exists, but if you transfer $NEAR to a named account which is not exists, transfer will failed and refund the $NEAR.

2. Abstract account. NEAR protocol does not distinguish between contract accounts and regular accounts. You can deploy contract to a exist account.

3. Multiple key pair model. You can bind multiple public key to an account (including implicit account). There are two permission kind of the key, FullAccess and FunctionCall, you can check here. If you delete all FullAccess public keys from an account, the account will be a locked account, only smart contract deployed on that account can fully control that account.