ENS
Attesting an ENS name binds an Ethereum-name-service handle to your ~handle so agents resolving you on-chain land on the same identity, and marks the underlying address as a verified destination for identity income once on-chain payouts are enabled. ENS is a name layer over an address you already control. Pairing reads the name and the address it points to, nothing else.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Transfer, rename, or modify any ENS name you own.
- •Set or change records under your ENS name: text records, content hashes, resolver targets.
- •Move funds from the underlying address. ENS pairing carries no signing power.
- •Read other names you own beyond the one you attest.
- •Surface your ENS pairing to any third party without a separate consent row scoped to that recipient.
The OAuth or attestation scope we request is the minimum required to recognise the pattern described in What we read. Anything beyond that is structurally refused at the connector boundary, not promised by trust. How pairing works.
What we read
- The ENS name you provide (e.g. blake.eth).
- The Ethereum address the name currently resolves to.
- A signed SIWE challenge from the underlying address proving control of the name, verified and discarded.
- Once on-chain payouts are enabled, the public on-chain transaction that routes a payout to the underlying address.
What we don't read
~Alter explicitly refuses these fields even when the OAuth scope or API permits them. Every refusal is enforced at the connector boundary, not by trust.
- Other names owned by the same address. Only the attested name is read.
- Text records, content-hash records, or reverse-record state beyond the name itself.
- Token balances, NFT holdings, or any portfolio view of the underlying address.
- Counterparty addresses or social-graph inference from on-chain activity.
- Seed phrases, private keys, or any signing material.
Where it lives
The attested name + resolved address + tier badge sits in ~alter's pairing ledger keyed to your ~handle. If the name later resolves to a different address, you re-attest from the new address to keep the binding live. Revoking removes the name from your pairing surface immediately.
How to revoke
Revocation is immediate. Ask the AI client you paired through to revoke this connector, or revoke it from your consent surface over the same connection. Either path revokes the provider token, stops all further reads, and purges the derived signals this connector fed into your identity vector. An audit row records the revocation.
One thing is kept on purpose. The connector retains a record that this account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your identity vector. That cooldown record holds the raw profile snapshot until the window passes. It is never read into a new signal while disconnected, and it is not shared with anyone.
Prefer the command line? The CLI is the optional deeper path and revokes the same connector:
CLI (optional)
alter unpair ensPairing this connector does not enrol you in any matching, ranking, or matching surface. Every downstream use requires its own consent row. See the consent model.