Farcaster
A Farcaster ID is not a login, and this connector never treats it as one. It builds on a wallet you have already attested: ~alter reads the on-chain registry to see whether custody of the FID currently sits at that address. You attest the wallet once and every name layer over it, this one included, composes on that single proof rather than asking you to sign again.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Cast, recast, reply, or send a direct cast from your account.
- •Follow or unfollow anyone, or change your profile.
- •Move, transfer, or recover custody of your FID.
- •Spend from the custody address, since no signing power is involved anywhere in this flow.
- •Surface your Farcaster 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 FID you provide.
- The custody address that FID currently resolves to, read from the public on-chain registry.
- Your existing wallet attestation, read only to compare the two addresses.
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 casts, replies, recasts, and likes.
- Your followers, follows, and channel memberships.
- Your signer keys, which live inside your client app and are never requested.
- Token balances, NFT holdings, or transaction history of the custody address.
- Any hosted indexer view of your account. Resolution reads the chain directly.
Where it lives
The attested FID, the custody address it matched and a tier badge sit in ~alter's pairing ledger keyed to your ~handle. If custody later moves to a different address, re-attest from the new one to keep the binding live. Revoking removes the FID 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 farcasterPairing 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.