# FIP: Auth Addresses · farcasterxyz protocol · Discussion #225 Source: https://github.com/farcasterxyz/protocol/discussions/225 Kiwi News: https://news.kiwistand.com/stories/FIP-Auth-Addresses-farcasterxyz-protocol-Discussion-225?index=0x681bd0e1b83eea6c96eff582582e2002cece82e9f221d9d85e1cab1183730c945400e858 Submitted by tim on 2025-05-07 UTC, 1 upvote, 0 comments ## Summary Authors @v, @horsefacts and @sanjay propose "auth addresses," a new Key Registry key type that lets an Ethereum address sign in on behalf of a Farcaster user without sharing custody credentials. A custody address adds an auth address to the registry, after which apps performing Sign in With Farcaster should accept its signatures for that fid. The article's example has Coinbase Wallet generate an ECDSA auth address and an Ed25519 signer, then add both in a single transaction. Auth keys cannot add signers onchain for now, and revoking an auth address is permanent. Transferring an fid does not revoke its auth addresses. ## Article FIP: Auth Addresses Title: Auth Addresses Type: Implementation FIP Authors: @v, @horsefacts , @sanjay Abstract Introduces auth addresses, a new key type in the Farcaster Key Registry that allows an Ethereum address to authenticate on behalf of a Farcaster user. This enables secure, multi-client access for users with smart wallets or multiple devices, without sharing custody credentials. Problem A user’s custody address holds their fid and is used to authenticate using Sign in With Farcaster into apps that rely on Farcaster identity. If a user wants to use multiple clients, they copy their EOA seed phrase into the the other app and can use it simultaneously. This breaks down when clients start using smart wallets where there is no easily transferrable seed phrase. Specification Introduce a new concept, auth addresses. Auth addresses are Ethereum addresses which are allowed to sign in on behalf of a Farcaster user. Until now, this could only be done by a custody address. A custody address can add any Ethereum address as an auth address to the Key Registry. A new key type will need to be added to the registry to allow for this. Once this is performed, all apps performing Sign in With Farcaster should accept a signature from this address as valid for the associated fid. A custody address can also revoke an auth address at any time. Apps must ensure that the key is currently present in the registry before authenticating. According to the rules of the Key Registry contract, revocation is permanent. Assume that Alice uses Warpcast today and wants to add Coinbase Wallet as another client. Coinbase Wallet generates an ECDSA auth address and an Ed25519 signer key. It then requests a single transaction which adds the auth address and the signer to the Key Registry. Once this is complete, Coinbase Wallet can use the auth address to sign into apps and the signer to sign casts. Farcaster Connect FIP should also be extended to support requesting these key pairs. Key Type What it can do Auth Sign in with Farcaster to clients, mini apps, and third party apps Custody Transfer fid, change recovery settings, add/remove keys, change fnames, sign mini app metadata, plus everything an auth address can do Rationale Should we allow these ECDSA auth keys to sign casts and messages? ECDSA signatures are ~10x slower to verify than the Ed25519 signatures we use today, which would create a bottleneck. A new client can ask the user to add an ECDSA auth key and an Ed25519 signer in a single transaction which minimizes any overhead for the user. Should auth keys be Ed25519 keys like signers instead of Ethereum addresses? FC users and developers have learned to treat ECDSA keys like they control money (keep client side and user controlled) and to treat Ed25519 keys like api keys (keep server side). This change requires users to treat some Ed keys like api keys and others like they control money, which causes confusion and doesn’t add any benefit over ECDSA keys. Should Farcaster users have a single wallet where each client has a signer? This has one major downside over the current approach which is that each wallet automatically has access to the user’s fid. The benefit of this approach is that auth keys can add signers and authorize other accounts. Implementation We can enable auth addresses with no changes or new deployments to the existing Farcaster contracts. Key Registry We will introduce a new KeyRegistry key type 2 that reuses the existing SignedKeyRequestValidator: keyRegistry.setValidator( 2, 1, IMetadataValidator(address(0x00000000FC700472606ED4fA22623Acf62c60553)) ); The existing validator checks that keys are exactly 32 bytes. Since Ethereum addresses are 20 bytes, auth keys must be left padded to 32 bytes. This is the same convention used by Solidity abi.encode(). For example, the address 0xe36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90 pads to 0x000000000000000000000000e36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90: ➜ bytes memory authAddress = abi.encode(address(0xe36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90)) ➜ authAddress Type: dynamic bytes ├ Hex (Memory): ├─ Length ([0x00:0x20]): 0x0000000000000000000000000000000000000000000000000000000000000020 ├─ Contents ([0x20:..]): 0x000000000000000000000000e36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90 ├ Hex (Tuple Encoded): ├─ Pointer ([0x00:0x20]): 0x0000000000000000000000000000000000000000000000000000000000000020 ├─ Length ([0x20:0x40]): 0x0000000000000000000000000000000000000000000000000000000000000020 └─ Contents ([0x40:..]): 0x000000000000000000000000e36d2f95a9b69df60dbf029bf7c4fa7d1ff56b90 Constructing signature metadata for auth keys remains the same as for key type 1: the requesting app or entity provides a typed signature over their fid, the key bytes, and a deadline timestamp. Snapchain Snapchain will automatically ingest Key Registry events for the new key type and store auth keys by fid. We'll need to expose new APIs to retrieve this data. Sign in With Farcaster Update Sign in With Farcaster to accept signatures from both FID owner or auth address. Relying parties may choose to accept SIWF messages signed by auth addresses in addition to custody addresses. To verify a SIWF message supporting auth addresses, the relying party must: Attempt to verify the message as an auth address signature: 1a. Verify the SIWF message as a SIWE message. If valid, continue to 1b. If invalid, proceed to 2. 1b. Call KeyRegistry.keyDataOf(signer FID, padded auth address) 1c. Ensure this call returns KeyData(KeyState.ADDED, 2). If so, accept the signature. If not, proceed to 2. If auth address verification fails, verify the message as a custody address signature according to current SIWF verification rules. Relying parties that accept an auth address signature must also accept a custody address signature. See the reference implementation in auth-client for an example. Clients and third party apps Warpcast will extend the existing "signer request flow" to enable auth key requests and batched auth key + app key requests. The existing Bundler contract can add multiple keys at registration time. Apps using third party auth tools like Privy will need to update to allow authentication from auth addresses. Applications that read or depend on Snapchain events may need to ensure they correctly handle new events with keyType=2. Apps that provide SIWF as a service should allow clients to opt in to auth key SIWF signatures. Considerations for clients and developers Apps requesting an auth key should ensure they correctly pad the address to exactly 32 bytes. Revoking an auth address is permanent according to the rules of the Key Registry. Apps and users should be careful when adding and revoking auth addresses. Apps should make it clear that auth keys are unlike verified addresses, which can be added and removed at will. Transferring or recovering an FID will not automatically revoke its auth keys (just like transferring an FID does not automatically revoke its signers). Users who purchase or receive an fid from an untrusted party should first verify that its auth addresses are revoked. Release See Auth Addresses Implementation. Appendix: FAQ Should auth keys be able to add signers? This would be ideal, but not possible in the onchain Key Registry. We plan to move key management to snapchain this year so we could move it when that happens. Can one auth address be added to multiple fids? Yes, and in fact this may be desirable for some use cases, like shared accounts. Should this replace verified addresses? A verified address is an Ethereum or Solana address that is provably controlled by the user. The proof is established by counter-signing a message with a user’s signer and the address being verified. This allows any app to be able to verify addresses which poses a slight security risk but has a simpler UX since it allows signing from web browsers. It’s not clear that we should deprecate these yet at least until using wallets from browsers becomes easier. Should we support Solana addresses? In theory, this should be fine since apps can verify any arbitrary signature. In practice, it may mean a little more overhead for the app developers. We assume for now that all auth addresses are Ethereum addresses.