Skip to main content
API Preview
Build

Lens

Lens is a name layer over an account, not a login, so attesting one asks nothing new of you if you have already attested a wallet. ~alter reads the Lens namespace on chain to see which account holds your username, then checks whether your attested address owns that account. No signature, no app registration, no credential.

What pairing does not authorise

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

  • •Post, mirror, comment, or collect from your Lens account.
  • •Follow or unfollow anyone, or change your profile metadata.
  • •Transfer your username or the account holding it.
  • •Spend from the owning address. This connector carries no signing power.
  • •Surface your Lens 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 Lens username you provide.
  • The Lens Account that currently holds it, and the address that owns that account, both read from the chain.
  • Your existing wallet attestation, read only to compare the owning address 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.

  • Your publications, mirrors, comments, and collects.
  • Your followers, follows, and the graph around your account.
  • Token balances, NFT holdings, or transaction history of the owning address.
  • Other usernames owned by the same address. Only the attested one is read.
  • Private keys or signing material of any kind.

Where it lives

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

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.