NEAR Account Model: Names, Keys & Storage

Contents

• What Is NEAR Protocol?
• TL;DR: NEAR Account Model at a Glance
• What Is the NEAR Account Model?
• Named Accounts and Implicit Accounts: How NEAR Identifies Users
• Sub-accounts: Hierarchical Account Organization on NEAR
• NEAR Access Keys: Full Access vs. Function Call Permissions
• Storage Staking: Why NEAR Accounts Require a Minimum Balance
• NEAR Account Model vs. Ethereum: A Side-by-Side Comparison
• Getting Started: Creating and Managing Your NEAR Account
• Frequently Asked Questions: NEAR Account Model
• Conclusion: What the NEAR Account Model Means for Developers and Users

What Is NEAR Protocol? (A Brief Introduction)

NEAR Protocol is a Layer-1, proof-of-stake blockchain built for developer accessibility, with low and predictable transaction fees and a sharding architecture designed to scale without sacrificing usability. Co-founded by Illia Polosukhin and Alexander Skidanov, NEAR Protocol was designed from the start with developer experience and end-user accessibility as primary goals, rather than retrofitting usability onto an architecture built for other purposes.

NEAR scales through Nightshade sharding, a mechanism that distributes account state and computation across parallel processing chains, allowing the network to handle high transaction volumes without proportionally increasing fees. The protocol supports smart contracts compiled to WebAssembly and keeps gas costs low by design, in contrast to blockchains where fee volatility creates friction for both developers and users. Ecosystem development is overseen by the NEAR Foundation, the nonprofit governance body that previously operated the official NEAR Wallet before transitioning to community-maintained alternatives.

The clearest expression of this developer-first philosophy is NEAR's account model, a design that rethinks how blockchain identity and permission management work from the ground up.

TL;DR: NEAR Account Model at a Glance

Quick summary for skim readers:

• NEAR accounts use human-readable names (e.g., alice.near) instead of cryptographic hash strings like Ethereum's 0x742d35Cc... addresses.
• Each account can hold multiple access keys simultaneously, each with its own permission level, from unrestricted control to narrowly scoped contract interactions.
• Any NEAR account can deploy a smart contract; there is no separate contract account type as in Ethereum.
• Sub-accounts follow a hierarchical namespace (e.g., contract.myapp.near under myapp.near), working like subdomains for blockchain accounts.
• Accounts must maintain a minimum NEAR token balance proportional to their on-chain storage usage, a mechanism called storage staking.
• NEAR's native multi-key permission system achieves many of the goals that Ethereum is building toward with account abstraction (EIP-4337), but through a different architectural approach built in from inception.

What Is the NEAR Account Model?

The NEAR account model is the on-chain identity and permission architecture that defines how accounts are named, what state they store, how access is managed through granular key permissions, and how they relate to smart contracts on the NEAR blockchain.

In blockchain context, an "account model" refers to the system a protocol uses to represent participants on-chain: what an account contains, how it is identified, how it authorizes transactions, and whether it can execute code. Ethereum uses one account model; Bitcoin uses a different paradigm entirely (the UTXO model, where balances are tracked as unspent transaction outputs rather than account balances). NEAR uses an account-based model, but its implementation differs significantly from Ethereum's in ways that matter for both usability and application development.

A NEAR account holds five things simultaneously: a unique account ID, a NEAR token balance, account state (on-chain data storage), an optional deployed smart contract compiled to WebAssembly (WASM, enabling contracts written in Rust or JavaScript), and one or more access keys with distinct permission levels. This unified structure means there is no separation between "user accounts" and "smart contract accounts" as in Ethereum. Any NEAR account can optionally host a smart contract without becoming a different category of object. Accounts without deployed contracts function as ordinary user accounts; accounts with deployed contracts are simultaneously user accounts and contract hosts.

The practical context for understanding why this matters is the decentralized application (dApp), a software application that runs on a blockchain network rather than centralized servers. NEAR's account architecture was designed to make dApp interactions more secure and more accessible than existing blockchain account models allow. The account ID system is where this design philosophy is most immediately visible, and that is where the architecture tour begins.

