Parallel analysis lane

[← Source sessions](/audits/fable/key-sessions) · [Transcript archive](/audits/fable/transcripts) · [Executive summary](/audits/fable/findings-summary)

# Parallel analysis lane | Field | Value | | --- | --- | | Session ID | `1767f04b-6ed9-40fd-86fe-6fafc0e41772` | | Lead session | `4adf41a3-989c-4464-b1aa-aafa6e26477e` | | Record type | Parallel workstream export | :::note[Appendix record] Readable export of a supplementary review session. Tool outputs and system context are omitted; download the [JSONL archive](/audits/fable-chats-4626-2026-06.zip) for the complete log. ::: ## Engagement brief

Thoroughness: medium.

Read-only exploration task in /home/akitav2/projects/4626/frontend:

1. Identify current linked-identity OAuth providers and where they are linked/unlinked in UI + API.
2. Identify current waitlist points sources and any existing social-action point flows.
3. Identify any existing verification endpoints for Twitter/X, Farcaster, Telegram actions.

Return:

• concise bullet list of concrete existing capabilities and file paths
• gaps/limitations that matter for implementing per-platform daily action components
• any existing data model fields that should be reused for componentized flow state.

Analysis

Searching the frontend for linked-identity OAuth, waitlist points, and social verification flows.

[REDACTED]

Tools invoked: UpdateCurrentStep, Grep, Grep, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Grep, Grep, Grep, Glob, Glob

Analysis

[REDACTED]

Tools invoked: Read, Read, Read, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Read, Read, Read, Grep, Read

Analysis

[REDACTED]

Tools invoked: Grep, Grep, Read, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Read, Read, Read, Grep, Read

Analysis

[REDACTED]

Tools invoked: Read, Grep, Grep, Read, Grep

Analysis

[REDACTED]

Tools invoked: Read, Read, Grep, Grep, Read

Analysis

[REDACTED]

Tools invoked: Read, Grep, Read, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Grep, Read, Read, Read, Grep

Analysis

[REDACTED]

Tools invoked: Read, Grep, Read, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Read, Grep, Grep, Read, Grep

Analysis

[REDACTED]

Tools invoked: Read, Read, Read, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Read, Grep, Read, Grep, Read

Analysis

[REDACTED]

Tools invoked: Grep, Read, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Grep, Grep, Read

Analysis

[REDACTED]

Tools invoked: Grep, Read

Analysis

[REDACTED]

Tools invoked: Grep, Glob

Analysis

[REDACTED]

Tools invoked: Read, Read

Analysis

[REDACTED]

Tools invoked: Grep, Read

Analysis

1) Linked-identity OAuth providers (link / unlink)

Supported providers (server AccountLinkProvider): email, google, apple, twitter, telegram, tiktok, external_eoa, zora_cross_app

• Type: /home/akitav2/projects/4626/frontend/server/_lib/identity/accountsIdentity.ts
• API allowlist: /home/akitav2/projects/4626/frontend/api/_handlers/accounts/_link.ts, _unlink.ts

Link flow (client → Privy OAuth → server persist + points):

• Controller: /home/akitav2/projects/4626/frontend/src/features/accountSetup/useAccountSetupController.ts
  • Privy methods: linkTwitter, linkGoogle, linkApple, linkTelegram (Mini App launchParams), linkWallet, Zora via performZoraCrossAppAuth + linkCrossAppAccount
  • Server: POST /api/accounts/link → recordProviderLink() in accountsIdentity.ts (reads verified Privy linked accounts only; ignores caller value)
• Unlink: Privy unlink* + POST /api/accounts/unlink → recordProviderUnlink()

UI surfaces:

• Linked identities list (link/unlink per provider): /home/akitav2/projects/4626/frontend/src/features/accountSetup/LinkedIdentitiesSection.tsx
  • Providers shown: email, google, apple, twitter, telegram, tiktok, external EOA (PROVIDER_ROWS in shared.ts) — not zora_cross_app
• Account setup / waitlist workspace: /home/akitav2/projects/4626/frontend/src/features/accountSetup/AccountSetupWorkspaceView.tsx — Zora has dedicated onLinkZora() (cross-app), not the generic list row
• Waitlist daily panel: /home/akitav2/projects/4626/frontend/src/features/waitlist/WaitlistUnlocksPanel.tsx — Connect X (twitter) and “Farcaster” (zora_cross_app via onLinkProvider)
• Accounts page: /home/akitav2/projects/4626/frontend/src/pages/accounts/AccountsPage.tsx (wraps setup controller)

