# The Address as Identity

> How a Whisper agent name is derived from its IPv6 address, what the account handle is, and why the forward and reverse records must agree.

*Source: https://www.whisper.security/docs/identity/address*

---
An allocation hands out one routable IPv6 `/128` from `2a04:2a01::/32`, announced by AS219419 and covered by an RPKI route origin authorisation. The upper half of the address carries routing and account topology. The lower half is the identity itself, and every name and record below is a function of it.

## The name is derived from the address

Take the last four hextets of the address, zero-pad each one to four hex digits, concatenate them, and prefix the result with `a`. That string is the handle. The fully qualified name is the handle, then the account handle, then the identity zone.

```text
address        2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
last hextets   e3b0  51ff  3bf7  f478
handle         ae3b051ff3bf7f478
name           ae3b051ff3bf7f478.t<tenant>.agents.whisper.online
```

Because the derivation runs one way only, there is nothing to look up and nothing to trust. Anyone holding the address can compute the name it must answer to, then check that the DNS agrees.

## The account handle

The middle label is an opaque account handle of the form `t<tenant>`: the letter `t` followed by a fixed run of hex. It is the same label in DNS, in the registry and in the verdict endpoint. A raw account identifier never appears in any of them, so publishing an identity does not publish who owns it, only that one owner owns all of them.

## The friendly name

An allocation can also carry a short label as a `CNAME` beside the canonical name, at `<label>.t<tenant>.agents.whisper.online`. It is convenient and it is guessable, which is why publication is a choice made when the identity is minted. Read the `member_published` field rather than an empty `member` field to know whether a label went into public DNS.

## The two-way lock

The reverse record and the forward record live in separate delegations and are populated independently. `PTR` under `ip6.arpa` names the identity; `AAAA` under the forward zone names the address. Forward-confirmed reverse DNS is the pair agreeing, and a mismatch is the signal that someone is claiming a name they were not given.

```bash
dig -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 +short
dig +short AAAA ae3b051ff3bf7f478.t<tenant>.agents.whisper.online
```

Both zones are signed with DNSSEC, so a validating resolver returns the `AD` bit on each answer. Read that bit. Without it you have two strings that agree, and no evidence that either came from the zone it claims.

## What hangs off the address

The same lower half seeds the rest of the record set. The `TLSA` record pins the identity to [its own key](/docs/identity/keys), and the [public registry](/docs/identity/registry) answers for the allocation. Issuing the address also writes a leaf into [the transparency log](/docs/identity/transparency). [The proof chain](/docs/identity/proofs) walks each one in order. If you would rather the names sat under a name your customers already recognise, [delegate your own apex](/docs/identity/own-domain) and the derivation runs unchanged underneath it.