What Is NEAR Token? Account Model Explained

Meta description: Learn how the NEAR account model works: named accounts, implicit accounts, access keys, sub-accounts, and storage staking explained for developers and crypto users.

Introduction: What Is NEAR Protocol and Why Does Its Account Model Matter?

NEAR Protocol is a Layer-1 proof-of-stake blockchain designed for scalable decentralized applications (dApps, software programs that run on a blockchain rather than a centralized server), and the NEAR account model is the architectural system that sets it apart from competing chains. Founded by Illia Polosukhin (a former Google AI researcher) and Alexander Skidanov (formerly of Microsoft), NEAR launched its mainnet in October 2020 with a deliberate goal: make blockchain development and usage feel closer to building and using ordinary software.

Most people encountering NEAR for the first time notice something unexpected. Their account looks like alice.near, not a cryptographic string of letters and numbers. That design choice is not cosmetic. It reflects a deeper architectural decision built into the NEAR account model that touches identity, permissions, storage, and how applications interact with users.

This article covers everything you need to understand about how NEAR Protocol works and what makes its account model distinctive. You will learn the difference between NEAR named accounts and implicit accounts, how NEAR access keys create a programmable permission system, how NEAR sub-accounts enable application-level namespacing, why storage staking requires a minimum balance in every wallet, and how NEAR's architecture compares structurally to Ethereum's. The final sections cover account creation, the NEAR token's utility, and a FAQ addressing the most common questions directly.

Contents

1. What Is NEAR Protocol? A Foundational Overview
2. The NEAR Account Model: How NEAR Manages Identity and Permissions On-Chain
3. NEAR Account Types: Named Accounts vs. Implicit Accounts
4. NEAR Access Keys: The Permission System That Makes NEAR Accounts Unique
5. NEAR Sub-Accounts: Understanding Account Hierarchy
6. Storage Staking: Why NEAR Accounts Require a Minimum Balance
7. NEAR Account Model vs. Ethereum Account Model: A Structural Comparison
8. How to Create and Manage a NEAR Account
9. The NEAR Token: Gas, Storage, and Staking
10. Frequently Asked Questions
11. Summary: What Makes the NEAR Account Model Distinctive

What Is NEAR Protocol? A Foundational Overview

NEAR Protocol is a Layer-1 proof-of-stake blockchain built for scalable, developer-friendly decentralized applications. It uses a proof-of-stake (PoS) consensus mechanism and Nightshade sharding to achieve horizontal scalability. NEAR Protocol is the blockchain network; the NEAR token is its native cryptocurrency used for transaction fees, storage, and staking.

Proof of stake means validators are selected to produce blocks based on the amount of NEAR tokens they have staked rather than expending computational energy as in proof-of-work systems like Bitcoin. Validators are nodes that stake NEAR tokens to participate in block production and transaction validation. They earn NEAR rewards for honest participation and face penalties for malicious behavior.

To handle growing transaction demand without sacrificing decentralization, NEAR achieves horizontal scalability through Nightshade, its sharding mechanism. Sharding splits a blockchain network into parallel processing segments called shards, allowing the network to handle more transactions simultaneously. Each shard processes a subset of transactions in parallel, so network capacity scales as demand grows.

What distinguishes NEAR from other Layer-1 chains is not sharding alone. The account model, examined in the sections that follow, is the architectural layer where NEAR makes its most consequential design departures from Ethereum and similar chains.

The NEAR Account Model: How NEAR Manages Identity and Permissions On-Chain

The NEAR account model is the system NEAR Protocol uses to manage user and application identities on-chain. Unlike Ethereum's address-based model, NEAR accounts have human-readable names, support multiple cryptographic keys with configurable permissions, and can optionally hold smart contracts within a single unified account type.

This unified design is a meaningful departure from how most blockchains handle identity. On Ethereum, there are two separate account types: externally owned accounts (EOAs) controlled by a private key, and contract accounts containing code. NEAR collapses this distinction. Every NEAR account can hold tokens, hold multiple access keys with different permission scopes, and optionally deploy a smart contract (a self-executing program stored on the blockchain that automatically enforces rules and handles transactions). An account without a deployed contract simply holds tokens and keys.

NEAR transactions use an action model, meaning a single transaction can batch multiple actions together, such as a token transfer combined with a contract function call. This reduces the number of separate transactions developers need to coordinate.

The NEAR account model rests on four structural pillars, each explored in the sections that follow:

1. Account IDs and types: how accounts are identified (named vs. implicit)
2. Access keys: how permissions are attached to accounts
3. Sub-accounts: how accounts can be organized hierarchically
4. Storage staking: how on-chain storage costs are managed

For the full technical specification, see the NEAR account model documentation.

NEAR Account Types: Named Accounts vs. Implicit Accounts

NEAR Protocol supports two distinct account types: named accounts, which use human-readable identifiers like alice.near, and implicit accounts, which use 64-character hexadecimal strings derived from a public key. Both types are fully functional NEAR accounts; they differ in format, registration process, and typical use case.

Named Accounts

A named account is a human-readable account identifier registered on-chain through NEAR's naming system. Named accounts work like domain names or email addresses: they are readable, memorable, and registered through a naming system rather than being cryptographically derived from a key pair.

On mainnet, the .near suffix is the top-level identifier owned by the .near registrar. An account like alice.near or defi-protocol.near is created by submitting a registration transaction through an existing NEAR account or a faucet service. According to the NEAR account model documentation, named account IDs follow these rules: 2 to 64 characters in length, lowercase letters and digits only, with hyphens and underscores permitted as separators, and the ID cannot start or end with a separator character.

In practice, this means a new NEAR user can share their account ID the same way they would share an email address, with no copying and pasting of cryptographic strings required.

Implicit Accounts

An implicit account uses a 64-character lowercase hexadecimal account ID derived directly from a public key, similar to how Ethereum wallet addresses work. The term "implicit" refers to the fact that the account ID is implicitly derived from the key, not that the account is anonymous or untracked. An example implicit account ID looks like 98793cd91a3f870fb126f662858dbb54de0ca... (64 characters total).

A keypair for an implicit account can exist without any on-chain registration transaction. The account becomes active on-chain only after it receives a funded transaction. Developers and exchanges commonly use implicit accounts for programmatic workflows where human-readable names are unnecessary.

Implicit accounts are analogous to traditional cryptocurrency wallet addresses: a long hex string derived from your public key, recognizable to anyone familiar with Ethereum or Bitcoin address formats.

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

Named accounts suit most end users and application deployments where a recognizable identity matters. Implicit accounts suit automated systems and programmatic workflows where account IDs are handled by software rather than shared with humans.

NEAR Access Keys: The Permission System That Makes NEAR Accounts Unique

NEAR access keys are cryptographic key pairs attached to a NEAR account, each with configurable permission scopes. Unlike Ethereum, where a single private key controls an account, NEAR accounts can hold multiple keys simultaneously, some with full control and others restricted to specific smart contract interactions. This design allows users to grant applications scoped access without exposing full account credentials.

Think of NEAR access keys like the permissions system on a smartphone: you can grant an app access to your camera without giving it access to your contacts, and you can revoke any permission at any time. The type of access key used to sign a transaction determines which actions that transaction is authorized to take. For the full technical specification, see the NEAR access keys documentation.

Full Access Keys

A full access key is a cryptographic key that grants unrestricted control over a NEAR account. A full access key can sign any transaction type: token transfers, contract deployments, account deletion, and adding or removing other keys. Think of it as a master key that opens every door in a building.

Your wallet's seed phrase generates and controls a full access key. Store it securely and never share it with third-party applications. If you lose all full access keys attached to an account, the account becomes inaccessible. Deleting a full access key is safe as long as at least one other full access key remains attached; deleting the last full access key locks the account permanently.

Function Call Access Keys

A function call access key is a cryptographic key with scoped, limited permissions. It can only call specific methods on a named smart contract, with an optional token allowance cap on gas spending. Think of it like an OAuth token or smartphone app permission: you grant an application specific, limited access that you can revoke at any time, without giving it control of your entire account.

When a dApp prompts you to "approve a connection" or "add an access key," it is requesting a function call access key, not your full account control. Function call access keys are safe to approve from trusted applications because their scope is fixed at creation: they cannot transfer your tokens, deploy contracts, or manage other keys. You can revoke any function call access key at any time through your wallet interface.

NEAR gas fees are low and predictable relative to Ethereum, and function call access keys can include a gas allowance so users do not need to manually approve fees for each individual interaction. According to the official documentation, approximately 30% of NEAR gas fees go to smart contract developers (verify the current percentage at docs.near.org, as this is subject to protocol updates).

In practice, this means a blockchain game can let you play 100 rounds without asking you to approve 100 separate transactions. Your function call access key handles the signing automatically within the permission scope you approved.

Full Access Key vs. Function Call Access Key: Comparison