For the complete technical specification, see the NEAR Protocol account model documentation at docs.near.org/concepts/basics/accounts/model.

Named Accounts and Implicit Accounts: How NEAR Identifies Users

NEAR identifies users and applications on-chain through two account formats: named accounts, which use human-readable strings like alice.near, and implicit accounts, which are 64-character hex strings derived from a public key.

Named Accounts: Human-Readable Blockchain Identities

Named accounts on NEAR are human-readable account identifiers that follow a domain-like structure, ending in .near on mainnet and .testnet on testnet, replacing the cryptographic hash strings used by blockchains like Ethereum.

The contrast is immediate: alice.near versus 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. Both are valid blockchain identifiers, but one is readable and the other requires careful copy-paste verification. Think of a NEAR named account like an email address: readable and tied to an identity, rather than a random string of characters that requires character-by-character comparison to verify.

Named accounts follow specific naming rules: account IDs are alphanumeric strings, can use dots as separators, must be between 2 and 64 characters, and must end in .near on mainnet or .testnet on the test network. The dot-separated structure creates a domain-like hierarchy: myapp.near is a top-level named account, and contract.myapp.near is a sub-account under it (more on sub-accounts in the next section).

The UX rationale behind named accounts goes beyond aesthetics. Readable identifiers reduce the risk of sending transactions to wrong accounts, make contract addresses discoverable, and lower the cognitive overhead of managing on-chain identities. For anyone who has triple-checked a MetaMask address before sending a transaction, the appeal of alice.near over a 42-character hex string is concrete rather than abstract. Users register and manage named accounts through MyNEARWallet at mynearwallet.com, the primary community-maintained account interface (the original wallet.near.org operated by NEAR Foundation has been deprecated).

Implicit Accounts: The Alternative Account Format

Implicit accounts are the second account format on NEAR: 64-character lowercase hex strings derived directly from a public key, which come into existence as soon as NEAR tokens are sent to that account ID without requiring any action from an existing account.

The key practical distinction: a named account requires an existing on-chain account to sponsor its registration via a transaction, while an implicit account comes into existence automatically when funds arrive at the derived account ID. This makes implicit accounts useful in contexts where bootstrapping from scratch is needed, or where human-readable names are unnecessary. Cryptocurrency exchanges typically use implicit accounts when crediting NEAR deposits to users, generating a unique account ID from the user's public key without requiring a pre-existing on-chain account.

One disambiguation worth stating plainly: implicit accounts are not anonymous. They are deterministically derived from a public key and are fully transparent on-chain. The word "implicit" refers to how the account ID is derived (from the key itself, without an explicit registration step), not to any privacy property.

Named and implicit accounts establish how NEAR identifies participants on-chain. Accounts can also contain other accounts under their namespace, and that hierarchical structure is where sub-accounts come in.

Sub-accounts: Hierarchical Account Organization on NEAR

Sub-accounts on NEAR work like subdomains on the web: just as docs.myapp.com and api.myapp.com are distinct addresses under the myapp.com domain, token.myapp.near and staking.myapp.near are distinct blockchain accounts under the myapp.near namespace.

A sub-account is an account whose ID exists under a parent account's namespace. The account contract.myprotocol.near is a sub-account of myprotocol.near. Only the parent account can create a sub-account: myprotocol.near can create contract.myprotocol.near, but no other account can create an account under that namespace without the parent's authorization.

Important: A parent account cannot access a sub-account's funds or state after the sub-account is created. Sub-accounts are fully independent accounts that share a namespace only, not subsidiaries controlled by a parent.

This independence is a common point of confusion. The parent-child relationship applies only at creation time. Once contract.myprotocol.near exists, it has its own access keys, its own NEAR token balance, and its own on-chain state. The parent account myprotocol.near has no special privileges over it.

