Skip to main content
API Preview
Build

Unstoppable Domains

Attesting an Unstoppable domain checks one thing: whether the wallet you have already attested owns the domain itself. ~alter deliberately does not read the records under your domain, because a record is set by the owner and can point anywhere, including at somebody else's address. Ownership binds the other way, so ownership is the only field read.

What pairing does not authorise

Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:

  • •Transfer, rename, or burn any domain you own.
  • •Set or change records under your domain.
  • •Move funds from the owning address. No signing power is involved.
  • •Read the payout addresses your records point at.
  • •Surface your Unstoppable 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 domain name you provide.
  • The address that currently owns the domain, read on chain across each deployment the namespace spans.
  • Your existing wallet attestation, read only to compare the owner against it.

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.

  • The records surface, including any crypto address you have published under the domain.
  • Token balances, NFT holdings, or transaction history of the owning address.
  • Other domains owned by the same address.
  • Subdomains issued under your domain.
  • Seed phrases, private keys, or any signing material.

Where it lives

The attested domain, the owning address it matched and a tier badge sit in ~alter's pairing ledger keyed to your ~handle. If the domain later changes hands, re-attest from the new owner's address to keep the binding live. Revoking removes the domain 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 unstoppable

Pairing 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.