A full access key is your account's master credential. A function call access key is a scoped delegation to a specific application. Most users interact daily through function call access keys and store their full access key only in a secure wallet or hardware device.

NEAR Sub-Accounts: Understanding Account Hierarchy

NEAR sub-accounts are hierarchical child accounts that extend a parent named account, following a subdomain-like naming pattern. Only the direct parent account can create a sub-account. Developers use them for contract isolation, application namespacing, and organizational account management.

Sub-accounts work like subdomains on a website: blog.example.com is a subdomain of example.com, just as app.alice.near is a sub-account of alice.near. The account hierarchy extends as deep as needed, with each level created by its direct parent.

alice.near
└── app.alice.near
    └── v2.app.alice.near

The creation rule is strict: alice.near can create app.alice.near, but alice.near cannot directly create sub.app.alice.near. Only app.alice.near can create that deeper child. After creation, sub-accounts are independent accounts with their own access keys; the parent account does not automatically control the sub-account.

Sub-accounts are not the equivalent of Ethereum contract accounts. Any NEAR account, including a sub-account, can optionally hold a smart contract. Sub-accounts are a naming and hierarchy feature, not a contract-specific type.

Three practical use cases drive most sub-account adoption:

1. Contract isolation: deploy separate smart contracts to v1.myapp.near and v2.myapp.near, keeping versions independent so a bug in one does not affect the other
2. Application namespacing: create user accounts within an application's namespace, such as username.myapp.near, giving the application a structured account space
3. Organizational separation: manage treasury and operations under one parent account, for example treasury.myorg.near and governance.myorg.near

In practice, this means a NEAR developer can deploy a new version of a smart contract to v2.app.myprotocol.near without touching the existing app.myprotocol.near, keeping production and development environments cleanly separated under one organizational namespace.

Storage Staking: Why NEAR Accounts Require a Minimum Balance

Storage staking is NEAR's mechanism for managing on-chain storage costs. NEAR accounts must lock a proportional amount of NEAR tokens to cover the storage they use on the blockchain, approximately 1 NEAR per 100KB of data (check the NEAR storage staking documentation for current figures, as protocol updates may adjust this ratio). This is why every NEAR account requires a small minimum balance.

For a basic account holding only keys and no deployed contract, the minimum balance is approximately 0.0023 NEAR as of this writing (verify the current figure at docs.near.org, as this is subject to protocol updates). The locked tokens cover the storage footprint of the account's state on-chain.

The locked tokens are not lost or burned. Think of storage staking like renting shelf space in a warehouse: you pay a deposit proportional to how much space you use, and you get your deposit back when you clear the shelf. If you delete stored data or close an account, the proportional NEAR tokens return to your balance.

Storage staking carries a distinct meaning from validator staking, and the difference matters. On NEAR, "staking" refers to two separate mechanisms:

• Storage staking locks tokens proportional to on-chain data storage. This is a mechanic built directly into the account model.
• Validator staking delegates tokens to network validators for block production and security. Validators earn rewards through this separate mechanism, which is the staking relevant to proof-of-stake consensus.

These two mechanisms are operationally independent. Storage staking is built into the account model itself: every NEAR account's state is stored on-chain, and that storage requires a proportional locked balance.

For developers building dApps that store data on behalf of users, this has design implications. A contract that stores user data must either fund that storage from its own balance or ensure users maintain sufficient balance to cover their data footprint.

In practice, the minimum balance in your NEAR wallet is not a fee. It is a recoverable deposit that you can reclaim if you close your account or reduce the data stored in it.

NEAR Account Model vs. Ethereum Account Model: A Structural Comparison

NEAR and Ethereum take fundamentally different approaches to account architecture. NEAR uses a unified account model where every account can hold tokens, keys, and code, while Ethereum separates externally owned accounts from contract accounts at the protocol level. NEAR accounts support multiple cryptographic key pairs with configurable permission scopes, while Ethereum accounts are controlled by a single private key. Where NEAR account IDs are human-readable strings like alice.near, Ethereum relies on 42-character hexadecimal addresses like 0x71C7656EC7ab88b098defB751B7401B5f6d8976F.

Ethereum's base-layer model defines two distinct account types. An externally owned account (EOA) is a user-controlled account identified by a 42-character hex address, controlled by a single private key. A contract account holds code and is controlled by that code's logic rather than a key. Only contract accounts can hold smart contracts in Ethereum's base-layer design. Refer to the Ethereum account model documentation for the full specification.

