FIP: Snapchain Signers

[topocount]

Abstract

This proposal introduces key registration via custody-authenticated messages, eliminating the gas cost and friction of onchain Key Registry transactions. Users register and revoke keys by producing an EIP-712 signature from their custody address. Snapchain processes these as protocol messages, achieving the same end state as onchain registration at zero cost. This decouples key registration from onchain signer addition, removing it from the user onboarding critical path.

The same KEY_ADD primitive supports two first-class capabilities in addition to traditional full-authority signers:

• Scopes — every KEY_ADD must explicitly enumerate the MessageType values the key may sign. There is no "full authority" shortcut; a full-authority client must list every type explicitly. This is a fail-closed design, so adding new MessageType values in the future does not implicitly grant them to existing keys.
• Sliding TTL (OAuth2-style) — a key may carry a TTL such that its validity window slides forward on every use. No refresh tokens; the key's activity is itself the renewal signal. Revocation remains immediate and is unaffected by TTL.

Motivation

Cost barrier

Each key currently requires an onchain transaction on Optimism. This costs gas, requires a wallet interaction, and demands the user wait for block confirmation. For miniapp developers trying to onboard users, this is a meaningful conversion barrier.

Custodial signer concentration

The cost barrier pushes miniapps toward a shared-signer model where a single app holds full signing authority for many users. This concentrates risk: a single server compromise exposes every user's signing capability.

Friction for developers

Onchain key registration requires developers to integrate wallet connection flows, manage gas sponsorship, and handle transaction failures. This complexity discourages experimentation and slows the pace of new app development.

All-or-nothing delegation

Today, every registered key has unrestricted, indefinite authority over every message type for the FID. There is no way to grant a miniapp permission to post casts but not change your profile, or to allow reactions but not verification messages. When a user authorizes a key for a miniapp, they grant the same authority they give to their primary client — an inappropriate trust model for lightweight integrations (frames, bots, tipping apps, mints).

Blast radius of compromise

If a miniapp's key is leaked, the attacker has full, indefinite signing authority over the user's FID. The Schedly incident demonstrated this precisely: the attacker had the same authority as the legitimate app. Scopes and sliding TTL together bound both the breadth and the lifetime of any compromise.

Why not MPC?

MPC/FROST threshold signing is a valid approach to key custody, but it introduces mandatory interactive signing rounds (2 round trips to a broker) for every signature. This conflicts with Farcaster's design goal of seamless programmatic signing — tips, mints, bots, and automated actions all depend on instant, local signing. Scopes plus sliding TTL deliver blast-radius reduction without adding per-signature friction. MPC remains complementary future work.

Specification

New message types

MESSAGE_TYPE_KEY_ADD = 16
MESSAGE_TYPE_KEY_REMOVE = 17

KeyAddBody

message KeyAddBody {
  bytes key = 1;                    // Ed25519 public key (32 bytes)
  uint32 key_type = 2;             // 1 = Ed25519
  bytes custody_signature = 3;     // EIP-712 signature from custody address
  uint32 deadline = 4;             // Farcaster epoch timestamp after which the custody signature is invalid
  uint32 nonce = 5;                // Monotonically increasing per-FID nonce
  bytes metadata = 6;              // Required: ABI-encoded SignedKeyRequestMetadata (see metadata validation)
  uint32 metadata_type = 7;        // Must be 1 (SignedKeyRequest)
  bytes registration_tx_hash = 8;  // Optional: tx hash of the FID registration transaction (see FID resolution)
  repeated int32 scopes = 9;       // Allowed MessageType values. Required, non-empty. See Scopes section.
  uint32 ttl = 10;                 // Seconds. 0 = no expiry. >0 = sliding expiry window (see Sliding TTL).
}

KeyRemoveBody

