> ## Documentation Index
> Fetch the complete documentation index at: https://docs.genlabs.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Address format

> How Grid encodes entity references as bech32m strings with network-specific prefixes.

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.

## Related

* [Entities and accounts](/user-guide/concepts/entities-and-accounts): what an entity actually is, and how components relate to it.