NEAR Account Model Explained: Keys & Storage

The NEAR Account Model is NEAR Protocol's protocol-level system for managing account identity and permissions alongside on-chain state. Every account on NEAR has a human-readable account ID, can hold multiple access keys with different permission scopes, and can store both a token balance and a deployed smart contract simultaneously. Blockchains manage value and identity through different systems (Bitcoin uses an Unspent Transaction Output, or UTXO, model, while Ethereum and NEAR use an account-based model where each account holds state directly), and NEAR's account-based design is what makes the architecture covered here possible.

NEAR Protocol is a proof-of-stake (PoS) layer 1 blockchain that launched its mainnet in 2020. It was created by NEAR Inc. (now operating as Pagoda), a developer tooling organization that continues to maintain the NEAR SDK and core protocol infrastructure. NEAR Protocol uses Nightshade sharding to partition the network into parallel shards, and account IDs play a role in shard assignment, which matters for developers thinking about cross-contract call patterns.

Four properties set the NEAR Account Model apart from other layer 1 account systems:

• Account IDs are human-readable strings, not random hexadecimal sequences
• A single account can hold an unlimited number of access keys, each with its own permission scope
• Any account can hold both a token balance and a deployed smart contract, with no architectural distinction between "user accounts" and "contract accounts"
• Accounts must maintain a NEAR token balance proportional to their on-chain storage usage, a mechanism called storage staking

This article covers each of these components in sequence: account ID types, access key types, storage staking, sub-accounts, the Ethereum architectural comparison, and a practical worked example.

Jump to a section:

• NEAR Account IDs: Named Accounts and Implicit Accounts
• NEAR Access Keys: How Account Permissions Work
• Storage Staking: How NEAR Ties Token Balance to On-Chain Storage
• NEAR Sub-Accounts: Hierarchical Account Namespaces
• NEAR Account Model vs. Ethereum: Key Architectural Differences
• What NEAR's Unified Account Architecture Means in Practice
• Frequently Asked Questions About the NEAR Account Model
• Key Takeaways and Next Steps

NEAR Account IDs: Named Accounts and Implicit Accounts

Every NEAR account is identified by a unique account ID. Unlike Ethereum, where accounts are identified by a 42-character hexadecimal address derived from a public key, NEAR account IDs come in two structurally distinct forms: named accounts and implicit accounts. Understanding the difference between them is the foundation for working with NEAR's account system.

Named Accounts: Human-Readable Identifiers

A named account is a human-readable account ID registered under a top-level domain: .near on mainnet, .testnet on the test network. Named accounts work like internet usernames or domain names: they are unique, chosen by the registrant, and easy to share and remember. Examples include alice.near, myprotocol.near, and nft.myprotocol.near. Unlike a username, a named account is a protocol-level object that holds a NEAR token balance, can have a smart contract deployed to it, and controls cryptographic access keys.

Registering a named account requires a small NEAR token deposit. To create one, visit a NEAR-compatible wallet interface such as MyNEARWallet or Meteor Wallet, choose your account ID, and fund the registration deposit. Named accounts can also create sub-accounts within their namespace (for example, alice.near can create app.alice.near), a topic covered in full in the sub-accounts section below.

Named accounts are a native protocol feature built directly into NEAR Protocol's account model. They are not an external naming service layered on top of the protocol, which is how Ethereum Name Service (ENS) works on Ethereum. ENS is a separate smart contract system; NEAR named accounts are a first-class part of the protocol itself.

Implicit Accounts: Derived From Public Keys

An implicit account is a 64-character hexadecimal account ID derived deterministically from an Ed25519 public key. An example implicit account ID looks like: 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. For developers coming from Ethereum, this is the most structurally familiar account type, because the derivation process is analogous to how Ethereum addresses are computed from public keys.

The creation mechanic for implicit accounts differs from named accounts in one key respect: no registration transaction is required. An implicit account becomes active the moment someone sends NEAR tokens to its account ID. This makes implicit accounts well-suited to programmatic account creation, exchange deposit addresses, and scenarios where human-readability is not a priority.

The "implicit" descriptor refers to the creation mechanism, not to anonymity. Implicit accounts are fully owned and controlled by the holder of the private key from which the account ID was derived. One further distinction: an implicit account ID is derived from a public key, but it is not identical to the public key itself. The account ID is a lowercase hex representation of the raw public key bytes. Ethereum developers familiar with address derivation will recognize the pattern, but should not assume the two representations are the same.