For dApp developers, sub-accounts provide a practical architecture pattern. Since any NEAR account can deploy a smart contract (compiled to WASM), sub-accounts become a natural way to give each contract component a readable, organized account ID. A DeFi protocol might deploy token.myprotocol.near for its token contract, staking.myprotocol.near for its staking contract, and governance.myprotocol.near for its governance contract. Each is a distinct account with its own contract, its own state, and its own key management, but the namespace makes the relationship between components immediately legible to anyone reading the chain. For step-by-step sub-account creation instructions, see the NEAR sub-account documentation at docs.near.org/concepts/basics/accounts/model#named-accounts.

Understanding how accounts are named and organized sets the stage for the next architectural layer: how they are secured and permissioned through access keys.

NEAR Access Keys: Full Access vs. Function Call Permissions

NEAR access keys are the permission layer that controls what actions can be taken on a NEAR account, and the system's most architecturally distinctive feature: a single NEAR account can hold multiple independent key pairs simultaneously, each with its own permission level.

How NEAR's Multi-Key System Works

Unlike most blockchain accounts, where one private key controls everything, a single NEAR account can hold multiple independent key pairs, each assigned a specific permission type, from unrestricted control to narrowly scoped contract interactions.

NEAR access keys use Ed25519 key pairs by default (with secp256k1 also supported for Ethereum toolchain compatibility). The permission system built on top of these key pairs is what makes NEAR's model architecturally distinct. Think of it like a keyring: a Full Access Key is the master key that opens every lock; a Function Call Access Key is a purpose-built key that only opens one specific door. Every transaction signed by any access key on an account consumes gas paid in NEAR tokens, but NEAR's transaction fees are low and predictable by design, in contrast to Ethereum's historically variable gas pricing.

For details on adding and managing access keys programmatically, see the NEAR access keys reference documentation at docs.near.org/concepts/basics/accounts/access-keys.

Full Access Keys: Unrestricted Account Control

A Full Access Key on NEAR is a key pair that can perform any action on the account it is attached to: transfer tokens, deploy smart contracts, create sub-accounts, add or delete other keys, and delete the account itself.

Because a Full Access Key controls the entire account, it carries the same risk profile as a master password. Full Access Keys should never be shared with third-party applications and should be stored in cold storage (hardware wallet or offline storage) for any account holding significant funds. If a Full Access Key is compromised, the attacker has complete control of the account with no native recovery mechanism unless one was configured in advance.

The comparison to Ethereum is instructive here. In Ethereum, your single private key for an Externally Owned Account (EOA) functions as a Full Access Key: it controls everything, and there is no native way to grant a dApp a lower-permission key for a specific contract interaction. Every dApp connection through MetaMask exposes your full account key to the transaction signing flow. That single-key limitation is precisely the problem that EIP-4337 account abstraction is designed to address on Ethereum. On NEAR, the solution was built into the base account model.

Function Call Access Keys: Scoped Permissions for dApp Security

A Function Call Access Key is a restricted key that can only call specified methods on one designated smart contract, with an optional gas allowance cap that limits total fee expenditure.

Where a Full Access Key is unrestricted, a Function Call Access Key is precisely bounded. The key specifies: one contract account ID it is permitted to call, which methods on that contract it can invoke (or all public methods, if not further restricted), and an optional NEAR token allowance that caps how much gas the key can spend before it requires replenishment. Once the allowance is exhausted, the key cannot sign further transactions until it is topped up or replaced.

The session-based authentication use case is where Function Call Access Keys show their practical value for dApp development. When you connect a dApp to your NEAR account, the dApp requests a Function Call Access Key scoped to its own contract. This key is stored in your browser session. From that point, the dApp can submit transactions on your behalf (approving a trade, minting an NFT, interacting with a game contract) without prompting you to sign each individual action. Your Full Access Key never leaves your secure wallet. If the dApp is compromised or malicious, the damage is bounded: the attacker can only call the specific contract methods the key was scoped to, and only up to the allowance amount. A Function Call Access Key functions like a session token in a web application: it grants temporary, scoped access to specific actions without exposing the full account credentials.

Access keys control what actions an account can take. Storage staking governs what an account must hold to exist on-chain.

Storage Staking: Why NEAR Accounts Require a Minimum Balance

