How Poolver works.

Poolver is an on-chain implementation of the ROSCA — rotating savings and credit association. Known in Brazil as consórcio, in Kenya as chama, in West Africa as tontine, in the Caribbean as susu. Globally, the informal market is estimated at over $500B annually.

The mechanism is simple: N wallets commit to contributing a fixed amount in USDC every round. Each round, one wallet receives the entire pool. After N rounds, everyone has paid N and received 1 full pool. No interest; rotation of liquidity, not creation of it.

Poolver replaces the village elder, the office administrator, and the broker with a Solana program. No administrator. No custodian. No permission. The code is the contract.

┌─ JOIN ───┐  ┌─ PAY ───┐  ┌─ DRAW ──┐  ┌─ SETTLE ─┐  ┌─ EXIT ──┐
│ deposit  │→ │ monthly │→ │   VRF   │→ │  tranche │→ │ reclaim │
│ collat.  │  │ 7-day   │  │  commit │  │  release │  │  collat │
│ + first  │  │ window  │  │  reveal │  │  to wnr  │  │ + rep   │
└──────────┘  └─────────┘  └─────────┘  └──────────┘  └─────────┘

1. JOIN. Pool opens with a target size (e.g. 20 members × $2,500 = $50K/round). You deposit 25% collateral + first month's contribution. Your slot activates when the pool fills.
2. PAY.Each round has a 7-day payment window. Contributions route to the pool PDA automatically if you've granted a payment authority; otherwise you sign. Missing the window moves you to "late" (day 8–14) and eventually "default" (day 15+).
3. DRAW.Once contributions are collected, Switchboard VRF selects the round's recipient from wallets that have not yet received and are in good standing.
4. SETTLE. The recipient receives the pool in tranches (see §06) minus the 1.5% protocol fee.
5. EXIT. On pool completion, collateral unlocks. Reputation accrues.

A worked example. Pool PLVR-4A9F: 20 members × $2,500/mo × 20 rounds. Collateral ratio 25%.

What you receive

The recipient is chosen by Switchboard VRF, a verifiable random function oracle. Selection is a commit-reveal sequence: the oracle publishes a commitment in block Nand the random seed in a later block. The seed is signed by the oracle's Ed25519 key; anyone can verify the proof against the oracle's on-chain pubkey.

request → commit(hash)  ...  reveal(seed, σ)  →  select(eligible, seed)
   │           │                   │                    │
 user        slot N            slot N+K            slot N+K (atomic)

Eligibility: any wallet in the pool that (a) has not yet received, (b) is current on payments, (c) is not in slashing penalty. Defaulted wallets are excluded. In early rounds all non-winners are eligible equally; later rounds narrow the set.

Front-running: impossible. The seed does not exist until the oracle reveals, and by that slot the eligible-set is already committed on-chain.

From round 2 onwards a second disbursement slot is auctioned. Bidding lets you buy priority if you need the liquidity sooner.

1. During a round's collection window, any eligible wallet may submit a bid in USDC, on top of their monthly contribution.
2. At draw time: Track A (main) is selected by VRF. Track B (auction) goes to the highest bidder.
3. The winning bid is added to the pool (benefiting everyone). In return, the bidder's future monthly contributions are reduced by the bid amount, spread over remaining rounds.
4. Ties break on: (1) higher wallet reputation, (2) earlier timestamp.

Bids are binding. If you win and default, insurance pays the Poolver and you are slashed per §06.

The hardest problem in a ROSCA: once you've received the pool, what stops you from walking away? Poolver stacks four mechanisms.

① Collateral lock

The 25% collateral you deposit at join is locked until pool completion, not until you win. If you stop paying after winning, your collateral is slashed in favour of the Poolver. For our example pool the collateral is $625 — one month's worth of "skin in the game" from every member.

② Tranche release

The winnings do not drop in one lump. They release in three parts:

Miss a post-win payment and the remaining tranches are forfeited to the insurance reserve. You still owe monthly contributions — the forfeit does not cancel the debt.

③ Insurance waterfall

5% of every contribution accrues to an insurance_pda. If a member defaults, the waterfall is: (a) slashed collateral → Poolver, (b) forfeited tranches → Poolver, (c) insurance reserve → Poolver to make it whole. The Poolver is guaranteed against single-member default in virtually every configuration.

④ Reputation slashing

Defaults are the single largest negative signal in the wallet reputation score. A default can permanently drop a wallet below the threshold required to join any future Poolver. Because the score is on-chain and non-transferable, a new wallet starts from 0 — so the cost of defaulting is structural, not just financial.

        ENFORCEMENT STACK
        ─────────────────
        ┌─ reputation ─┐   ← permanent, on-chain
        ├─ insurance ──┤   ← Poolver kept whole
        ├─ tranche ────┤   ← leverage over time
        └─ collateral ─┘   ← locked at join

           DEFAULT COST ≈ collateral + forfeited tranches + rep wipeout

The treasury is governed by protocol token holders (future). Until then it's a multisig. Surplus insurance (if a pool completes with no defaults) rolls forward; deficits are topped up from treasury.

Every Solana wallet that has ever interacted with Poolver has an on-chain UserReputationaccount — a non-transferable record of how that wallet has behaved across every pool. It's read directly from the chain (no oracle, no off-chain database) and surfaced everywhere a wallet is shown: the topbar of the user themselves, and the "Rep" column of every pool roster so you can see who you're joining a pool with.

What gets tracked

The four-color tier system

The full numeric history is reduced to a single color so a glance at a roster row tells you whether the counterparty is safe. Rules:

How tiers change

• Joining a pool increments pools_joined only — your color does not change.
• Completing a pool (12 months elapsed without defaulting) increments pools_completed. Gray → Green if no prior defaults; Red → Yellow if there were any.
• Defaulting (liquidated by liquidate_default on day 30 of unpaid status) increments pools_defaulted. Gray → Red, Green → Yellow.

Reputation is permanent and on-chain. There is no admin instruction to reset it — the only way out of Yellow or Red is to complete more pools cleanly. New wallets start at Gray; bad behavior cannot be hidden by switching wallets and rejoining, because every new wallet starts from zero.

• Smart contract risk. The program is audited-pending. Until post-audit, pools are capped in size and treasury reimbursement is at multisig discretion.
• Oracle risk. Selection depends on Switchboard availability. If the oracle stalls, draws are paused; contributions are not affected.
• Stablecoin risk. USDC is an off-chain-backed token. A USDC depeg affects the real value of pool balances.
• Regulatory. Poolver is a programmatic savings coordination tool. It is not a bank, securities offering, or insurance product. Availability in your jurisdiction is your responsibility. This is not financial advice.
• Anonymity. Wallets are pseudonymous. If you link your wallet to your identity off-protocol, the protocol cannot unlink it.

Last updated 2026-04-20 · v0.1.0