message KeyRemoveBody {
  bytes key = 1;                    // Ed25519 public key to remove
  bytes signature = 2;             // EIP-712 signature from custody address OR Ed25519 signature from the key itself (self-revocation)
  uint32 signature_type = 3;       // 1 = custody (EIP-712), 2 = self (Ed25519)
  uint32 deadline = 4;             // Farcaster epoch timestamp after which the signature is invalid
  uint32 nonce = 5;                // Monotonically increasing per-FID nonce
}

MessageData extension

message MessageData {
  // ... existing fields ...
  oneof body {
    // ... existing bodies ...
    KeyAddBody key_add_body = 19;
    KeyRemoveBody key_remove_body = 20;
  }
}

EIP-712 domain and types

Domain: {
  name: "Farcaster KeyAdd",
  version: "1",
  chainId: <OP chain ID>
}

KeyAdd: [
  { name: "fid", type: "uint256" },
  { name: "key", type: "bytes" },
  { name: "keyType", type: "uint32" },
  { name: "scopes", type: "uint32[]" },
  { name: "ttl", type: "uint32" },
  { name: "nonce", type: "uint32" },
  { name: "deadline", type: "uint256" }
]

KeyRemove (custody, EIP-712): [
  { name: "fid", type: "uint256" },
  { name: "key", type: "bytes" },
  { name: "nonce", type: "uint32" },
  { name: "deadline", type: "uint256" }
]

KeyRemove (self-revocation): Ed25519 signature over the same fields, signed by the key being removed.

The scopes and ttl fields are part of the signed authorization payload so the custody signature binds to the exact permissions and lifetime being granted.

FID resolution (KEY_ADD only)

KEY_ADD requires a registered FID. The client is responsible for submitting the FID registration transaction on-chain before submitting the KEY_ADD message to Snapchain. The registration_tx_hash field controls how the FID is resolved:

If registration_tx_hash is absent: The FID must already exist in Snapchain state (i.e., an IdRegisterEvent has been processed). If it does not exist, reject with a 400-level error.

If registration_tx_hash is present:

1. Check Snapchain's on-chain event index for the tx hash:
   • Found, with matching IdRegisterEvent for this FID → FID is resolved, proceed to validation
   • Found, but no matching IdRegisterEvent → reject (400)
2. If not found, query L1/L2 RPC for the transaction status:
   • Tx settled with no events emitted (reverted/failed) → reject (400)
   • Tx not found or still pending → accept into mempool, process when the on-chain event arrives
   • Tx settled and succeeded but events not yet ingested → accept into mempool (Snapchain will catch up shortly)

Mempool entries with a registration_tx_hash are flushed when the corresponding on-chain event batch is ingested, or evicted after a TTL (e.g., 10 minutes) if the tx never settles.

Transaction replacement detection

When a KEY_ADD is accepted into the mempool with a pending registration_tx_hash, Snapchain records the sender address, account nonce, and requestFid (app FID) from the pending transaction. Rather than polling on a timer, eviction is lazy: the replacement check runs the next time any request arrives for the same user FID or the same app FID (another KEY_ADD, KEY_REMOVE, self-revocation, or regular message). Snapchain checks eth_getTransactionCount for the sender. If the sender's on-chain nonce has advanced past the recorded nonce without the expected tx hash settling, the original transaction was replaced — evict the mempool entry.

Hooking into app FID activity is valuable because the app is typically more active than any individual user — an app registering keys for many users will naturally trigger replacement checks for all its pending entries. This makes the RPC cost zero in the common case (tx settles quickly, on-chain event flushes the entry) and provides frequent eviction opportunities via app activity. The TTL remains as a backstop for entries where neither the user nor app see further requests.

(Pending discussion with Arthur on whether this approach is sufficient or if active polling is also needed.)

Metadata validation (SignedKeyRequest)

For key registration via KEY_ADD, the metadata field is required with metadata_type = 1 (SignedKeyRequest). This contains an ABI-encoded SignedKeyRequestMetadata struct — the same format used by the onchain SignedKeyRequestValidator contract:

