Design a Crypto Social Feed with Token Rewards (Steemit-like)

Problem statement

Design a decentralized blogging and microblogging platform where posts and comments earn token rewards driven by community upvotes, and where curators who vote early on good content share in the reward. The system must create posts, accept and revise votes, weight votes by staked stake, distribute a daily reward pool per post and per curator, detect spam and vote farms, and expose governance that can retune reward parameters without a hard fork.

The defining property is that an upvote is not a like: it is a monetary instruction. A like can be eventually consistent and silently dropped; a vote changes who gets paid, so the vote path needs money-grade idempotency, ordering, and auditability while the feed path stays cheap and available. Every architectural decision in this answer flows from that split.

Why the problem is distinctive

A conventional feed system optimizes read latency and fan-out cost. A token-rewarded feed additionally optimizes economic integrity: a sybil cluster of ten thousand fake accounts casting coordinated votes is not a reliability incident, it is a theft of the reward pool from honest authors. Therefore the design couples three subsystems that ordinary social platforms keep separate: the engagement plane (posts, votes, feeds, notifications), the reward accounting plane (stake snapshots, reward shares, payout schedules), and the settlement plane (epoch commitments, treasury, on-chain claims). A fourth cross-cutting plane, governance and trust-and-safety, owns parameter versioning, moderation, and sybil enforcement.

Public operating baseline versus design assumptions

Public evidence shows the category is real. Hive, the chain behind the Steemit successor ecosystem, publishes 3-second blocks produced by 21 elected witnesses under delegated proof-of-stake, and its resource-credit model makes user transactions fee-less but rate-limited (company- and explorer-reported). Reddit shipped Community Points (Moons and Bricks) to tens of millions of daily active uniques, issuing points off-chain with on-chain claim on Arbitrum Nova before sunsetting the program in October 2023 for regulatory reasons (Reddit's S-1 reports 73.1M daily active uniques for Q4 2023). Brave pays BAT for opt-in attention at company-reported tens of millions of monthly active users. These are cited context, not requirements for our fictional system.

For capacity planning this answer explicitly assumes: 20M registered accounts, 5M DAU, 900K peak concurrent sessions, 1.2M posts/day, 3.6M comments/day, 26M vote operations/day, and a 10x write peak. Unless a number is tied to a citation it is a stated design assumption, target, or budget.

The four architectural planes

1. Engagement plane: post creation, editing, voting, follows, feed ranking, notifications, WebSocket reward ticks.
2. Reward accounting plane: stake and vesting state, vote power, reward shares per post, curation shares, cashout queue, epoch snapshots.
3. Settlement plane: hourly Merkle commitment of claimable balances, treasury, price oracle, on-chain claim contracts, payout audit.
4. Governance and trust-and-safety plane: parameter proposals with timelocks, witness or validator election inputs, moderation pipeline, sybil and vote-ring enforcement, appeals.

A strong interview answer keeps these planes separate, lets the feed degrade without touching accounting, and never lets accounting correctness depend on feed availability.