NEAR Protocol

Address format

A NEAR address is an account ID. Named accounts read like domains: wrap.near, usdt.tether-token.near. Only near can create alice.near. Top-level names like aurora exist too.

The library follows validate in near-account-id-rs. An ID has 2 to 64 characters. It uses lowercase a-z and 0-9. Separators -, _ and . go between parts. They can't appear at either end or next to another separator. Uppercase fails.

Typed accounts carry a key instead of a name:

• NEAR-implicit: 64 hex digits, an Ed25519 public key.
• ETH-implicit: 0x and 40 lowercase hex digits.
• Deterministic: 0s and 40 hex digits.
• Universal: 0u and 52 Crockford base32 digits.

They pass the same grammar. Nothing extra is decoded.

There's no checksum. Mistype wrap.near as wrap.neat and the grammar is perfectly happy.

import { getChain } from "@agntn/chains";

const chain = getChain("near");
chain.assertAddress("wrap.near"); // returned unchanged
chain.assertAddress("aurora"); // a top-level name, returned unchanged
chain.type; // "near"
chain.caip2; // "near:mainnet"

NEAR has 24 decimals, with 10^24 yoctoNEAR per NEAR. Its SLIP-44 coin type is 397.

The ChainAgnostic registry has no NEAR namespace. The near:mainnet ID is what WalletConnect wallets pass around.

Why identify is pickier

How loose is that grammar? It accepts bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4, a Bitcoin SegWit address. It also accepts every lowercase Bech32 address and every bare CashAddr.

NEAR overrides claimsAddress for identify. It claims IDs with a dot and the four typed forms. Bare words stay out of identify, but assertAddress still accepts them. That boundary makes sense.

A lowercase 0x address with 40 hex digits appears on both NEAR and EVM chains. An ETH-implicit account represents the same 20 bytes.

Transaction hashes

A transaction hash is a 32-byte CryptoHash in base58. It's read the way CryptoHash::from_str reads it.

Spellings

near, NEAR Protocol. The key is near, the rest resolve through getChain.