One-time link points (via applyPointEvent → points table):

• link_email +10, link_google/link_apple +20, link_twitter/link_telegram/link_tiktok +16, link_external_eoa +10, link_zora +40
• Defined: LINK_POINTS in accountsIdentity.ts; UI badges: PROVIDER_POINTS in waitlistTiers.ts

Telegram (separate from generic Privy link in web):

• Web UI blocks Telegram link unless opened from Telegram Mini App (readPrivyTelegramLaunchParams)
• Bot + Mini App backend: /home/akitav2/projects/4626/frontend/api/_handlers/telegram/_link-complete.ts, _link-ready.ts, _miniapp-session.ts, _unlink.ts (routes in _routes.telegram.ts)
• Persistence: telegram_user_links (profile_id, privy_user_id, telegram_user_id, link_status, owner_verified, …)

Zora / “Farcaster” note: There is no standalone Farcaster OAuth provider. Waitlist UI treats Zora cross-app (zora_cross_app) as “Farcaster connected” (WaitlistUnlocksPanel.tsx). Zora link uses Privy cross-app to Zora’s Privy app (ZORA_PRIVY_APP_ID in client.tsx + zoraCrossApp.ts).

---

2) Waitlist points sources & social-action flows

Canonical scoring: weightedWaitlistPoints() in /home/akitav2/projects/4626/frontend/server/_lib/onboarding/waitlistScoring.ts
Ledger writer: awardWaitlistPoints() + recordReferralPassthrough() in waitlistPoints.ts; link events use applyPointEvent() in accountsIdentity.ts

Source family	Examples	Live writer today	Weight toward public score
Bootstrap	waitlist_signup (+5)	POST /api/waitlist/bootstrap	1.00×
CSW signing	csw_link (+50)	POST /api/onboarding/register-sub-account	1.00×
Identity link	link_*	POST /api/accounts/link	0.60×
Referral mirror	referral_passthrough	auto on any award	1.00×
AMOE bridge	amoe_checkin (+6/day)	awardAmoeCheckinPoints() from Twitter/XMTP check-in	1.00×
Social (planned)	social_x, social_zora, social_telegram, social_base_app, social_discord (+2 each in constants)	No live endpoint — only in WAITLIST_POINTS + backfill map	0.50× if rows exist
Bonus / agent	bonus_*, agent_*, lens_identity, grove_proof	No live UI writer found	0.30–0.40×
AMOE ledger	amoe_twitter_daily, amoe_xmtp_daily, amoe_entry_spend	Lottery lane	0× on waitlist surfaces

Waitlist “daily social” UI (honor-system only):

• /home/akitav2/projects/4626/frontend/src/features/waitlist/WaitlistUnlocksPanel.tsx
  • Step 2: opens Twitter/Warpcast compose intents (ShareVaultButton helpers) — no server verification, no points write
  • Step 3: Telegram group link + copy-paste prompt — no verification
  • Copy claims “+2 pts per platform” but nothing awards social_* today

Verified social-action flows (lottery / AMOE lane, not waitlist daily share):

• Twitter/X: POST /api/v1/lottery/amoe/twitter-checkin → verifyTweetForAmoe() (server/twitter/verifyTweet.ts) + claimDailyTwitterCheckin() (lotteryAmoe.ts)
  • UI: /home/akitav2/projects/4626/frontend/src/components/lottery/AmoeEntryCard.tsx
  • Requires linked Twitter in Privy; verifies tweet content (4626 + AMOE legal markers + link)
  • Awards: amoe_twitter_daily (1 credit, 0 waitlist weight) + best-effort amoe_checkin (+6 waitlist pts)
• XMTP: POST /api/v1/lottery/amoe/xmtp-checkin returns 410 (xmtp_checkin_auto_only); credits auto-awarded server-side in frontend/server/agents/eliza/index.ts via claimDailyXmtpCheckin()
• Referrals: ReferralShareBlock.tsx + GET /api/waitlist/referrer; conversions in referral_conversions; passthrough via recordReferralPassthrough