struct SignedKeyRequestMetadata {
    uint256 requestFid;      // App FID that requested this key
    address requestSigner;   // Custody address of the app FID
    bytes signature;         // EIP-712 signature from requestSigner
    uint256 deadline;        // Signature expiry
}

Onchain, the contract verifies this signature before emitting the event — Snapchain trusts the contract. For signers registered via KEY_ADD, there is no contract in the loop, so Snapchain must verify the SignedKeyRequest signature directly:

1. ABI-decode metadata → extract requestFid, requestSigner, signature, deadline
2. Verify deadline >= current_block_timestamp
3. Recover Ethereum address from signature via EIP-712 typed data recovery (same domain the contract uses)
4. Verify recovered address == requestSigner
5. Verify requestSigner is the custody address of requestFid (lookup from IdRegisterEvent)

Without this verification, an attacker could claim any requestFid, enabling false app attribution and nonce consumption on another app's counter.

The verified requestFid is stored alongside the key registration and serves as the appFid for downstream indexing (consistent with the on-chain path).

Nonce scoping

Nonces are scoped by the entity authorizing the operation:

• User nonce (per user FID): Used by KEY_ADD and custody KEY_REMOVE (signature_type = 1). The user's custody address is the authorizing entity.
• App nonce (per app FID): Used by self-revocation KEY_REMOVE (signature_type = 2). The app that holds the key is the authorizing entity. Scoped to the requestFid from SignedKeyRequestMetadata stored at key registration time.

This ensures an app's self-revocation activity does not consume the user's nonce counter. Spam protection for self-revocation is additionally provided by the active key state check — an app can only self-revoke keys that are currently active.

Scopes

The scopes field enumerates the MessageType values a key is permitted to sign. It is required and must be non-empty for every KEY_ADD. There is no "full authority" shortcut — callers that want a key with broad permissions must list every MessageType explicitly. This is a fail-closed design: if new MessageType values are added to the protocol in the future, existing keys do not implicitly gain access to them. The custody signature binds to the exact set of scopes, so any change to a key's authority requires a new KEY_ADD.

Any message whose type is not in the key's scopes fails validation.

Client libraries and SDKs should provide a convenience helper (e.g., allStandardTypes()) that expands to the current set of standard message types at call time. This gives callers a simple one-call UX equivalent to "full delegation" while keeping the on-wire representation explicit and the signed authorization unambiguous.

Use case	scopes
Full-authority client signer (Warpcast, etc.)	[CAST_ADD, CAST_REMOVE, REACTION_ADD, REACTION_REMOVE, LINK_ADD, LINK_REMOVE, VERIFICATION_ADD_ETH_ADDRESS, VERIFICATION_REMOVE, USER_DATA_ADD, FRAME_ACTION] (all current standard types, explicitly listed)
Cast-only bot	[CAST_ADD, CAST_REMOVE]
Social actions only	[REACTION_ADD, REACTION_REMOVE, LINK_ADD, LINK_REMOVE]
Miniapp with no write needs	Don't register a key

Note: USER_DATA_ADD comprises multiple data types. These are not decomposed for scoping as a part of this FIP. For example, a signer cannot update a PFP but not a BIO. The reason for this is that these are all client-level modifications changes a user might want to make, not app specific.

Onchain keys registered via the existing Key Registry contract predate the scopes field. They are grandfathered as implicit full authority for backwards compatibility — their validation path is unchanged. This grandfather clause only applies to onchain keys; every KEY_ADD must carry explicit scopes.

Note: Onchain keys may eventually be subject to a TTL (and possibly scopes) via a future FIP, to bring them in line with signers registered via KEY_ADD and retire the grandfather clause. That migration is out of scope for this proposal.

Regardless of scopes, all keys are always blocked from signing KEY_ADD messages at the mempool layer. KEY_ADD authorization comes from the embedded custody_signature, not from the message signer — this keeps the mempool surface tight. KEY_REMOVE has a separate carve-out described below.

Sliding TTL

The ttl field enables OAuth2-style sliding expiration:

