warpcast compatibility

Short answer: Warpcast — the company that runs the Farcaster mobile app and farcaster.xyz — requires every account it treats as "active" to have a signer that they registered, using their private signing key, during their mobile onboarding flow. Lectern-created accounts don't have that signer, and there's no public way to add one to an externally-registered FID.

This is a Warpcast product choice, not a Farcaster protocol limit. Your Lectern account is fully sovereign and works everywhere else in the open Farcaster ecosystem.

What works and what doesn't

Your Lectern account works fully in:

Lectern (macOS) — the full client this site is about
Any Farcaster Hub — read and write directly against Quilibrium's Hypersnap, Pinata's hub, or any other public Hub
SIWF mini-apps — Sign In With Farcaster works because it only needs your custody key; no Warpcast involvement
vrypan/fario — the other sovereign-only Farcaster CLI; uses the same on-chain pattern as Lectern
Any future client that signs in via Lectern's QR companion (planned for a later release)

Your Lectern account does not work in:

Warpcast mobile (iOS / Android) — "Use recovery phrase" returns "not associated with an active Farcaster account"
farcaster.xyz desktop — sign-in now requires QR confirmation from Warpcast mobile, and mobile doesn't recognize your account
Clients that delegate signer registration to Warpcast's API (herocast, supercast, etc.) — they require Warpcast mobile to confirm the signer request, which is the same chicken-and-egg

Why this isn't a Lectern bug

Farcaster the protocol is open and portable. Account custody lives in smart contracts on Optimism that you control. Signers — the Ed25519 keys that sign your casts — are added to the on-chain KeyRegistry contract. Anyone with custody control can add a signer, and any client can read your messages from any Hub.

Lectern registers signers using your own custody key as the signing party. Specifically, when Lectern calls KeyGateway.add(...), it constructs SignedKeyRequestMetadata with requestSigner = your custody address and signs the request with your custody key. This is the canonical sovereign pattern, and it's how the protocol was designed to be used.

Warpcast the app has added an extra check on top. When you try to import an account into Warpcast mobile via "Use recovery phrase," their app accepts the import only if the FID has at least one signer where:

requestSigner == 0x7f4d8e3554bf6ae9c49cd04faabe6cea5ba42cb1

That address is Warpcast's own signing EOA. The signature inside the metadata can only be produced by Warpcast's backend, which holds the corresponding private key. There is no public API to request a Warpcast-signed signer for an FID that didn't go through their mobile Sign Up flow.

This isn't documented as a hard rule, but it's empirically verifiable. We compared the on-chain signer state of a Lectern-only account against a Warpcast-onboarded account and found this exact difference. You can verify it yourself for any FID:

curl -s "https://haatz.quilibrium.com/v1/onChainSignersByFid?fid=<FID>" | \
  python3 -c "
import json, sys, base64, binascii
def fp(s): return s + '=' * (-len(s) % 4)
for e in json.load(sys.stdin).get('events', []):
    m = e.get('signerEventBody', {}).get('metadata', '')
    if m:
        h = binascii.hexlify(base64.b64decode(fp(m))).decode()
        print('  requestSigner: 0x' + h[88:128])
"

If any signer's requestSigner is 0x7f4d8e3554bf6ae9c49cd04faabe6cea5ba42cb1, Warpcast mobile will recognize the account. If none are, mobile rejects.

What about FIDs people buy on the marketplace?

This is the question that throws everyone, because purchased FIDs do work in Warpcast mobile. Here's why:

Purchased FIDs were originally registered through Warpcast's mobile onboarding flow by the seller, before they listed the FID for sale. That onboarding atomically registered Warpcast's signer at the same moment the FID was minted. When ownership transfers (IdRegistry.transfer), only the custody address changes — the KeyRegistry state is left alone. So the Warpcast signer survives the sale, and the buyer inherits an "active" account.

Lectern-created accounts never go through Warpcast's flow, so they're born without that signer. There's no on-chain action that retroactively adds it, because adding it requires Warpcast's private key.

This is what "I had to go to the contracts directly" means in practice for someone who bought a FID:

Call IdRegistry.transfer(to, deadline, sig) — receive custody
Call IdRegistry.changeRecoveryAddress(newRecovery) — claim recovery
Done. The pre-existing Warpcast signer keeps the account active in mobile.

Lectern implements the recovery-side operations (lectern recover, lectern change-recovery-address). They work fine for purchased FIDs. They just can't create a Warpcast signer on a sovereign-registered FID, because no client can.

