The problem fama solves

Fama is Twitter with consequences.

Every post is a falsifiable claim with a deadline. When the deadline passes, the claim resolves, the author’s credibility updates, and future feed ranking changes. Instead of optimizing for engagement, Fama optimizes for being right.

What do we solve

Let's be honest, your twitter timeline is full of thirst traps and rage baits. The more you engage with the post, the higher is it on your feed.
The most important tweets or the tweets that are carrying the value are often left behind

Fama solves this by turning posts into falsifiable claims with deadlines. Instead of likes or follower count deciding who gets seen, authors build a non-transferable credibility score from resolved claims.

People can use Fama to:

• Make public predictions with accountable outcomes
• Track who is consistently right over time
• Discover high-signal voices without relying on popularity
• Challenge claims by agreeing or disagreeing before the deadline
• Build a portable truth record
• Reduce misinformation incentives by making vague, viral posting less valuable

For users, Fama makes social discovery safer and more useful: the feed surfaces people with proven accuracy, not just people who are good at getting attention.

For communities, it creates a shared memory of who made which claims, when they made them, how the crowd voted, and what actually happened.

Challenges we ran into

One of the main hurdles was wiring together several moving pieces without making the app feel fragile: authentication, wallet/KMS signing, generated media, and the social posting flow all had to agree on the same user and asset state.

SpaceComputer

The trickiest bug was around key creation and signing with the OrbitPortSDK. Some requests looked correct from the frontend but failed because the backend payload shape did not match what the provider expected. I worked through it by isolating the flow with small server-side debug calls, comparing the raw API response against the SDK behavior, then tightening the request format and error logging so failures became obvious instead of silent.

Swarm

We tried to implement swarm-based key-value storage. The problem was that the local node setup did not work, so we needed to use their hosted solution.

Apify

The process of using Apify via x402 had two main issues.

First, the whole process is oriented around the

apify mcp cli

, which made raw HTTP requests harder to work with. We had to use some workarounds, especially since we use SpaceCoin KMS.

Second, even though some scrapers were marked as pay-per-request, we sometimes got an error saying they had to be paid per batch.