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 | `a7ee619b-0238-4593-bde9-d8d5f0dd2830` | | 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:

1. Find existing server-side integrations for X/Twitter, Farcaster, Telegram, Zora, and Base app posting/automation.
2. Determine what can be objectively verified vs what is hard/impossible to verify for user actions (like/retweet/comment/bookmark, channel join, etc.) given current codebase.
3. Look for existing daily-checkin mechanisms and anti-abuse patterns.

Return:

• capability matrix in bullet form (platform -> currently verifiable actions)
• recommended safest/high-signal daily mechanics compatible with current infra
• key risks (rate limits, fraudability, policy/compliance) that should shape product decisions.

Analysis

I'll map server-side social integrations and verification patterns across the repo.

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

Tools invoked: Grep, Glob, Grep, Read

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

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

Analysis

[REDACTED]

Tools invoked: Grep, Read, Grep, Read

Analysis

[REDACTED]

Tools invoked: Read, Grep, Read, Grep

Analysis

[REDACTED]

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

Analysis

[REDACTED]

Tools invoked: Read, Read, Grep, Grep

Analysis

[REDACTED]

Tools invoked: Read, Grep, Read

Analysis

[REDACTED]

Tools invoked: Read, Grep, Read

Analysis

[REDACTED]

Tools invoked: UpdateCurrentStep

Analysis

Capability matrix (platform → verifiable today)

X / Twitter

Server integrations

• Read/verify: frontend/server/twitter/verifyTweet.ts — Twitter API v2 with X_BEARER_TOKEN (fallbacks in twitterEnv.ts). Used by POST /api/v1/lottery/amoe/twitter-checkin.
• Post (outbound automation): frontend/server/twitter/commands.ts — OAuth 1.0a (X_* / HERMIT_TWITTER_*). Used by Keepr/Telegram /x commands and Hermit cross-post in frontend/server/commands/execute.ts.
• Eliza plugin: context-only (frontend/server/agents/eliza/plugins/twitter/index.ts), not ingress.

Objectively verifiable user actions

• Publish a specific AMOE template tweet — tweet exists, author matches Privy-linked X account, required text markers (4626, alternative method of entry, no purchase necessary) + 4626.fun link.
• One claim per wallet per UTC day + global tweet-id dedupe (lottery_amoe_daily_twitter_checkins).
• Privy X link (one-time) — POST /api/accounts/link with provider: twitter → link_twitter (+16 pts); trusts Privy linked-account state, not an X API profile fetch at award time.

Hard / not implemented

• Like, retweet, quote, bookmark, follow, reply to arbitrary posts, view counts.
• Daily waitlist “Share on X” (WaitlistUnlocksPanel.tsx) — opens compose intent only; no server endpoint awards social_x (source exists in schema/backfill only).
• Commenting on 4626 posts without the AMOE template path.

---

Farcaster

Server integrations

• No runtime cast-publish path in frontend/server/ (.cursor/skills/farcaster-agent/SKILL.md describes Neynar /fc cast — not backed by implementation in this repo).
• Read/enrichment only: Neynar bulk-by-address in indexer/src/polishProfiles.ts, crossReferenceFarcaster.ts; Ethos lookups via service:farcaster: in ethosClient.ts.
• DB: farcaster_* columns on profiles / zora_profiles; farcaster_rollout_events table (audit/dead-table list).

Objectively verifiable

• Privy “Farcaster” path = zora_cross_app link — recordProviderLink → link_zora (+40 pts, one-time).
• FID/username resolution for indexer/explore (read-only).

Hard / not implemented

• Cast posted, like/recast, follow channel, frame interaction, Warpcast compose from waitlist UI.
• social_zora daily points — defined in waitlistPoints.ts / backfill map, never written by live API.

---

Telegram

Server integrations

• Bot API: frontend/server/_lib/messaging/telegramBotApi.ts, large webhook surface under frontend/api/_handlers/telegram/.
• Account link: POST /api/telegram/link-complete — Mini App initData session proof + optional single-use link token; awards link_telegram (+16 pts).
• Trading / holder rooms: telegramTrading.ts, getChatMember in api/_handlers/telegram/webhook/telegramApi/chats.ts (admin/trade gating, optional TELEGRAM_REQUIRE_TRADE_MEMBERSHIP).
• Outbound: bot sendMessage, telegramToAlfaclubRelay.ts, ops broadcast in scripts/ops/1659-risk-watcher.ts.
• Zora CSW gate: cswGateVerification.ts + _cswEntryTelegramVerify.ts (Telegram username bound to CSW outreach flow).

Objectively verifiable

• Telegram identity bound to 4626 account (Mini App session + verified email account resolution).
• Group admin role for bot command authorization (getChatMember).
• Optional trade-room membership when env flag enabled (not waitlist points).

Hard / not implemented

• Joining @fun4626 or posting check-in copy in group — UI only (WaitlistUnlocksPanel); no membership-verified daily award.
• social_telegram daily points — schema only, no live writer.
• Message content in groups (unless you build bot-side ingestion + attribution).

---

Zora

Server integrations

• Trading/automation: frontend/server/zora/commands.ts — buy/sell/trend funnel/launch sentinel (on-chain, Keepr/XMTP command driven).
• Index/sync: zora-profiles/refreshProfiles.ts, creatorMetricsSync.ts, explore APIs.
• Wallet: zoraWalletHoldings.ts, cross-app link via Privy.

Objectively verifiable

• On-chain trades routed through Keepr (balance/RPC preflight).
• Zora cross-app wallet link (Privy) — one-time link_zora.
• CSW gate / holder verification for gated flows.