Ethereum's EIP-4337 account abstraction proposals are evolving the base-layer model toward more programmable accounts. This comparison reflects Ethereum's native base-layer account model, not account abstraction extensions.

For developers evaluating Ethereum compatibility, Aurora (an EVM-compatible layer built on NEAR) allows Solidity smart contracts to run on NEAR's infrastructure. The Rainbow Bridge enables asset transfers between NEAR and Ethereum for interoperability between the two ecosystems. Other Layer-1 chains such as Solana take different architectural approaches to account management that involve separate trade-offs worth evaluating independently.

NEAR gas fees are low and predictable relative to Ethereum's base-layer fees, and approximately 30% of NEAR gas fees go to smart contract developers (verify at docs.near.org), creating a direct developer incentive tied to contract usage.

NEAR Account Model vs. Ethereum Account Model

The two models represent different architectural trade-offs. Ethereum's separation of account types maps cleanly onto existing developer mental models and benefits from the largest EVM ecosystem and tooling base. NEAR's unified model removes the distinction between user accounts and contract accounts, enabling programmable permissions at the account level from the start.

How to Create and Manage a NEAR Account

Creating a NEAR account takes four steps, and you can complete the process through any of NEAR's supported wallet providers.

1. Choose a NEAR wallet. Current options include MyNearWallet, Meteor Wallet, and Ledger hardware wallet support. The original NEAR Wallet at wallet.near.org was deprecated, so check current NEAR wallet options for an up-to-date list, as the wallet ecosystem evolves over time.

2. Create your account with a chosen name. You will select your account ID during wallet setup, for example yourname.near. The wallet handles the on-chain registration transaction.

3. Secure your seed phrase. Your seed phrase controls your full access key. Treat it like a master password: write it down offline, store it securely, and never share it with any website or third-party application. Anyone who has your seed phrase has full control of your account.

4. Fund your account. Transfer enough NEAR to cover the minimum storage staking balance (approximately 0.0023 NEAR as of this writing, check docs.near.org for current figures) plus any transaction fees for your initial activity.

When a dApp asks you to connect your wallet, it is requesting a function call access key, not your full account control. The dApp can only call the specific contract methods you approve, within the gas allowance you set. You can revoke any function call access key at any time through your wallet's key management interface.

For ongoing account security, keep your seed phrase stored offline, revoke function call access keys from applications you no longer use, and consider a hardware wallet like Ledger for high-value accounts. For step-by-step account creation instructions, refer to the official NEAR documentation at docs.near.org.

The NEAR Token: Gas, Storage, and Staking

The NEAR token serves three distinct functions within NEAR Protocol:

• Gas fees: the NEAR token pays for transaction computation on the network. Fees are low and predictable relative to Ethereum's base-layer costs.
• Storage staking: NEAR tokens are locked as collateral to cover on-chain data storage, as described in the storage staking section above. This is the source of every account's minimum balance requirement.
• Validator staking: NEAR token holders can delegate tokens to validators, earning validator staking rewards for contributing to network security and block production.

The NEAR ecosystem supports a range of application categories. DeFi protocols such as Ref Finance, NFT marketplaces such as Mintbase and Paras, blockchain games, and DAOs represent active areas of NEAR Protocol development since its 2020 mainnet launch. Each of these application types depends on the account model's features: named accounts for user identity, function call access keys for delegated permissions, and storage staking for on-chain data management.

Validators earn rewards for honest participation in block production. This validator staking reward mechanism connects directly to the proof-of-stake consensus described earlier: staked tokens signal commitment to the network's integrity, and rewards flow proportionally to that commitment.

The NEAR token is the economic substrate of the account model. It funds the gas fees that make transactions possible, secures on-chain storage through storage staking, and backs network security through validator staking.

Whether NEAR token is a suitable investment depends on individual financial circumstances and risk tolerance. This article covers NEAR's technical architecture. For investment decisions, consult a qualified financial advisor and conduct independent research.

NEAR Protocol and NEAR Account Model: Frequently Asked Questions

What is a NEAR account, and why does it have a username instead of a wallet address?

NEAR accounts use human-readable identifiers like alice.near because the NEAR account model was designed with user experience in mind from the protocol level. Rather than deriving account IDs cryptographically from a public key (which produces a long hex string), NEAR allows accounts to be registered with readable names through a naming system. You can share your NEAR account ID the same way you share an email address, without copying a 42-character hex string.

What is the difference between a full access key and a function call access key?

