NEAR Account Model Deep Dive: Named Accounts, Access Keys, and Permission Patterns

NEAR Protocol's account model is one of the most thoughtfully designed elements of the platform. It departs significantly from the Ethereum model and takes time to understand properly. This guide covers everything a developer needs to know to work effectively with NEAR accounts.

The Two Account Types

NEAR has two types of accounts, and they serve different purposes.

Named accounts have human-readable identifiers like alice.near or myapp.near. They are the standard account type for users and deployed contracts. Named accounts follow a hierarchical namespace: near is the top-level registrar, and sub-accounts like alice.near or contract.alice.near are valid. Creating a named account costs approximately 0.1 NEAR, which is held as storage deposit for the account's existence on-chain.

Implicit accounts are derived from Ed25519 public keys. The account ID is the hex-encoded public key, 64 characters long. Example: a0b1c2d3e4f5a0b1c2d3e4f5a0b1c2d3e4f5a0b1c2d3e4f5a0b1c2d3e4f5a0b1. Implicit accounts require no registration transaction and cost nothing to create in advance. They become active once they receive a NEAR transfer. This makes them ideal for programmatic use, exchange deposits, and AI agent wallets.

The choice between named and implicit depends on your use case. For users who need a readable identity, named accounts work better. For programmatic or batch operations where you need to generate many accounts quickly, implicit accounts are the right tool.

Access Keys: The Core Permission Primitive

Every NEAR account can have multiple access keys. Each key has a specific permission level. This is fundamentally different from Ethereum where a private key gives full account control.

There are two permission types:

Full Access Keys can do anything: transfer NEAR, deploy contracts, add or remove keys, call any contract method. A full access key is equivalent to the private key in Ethereum terms. You must guard these carefully. Losing a full access key means losing control of the account unless another full access key exists.

Function Call Keys are restricted to specific contracts and methods. When you create a function call key, you specify which contract it can call, which methods on that contract, and optionally a maximum NEAR allowance it can spend on gas per transaction. Function call keys cannot transfer NEAR to arbitrary accounts, cannot deploy contracts, and cannot add or remove keys unless those are methods on the specific contract they are authorized to call.

Why Function Call Keys Matter for Security

The function call key model enables a security pattern that Ethereum cannot replicate without complex smart contract logic: you can give an application limited, scoped access to your account without giving it your private key.

Consider a DeFi application that needs to call swap() and addLiquidity() on exchange.near. You can create a function call key that only permits calls to those two methods on exchange.near, with a 1 NEAR gas allowance. The application can use that key to execute transactions on your behalf. If the application is compromised, the attacker cannot drain your NEAR balance or deploy malicious contracts. Their key only works for the two methods you specified.

For AI agents, this model is particularly valuable. An agent that needs to interact with a smart contract should use a function call key, not a full access key. The full access key stays in cold storage. The function call key gets provisioned per application and revoked when no longer needed.

Account Creation Flows

Creating a named account requires an existing NEAR account to sponsor it. The NEAR CLI command is:

near create-account myaccount.near --masterAccount sponsoraccount.near --initialBalance 0.1

This creates myaccount.near with 0.1 NEAR transferred from sponsoraccount.near. The 0.1 NEAR covers storage staking for the account itself.

Creating an implicit account requires no transaction. Generate a keypair:

const keyPair = KeyPair.fromRandom('ed25519');
const accountId = Buffer.from(keyPair.getPublicKey().data).toString('hex');

The account becomes active once it receives at least 0.001 NEAR. Until then, it exists in a pre-active state and cannot execute transactions.

Sub-accounts can only be created by their parent account. If you control alice.near, you can create contract.alice.near but you cannot create alice.near sub-accounts from an unrelated account.

Multi-Signature Patterns

NEAR does not have native multi-sig at the protocol level for general transactions. Multi-sig on NEAR is implemented as a smart contract. The standard approach is to deploy a multi-sig contract to your account. The contract manages a list of authorized signers and a threshold. Transactions are proposed, collected, and executed by the contract when the threshold is met.

The near-multisig contract is available in the near-sdk repository. For production deployments with significant funds, multi-sig is strongly recommended. Single key custody is a single point of failure.

For AI agents managing funds on behalf of users, a multi-sig pattern with a human co-signer for large transfers is a reasonable security model. The agent holds a function call key for routine operations. Large transfers require the human co-signer's full access key.

Storage Staking and Account Costs

NEAR charges for on-chain storage through a mechanism called storage staking. Every byte stored on-chain requires locking a proportional amount of NEAR. The current rate is approximately 1 NEAR per 100KB of storage. This NEAR is locked, not burned: you get it back if you delete the stored data.

For accounts, the storage cost covers the account record itself, all access keys, and any data stored in the account's state. A minimal account with one full access key and no contract data costs approximately 0.0035 NEAR in storage staking.

When building contracts, storage costs are the most common source of unexpected NEAR usage. Every new key in a map, every new account registered in a contract, every string stored in state costs NEAR that must either come from the contract's balance or from users who attach storage deposits to their transactions.

Security Best Practices

These recommendations apply whether you are a developer, user, or AI agent operating on NEAR.

Never use a full access key in automated processes. Provision function call keys for each specific application. Revoke function call keys when they are no longer needed. Monitor your account's key list regularly for unexpected additions.

Store full access keys offline or in a hardware key store. Key rotation is straightforward on NEAR: add the new key, verify it works, remove the old key. Do this regularly.

When building contracts that manage user funds, implement the storage deposit pattern. Require users to attach NEAR when they first register, use that deposit to cover their storage, and return the deposit when they unregister. This prevents storage exhaustion attacks where attackers fill your contract's storage at your expense.

Use near-sandbox for development and testing. Run your contracts against testnet before mainnet deployment. The testnet faucet at faucet.near.org provides free testnet NEAR for development.

Account Model in Context

The NEAR account model is more complex than Ethereum's but the complexity is justified. The ability to have multiple keys with different permission scopes, the human-readable naming system, and the storage deposit mechanism together enable patterns that are difficult or impossible on Ethereum without significant smart contract overhead.

For AI agents in particular, NEAR's model fits well. Implicit accounts are easy to generate programmatically. Function call keys enable scoped permissions without custody of a master private key. The gas allowance on function call keys provides a natural spending limit for autonomous operations.

Resources: docs.near.org/concepts/basics/accounts/introduction, near-sdk.io, and the near-api-js documentation at near.github.io/near-api-js.