FomoScan identity integration

Blocked. It is not yet established that Fomo accounts hold Robinhood Chain positions. No such claim is made anywhere in this system until it is proven with a live FomoScan key, a real handle, and observable onchain activity. This is production gate 1, and everything else is downstream of it.

#Advisory, behind a boundary

FomoScan is one implementation of SourceIdentityProvider. It answers who is this? and nothing else.

It decides exactly one thing: which address a curator chooses to observe, once, at curation. After that the address is recorded onchain and the identity provider is out of the path entirely.

If FomoScan were offline, malicious, or permanently removed, every vault would keep mirroring correctly. Vaults would lose display names and avatars.

Security. That is enforced structurally, not by convention. The module defining the provider interfaces imports nothing, so a SourcePositionProvider has nowhere to obtain an API response from.

#The schema, and its two warnings

Schemas are transcribed from the live OpenAPI document and validated with Zod at the boundary. They are passthrough, not strict: a new field should not break this application, but a field changing type or disappearing must be caught loudly rather than surfacing later as undefined inside a vault decision.

Two fields carry warnings from the specification itself, and both matter:

• id is stable; handle is not. The specification says users rename and that you should not key on the handle. Every join in this codebase uses id.
• twitter is self-declared and not verified. The specification describes it as "a claim, not a proof". The interface therefore never renders it as a verification tick — the X badge carries an outbound arrow, and its tooltip says so in words.

#200 with evmAddress: null

This means FomoScan holds no verified wallet for this user. It does not mean the user has none.

Flattening those two into "not found" would silently exclude eligible accounts, so the distinction is preserved through the eligibility result: evm_unverified is a different status from not_found.

#Non-EVM identities

An identity resolving only to a Solana address is refused as a structural mismatch, not a transient failure, and is not retried. Retrying cannot turn a Solana address into an EVM one.

#Cost

A live resolve costs 100,000 CU on every call including misses. It is therefore run deliberately, from a command, and never automatically on page render:

pnpm discover:fomo --handle <handle> --json

#Fixture mode

With no key configured the provider runs in mock mode against recorded fixtures that are structurally identical to production responses and schema-valid.

Fixtures are obviously synthetic — every handle is prefixed `` — and carry no invented photographs: profilePicture is null throughout, exactly as it would be for a real user who has not set one. Fabricating a face for a fictional trader would be inventing a person.

Whenever identity is in mock mode, the whole surface is labelled Development data.