A full access key grants unrestricted control over a NEAR account: it can sign token transfers, deploy contracts, manage other keys, and delete the account. A function call access key has scoped permissions: it can only call specific methods on a named smart contract, with an optional gas allowance cap. Your seed phrase controls a full access key. When a dApp requests wallet access, it is requesting a function call access key, which you can revoke at any time.

What is storage staking, and why does my NEAR account need a minimum balance?

Storage staking is NEAR's system for funding on-chain storage. Every NEAR account must lock a proportional amount of NEAR tokens to cover its storage footprint on the blockchain, approximately 1 NEAR per 100KB of data. A basic account requires approximately 0.0023 NEAR (check docs.near.org for current figures). The locked tokens are not fees; they are a recoverable deposit returned when stored data is deleted or the account is closed.

What are NEAR sub-accounts, and what are they used for?

NEAR sub-accounts are child accounts that extend a parent named account using a subdomain-like naming structure. For example, app.alice.near is a sub-account of alice.near. Only the direct parent account can create a sub-account. Developers use sub-accounts for contract version isolation (e.g., v1.myapp.near and v2.myapp.near), application namespacing (e.g., username.myapp.near), and organizational account separation under a single parent identity.

How is NEAR Protocol different from Ethereum?

NEAR uses a unified account model where every account can hold tokens, keys, and code, while Ethereum separates externally owned accounts (EOAs) from contract accounts. NEAR accounts support multiple access keys with configurable permission scopes; Ethereum accounts are controlled by a single private key. NEAR account IDs are human-readable strings; Ethereum accounts use 42-character hexadecimal addresses. These are architectural trade-offs, each with distinct developer ecosystem implications.

Can every NEAR account hold a smart contract?

Every NEAR account has the option to deploy a smart contract, but no account is required to do so. An account without a deployed contract simply holds tokens and access keys. On Ethereum, only contract accounts hold code; user accounts (EOAs) cannot. NEAR removes this distinction: any account, including sub-accounts, can optionally hold a smart contract written in Rust or JavaScript/TypeScript via the NEAR SDK.

What wallets support NEAR Protocol?

Current NEAR wallets include MyNearWallet, Meteor Wallet, and Ledger hardware wallet support. The original NEAR Wallet at wallet.near.org was deprecated. The wallet ecosystem evolves as the protocol develops, so check current NEAR wallet options for the most up-to-date list. All supported wallets allow you to create and manage NEAR accounts, view your access keys, and approve or revoke dApp key requests.

What is Nightshade sharding on NEAR?

Nightshade is NEAR Protocol's sharding mechanism for achieving horizontal scalability. Sharding splits the network into parallel processing segments called shards, each handling a subset of transactions simultaneously. Nightshade is NEAR's specific implementation, designed to scale network throughput as demand increases without sacrificing decentralization. For a deeper technical treatment of Nightshade, refer to the official NEAR documentation.

Summary: What Makes the NEAR Account Model Distinctive

The NEAR account model is not a minor implementation detail. It is the structural foundation of NEAR's approach to developer and user experience on-chain, and it differs from Ethereum's base-layer design in consequential ways.

Key takeaways from this article:

• Named accounts use human-readable IDs like alice.near, registered through a naming system and shareable like an email address
• Implicit accounts provide a programmatic alternative, using 64-character hex IDs derived directly from a public key
• NEAR access keys attach multiple cryptographic key pairs to a single account, each with configurable permission scopes (full access keys for complete control, function call access keys for scoped dApp interactions)
• Sub-accounts create a hierarchical namespace for dApp architecture, contract versioning, and organizational separation
• Storage staking requires a small locked NEAR balance proportional to on-chain data stored, a recoverable deposit rather than a fee
• NEAR's unified account design contrasts with Ethereum's split between EOAs and contract accounts, giving every NEAR account the option to hold tokens, keys, and code within a single account type

Understanding these six aspects of the account model gives developers, investors, and users a clear picture of what NEAR Protocol offers architecturally and why its design choices produce the user experience that distinguishes it from other Layer-1 chains.

Next steps:

• Explore the complete NEAR account model documentation for technical depth on account ID formats, access key specifications, and storage staking ratios
• Set up your first account through current NEAR wallet options if you are new to NEAR
• For developers ready to build, consult the NEAR Protocol developer documentation for SDK guides, contract deployment tutorials, and the full access key API reference

Related Reading

• What Is Cardano (ADA)? Crypto Blockchain Explained
• What Is Polkadot Crypto (DOT)? Parachains Explained
• What Is Chainlink (LINK)? Token and Oracle Explained