• ttl = 0 → the key never expires based on inactivity. This is the default and matches traditional signer behavior.
• ttl > 0 → the key is valid while last_used_at + ttl >= current_block_timestamp. Each successfully validated message signed by the key updates last_used_at to message.timestamp. There are no refresh tokens — continued use of the key is itself the renewal signal.

last_used_at is initialized to message.timestamp at the time of KEY_ADD. A key registered with a TTL but never used will expire ttl seconds after creation.

Revocation (via KEY_REMOVE, either custody or self-signature) is immediate and unaffected by last_used_at or ttl. A revoked key cannot be "reactivated" by any operation; it must be re-registered with a new KEY_ADD.

The maximum allowed ttl is 90 days (open question — see below). Keys with ttl > 0 and ttl > MAX_TTL are rejected at KEY_ADD time.

Validation flow (KEY_ADD)

1. Resolve FID (see FID resolution above)
2. Decode MessageData and extract KeyAddBody
3. Verify metadata_type == 1 and validate SignedKeyRequest metadata (see above)
4. Verify deadline >= current_block_timestamp
5. Verify nonce > last_nonce_for_fid (per-FID monotonic counter, stored on shard 0)
6. Recover Ethereum address from custody_signature via EIP-712 typed data recovery (over the full payload including scopes and ttl)
7. Verify recovered address matches the custody address of the FID (from IdRegisterEvent)
8. Verify key_type == 1 (Ed25519)
9. Verify scopes is non-empty and every value is a valid MessageType enum value
10. Verify ttl <= MAX_TTL (90 days)
11. Register key as active — equivalent to an on-chain SIGNER_EVENT_TYPE_ADD
12. If ttl > 0, initialize last_used_at = message.timestamp

Validation flow (KEY_REMOVE)

KEY_REMOVE supports two authorization modes via signature_type, reusing a single message type to minimize API surface:

Custody revocation (signature_type = 1): The FID owner revokes a key.

1. Decode MessageData and extract KeyRemoveBody
2. Verify FID exists in Snapchain state
3. Verify key is currently an active key for this FID
4. Verify deadline >= current_block_timestamp
5. Verify nonce > last_nonce_for_fid
6. Recover Ethereum address from signature via EIP-712 typed data recovery
7. Verify recovered address matches the custody address of the FID
8. Deactivate key — equivalent to an on-chain SIGNER_EVENT_TYPE_REMOVE

Self-revocation (signature_type = 2): The app/entity that holds the key revokes it. This enables mass revocation when an app is compromised (e.g., the Schedly incident) without requiring each user to act individually. Self-revocation is always allowed regardless of scopes — a scoped key whose scopes don't include KEY_REMOVE must still be able to revoke itself if compromised.