Named vs. Implicit Accounts: A Side-by-Side Comparison

The two account ID types differ across five dimensions:

Named accounts suit user wallets and protocol deployments where readability matters. Implicit accounts suit exchanges, programmatic tooling, and scenarios where accounts are created in bulk without user interaction.

NEAR Access Keys: How Account Permissions Work

NEAR access keys are the authorization layer of the account model. Every NEAR account can hold multiple access keys simultaneously, and each key carries a distinct permission scope. A NEAR account can hold an unlimited number of access keys at once. Each key is an independent Ed25519 cryptographic key pair, and you can add or remove keys without creating a new account. Keys are added via a transaction signed by an existing Full Access Key, using the NEAR CLI (near add-key) or programmatically through the SDK.

This differs from Ethereum, where a single private key controls each address. NEAR's multi-key design enables finer-grained permission control without compromising account continuity. NEAR supports two key types: Full Access Keys and Function Call Access Keys. See the NEAR Protocol documentation on access keys for the full technical specification.

Full Access Keys: Master Credentials

A Full Access Key is an access key with unrestricted permissions over an account. It can authorize token transfers, smart contract deployment, adding or removing other keys, and account deletion. Think of a Full Access Key like a master key to your house: it opens every door. Unlike a house key, a Full Access Key is a cryptographic key pair that signs transactions on the NEAR blockchain, so the same security practices apply. Store it in a hardware wallet or offline, for the same reasons Ethereum users protect their seed phrases.

A NEAR account can have multiple Full Access Keys. One per device is a common pattern, with each key carrying the same full permission level. This is an important architectural point: there is no single "master private key" in the way Ethereum accounts have one. Multiple Full Access Keys can coexist on a single account simultaneously.

Developer Note: A compromised Function Call Access Key does not grant Full Access Key permissions. The permission scopes are architecturally separate at the protocol level. Revoking a Function Call Access Key does not affect any Full Access Key on the same account, and vice versa.

Function Call Access Keys: Scoped Permissions for dApps

A Function Call Access Key is a scoped access key that can only call specific methods on one specific contract, with an optional NEAR token allowance that caps how much gas the key can spend. Think of it like a session token or a scoped OAuth permission: it grants a specific application the right to perform specific actions on your behalf, without giving it access to your full account. Unlike an OAuth token, a Function Call Access Key is a cryptographic key pair stored on chain, and its permission boundaries are enforced at the protocol level, not by the application.

When you connect your NEAR account to a decentralized application (dApp) and approve a Function Call Access Key, the dApp can submit certain transactions automatically without triggering a wallet confirmation pop-up for each one. This enables session-based UX in games, DeFi protocols, and social applications. On Ethereum, each of those interactions would require a separate MetaMask confirmation. On NEAR, the user approves the key once, and the dApp operates within that scope for the session.

Function Call Access Keys can carry an optional NEAR token allowance, which limits the total gas the key is permitted to spend. Once that allowance is exhausted, the key can no longer submit transactions until the user tops it up or issues a new key.

Common Misconception: Granting a Function Call Access Key to a dApp does not give the dApp control of your account. The key is scoped strictly to defined contract methods and a gas allowance. It cannot transfer your NEAR token balance, cannot deploy contracts, and cannot add or remove other keys on your account.

Developer Note: Function Call Access Keys enable session key patterns in dApps. A user can authorize a key for a game session or a DeFi trading session, and the application operates within that scope without requiring per-transaction approvals. This is one of the most developer-relevant UX differences between building on NEAR versus Ethereum.

Full Access Key vs. Function Call Access Key: Key Differences

Full Access Keys and Function Call Access Keys differ across six dimensions:

Full Access Keys belong to the account owner and should be held offline or in hardware. Function Call Access Keys are issued to applications and can be revoked by the account owner at any time.

Storage Staking: How NEAR Ties Token Balance to On-Chain Storage

Storage staking is a component of NEAR's account architecture that most blockchain education resources skip, but it has direct practical implications for every developer building on NEAR and every user managing an account.

Why NEAR Requires a Token Balance for Storage

Definition: Storage staking (also called state staking in some NEAR documentation) is the requirement for NEAR accounts to maintain a NEAR token balance proportional to the amount of on-chain data they store. This locked balance acts as a refundable deposit, not a fee.

