Skip to main content
Grid addresses (the grd@1q… strings you see in CLI and RPC output) are bech32m encodings of an entity reference, with a network-specific human-readable prefix (HRP).

​
Structure

<chain_id>@<version>@<bech32m-encoded payload + checksum>
  • chain_id: network identifier. Examples: grd (The DevNet Grid), gt1 (The TestNet 1 Grid).
  • version: currently 1; allows the format to evolve.
  • Payload (31 bytes), bech32m-encoded:
    • entity_id (26 bytes): hash of the entity’s public key.
    • component_index (4 bytes, little-endian): which component inside the entity is being addressed. Index 0 is the default (the account component), used when sending an activation to an entity without targeting a specific component.
    • vm_id (1 byte): which VM runs the target component.
  • Checksum: 6-character bech32m CRC. Catches typos and prevents cross-network mix-ups: the HRP feeds the checksum, so an address valid on grd will fail validation on gt1.
A complete address is roughly 73 characters and starts with the HRP, e.g. grd@1@….

​
Entity vs. component addressing

Most user-facing flows (e.g. gen wallet transfer --to <addr>) target the entity as a whole and let the account component (index 0) route the activation. To call a specific component directly, use the same address format with that component’s index baked in. Decoding is server-side: the CLI and RPC accept the human-readable form, but validators decode it before signing or verifying, so a signed payload can always be inspected to confirm the targeted entity.