1. Decode MessageData and extract KeyRemoveBody
2. Verify FID exists in Snapchain state
3. Verify key is currently an active key for this FID
4. Verify deadline >= current_block_timestamp
5. Look up the requestFid (app FID) stored at key registration time
6. Verify nonce > last_nonce_for_app_fid (app FID's nonce counter)
7. Verify signature is a valid Ed25519 signature over the removal payload, signed by key
8. Deactivate key — equivalent to an on-chain SIGNER_EVENT_TYPE_REMOVE

Validation flow (messages signed by a key)

For every user message (cast, reaction, link, etc.), after the existing signature/hash checks, Snapchain performs:

1. Look up the key for (fid, message.signer) in the signer index. If absent, reject (MissingSigner).
2. If the key has ttl > 0:
   • Read last_used_at for this key.
   • If last_used_at + ttl < current_block_timestamp, reject (expired).
3. Scope check:
   • If the key is an onchain (grandfathered) key: skip the scope check.
   • Otherwise (signer registered via KEY_ADD): if message_data.type is not in scopes, reject.
   • Exception: a self-revocation KEY_REMOVE signed by the key being removed is permitted regardless of scopes.
4. Accept.
5. If ttl > 0, write last_used_at = message.timestamp.

Onchain keys perform a single read, identical to today. Signers registered via KEY_ADD add a scope containment check (microseconds). TTL'd keys additionally read and write last_used_at.

Conflict resolution

Signers registered via KEY_ADD and onchain keys coexist:

• Same key, both add: First registration (by block height for onchain, by message timestamp for KEY_ADD, with KEY_ADD taking precedence for ties) wins. Duplicate add is a no-op.
• Removal: Removal via either pathway deactivates the key regardless of how it was registered.
• Re-registration: A removed key can be re-added via either pathway.

Nonce management

There are two nonce counters, both monotonically increasing and stored on shard 0:

• User nonce (per user FID): Used by KEY_ADD and custody KEY_REMOVE. Prevents replay and ensures ordering of user-authorized key operations.
• App nonce (per app FID): Used by self-revocation KEY_REMOVE. Scoped to the requestFid from SignedKeyRequestMetadata. Since requestFid is mandatory and verified (see metadata validation), every key has a valid app FID to scope against.

If a message arrives with a nonce that has already been used or is less than the current nonce for its respective counter, it is rejected.

Storage and shard routing

Key operations via KEY_ADD and KEY_REMOVE are routed to shard 0 and are never pruned. This ensures key state is always available for message validation across all shards.

The primary record mirrors the existing onchain signer index and is extended to carry scopes and ttl:

Primary: [RootPrefix::OnChainEvent | OnChainEventPostfix::OnChainEvents | EventTypeSigner | FID | BlockNumber/Timestamp | LogIndex/Nonce]
  → serialized OnChainEvent (for onchain) or KeyAdd message including scopes/ttl (for `KEY_ADD`)

Secondary (key lookup): [RootPrefix::OnChainEvent | OnChainEventPostfix::SignerByFid | FID | PublicKey]
  → pointer to primary key

Signers registered via KEY_ADD reuse the same secondary index (SignerByFid) so that get_active_signer() works identically for both onchain and KEY_ADD-registered signers. Onchain keys predate scopes and ttl and are grandfathered: the scope check is bypassed for them, and they have no TTL. Signers registered via KEY_ADD always carry explicit scopes (required non-empty at KEY_ADD time) and optional ttl.

Nonce storage

User nonce:
[RootPrefix::OffchainKey | OffchainKeyPostfix::UserNonce | FID]
  → u32 (last used user nonce)

App nonce:
[RootPrefix::OffchainKey | OffchainKeyPostfix::AppNonce | AppFID]
  → u32 (last used app nonce)

Sliding-expiry storage

A new per-key index tracks last_used_at for keys with ttl > 0:

[RootPrefix::OffchainKey | OffchainKeyPostfix::LastUsedAt | FID | PublicKey]
  → u32 (last used farcaster epoch timestamp)

Only populated for keys where ttl > 0. Keys with ttl = 0 skip this write on every validated message, keeping the hot path unchanged.

Implementation in Snapchain

Key changes

1. Protobuf: Add MESSAGE_TYPE_KEY_ADD (16), MESSAGE_TYPE_KEY_REMOVE (17), KeyAddBody (with scopes and ttl), KeyRemoveBody to message.proto.
2. EIP-712 recovery: Add an EIP-712 typed data recovery function. Snapchain already has alloy_primitives as a dependency and uses SignatureScheme::Eip712 for address verification — this extends that capability to custody signature recovery over the extended KeyAdd payload.
3. Validation (src/core/validations/message.rs): Add validation for KeyAddBody and KeyRemoveBody — check field presence, key length, deadline, scopes enum values, ttl <= MAX_TTL.
4. FID resolution (src/mempool/mempool.rs, src/connectors/onchain_events/mod.rs): Implement the registration_tx_hash flow — check on-chain event index, query L1/L2 RPC for pending txs, buffer in mempool, flush on event ingestion.
5. Engine (src/storage/store/engine.rs, src/storage/store/block_engine.rs): Handle KEY_ADD and KEY_REMOVE in the message processing pipeline. These update the signer index (same secondary index used by get_active_signer()). For every validated user message, additionally check scopes, check sliding expiry (if ttl > 0), and update last_used_at on success.
6. Shard routing: Route KEY_ADD and KEY_REMOVE to shard 0.
7. Nonce store: New lightweight store for per-FID and per-app nonces on shard 0.
8. Last-used store: New lightweight store for last_used_at on shard 0, populated only for keys with ttl > 0.

What doesn't change

• get_active_signer() remains the entry point for the signer lookup — its return type grows to carry scopes and ttl, but callers that don't care about those fields continue to work.
• Message validation for all other message types is unchanged.
• On-chain event processing is unchanged.
• Consensus is unchanged (new message types flow through existing consensus).

Performance

Path	Cost
Message signed by onchain (grandfathered) key	1 RocksDB read — unchanged
Message signed by signer registered via KEY_ADD, ttl = 0	1 read of key record + in-memory scope check
Message signed by signer registered via KEY_ADD, ttl > 0	1 read of key record + in-memory scope check + 1 read of last_used_at + 1 write of last_used_at
KEY_ADD	EIP-712 recovery + write (no change to hot path)
KEY_REMOVE	Signature recovery + delete (no change to hot path)

All operations are O(1) point reads/writes. The additional cost for scoped/TTL'd keys (~microseconds) is negligible compared to consensus and network latency, and is skipped entirely for traditional onchain signers.

Security Properties

Same trust model as onchain

Key registration via KEY_ADD requires the same custody address signature that the onchain Key Registry requires. The trust anchor is identical. The difference is that snapchain validates the signature directly instead of relying on an onchain contract.

Replay protection

The per-FID nonce prevents replay attacks. A captured KEY_ADD message cannot be replayed because the nonce will have already been consumed.

Custody-signature deadline enforcement

The deadline field in the custody signature prevents long-lived authorization payloads from being submitted later. If a user signs a key authorization but the app never submits it, the authorization becomes invalid after the deadline. This is separate from the key's own ttl — the deadline controls how long the authorization-to-register is valid, while ttl controls how long the registered key itself is valid.

Blast radius containment

Scopes and sliding TTL together bound the impact of a key compromise:

• A compromised scoped key can only produce messages of permitted types.
• A compromised TTL'd key is only usable until last_used_at + ttl — and if the attacker stops using it, it expires on its own. If the attacker keeps using it, the legitimate app is likely to notice anomalous activity and revoke before further damage.

Compare to a traditional onchain signer, where a compromise grants unrestricted, indefinite authority.

Transparent revocation

Custody can revoke any key immediately via KEY_REMOVE (signature_type=1). A key can always revoke itself via self-signature (signature_type=2) regardless of its scopes — this remains true even for scoped keys whose scopes don't include KEY_REMOVE, so that compromised keys can be terminated by the app that holds them.

Standard signatures

Keys produce standard Ed25519 signatures. The Message envelope, HashScheme, and SignatureScheme are unchanged. Existing clients that verify signatures will still verify correctly. The get_active_signer() lookup itself is also unchanged. What changes is (a) the set of keys in the signer index now includes signers registered via KEY_ADD, and (b) validation applies additional scope and expiry checks after the lookup.

Key operation rate limiting

KEY_ADD is subject to a dedicated rate limit, separate from regular message rate limits: 1 key add per FID per minute. This is enforced at the RPC ingestion layer. KEY_REMOVE is not rate limited — revocation of a compromised key should never be blocked.

This rate limit is sufficient for legitimate usage (key registration happens once during onboarding, or during periodic rotation for TTL'd keys) while preventing spam. The rate limiter's per-FID check also serves as the hook for lazy eviction of stale mempool entries — when a KEY_ADD arrives for a FID with a pending registration_tx_hash, the replacement detection check (see FID resolution) runs at the same time.

(Rate limit value pending discussion with Arthur — 1/min is the starting proposal.)

Active key cap

The maximum number of active keys per FID is 1000, matching the on-chain KeyRegistry contract limit. This is a combined cap across on-chain and off-chain keys. KEY_ADD is rejected if the FID already has 1000 active keys.

No new key types

This proposal only supports Ed25519 keys (key_type == 1), the same key type supported by on-chain registration.

No interactive signing protocol

Keys — including scoped or TTL'd keys — require no network round trips to produce a signature. The holder has the complete private key. This preserves programmatic signing for tips, mints, bots, and automated workflows.

Comparison with MPC/FROST

Dimension	This proposal (scopes + TTL)	MPC/FROST
Signing latency	Instant (local)	2 round trips to broker
Programmatic signing	Yes	Requires broker availability
Blast radius reduction	Scope + sliding TTL	Threshold (no single party can sign)
Protocol changes required	Yes (new message types + fields)	None (standard Ed25519 output)
Infrastructure dependency	None	MPC broker service
Offline signing	Yes	No
Key compromise model	Bounded by scope and inactivity	Neither party alone can sign

These approaches are complementary. A future FIP could add MPC as an option for how key private material is custodied, while this proposal handles the delegation/scoping/lifetime layer. This proposal prioritizes the scope+TTL model because it delivers the most immediate ecosystem value with the least per-signature friction.

EIP-1271 (Smart Contract Wallets)

Smart contract wallet support via EIP-1271 is intentionally deferred. It requires snapchain to make onchain isValidSignature calls during validation, which introduces external dependencies in the consensus-critical path. This deserves its own FIP with a detailed design for how validators handle these calls (caching, timeout, fallback behavior).

Future Consideration: ZK-Gated Opaque Policies

The transparent ACL in this proposal (scopes) is simple and auditable, but it requires policies to be visible on-chain. An alternative approach would use ZK proofs to enforce opaque (private) policies:

1. At KEY_ADD, the app commits to a policy as a hash (not plaintext scopes).
2. Each message signed by the key includes a ZK proof: "this message complies with the policy committed at creation time, and the current Snapchain state authorizes it".
3. Snapchain verifies the proof instead of checking scopes — enforcement is still at the protocol layer, but the policy itself stays private.

This achieves non-transparent ACL enforcement without introducing a broker dependency. The app still holds the complete key and signs locally (no MPC latency), but cannot produce a message that passes validation without a valid proof of policy compliance.

This approach adds significant complexity (ZK circuit design for Snapchain state proofs, proof generation cost per message, verification cost at validators) and is deferred to a future FIP. It becomes more attractive if apps need richer or private policy semantics beyond per-MessageType scoping.

Open Questions

1. Max TTL: 90 days is proposed as a starting point. Should this be shorter (e.g., 30 days) to force more frequent re-authorization, or longer for long-running bots? Shorter caps improve security guarantees but increase rotation frequency.
2. Rate limiting value: 1 KEY_ADD per FID per minute is the starting proposal. Pending discussion with Arthur.
3. RPC API: What new RPC endpoints are needed? At minimum: getSignersByFid should return both on-chain and off-chain keys transparently, including their scopes, ttl, and (if applicable) last_used_at. A user-facing UI listing active delegations is important for transparency.
4. Per-key write amplification for TTL'd keys: Every validated message from a TTL'd key writes to the last_used_at index. For high-throughput bots, this could be meaningful. Should we coarsen updates (e.g., only bump last_used_at if the new value differs by more than N seconds from the previous)?
5. Storage quota: Should off-chain key creation count against the FID's storage quota? Currently proposed as free (shard 0), but this could allow abuse by creating large numbers of keys. The 1000-key cap limits absolute damage; the 1/min rate limit limits velocity.
6. Finer-grained scoping: This FIP scopes permissions at the MessageType level. Future extensions could add target-level scoping (e.g., "only react to casts in this channel") but this adds significant complexity and is deferred.

References

• Functional Signers proposal (Discussion #262)
• EIP-712: Typed structured data hashing and signing
• Farcaster Key Registry contract
• OAuth 2.0 Token Expiry (RFC 6749)
• Alchemy Session Keys documentation

[CryptoExplor]

This FIP directly addresses one of the most painful points in the current mini-app developer experience. The gas cost + wallet interaction requirement for key registration is a real conversion killer — I've seen users drop off at exactly that step during onboarding flows.

What this unblocks for mini-app devs:

The shift to EIP-712 offchain custody signatures processed by Snapchain means apps can register keys as part of normal sign-up flow without ever prompting a wallet gas transaction. For apps targeting users who are new to web3 (or just on mobile), this is significant. The Schedly/Supabase incident is also a good reference point here — self-revocation (signature_type = 2) being available to the app without requiring individual user action is exactly the emergency escape hatch that was missing.

A few thoughts/questions from the dev side:

1. SDK changes: Will the @farcaster/miniapp-sdk or auth-kit be updated to abstract the EIP-712 signing + KEY_ADD message construction? Right now most apps rely on Neynar or Privy for signer management — it'd be great to know if those providers are in the loop on this draft.

2. Deadline UX: The deadline field on the custody signature — what's the expected TTL for typical onboarding flows? If a user starts registration, gets interrupted, and comes back 20 minutes later, will their pending signature still be valid? Guidance on recommended deadline windows for app developers would be helpful.

3. Rate limit (1 KEY_ADD / FID / minute): For apps doing batch onboarding (e.g., migrating existing users), is there any provision for a higher rate? Or is the expectation that migration flows use the on-chain path in bulk?

4. RPC API (Open Question Add spec for URIs #1): Agreed that getSignersByFid returning both on-chain and off-chain keys transparently is the right approach. From an app developer perspective, it'd also be useful to have a lightweight isActiveKey(fid, pubkey) endpoint that doesn't require parsing the full signer list — that's the hot path for most message validation.

Overall this is a well-scoped, immediately valuable change. Separating it from the broader Functional Signers proposal and shipping it independently was the right call.

[topocount]

@CryptoExplor great questions!

1. Yes we'll be adding this functionality to the SDK
2. Deadline UX These signatures are gasless so it's not unreasonable to expect the user to auth another key when they return
3. Rate limit onchain signers will not be hard-deprecated in any way. I added a note above to indicate that we'll likely add a sliding TTL for onchain signers at some point before we fully deprecate them, just so we can start invalidating inactive signers without disrupting those that are still used.
4. good calllout on 4. Will consider

[CryptoExplor]

@topocount Thanks for the detailed responses! This clarifies a lot.

On SDK integration: Glad to hear it. Having native support will make adoption much smoother for builders. Any timeline estimate for when this hits the SDK?

On Deadline UX: Makes sense — gasless signatures do change the cost/friction calculation. One follow-up though: for mobile users on spotty connections or those who auth infrequently, what's the re-auth flow look like? Will clients need to implement their own "deadline approaching" warnings, or will there be SDK-level helpers for this?

On sliding TTL for onchain signers: This is the right path forward. Gradual deprecation > hard cutoffs. The sliding TTL approach could also serve as a useful data signal — if an onchain signer hasn't been used in X months, it's likely a dormant key and safe to invalidate. Have you considered tying the TTL window to actual usage patterns rather than a fixed timeframe? (e.g., "inactive for 6 months" vs "hasn't signed a cast in the last 180 days")

One more edge case to consider:
What happens if a user's offchain signer expires mid-session while they're composing a long post or doing a batch operation? Do clients need to handle re-auth before submission, or will the protocol reject with a clear error that clients can catch and prompt re-auth?

Looking forward to seeing this ship!

[topocount]

Updated the FIP to add scoping. This authorizes specific message types the signer can submit. We added this functionality to this FIP because we don't want to roll out offchain signers without this security feature.