Blog · 2026-10-09 · Dual-Pillar series · Addressing

Why agent addresses should be derived, not assigned

rttp:// · IANA Registered · Provisional · CRI 27 · Sister pillar: iqa:// (IANA Registered · Provisional · CRI 28)

Author: Aicent Stack · Part of the Dual-Pillar series · Addressing pillar


When one agent needs to call an agent in another domain, the first task is to find it and recognize it. Today's mainstream answer is to assign every subject an address — domains look to DNS, certificates to CAs, DIDs to registries. The address is a number plate issued by an authority; the verifier takes the plate back to the registry to check it. This machinery has run for decades, but it carries a hidden bill: every verification is an online round trip, and every ounce of trust leans on an online third party.

In a world of agents delegating to agents across domains, that bill compounds exponentially.

1. Three bills of assigned addressing

2. Derivation: turning the address into a mathematical fact

RTTP (Resonant Time Transfer Protocol) works differently: the address is not issued; it is computed.

The subject address = the first 16 bytes of SHA-256(authority string). The same string always yields the same address; different strings almost certainly yield different addresses. Given an address, the verifier recomputes it and checks — no need to ask anyone.

Three properties follow: determinism (no randomness, no clock, no network), self-evidence (the binding between address and subject is embedded in the address itself), and off-line-ness (verification can happen anywhere — an air-gapped workshop, a device in flight).

3. Is 128 bits enough? An honest margin ledger

Truncated to 128 bits, someone will ask: what about collisions?

A second-preimage attack takes ~2^128 hashes. The birthday bound of 2^64 applies only to "collide with anything whatsoever"; an attacker needs to "collide a specific subject on purpose" — which requires three constraints to hold simultaneously: no steerability, no chosen-prefix structure, and separation between declaration and proof. Not one can be dropped. The specification also explicitly forbids using the 8-hex display prefix as a unique identifier — a 2^16 space cannot carry any serious scenario.

The margin is not a gut feeling; it is computed, published in the open specification, and re-checkable by anyone.

4. One address, three jobs

The derived 16-byte shard holds three jobs in the protocol:

The URI also reads out the action class directly (verify / audit / attest / revoke — a closed set). One identifier, three uses, zero extra state.

5. The honest boundary

Derivation settles one thing only: "the binding between address and subject is a mathematical fact." It does not settle "who controls this string" — that is the business of the sister protocol IQA (iqa://): who issued the proof, in what standing, under what authority, answered by the 128-byte envelope and fail-closed verification. The addressing pillar and the attestation pillar each carry their own span; joined, they make the full trust chain.

We do not ask one pillar to hold up the whole building — that is the literal meaning of "dual-pillar".


The rttp scheme is registered with IANA (Provisional · CRI 27); the sister pillar iqa:// is registered with IANA (Provisional · CRI 28); the merged specification draft-li-rttp-iqa-addressing is under review in the IETF independent submission stream; the trilingual reference implementations and byte-level test vectors are all open source.

Repos: github.com/Aicent-Stack · Spec & evidence chain: iqa.org · Addressing pillar: rttp.com

One sentence: an assigned address is someone else's promise; a derived address is your own mathematics.