How we confirmed this (so we don't have to do it again)

When we first hit this gate, we cycled through four theories before landing on the structural cause. Documenting them here so the next person doesn't repeat the work:

Hypothesis: Neynar indexer lag. Mobile would update after the Hub propagation caught up. → False. Mobile's "not associated" rejection doesn't query Neynar at all; it's a Warpcast-internal check.
Hypothesis: missing FIP-13 auth address. Mobile validates the recovery-phrase-derived address against KeyRegistry.keyDataOf(fid, paddedAddress) looking for a keyType=2 auth address. → False. We built lectern register-auth-address, registered the custody as an auth address (confirmed is_auth: true via the Hub), and mobile still rejected. Comparison check: @lectern (a working account) has is_auth: false for its own custody, proving auth-address presence is unrelated.
Hypothesis: signer metadata orphaned after custody rotation. When migrate-to-mnemonic rotates custody, existing signers still have requestSigner = old custody baked into their metadata. → False. We re-registered the signer with --replace so the new metadata pointed at the new custody. Mobile still rejected.
Hypothesis: on-chain recovery doesn't match mnemonic m/1. Mobile derives both m/44'/60'/0'/0/0 (custody) and m/44'/60'/0'/0/1 (recovery) from the phrase and validates the pair. → Partially true. We built lectern change-recovery-address, rotated recovery to the mnemonic's m/1 derivation, and the mobile error message changed from "No FID found for this recovery phrase" to "not associated with an active Farcaster account." That confirms mobile does validate the pair — but it's not the gating check.
Actual cause: Warpcast signer absence. The "active" check is on the signer table, not the custody/recovery pair. Confirmed by decoding the SignedKeyRequestMetadata of every signer on a working account vs a broken one: working accounts have a signer with requestSigner = 0x7f4d8e3554bf6ae9c49cd04faabe6cea5ba42cb1; broken ones don't.

The first four artifacts are kept as useful tools — change-recovery-address is hygienically correct after migrate-to-mnemonic, and register-auth-address is real FIP-13 functionality that helps with some SIWF mini-apps. They just don't unlock Warpcast.

What to do if you want Warpcast access

You have four options depending on which account we're talking about and how much sovereignty you want.

Option A — Existing Warpcast account, want to use it in Lectern too (most common case): Dual-client import. Open the macOS app onboarding → "import existing account" → Dual-client (keep Warpcast access). Paste your 12-word Farcaster Recovery Phrase from Farcaster mobile (Settings → Advanced → Show Farcaster Recovery Phrase). Lectern derives custody from m/0, verifies on-chain, and adds a Lectern Ed25519 signer alongside Warpcast's existing one (~$0.10 OP ETH gas). The account works in BOTH clients simultaneously — Warpcast mobile keeps working, Lectern desktop also works. Recovery stays as Warpcast's contract, so this is NOT fully sovereign — but it's the lowest-friction way to use one FID in both ecosystems.

Option B — Existing Warpcast account, want to leave Warpcast entirely: Sovereign handoff. Same onboarding path, pick Sovereign handoff. Lectern generates a fresh 24-word mnemonic locally; you paste the new m/1 address into Farcaster mobile's "Change Recovery Address" and Lectern detects the rotation on-chain, then broadcasts IdRegistry.recover() to take custody. Both keys end up under Lectern's control via a single mnemonic. One-way — Warpcast has no UI to re-onboard a FID that's left their system. Once done, Warpcast mobile loses access to this FID. No private keys are exported from Warpcast at any point; you just authorize one action in the mobile app.

Option C — Lectern-created FID, want Warpcast access: Maintain a second account. You can't convert a Lectern-created FID to a Warpcast-active one. Workaround: keep the Lectern-created FID for sovereign use, register a separate FID through Warpcast mobile for that side of the ecosystem. Both can be managed from Lectern (use Option A for the Warpcast-onboarded one). This is what we do — @lectern is the sovereign main account, @lctrn is the Warpcast-onboarded companion used for Spaces and anywhere Warpcast access is required. Cost: $1-ish for the second registration through Warpcast's mobile flow.

Option D — Buy a FID with a pre-existing Warpcast signer. Marketplaces like fid.market list FIDs that originally went through Warpcast onboarding. After transfer, the Warpcast signer carries over, and the FID becomes both yours and Warpcast-active. The transfer happens through the marketplace's escrow flow using IdRegistry.transfer(to, deadline, sig) signed by the seller — lectern recover does NOT apply here (it requires the on-chain recovery key already in your Keychain, which a buyer never has). After the transfer lands and the FID is under your custody, run lectern change-recovery-address --send to point recovery at your own wallet. Cost: variable; depends on the FID's number and the seller's price.

There's no path that converts an existing Lectern-created FID into a Warpcast-active one (Options A and B only work for FIDs that originally went through Warpcast onboarding). For new sovereign FIDs, you're choosing between "use in Lectern + sovereign ecosystem" and "give up Warpcast." We checked.

Will Lectern fix this in the future?

Not in the sense of unlocking Warpcast specifically — that would require Warpcast to add a public flow for adding their signer to externally-created FIDs, which would defeat the managed-keys design they've built their app around. We can't unilaterally fix it.

What we are working on:

A signer-export envelope standard. No Farcaster client currently has a documented portable format for moving accounts between clients. Lectern's mnemonic backup is already the most sophisticated thing in the ecosystem; we plan to formalize it as a published spec that other sovereign clients can adopt.
A Lectern-side QR/sign-in companion at lctrn.app. Other Farcaster clients that follow the protocol spec could delegate "confirm sign-in" to Lectern the same way they currently delegate it to Warpcast mobile. This would give sovereign FID holders a real cross-client desktop path that doesn't route through Warpcast.

Both of these strengthen the sovereign ecosystem rather than fighting the Warpcast gate, which is the only honest path forward.