Hard / not implemented

• “Posted on Zora”, social engagement, creator-coin interactions as waitlist proof.
• Zora as a daily check-in channel (no endpoint).

---

Base App

Server integrations

• Wallet/onboarding only: baseAppInvite, CSW owner install, register-sub-account (+50 csw_link pts), canonicalCswDelegation.ts.
• Agent MCP: frontend/server/_lib/agents/base-mcp/ — swap/transfer approval store (not social).
• Leaderboard badge: show_base_app_badge when profiles.base_sub_account is set.

Objectively verifiable

• Sub-account registration / CSW owner state (on-chain + Privy).
• Base App wallet connection as execution track (not a social post).

Hard / not implemented

• Base App casts/posts, likes, follows.
• social_base_app daily points — defined but not awarded live.

---

Existing daily-checkin & points mechanics

Mechanism	Verification strength	Rewards	Where
AMOE X daily tweet	Strong (API + Privy author + content)	1 AMOE credit + 6 waitlist amoe_checkin	/api/v1/lottery/amoe/twitter-checkin
AMOE XMTP daily DM	Strong (server sees inbound DM to CANONICAL_CSW_ADDRESS)	1 AMOE credit + 6 amoe_checkin	Auto in eliza/index.ts; manual API returns 410
Waitlist daily social share	None (intent URLs only)	UI claims +2/platform; no server claim	WaitlistUnlocksPanel.tsx
Provider link (X/TG/Zora)	Medium (Privy verified link)	One-time link_* (+16–40)	/api/accounts/link, Telegram link-complete
Email waitlist signup	Strong (Privy OTP)	+5 waitlist_signup	/api/waitlist/bootstrap
Referral	Medium (code + email account; IP/UA hashed)	50% passthrough on referee points	waitlistPoints.ts
AMOE ZK lottery entry	Strong (on-chain nullifier + proof)	Burns credits	/api/v1/lottery/amoe/*

Anti-abuse patterns already in code

• Idempotent points inserts (ON CONFLICT DO NOTHING), MAX_AWARD_AMOUNT = 10_000, referral one-hop only (REFERRAL_FAMILY_EXEMPT).
• AMOE: per-wallet/day uniqueness, global tweet-id uniqueness, verified_privy_only policy for Twitter awards, durable rate limit (6/min) + lotteryWrite (40/min).
• Telegram: single-use link-start tokens, Mini App session verification, rate limits on link paths.
• AMOE replay store: nullifier collision / in-flight protection (amoeReplayStore.ts).
• Gap: in-memory checkRateLimit resets on serverless cold starts (rateLimit.ts comment FINDING-11); durable limiter needs agent_rate_limits table.

---

Recommended safest / high-signal daily mechanics (compatible with current infra)

1. Keep AMOE Twitter template check-in — only X path with cryptographic/API-grade proof today; tune copy/requirements, not the verification model.
2. Keep auto XMTP DM to agent 4626 — zero user friction, server-origin proof; good “daily touch” if product accepts chat noise.
3. Referral with verified email — highest-trust growth loop already wired; passthrough mirrors organic activity.
4. One-time Privy provider links (X, Telegram, Zora cross-app) — good onboarding milestones; don’t re-award daily without new verification.
5. On-chain or in-app actions you control (swap, deploy milestone, CSW owner install) — verifiable via existing wallet/session infra; better than unverified social intents.

Avoid until new APIs exist

• Daily points for X/Farcaster “share” buttons, Telegram group join, likes/RTs/bookmarks — all trivially gameable or API-blocked/expensive on X; Farcaster needs Neynar signer + cast lookup; Telegram needs getChatMember wired to a points endpoint with bot-in-group constraints.

---

Key risks for product decisions

Rate limits & cost

• Twitter verify uses Bearer read; posting uses OAuth1 write — separate apps/permissions (HERMIT_TWITTER_STRICT isolates Hermit keys).
• Twitter API tiers cap read volume; burst check-ins need durable rate limits + monitoring.
• Neynar/Farcaster cast verification would add paid API + signer custody if you build it.

Fraudability

• social_* and bonus_* sources are labeled “verified” vs “honor system” in waitlistPoints.ts, but daily social_* has no live award path — UI copy in WaitlistUnlocksPanel over-promises vs backend.
• Privy link awards trust the link event, not ongoing behavior.
• Referral IP/UA hashing is attribution, not sybil prevention.

Policy / compliance

• AMOE tweet check-in requires specific legal/disclosure language — good for compliance, poor for generic “engagement farming.”
• Automating X/Farcaster posts (Hermit, Keepr) needs clear bot/disclosure and OAuth app permission scope (“Read and write”).
• Telegram: storing telegram_user_id, Mini App initData — align with privacy policy; group membership checks require bot admin in target chats.
• X/Telegram TOS: incentivized likes/follows is high policy risk; template tweet + self-initiated DM is safer.

Architecture drift

• Farcaster agent skill and KPR README mention Neynar queue actions; keepr-action-queue.action.ts only processes XMTP + strategy actions — no Farcaster executor in tree.
• Waitlist “daily playbook” and AMOE lottery are two points systems; AMOE credits don’t count toward public waitlist total (only amoe_checkin bridge does).

---

Bottom line: The only production-grade, user-attributed daily social proofs today are AMOE Twitter tweet verification and inbound XMTP DMs to the canonical CSW. Everything else in the waitlist daily UI is either one-time Privy linking or unverified client-side intents. Building high-signal daily mechanics should extend those two patterns (server-observed action + identity binding + idempotent ledger), not add honor-system share buttons without verification.

[REDACTED]