Storage staking works like a security deposit on an apartment. Your NEAR tokens are locked in proportion to the storage you occupy and are returned when you delete that stored data. Unlike a rent payment, the tokens are not transferred to anyone; they remain in your account, just reserved against the storage you hold.

One distinction worth clarifying: storage staking is not the same as validator staking. Both mechanisms lock NEAR tokens, but they serve completely different purposes. Validator staking locks tokens to participate in block production and earn consensus rewards. Storage staking locks tokens proportional to on-chain storage usage to prevent state bloat and align the cost of storage with the entities consuming it. They are separate locked balances with separate purposes.

Storage staking is also separate from gas fees. Gas fees are per-transaction execution costs paid in NEAR tokens and burned after each transaction. Storage staking is an ongoing balance requirement tied to how much data an account holds, not to how many transactions it sends.

Storage Staking in Practice: What It Means for Accounts and Contracts

Storage staking affects accounts at three levels:

• Account creation: Requires a minimum NEAR token balance. The current rate is approximately 0.00182 NEAR per byte of state (verify current rates in the official NEAR storage staking documentation before making development decisions, as protocol governance can adjust this figure).
• Contract deployment: Requires a proportionally larger deposit based on the compiled contract size. The contract's WASM bytecode is stored on chain as part of the account's state, and the storage deposit scales with that size.
• Contract state data: Data stored in contract state (such as user balances in a token contract or game state in an on-chain game) requires an ongoing balance maintained by whoever controls the contract account.

If a NEAR account's balance falls below its storage requirement, the account cannot send outgoing transactions until the balance is topped up. The account is not deleted and its data is not lost; it simply becomes inactive for outgoing transactions until sufficient NEAR tokens are deposited.

Developer Note: Decide early whether your application will front the storage deposit for users during onboarding or require users to maintain their own balance. Many protocols absorb storage costs to reduce friction. This is a real onboarding economics decision that affects user acquisition, so factor it into your dApp's cost model before launch.

NEAR Sub-Accounts: Hierarchical Account Namespaces

A NEAR sub-account is an account whose ID is prefixed by a parent account's ID. For example, app.alice.near is a sub-account of alice.near, and only alice.near can create accounts in that namespace.

One important detail to be precise about: after a sub-account is created, the parent account does NOT control it. The sub-account is fully independent: it has its own access keys, its own NEAR token balance, and its own on-chain state. The parent account's only special authority is the ability to create sub-accounts in its namespace. Beyond that act of creation, the two accounts have no ongoing control relationship.

The naming hierarchy resembles web domains and subdomains. alice.near is like a domain, and app.alice.near is like a subdomain. Just as registering a domain does not give you ongoing control over the content hosted on its subdomains, creating a sub-account does not give the parent account authority over how that sub-account is used afterward.

A typical use pattern for protocol teams looks like this:

myprotocol.near
  → token.myprotocol.near
  → staking.myprotocol.near
  → dao.myprotocol.near

Each sub-account is independently controlled after creation. Each carries its own access keys, holds its own balance, and can have a separate smart contract deployed to it. Creation is initiated by the parent account, either through the NEAR CLI or programmatically via a contract call. After that transaction, control passes entirely to whoever holds the access keys for the new sub-account.

Common Misconception: The parent account does not govern sub-accounts after creation. Sub-accounts are fully autonomous protocol-level accounts. The naming convention reflects who created them, not who controls them.

Developer Note: Sub-accounts are a standard pattern for modular protocol architecture. Deploying separate contracts to separate sub-accounts gives each module independent access key management, independent upgrade paths, and cleaner permission isolation. Many production NEAR protocols use this pattern for token contracts, governance modules, and staking logic.

NEAR Account Model vs. Ethereum: Key Architectural Differences

The NEAR Account Model and the Ethereum account model take different architectural approaches to the same problems: how to identify accounts, how to authorize transactions, and how to deploy smart contracts. For developers evaluating NEAR as a build platform, understanding these differences is a prerequisite for making informed architecture decisions.

Ethereum separates accounts into two types: Externally Owned Accounts (EOAs) and Contract Accounts. An EOA is controlled by a single private key and cannot hold deployed code. A Contract Account is controlled by code and has no private key. This separation means that if you want an Ethereum address to both hold ETH and execute smart contract logic, you need two separate account objects working together.

