Account Number

Overview

Some blockchain systems use human-readable or numeric account identifiers alongside cryptographic addresses. Others include an account number in the signed transaction context so a signature created for one account instance cannot be replayed after the account is recreated or interpreted elsewhere.

Application platforms also assign internal account numbers to customers. These identifiers belong to the service database and may map to several blockchain addresses or custodial balances. They should not be presented as on-chain ownership evidence. The field must be interpreted through network documentation. A numeric account identifier may remain stable while keys rotate, or it may change when an account is removed and recreated. In other systems, no protocol-level account number exists at all.

Developers should avoid naming a nonce or sequence value “account number” unless the protocol uses that exact term. APIs should expose network, address, account number, and internal customer ID as separate fields. Security depends on binding identifiers correctly in signatures and lookups. Accepting a transaction under the wrong account number or network context can create replay or attribution errors.

Account number is therefore a contextual identifier, not a universal blockchain primitive. Its scope, lifecycle, and relationship to keys and addresses must be documented explicitly. Systems should validate account numbers as scoped values rather than globally unique identifiers. The same number may exist on another chain, in another namespace, or under a recreated account. Signed payloads should bind the number to chain and account context. Databases should use composite keys and preserve the original protocol field instead of converting it into an unrelated customer identifier.