Token Granularity

Overview

Token Granularity is the smallest meaningful increment in which a token can be represented, transferred, priced, settled, or accounted for within a specific system. It reflects both ledger divisibility and application-level rules. For token integrations, the relevant rule can exist in smart-contract code, an upgradeable module, an issuer policy, or an off-chain compliance service. Systems should therefore inspect both the deployed implementation and the current administrative configuration instead of relying on a token name or interface label.

Granularity can be coarser than the contract’s minimum unit when exchanges, payment products, or legal instruments permit only larger increments. It should be read alongside Token Minimum Unit, Token Decimal Precision, and Token Minimum Transfer. These related concepts describe different parts of the lifecycle, so substituting one label for another can hide who has authority, which balance is measured, or what action is actually permitted.

Operationally, teams should define granularity separately for balances, orders, transfers, fees, redemptions, and reporting and should align rounding across all connected systems. A production system should preserve the applicable network, contract or asset identifier, units and precision, rule version, responsible role, effective timestamp, and the transaction or source record used to make the decision. Changes should be observable and reconciled rather than inferred from a wallet display alone.

The principal risks are that mismatched granularity can create rejected transactions, residual balances, unfair rounding, and discrepancies between on-chain and financial records. Teams should test normal and exceptional paths, including failed transactions, delayed external services, upgrades, role changes, unavailable redemption or transfer routes, and inconsistent data between blockchain, market, legal, and accounting systems.