NEAR uses a unified model. Any NEAR account can hold a token balance and have a smart contract deployed to it simultaneously. There is no separate "contract account" type. The account alice.near can hold NEAR tokens, run a deployed WASM contract, and maintain multiple access keys with different permission scopes, all as a single protocol object. Any NEAR account can hold a smart contract, a token balance, and multiple access keys at the same time.

Ethereum accounts are each controlled by one private key. NEAR accounts support multiple access keys with different permission scopes, enabling patterns like session keys and multi-device key management that Ethereum's account model does not support natively at the protocol level.

Note: Ethereum-compatible smart contracts can run on NEAR via Aurora, an EVM compatibility layer deployed as a smart contract on NEAR. Aurora is a separate layer; native NEAR development uses WebAssembly (WASM) compiled from Rust or JavaScript, not Solidity. See the Ethereum account model documentation for the full Ethereum account specification.

What NEAR's Unified Account Architecture Means in Practice

The components of the NEAR Account Model (account IDs, access keys, storage staking, and sub-accounts) form a unified system that produces concrete differences in how applications behave and how users experience them.

Consider a single NEAR account, alice.near. Alice's account can simultaneously:

1. Hold a NEAR token balance
2. Have a smart contract deployed to it, compiled to WebAssembly (WASM) from Rust
3. Carry three access keys: a Full Access Key stored in her hardware wallet, a Full Access Key on her laptop, and a Function Call Access Key granted to a DeFi dApp for session-based trading
4. Own two sub-accounts (app.alice.near for a deployed game contract, and vault.alice.near for a savings contract), each independently controlled

Alice's account ID is readable and shareable. She never copies a 42-character hex string to receive tokens or interact with a contract.

For developers, the practical implications are substantial. Session key patterns eliminate per-transaction wallet friction in games and social apps. Sub-account architecture lets protocol teams deploy modular contracts with independent upgrade paths. Storage staking creates a predictable cost model for on-chain data that must be factored into onboarding economics. Accounts can also interact with the Rainbow Bridge to transfer assets between NEAR and Ethereum, and are managed through NEAR-compatible wallet interfaces such as MyNEARWallet or Meteor Wallet.

For end users, the account model translates to readable account IDs that work like usernames, dApp sessions that don't interrupt the experience with wallet pop-ups, and a key rotation model that allows account recovery without depending on a single seed phrase.

Frequently Asked Questions About the NEAR Account Model

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

Named accounts are human-readable identifiers (such as alice.near) registered under a top-level domain, require a small NEAR token deposit at registration, and are chosen by the user. Implicit accounts are 64-character hexadecimal IDs derived from an Ed25519 public key, require no registration, and activate automatically when NEAR tokens are sent to the account ID. Named accounts are typical for user wallets and protocol deployments; implicit accounts are common for exchanges and programmatic tooling. See the named vs. implicit comparison table above for a full side-by-side breakdown.

How many access keys can a NEAR account have?

A NEAR account can hold an unlimited number of access keys simultaneously. Each key has its own permission scope: either a Full Access Key with unrestricted permissions, or a Function Call Access Key scoped to specific contract methods. This allows users to maintain separate keys for different devices or dApps without creating new accounts. You can add or revoke individual keys at any time without affecting the others. See the access keys section for details on each key type.

What is storage staking on NEAR Protocol?

Storage staking is the requirement for NEAR accounts to maintain a NEAR token balance proportional to the amount of on-chain data they store. The tokens are locked as a deposit, not spent, and are released if the stored data is deleted. This mechanism prevents state bloat on the network and ensures storage consumers bear the cost of the resources they occupy. Storage staking is separate from gas fees (which are burned per transaction) and from validator staking (which secures network consensus). See the storage staking section for the full explanation.

Can a NEAR account hold a smart contract?

Yes. Any NEAR account can have a smart contract deployed to it. Unlike Ethereum, which separates Externally Owned Accounts (user accounts that cannot hold code) from Contract Accounts (code-holding accounts with no private key), NEAR uses a unified account model where any account can simultaneously hold a NEAR token balance and deployed contract code. Contracts on NEAR are compiled to WebAssembly (WASM) from Rust or JavaScript source code, not Solidity. See the Ethereum comparison section for the full architectural breakdown.

What happens if my NEAR account balance falls below the storage requirement?

