Arkiv Ideathon · DeFi track · idea + data-model design

Roundbook

Rotating savings circles (esusu, ajo, tontines) are the original DeFi, running for centuries without a protocol. Roundbook turns the coordinator's book into tamper-proof Arkiv state: signed contributions, verifiable payouts, and a savings reputation members carry from circle to circle.

evidence on Arkiv money on any rail execution off the hot path
The product

The book, rebuilt

One round of a real circle, as every member's app sees it. Each row is the result of a query, not a coordinator's pen. The classic esusu failures (an "adjusted" book, a denied payment, a reshuffled payout) all become detectable states.

Lagos Devs Circle round 4 of 12 · 50 USDC / member / month · payout order committed by hash
memberstatusevidence
Ada✓ paidReceipt (member-signed) + Ack (coordinator-signed)
Bayo✓ paidReceipt + Ack · settlementRail: stablecoin · tx 0x91…
Chidi⚠ contestedReceipt exists, no Ack — queryable dispute state
Dejidue in 3 daysopen Pledge · dueBy 1725062400
Efe→ receives payoutPayout entity matches payoutOrderHash reveal ✓
round completion: count(receipts) 3 / 5 members · no coordinator can edit a row: every entry carries an immutable $creator and a tx hash
Two-party attestation

Who signs what

An Arkiv entity has exactly one immutable $creator, so a contribution is never one record both parties "agree" on. It is a chain of signed entities, and every gap in the chain is itself a queryable state.

member writesReceipt"I paid 50 USDC, round 4" · $creator = member
coordinator writesAckcountersigns by receiptId · missing Ack = contested
at round closeRoundSummaryonTime + coarse bucket · lists the receipt/ack ids it aggregates
member co-signsSummaryAcka summary only counts once its member has signed off
Entity Expiration as product logic

Four lifetimes, one axis

What prunes fast, what lingers for disputes, what must be renewed to stay real, and what is built to outlive everything else.

Pledgeround end + 14 d dispute window
Receipt + Ackround + 90 days
Circlerenewed each round via Lifetime Extension
RoundSummary5 years, prepaid from a small fee
daysmonthsyears

The dashed bar is the point: a Circle stays alive only while someone keeps renewing it, so a circle nobody renews is visibly dormant — that IS the "is this circle real?" check. And the reputation layer is built to outlive its own evidence: precise receipts expire, coarse summaries persist.

Schema

Five entity types

Circle renewed each round

  • coordinator = $creator
  • memberCount · contributionCents · periodDays int
  • payoutOrderHash string commitment

Payout order is commit-reveal: hash at creation, revealed per round, so a reshuffle is detectable and fairness itself is verifiable.

Pledge round + 14 d

  • circleId shared key · member
  • roundNum int · dueBy int, unix s

Stale obligations prune themselves. A pledge past dueBy with no receipt is the missed payment evidence.

Receipt + Ack round + 90 d

  • Receipt: written by the member
  • amountCents int · settlementRail cash|bank|stablecoin
  • Ack: written by the coordinator, keyed by receiptId

Short-lived dispute evidence, not long-term surveillance. Receipt without Ack = contested, and that state is queryable.

RoundSummary 5 years

  • member · circleId · roundNum int
  • onTime int 0/1 · amountBucket int, coarse tier

The reputation layer. Self-contained, so it outlives its circle; only counts once the member co-signs it with a SummaryAck.

Reads

The queries it lives on

eq(circleId) & eq(type,'receipt') & eq(roundNum, 4) · count() vs memberCount

Who paid this round, and round completion at a glance. The matching Ack query turns "he says he paid" into a resolved or contested fact.

eq(type,'summary') & eq(member, m)

The vetting query. Multi-year savings reputation across every circle a member ever joined. A new circle admits you by query, not by vibes, and it works even after the source circles expired.

eq(circleId) & eq(type,'payout') → checked against payoutOrderHash

Payout history against the committed order: a reshuffled payout is detectable.

lt(dueBy, now) & no matching receipt

Missed payments, computed by the app. Arkiv stores and answers; it never executes. The circle's social layer, the thing that has made esusu work for centuries, acts on the evidence.

The system

One board, end to end

Who signs what, the entity layer with its lifetimes, and the queries that read it. Click for full size.

Roundbook system diagram: members and coordinators write signed entities into Arkiv; five entity types with differentiated lifetimes; member apps, new circles and auditors read the book through queries; the money stays off the hot path

Why Arkiv, not Postgres?

  • A coordinator's notebook is an operator-controlled database. Roundbook's premise is removing that single writer.
  • On-chain ROSCA protocols already exist, and they share the gap: contributions settle across mixed rails, so the evidence layer is missing even when the payout is on-chain. Roundbook is that layer.
  • Portable reputation needs neutral ground: a summary in one company's database dies with that company; a coordinator-run server recreates the exact trust problem.
  • Bytes x lifetime pricing fits: evidence is cheap and short, reputation is small and long.

What stays off Arkiv

  • The money. Cash, bank, or stablecoin: Arkiv holds evidence around settlement, never settlement.
  • Identities. Pseudonymous keys on-chain; real names stay in the circle's social layer.
  • Exact long-term amounts. Precise figures expire with the receipts; the 5-year layer carries coarse buckets and on-time flags. A scraper learns reliability, not wealth.
  • Enforcement. Arkiv never executes; the circle acts on the evidence.