The verification problem

Cross-platform identity verification today depends on the platforms themselves vouching for you. A blue check on one site says nothing about another. Linking a wallet to a social handle requires the platform's API to be running, the platform's policy to allow it, and the platform's data to stay accurate. None of those are durable.

For decentralised systems — DAOs, on-chain reputation, ENS-native governance — this matters. The link between an Ethereum identity and a social presence carries real weight, but the proof lives in a service that can disappear, rename, or change its mind tomorrow.

What atst.me is

atst.me is a specification and reference attester service for cryptographic attestations binding an ENS name to a social account. The attester is a backend service that observed both the wallet (via SIWE) and the platform login (OAuth, login widget, etc.) within a single session, then signed an attestation under EIP-191 over the canonical DAG-CBOR encoding of the payload:

$$\sigma = \mathrm{sign}_{\,\mathrm{EIP\text{-}191}}\!\Big(\,\mathrm{keccak256}\big(\mathrm{dag\text{-}cbor}(\mathcal{P})\big)\,\Big)$$

What lives on chain is a compact three-element envelope — version, issuance timestamp, and the signature — wrapped in a CBOR tag that spells "atst" in ASCII (0x61747374):

$$\mathtt{Envelope}_{v2} \;=\; \#6.1635021684\big[\; 2,\;\; \mathtt{issuedAt}\!:\!\mathtt{uint},\;\; \mathtt{sig}\!:\!\mathtt{bstr}_{65}\;\big]$$

The payload $\mathcal{P}$ itself is not stored. The signed envelope is published as a parameterised text record on the user's ENS name — for example, attestations[com.x][attester.eth] — and verifiers reconstruct $\mathcal{P}$ from public context (the ENS name being read, the platform from the record key, the handle from a sibling text record, the timestamp from the envelope) before checking the signature. No central registry, no platform dependency at read time, no honeypot.

Currently X (com.x) and Telegram (org.telegram) are supported; the framework extends to any platform with server-verifiable authentication.

Two attestation modes

Handle attestations bind to a public handle. The handle is visible on-chain as a plain text record (com.x = "alice") and the signed envelope sits next to it. Any verifier can check the link.

UID attestations bind to the platform's internal user ID — the OAuth sub, the Telegram numeric ID, or equivalent. The UID itself is not stored on chain; only the signature is. Anyone who knows the UID out-of-band can verify the attestation, but the identifier stays hidden. This is the mode for the account I attested to is still the account I attested to even when the visible handle changes — two questions that platforms have historically conflated.

The two payloads share four fields and differ only in the fifth — a visible handle ($\mathtt{h}$) versus a private UID ($\mathtt{u}$):

$$\mathcal{P}_{\mathrm{handle}} = \begin{Bmatrix} \mathtt{n} : \mathtt{tstr} \\ \mathtt{a} : \mathtt{bstr}_{20} \\ \mathtt{p} : \mathtt{tstr} \\ \mathtt{h} : \mathtt{tstr} \\ \mathtt{t} : \mathtt{uint} \end{Bmatrix} \qquad \mathcal{P}_{\mathrm{uid}} = \begin{Bmatrix} \mathtt{n} : \mathtt{tstr} \\ \mathtt{a} : \mathtt{bstr}_{20} \\ \mathtt{p} : \mathtt{tstr} \\ \mathtt{u} : \mathtt{tstr} \\ \mathtt{t} : \mathtt{uint} \end{Bmatrix}$$

$\mathtt{n}$ is the ENS name, $\mathtt{a}$ the 20-byte wallet address the attester observed via SIWE, $\mathtt{p}$ the reverse-DNS platform namespace, and $\mathtt{t}$ the issuance timestamp matching the envelope.

Revocation by ENS rotation

The attester's address is derived by resolving its ENS name at verify time. Rotating that address record retires the prior signing key — every signature made with the old key fails verification on the next read. There's no separate revocation registry, no expiry queue, no authority to call. Key rotation is the revocation mechanism.

Status

The service is live at atst.me and the v2 envelope format is published as a specification. The SDK ships handle and UID verification with configurable expiration windows. Lighthouse runs atst.me as a reference implementation for what verifiable cross-system identity can look like when neither the issuing service nor the receiving platform has to be trusted at read time.