If a NEAR account's balance falls below the minimum required for its storage usage, the account cannot send outgoing transactions until the balance is topped up. The account is not deleted and its data is not lost; it simply becomes inactive for outgoing transactions until sufficient NEAR tokens are deposited. The stored data remains intact on chain. See the storage staking in practice section for details on balance requirements.

What is a sub-account on NEAR and who controls it?

A NEAR sub-account is an account whose ID is prefixed by a parent account's ID. For example, app.alice.near is a sub-account of alice.near, and only alice.near can create accounts in that namespace. After creation, the parent account does NOT control the sub-account. The sub-account is fully independent with its own access keys, its own NEAR token balance, and its own on-chain state. The parent's naming authority is limited to the creation act. See the sub-accounts section for the full explanation.

How is NEAR Protocol different from Ethereum in terms of accounts?

The core architectural difference is account structure. Ethereum has two separate account types: Externally Owned Accounts (controlled by a single private key, no code) and Contract Accounts (controlled by code, no private key). NEAR uses a unified account model where any NEAR account can hold both a token balance and a deployed smart contract simultaneously. NEAR accounts also support multiple access keys with different permission scopes, while Ethereum accounts are each controlled by a single private key. NEAR account IDs can be human-readable named accounts, whereas Ethereum addresses are always hexadecimal strings. See the full comparison table for a side-by-side breakdown.

What is a Full Access Key vs. a Function Call Access Key on NEAR?

A Full Access Key has unrestricted permissions over an account: it can authorize token transfers, contract deployment, and adding or removing other keys. A Full Access Key is the account owner's highest-trust credential and should be stored in a hardware wallet or offline. A Function Call Access Key is scoped to call specific methods on a specific contract, with an optional NEAR token allowance for gas. It cannot transfer token balances or modify other keys. Full Access Keys are for account owners; Function Call Access Keys are issued to dApps to enable session-like interactions without requiring full account access. See the key comparison table for a full breakdown.

What does a NEAR account ID look like?

NEAR account IDs come in two forms. Named accounts look like readable usernames or domain names: alice.near, myprotocol.near, app.alice.near. Implicit accounts are 64-character hexadecimal strings derived from a public key, similar in visual format to Ethereum addresses but longer: for example, 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. Named accounts use the .near suffix on mainnet and .testnet on the test network. See the account IDs section for the full breakdown and comparison table.

Is NEAR Protocol proof of stake?

Yes. NEAR Protocol uses a proof-of-stake (PoS) consensus mechanism. Validators stake NEAR tokens to participate in block production and earn protocol rewards. Validator accounts are standard NEAR accounts with staking contracts deployed to them, which illustrates the unified account model in practice. Validator staking is a separate mechanism from storage staking; they both lock NEAR tokens but serve entirely different purposes.

Key Takeaways and Next Steps

The NEAR Account Model unifies account identity with permissions and on-chain storage management in a single architecture. Rather than separating user accounts from contract accounts, or limiting each account to a single private key, NEAR builds flexibility and scoped permissions directly into the account layer.

Key takeaways:

• NEAR account IDs are human-readable named accounts (e.g., alice.near) or 64-character implicit accounts derived from a public key, not hexadecimal addresses
• Named accounts require a NEAR token deposit at registration; implicit accounts activate automatically on first token receipt
• Every NEAR account can hold multiple access keys simultaneously, each with a distinct permission scope
• Full Access Keys authorize all account actions and belong to the account owner; Function Call Access Keys are scoped to specific contract methods and issued to applications
• Any NEAR account can hold both a NEAR token balance and a deployed smart contract. There is no separate contract account type
• Storage staking requires a locked NEAR token balance proportional to on-chain storage consumption. It is a refundable deposit, not a fee, and is distinct from both gas fees and validator staking
• Sub-accounts follow a hierarchical naming convention, but the parent account does not control sub-accounts after creation. Each sub-account is fully autonomous

Developers ready to build on NEAR can start with the NEAR Protocol account model documentation, which provides the technical specification and SDK references. For storage staking specifics and current rate parameters, consult the official NEAR storage staking documentation before making architecture decisions, as protocol parameters can change through governance. Users creating their first NEAR account can do so through a NEAR-compatible wallet interface such as MyNEARWallet or Meteor Wallet.

Technical accuracy note: NEAR Protocol is an active, evolving blockchain. Technical specifications, including storage staking rates and account creation requirements, may change as the protocol is updated. Verify current specifications against the official NEAR Protocol documentation before making development decisions.