Storage staking on NEAR is the mechanism by which every account must maintain a minimum NEAR token balance proportional to the amount of on-chain storage (state) the account uses.

The mechanism works as follows: NEAR allocates on-chain storage measured in bytes. For every byte of state stored in an account (balance records, contract code, stored data, access keys), a corresponding amount of NEAR tokens must be held in the account balance. Those tokens are not spent or destroyed; they are reserved as a locked balance against the storage footprint. If you reduce your account's storage by deleting state or contract data, the corresponding tokens are unlocked and returned to your available balance. Storage staking works like a refundable security deposit: you lock a proportional amount of NEAR tokens for the storage your account uses, and you get those tokens back if you reduce your storage footprint.

The purpose of this design is economic: it prevents state bloat by ensuring that the party benefiting from on-chain storage bears the cost of that storage. Without a mechanism like this, a blockchain network can accumulate unbounded amounts of dead state from abandoned accounts or contracts, degrading performance for all participants.

In concrete terms, the storage staking rate is approximately 1 NEAR token per 10 KB of on-chain storage, and a freshly created empty NEAR account requires a minimum balance of approximately 0.00182 NEAR to cover its base state footprint. Verify current figures against the NEAR storage staking documentation at docs.near.org/concepts/storage/storage-staking before relying on these numbers for development planning, as protocol parameters change with upgrades.

For smart contract developers, the storage staking implication requires active planning. When a NEAR account deploys a contract, the contract code itself occupies storage in the account state. A larger contract binary requires a proportionally larger reserved balance. If your contract stores significant data (user records, token balances, governance votes), the account hosting that contract must maintain a balance large enough to cover both the contract code and the accumulated state. This is a capital requirement that scales with application usage, and it needs to be accounted for in your economic model before deployment.

Storage staking creates a real capital lock-up requirement. Some developers find this constraining compared to chains that do not require reserved storage balances. The trade-off is deliberate: the constraint prevents the network state from growing without bound, and the tokens are recoverable. But the constraint is real and should be planned for rather than discovered after deployment.

Storage staking vs. validator staking: These are two distinct mechanisms on NEAR. Storage staking locks NEAR tokens against your account's on-chain data footprint; those tokens act as a reserved balance proportional to storage used. Validator staking locks NEAR tokens against the consensus mechanism, where validators stake tokens to participate in block production and earn staking rewards. This article covers storage staking only. Do not conflate these two uses of the word "staking."

Gas fees (transaction execution costs) are separate from storage staking. Gas fees are consumed per transaction and paid in NEAR tokens at the time of signing; storage staking is a reserved balance that persists with the account as long as the associated state exists.

Understanding storage staking completes the picture of how NEAR accounts work in isolation. The next question is how this architecture compares to Ethereum's.

NEAR Account Model vs. Ethereum: A Side-by-Side Comparison

NEAR and Ethereum take fundamentally different approaches to on-chain account architecture, and the differences are consequential for how developers build decentralized applications and how users manage their on-chain identities.

Ethereum's Two-Account System vs. NEAR's Unified Account Model

The table below contrasts the two account models across eight architectural dimensions. The most significant difference is that Ethereum separates user accounts (Externally Owned Accounts, or EOAs) from smart contract accounts into two distinct types, while NEAR uses a single unified account type for both.

Ethereum's EOA and Contract Account separation creates friction in practice. Most dApp interactions require an EOA to call a Contract Account, meaning users must manage both types as distinct entities. An EOA is controlled by a single private key with no native way to scope permissions: any dApp connected to a MetaMask account can request signatures that expose the full account key to the transaction flow. Ethereum's model has clear design rationale and served its original goals well, but the single-key limitation became apparent as dApp interactions grew more frequent and varied.

NEAR's unified account type eliminates the EOA/contract separation. Every NEAR account is potentially a contract host, and the multi-key system with Function Call Access Keys addresses the single-key limitation without requiring a separate protocol layer. Both NEAR and Ethereum operate in the account-based paradigm, in contrast to Bitcoin's UTXO model where balances are tracked as unspent transaction outputs rather than account state; the difference between NEAR and Ethereum lies in how those accounts are structured and permissioned, not in the fundamental paradigm.