Read APIs for points state:

• GET /api/accounts/me, GET /api/accounts/me/points, GET /api/waitlist/position, GET /api/waitlist/points-activity, GET /api/waitlist/leaderboard

---

3) Verification endpoints (Twitter/X, Farcaster, Telegram)

Platform	Endpoint	Purpose
Twitter/X (AMOE)	POST /api/v1/lottery/amoe/twitter-checkin	Server verifies tweet via X API v2 + linked Privy Twitter identity
Twitter/X (bot ops)	server/twitter/commands.ts (verifyTwitterAccount)	Hermit/protocol OAuth1 account verify — not waitlist
Farcaster	None for user-action verification	Only Warpcast compose URL in UI; Ethos uses service:farcaster: keys (ethosClient.ts)
Telegram Mini App session	POST /api/telegram/miniapp/session	verifyTelegramMiniAppInitData() — link/onboarding gate
Telegram link completion	POST /api/telegram/link/complete, link/ready	Binds Telegram ↔ Privy ↔ profile (telegram_user_links)
Telegram unlink	POST /api/telegram/unlink + POST /api/accounts/unlink	Bot /unlink + account unlink
Telegram (Zora CSW gate)	POST /api/zora/csw-entry/telegram-verify	CSW-entry campaign verify, not waitlist daily actions
XMTP daily	Auto in Eliza agent	Manual endpoint deprecated (410)

---

Gaps / limitations for per-platform daily action components

1. Waitlist daily share is UI-only — WaitlistUnlocksPanel opens intents but has no callback, proof submission, or social_* point writes.
2. social_x / social_zora / social_telegram exist in types/backfill only — no awardWaitlistPoints({ source: 'social_x', ... }) call site in production handlers.
3. Two parallel Twitter models — waitlist share (generic referral URL, no verify) vs AMOE check-in (strict tweet proof, AMOE copy, lottery credits). Don’t conflate them.
4. “Farcaster” = Zora cross-app — no Farcaster OAuth, no cast verification, no social_zora daily endpoint.
5. Telegram daily check-in has no server verify — join group + copy text only; link path requires Telegram Mini App context.
6. No per-day completion table for waitlist social actions — unlike lottery_amoe_daily_twitter_checkins / amoe_checkin day-key pattern.
7. Provider list split — LinkedIdentitiesSection omits Zora; waitlist panel omits google/apple/tiktok/discord despite API support.
8. Scoring mismatch in copy — UI says “+2 pts per platform”; constants use social_* at 2 raw (0.50× → 1 counted pt if ever awarded) vs link bonuses at 16 raw (0.60× → ~10 pts).
9. Discord / bonus socials — defined in WAITLIST_POINTS but no link UI or verification path found.

---

Data model fields to reuse for componentized flow state

Identity / gating (already wired to /api/accounts/me):

• account_linked_methods: privy_user_id, type (twitter, telegram, zora_cross_app, …), value, verified
• account_zora_signals: zora_linked, canonical_csw_address, zora_handle, creator_coin_address
• telegram_user_links: profile_id, privy_user_id, telegram_user_id, telegram_username, link_status, last_verified_at, owner_verified
• Client shape: AccountsMePayload.linkedMethods + accountSignals (types.ts)

Points / idempotent daily awards (recommended pattern):

• points: signup_id (= profiles.id), source, source_id, amount, created_at — unique on (signup_id, source, source_id)
• For daily actions: source_id = '<wallet_or_profile>:<YYYY-MM-DD>' (see amoeWaitlistPoints.ts / awardAmoeCheckinPoints)
• Suggested sources: social_x, social_zora, social_telegram (already in WaitlistPointSource union) or extend with explicit daily_* names
• Referral side effects: profiles.referred_by_signup_id, referral_code, referral_conversions.status / qualified_at

Verified-action proof (if reusing AMOE Twitter verifier):

• lottery_amoe_daily_twitter_checkins: wallet_address, checkin_date, tweet_id, tweet_url, tweet_author_* (migration 042_amoe_twitter_checkin_tweet_proof.sql; Supabase types may be stale)

No existing table for waitlist-specific “step 2 shared on X today” state — either add one or standardize on points + optional proof columns mirroring the AMOE check-in tables.

[REDACTED]