Near Protocol Address Format: Complete Guide for Accounts and Contracts

The Near Protocol address format can look confusing at first, especially if you come from Ethereum or Bitcoin. On Near, you see short, human-readable names like alice.near, but also long hex strings like 7b3f9d0b.... This guide explains how Near addresses work, how they are formatted, and how to read and use them safely.

Why Near Protocol Address Format Is Different From Other Chains

Near Protocol uses a unique account model that feels closer to usernames than raw wallet hashes. Instead of only long random strings, Near supports readable names, subaccounts, and contract-style addresses. This design aims to make crypto use simpler for regular users and developers.

To understand the Near Protocol address format, you first need to know that on Near, “address” and “account ID” usually mean the same thing. Both point to an on-chain account that can hold tokens, deploy contracts, or sign transactions. The difference lies in the format of that ID.

Two Main Near Address Types: Human-Readable and Implicit

Near accounts come in two main forms. The first is a human-readable account ID, such as mywallet.near. The second is an implicit account ID, which is a long hexadecimal string derived from a public key.

Both formats represent valid accounts on Near. They follow different rules and are created in different ways, but they can hold NEAR, interact with contracts, and sign transactions just the same.

Human-Readable Near Account IDs (Named Accounts)

Human-readable accounts are what most users see in wallets and dApps. These are string-based IDs like alice.near or nft.marketplace.near. They are easier to remember and share than long hashes.

A human-readable Near address follows these basic rules:

• Only lowercase letters a–z, digits 0–9, dashes -, and underscores _.
• Account ID length is between 2 and 64 characters.
• No uppercase letters, spaces, or special symbols like @ or #.
• Account IDs are case-sensitive in theory but standard practice is all lowercase.
• Top-level accounts often end with .near on mainnet, though other TLD-like endings are possible.

These rules help Near keep account names simple, safe to type, and easy to validate in wallets and tools. If a string breaks these rules, it is not a valid human-readable Near account ID.

Subaccounts and Dotted Structure in Near Addresses

One of the most important parts of the Near Protocol address format is subaccounts. Near uses a dotted structure, similar to domains, to show account hierarchy. For example, app.alice.near is a subaccount of alice.near.

The rightmost part of the account ID is the parent account. Every dot introduces a new level. The parent account has the right to create and manage its subaccounts. This structure is widely used for contracts, apps, and project namespaces.

A project can use subaccounts to separate features, such as nft.app.near for NFTs and vault.app.near for storage. This pattern keeps addresses readable while still showing ownership and control.

Implicit Near Addresses: Hex-Encoded Public Key Accounts

The second main Near address format is the implicit account ID. This address type is a 64-character hexadecimal string. It is derived directly from a public key, without any human-readable name.

An implicit Near address has these traits: it is exactly 64 characters long and uses only the characters 0–9 and a–f. The address has no dots, no .near ending, and no letters outside the hex range. Many wallets show this format when you create an account with a seed phrase but do not pick a username.

Because implicit addresses are long and machine-like, wallets often shorten them in the UI. You may see only the first few and last few characters, with the middle hidden, while the full value is still stored and used internally.

How Near Converts Public Keys Into Implicit Account IDs

For implicit accounts, Near takes the public key and encodes it as a 32-byte value. That value is then written as a 64-character hex string. The result is the implicit account ID, which you can use as a Near address.

This process keeps the address tightly linked to the key pair. If you control the private key, you control the implicit account. You do not need a human-readable name to use Near, but many users later create a named account for convenience.

Some users keep both types of accounts. They use a named account for daily activity and an implicit account for long-term storage or advanced workflows, while still following the same Near address rules.

Comparing Near Protocol Address Formats With Other Chains

Near’s address format differs from Ethereum, Bitcoin, and some other smart contract chains. Understanding the differences helps avoid mistakes when copying addresses across tools.

The table below compares typical address formats across popular networks.

Common address formats across blockchains

This comparison shows how Near combines the convenience of names with the raw key-based format. Human-readable accounts are unique to Near’s model, while implicit accounts feel closer to what other chains use.

Near Contract Addresses and How They Look

On Near, contracts live at account IDs as well. There is no separate “contract address” format like on Ethereum. The same Near address format is used for both user accounts and contracts.

For example, a DeFi app might deploy a contract to dex.project.near. That account ID is a normal Near address. The difference is that the account has contract code deployed and can handle method calls.

Many projects use subaccounts to organize contracts, such as token.project.near, router.project.near, or nft.project.near. This makes it easier to see which contracts belong to which parent project.

How Wallets Show and Use Near Protocol Address Format

Different Near wallets and explorers display addresses slightly differently, but they follow the same base rules. A wallet may show a human-readable name as the primary ID and the implicit address as a backup.

Many Near wallets share a similar pattern in how they handle addresses:

1. Let users register a human-readable account like username.near.
2. Store and manage one or more keys for that account ID.
3. Support both named accounts and implicit accounts in the same interface.
4. Show shortened forms of long hex addresses for easier reading.
5. Offer address books or labels so users can tag trusted addresses.

Understanding this wallet behavior helps you know which string you are looking at and why it may appear shortened or formatted in a certain way on the screen.

Validating a Near Address Format by Eye

You can often spot whether a string is a valid Near address format without tools. A quick visual check reduces the risk of sending funds to a wrong or fake address.

Use the following mental checklist when you review a Near address:

For a human-readable Near address, check that the string is 2–64 characters, uses only lowercase letters, digits, dashes, underscores, and dots, and does not start or end with a dot. For an implicit address, check that the string is exactly 64 characters and uses only characters 0–9 and a–f. If the address does not match either pattern, treat it as suspicious.

Best Practices for Using Near Addresses Safely

Address format knowledge helps, but daily habits matter more for safety. A few simple practices can prevent most mistakes with Near addresses.

Always copy and paste addresses rather than typing them by hand. Double-check the first and last 4–6 characters before sending funds. Use trusted explorers or official project references to confirm contract addresses. Be careful with lookalike names that swap similar characters, such as neаr with a different “a” character. For large transfers, send a small test amount first so you can confirm that the address behaves as expected.

If anything about an address feels off, pause and verify it with another source. Slowing down for a short check is far cheaper than sending tokens to an incorrect or malicious account.

How Near Address Format Affects Developers

For developers, the Near Protocol address format shapes how applications manage users and contracts. Code often needs to handle both human-readable and implicit accounts correctly.

Many dApps follow a few common patterns when working with Near addresses. They accept account IDs as plain strings and validate them against Near rules. They use subaccounts to separate logic, like storage.app.near and vault.app.near. They also map users’ human-readable names to internal data while still supporting implicit accounts for advanced users or programmatic access.

Good address handling in code includes input validation, clear error messages, and logging of the exact account ID used for each action. These habits reduce bugs and make on-chain behavior easier to review later.

Key Takeaways About Near Protocol Address Format

Near addresses are either human-readable account IDs like alice.near or 64-character hex implicit IDs. Both formats are valid and can own tokens or contracts. Human-readable accounts follow strict character and length rules and can form dotted hierarchies with subaccounts.

Implicit accounts map directly to public keys and use only hex characters. Contracts use the same Near address format as user accounts, often under project-style subaccounts. With these basics, you can read, share, and validate Near addresses with confidence across wallets and dApps.