NEAR's Account Model and Ethereum Account Abstraction (EIP-4337)

EIP-4337 (account abstraction) is Ethereum's effort to give EOAs the kind of programmable permission and session-key capabilities that NEAR's account model was designed to include from the start.

EIP-4337 is a live Ethereum standard (not a theoretical proposal) that enables smart contract wallets to function as first-class citizens, supporting programmable transaction validation, session keys, social recovery, and sponsored transactions. It requires specific bundler infrastructure to operate and is actively deployed across the Ethereum ecosystem, though it is not a universal upgrade applied to all accounts automatically.

The parallel with NEAR's Function Call Access Keys is real: both approaches address the problem of granting dApps scoped, limited-permission access for specific interactions without exposing the full account key. A developer familiar with EIP-4337 session keys will find NEAR's Function Call Access Keys conceptually familiar. The important nuance is that these are architecturally distinct implementations of overlapping ideas, not identical systems. NEAR's multi-key permission model is native to the base protocol; EIP-4337 layers smart contract wallet logic on top of Ethereum's existing EOA model. The problems they address overlap significantly; the mechanisms differ. For the complete EIP-4337 specification, see the EIP-4337 account abstraction specification at eips.ethereum.org/EIPS/eip-4337.

For Ethereum developers evaluating NEAR, two ecosystem bridges are worth noting. Aurora at aurora.dev, an EVM-compatible environment built on NEAR, allows Ethereum developers to deploy Solidity contracts on NEAR infrastructure while NEAR accounts serve as the underlying identity layer. Developers working across both ecosystems can use Rainbow Bridge at rainbowbridge.app to transfer assets between NEAR accounts and Ethereum addresses without relying on centralized custody.

Now that the architecture is clear, here is what creating and managing a NEAR account actually involves in practice.

Getting Started: Creating and Managing Your NEAR Account

You can create your first NEAR account through MyNEARWallet at mynearwallet.com, the primary community-maintained interface for NEAR account registration and key management. Verify the current canonical wallet recommendation at the time you read this, as the NEAR wallet ecosystem continues to evolve; other compatible wallet applications exist alongside MyNEARWallet.

If you are coming from Ethereum and MetaMask, the conceptual difference is worth understanding before you start. A MetaMask wallet is primarily a key manager and transaction signer for Ethereum EOAs: it holds your private key and presents it to dApps for transaction signing. A NEAR account is a full on-chain identity with a readable name, on-chain state storage, programmable key permissions, and optional contract hosting. The wallet application (MyNEARWallet) is the interface; the NEAR account is the on-chain object. These are different things, and the distinction matters for how you think about key management.

Creating a NEAR account requires a small initial NEAR token balance to cover the base storage staking requirement (approximately 0.00182 NEAR for an empty account, as covered in the Storage Staking section above). This initial balance covers the base state footprint of a new account.

Three risks are worth knowing before you start. First, if you lose your Full Access Key with no recovery mechanism configured, the account is unrecoverable. Store your Full Access Key in cold storage and configure any available recovery options before you need them. Second, the NEAR tokens reserved for storage staking are locked as long as the associated state exists; this is a capital commitment, not a fee. Third, account deletion on NEAR is irreversible. For a full step-by-step account creation guide, see the NEAR developer documentation at docs.near.org/concepts/basics/accounts/model.

The most common questions about the NEAR account model are answered below.

Frequently Asked Questions: NEAR Account Model

The questions below address the most common points of confusion about NEAR's account model, with cross-references to the relevant sections above for readers who want full coverage.

Can any NEAR account deploy a smart contract?

Yes. In NEAR, any account can optionally deploy a smart contract compiled to WebAssembly (WASM). There is no separate contract account type, unlike Ethereum where deploying a contract requires creating a distinct Contract Account. An account without a deployed contract functions as a standard user account; an account with a deployed contract functions as both simultaneously. See the What Is the NEAR Account Model section above for the full architectural explanation.

