Skip to main content
API Preview
Build

Solana Name Service

A .sol name is a name layer over a Solana address, not an account you log into. Attesting one reads the name's registry account on chain and checks the owner against a Solana wallet you have already attested. Top-level names only for now, and nothing beyond the name and its owner is 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 modify any name you own.
  • Set or change records under your name.
  • Move funds from the owning address. No signing power is involved.
  • Read other names owned by the same address.
  • Surface your SNS 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 .sol name you provide.
  • The registry account that name derives to, and the address that owns it, read from a public Solana endpoint.
  • 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.

  • Token balances, NFT holdings, or any portfolio view of the owning address.
  • Transaction history or counterparties, and any social inference from them.
  • Subdomains under your name, which are out of scope entirely.
  • Other names owned by the same address.
  • Seed phrases, private keys, or any signing material.

Where it lives

The attested name, the owning address it matched and a tier badge sit in ~alter's pairing ledger keyed to your ~handle. If the name later resolves to a different owner, re-attest from that 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 sns

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.