Expanding social betting from Farcaster to Twitter, with unified identity and cross-platform wagering.
Farcaster is our home, but X is where the volume lives. Here's the case for expansion.
X has ~500M monthly active users vs Farcaster's ~500K. Even a small percentage means massive growth potential.
CT (Crypto Twitter) is where narratives form and spread. Betting on tweets = betting on culture.
More whales, more degens, more action. Higher volume = more fees = sustainable growth.
Users on both platforms can link accounts. One vault, two betting arenas.
The core challenge: linking users across platforms while maintaining a single vault per person.
FID: 12345
@username
On-chain mapping
0x1234...abcd
Users log into the webapp with Twitter. This is the source of truth for identity verification.
Users input their wallet address in the app. We store the link between social identity and address.
An on-chain mapping enables cross-platform resolution. FC user betting on Twitter user? Registry resolves it.
How the pieces fit together across platforms.
| Component | Farcaster | Notes | |
|---|---|---|---|
| Bot Interface | ✓ Neynar | + Twitter API | Separate bots, shared backend |
| User Vaults | ✓ Existing | ✓ Same vaults | One vault per user, cross-platform |
| Identity Resolution | ✓ FID | + Twitter ID | Registry maps both to wallet |
| Bet Targets | ✓ Casts | + Tweets | New content type for tweets |
| Settlement | ✓ Likes/RTs | + Engagement | Oracle for Twitter metrics |
| WebApp | ✓ FC Auth | + Twitter OAuth | Both auth methods supported |
How different user combinations are handled.
Works exactly as today. Social identity routing handles everything.
New flow, same logic. Twitter bot handles it like FC bot does.
User linked both accounts in webapp. Same vault accessible from either platform.
Uses raw address functions. Both parties need wallets connected. Falls back to address-based resolution.
Possible but unlikely. User would have to intentionally fund two different wallets. Accept this edge case.
Phased approach to minimize risk and enable incremental rollout.
• Deploy on-chain identity registry contract
• Add Twitter OAuth to webapp
• Build wallet connection flow
• Create identity linking UI
• Build Twitter bot using same architecture as FC bot
• Implement tweet parsing and bet detection
• Connect to shared executor backend
• Internal testing with team accounts
• Build/integrate Twitter engagement oracle
• Handle likes, retweets, reply counts
• Test settlement accuracy
• Handle edge cases (deleted tweets, protected accounts)
• Beta launch with trusted users
• Enable cross-platform betting
• Marketing push on CT
• Monitor and iterate
What could go wrong and how we handle it.
Twitter API is expensive and they can revoke access. Mitigation: Keep FC as primary, treat X as growth channel.
Twitter actively bans bot accounts. Mitigation: Rate limiting, human-like behavior, multiple backup accounts.
Users might not bother linking accounts. Mitigation: Clear incentives, seamless UX, works without linking.
Twitter metrics can be gamed or delayed. Mitigation: Multiple data sources, dispute period, conservative settlement.
Questions? Let's discuss.