How do NEAR access keys make dApps safer to use?

Function Call Access Keys restrict a dApp to specific contract methods with an optional gas allowance cap. When you connect to a dApp using a Function Call Access Key scoped to that dApp's contract, your Full Access Key (and your full account balance) is never exposed to the third-party application. If the dApp is compromised, the damage is bounded to the allowance and the specified contract. See the NEAR Access Keys section for the complete breakdown.

What happens if I lose my Full Access Key?

Full Access Key loss without a pre-configured recovery mechanism makes the account permanently unrecoverable. You cannot reset or recover a Full Access Key the way you reset a password, because there is no central authority that controls the account. Always store Full Access Keys in secure cold storage, and configure any available account recovery options through your wallet application before you need them. Some wallets offer social recovery or multi-key recovery configurations.

Are gas fees the same as storage staking?

No. Gas fees are per-transaction execution costs consumed at the time a transaction is signed; they are paid in NEAR tokens and do not persist after the transaction completes. Storage staking is a minimum reserved NEAR token balance that persists with the account as long as the associated on-chain state exists. Both involve NEAR tokens, but they operate as entirely separate mechanisms. See the Storage Staking section for the full explanation.

How does NEAR's account model relate to Ethereum's account abstraction (EIP-4337)?

NEAR's native multi-key permission system achieves many of the goals that EIP-4337 is designed to add to Ethereum, including scoped session-based permissions for dApp interactions and programmable key logic. The two are architecturally distinct implementations of overlapping ideas: NEAR's approach is native to the base protocol, while EIP-4337 layers smart contract wallet logic on top of Ethereum's existing EOA model. They solve similar problems through different architectures. See the NEAR vs. Ethereum comparison section for the detailed analysis.

What is the difference between a named account and an implicit account on NEAR?

Named accounts are human-readable identifiers (e.g., alice.near) registered through a transaction from an existing account, ending in .near on mainnet and .testnet on testnet. Implicit accounts are 64-character hex strings derived directly from a public key, which come into existence automatically when NEAR tokens are sent to that account ID, with no registration transaction required. See the Named Accounts and Implicit Accounts section for the full comparison table.

How many access keys can a single NEAR account hold?

A NEAR account can hold multiple access keys simultaneously, with each key assigned its own permission type (Full Access Key or Function Call Access Key) and, for Function Call Access Keys, its own contract scope and gas allowance. There is no hard documented limit on the number of keys per account. This multi-key capability is what distinguishes NEAR's permission model from Ethereum's single-key-per-EOA approach. See the NEAR Access Keys section for details.

Does storage staking mean I lose my NEAR tokens?

No. NEAR tokens reserved for storage staking are locked but not spent. They remain in your account as a reserved balance and are released back to your available balance if you reduce your account's on-chain data footprint by deleting state. The tokens are a deposit against storage usage, not a fee. See the Storage Staking section for the mechanism and current figures.

Conclusion: What the NEAR Account Model Means for Developers and Users

The NEAR account model reflects a set of deliberate architectural choices: human-readable account names lower the barrier to entry and reduce transaction errors; a multi-key permission system reduces security risk for dApp interactions by scoping third-party access without exposing master keys; storage staking creates economic alignment between resource usage and cost; and a unified account-contract structure eliminates the EOA/contract separation that adds friction to Ethereum development.

The storage staking minimum balance requirement is a genuine constraint to plan for, not a footnote. If your application stores significant on-chain state, the reserved balance requirement scales with that state. Budget for it in your application's economic model before deployment, not after.

Next steps by persona:

• Developers: Start building on NEAR Protocol at docs.near.org/develop
• Users: Create your NEAR account at MyNEARWallet at mynearwallet.com
• Researchers: Deep dive into the complete account model specification at NEAR Protocol account model documentation at docs.near.org/concepts/basics/accounts/model

Technical specifications in this article reflect NEAR Protocol at time of writing. NEAR Protocol is actively developed; verify current figures against docs.near.org before relying on specific numeric values for development or operational planning. This content is for informational purposes only and does not constitute financial or investment advice.