PoolFi Litepaper
Transparent savings coordination on Solana, with progressively stronger on-chain enforcement
PoolFi is currently under development and has not yet launched on mainnet. This litepaper describes the intended protocol design and may evolve as development progresses.
MVP Trust Model — Hybrid Protocol
PoolFi MVP is a hybrid protocol from day 1: on-chain custody and enforcement for all user funds, with off-chain coordination, identity, invitations, reputation, admin review, UI, notifications, and analytics.
On-chain (Solana program): collateral vault, contribution vault, escrow vault, deterministic payout release, progressive escrow release, default waterfall enforcement, and multisig-gated admin controls. The on-chain program is the source of truth for all money movement. Supabase/admin cannot arbitrarily release or withdraw user funds.
Off-chain (Supabase): coordination metadata only — profile data, invitations, reputation events, admin review notes, and UI state. Reputation tracking remains off-chain in MVP; on-chain reputation is planned for a future phase.
This document must align with the PoolFi canonical project source. If there is a conflict, the canonical source takes priority.
1. Executive Summary
PoolFi Protocol is a savings coordination infrastructure built on Solana. Inspired by traditional ROSCA (Rotating Savings and Credit Association) systems—known globally as kutu, arisan, susu, hui, tanda, and chit funds—PoolFi enables communities to form transparent savings pools using stablecoins on the blockchain.
The protocol facilitates recurring contributions, transparent payout queues, collateral protection, and reputation tracking. During the MVP phase, reputation is tracked off-chain while maintaining transparency through auditable pool activity records. Portable on-chain reputation is planned for a future phase. PoolFi does not require a native token to function and is not a lending platform, yield farming protocol, or speculative investment vehicle.
2. The Problem
Trust Deficit
Traditional savings groups rely entirely on interpersonal trust, making them vulnerable to organizer fraud and participant defaults.
Geographic Limitations
Physical meetups and cash handling limit participation to local communities, excluding the global diaspora.
3. Why Traditional ROSCA Systems Matter
ROSCA systems have existed for centuries across cultures worldwide. These informal savings groups serve millions of people who lack access to traditional banking or prefer community-based financial coordination. The systems are known by many names:
These systems coordinate billions of dollars annually, demonstrating the massive demand for community savings coordination. However, they remain largely offline and dependent on trust.
4. Why ROSCA Does Not Scale
- 1Physical coordination limits pool sizes and geographic reach
- 2Cash handling creates security risks and friction
- 3No default protection beyond social pressure
- 4Limited reputation portability across groups
- 5Organizer burden for tracking and enforcement
- 6No transparency for external observers
5. Introducing PoolFi Protocol
PoolFi brings ROSCA systems on-chain, preserving the social benefits while eliminating the trust requirements and operational friction. The protocol provides:
Protocol-Managed Coordination
Transparent contributions and payouts
Collateral Protection
Default protection through locked deposits
Reputation Tracking
Portable history across all pools (off-chain during MVP, on-chain in future)
Transparent Queues
Visible payout order and timing
6. How PoolFi Works
Pool Creation
Organizer creates a private invite-only pool (max 10 members, USDC, fixed 3× collateral). Pool PDA is initialized on-chain.
Collateral Lock
Participants submit JoinPool on-chain instruction — deposits fixed 3× contribution as collateral into program-owned collateral vault.
Scheduled Contributions
Participants submit DepositContribution on-chain each cycle, transferring USDC to program-owned contribution vault.
Escrow-Adjusted Payouts
ExecuteRelease releases immediate payout portion on-chain; withheld escrow stays in program vault per C2 schedule. Progressive escrow release runs post-payout.
Reputation Building
Successful completion builds reputation (off-chain in MVP), improving future queue positions.
Pool Completion
After all payouts and post-payout cycles, remaining escrow and collateral are returned on-chain.
7. Supported Assets
USDC
USD Coin
Primary stablecoin for contributions and payouts
USDT
Tether
Alternative stablecoin option
SOL
Solana
Native token for network fees
8. Pool Types
Weekly
7 days
Fast cycling, smaller amounts
Bi-Weekly
14 days
Balanced pace for most users
Monthly
30 days
Larger amounts, longer cycles
9. Collateral Protection Model
PoolFi requires participants to lock collateral as a risk-reduction mechanism. Collateral reduces the likelihood of loss in the event of a default, but it does not eliminate default risk entirely. If a defaulting member has already received their payout and their collateral is insufficient to cover outstanding obligations, remaining members may absorb a partial shortfall. The collateral model is designed to:
- Align participant incentives with pool success
- Partially compensate the pool in case of defaults
- Scale with contribution amounts and pool risk profiles
- Be returned upon successful pool completion
Risk Disclosure: Collateral provides a meaningful deterrent and partial recovery mechanism. It is not a guarantee of full recovery. Participants should only join pools with members they have reason to trust, and should treat any payout as contingent on all members fulfilling their obligations.
10. Default Handling
In the event of a missed contribution, the protocol has a structured default handling process:
Grace Period
A short grace period allows for delayed contributions with a small penalty fee
Collateral Liquidation
If the grace period expires, collateral is partially liquidated to cover the missed contribution
Reputation Impact
Defaulting participants receive reputation penalties affecting future queue positions
Pool Continuation
The pool continues with remaining participants; payouts are adjusted accordingly
11. Reputation System
PoolFi MVP tracks reputation off-chain while maintaining transparency through auditable pool activity records. Future protocol phases may commit reputation snapshots or reputation proofs on-chain, but reputation should be treated as off-chain during MVP:
Successful Completions
Each completed pool builds reputation
Payment History
On-time contributions increase reputation score
Default Records
Defaults decrease reputation significantly
Queue Position
Reputation may improve queue position by up to 3 slots from join-order base
12. Deterministic Queue Assignment
PoolFi uses deterministic queue assignment to ensure fairness, transparency, and predictability. Queue position is based primarily on join order, with bounded reputation-based adjustments:
- • Join order is the foundation: Earlier joiners receive earlier base positions
- • Reputation adjustment: Higher reputation may improve position by up to 3 slots maximum
- • Early participation bonus: First 10% of joiners receive modest priority boost
- • Fixed final queue: Once assigned, queue order remains unchanged for pool lifecycle
Key Principle: Reputation can improve position but is capped at a maximum of 3 positions from the original join-order position. This keeps queue assignment predictable and auditable while still rewarding trustworthy participation.
13. Fee Structure Overview
PoolFi implements a 5% fee on payouts that aligns incentives across all participants in the ecosystem. This fee structure mirrors how successful ROSCAs operate in the real world—where community leaders and introducers play essential roles in maintaining healthy pools.
Proposed MVP fee allocation: The following split represents a proposed allocation pending final reserve policy (Issue #40). The Security Reserve allocation from the 5% fee must be clarified by the reserve policy.
1%
Protocol Development
2%
Security Reserve
1%
Introducer
1%
Pool Creator
Total: 5% per payout (applied only when participants receive payouts)
Unlike purely collateral-based systems, this fee structure creates social accountability by rewarding the human relationships and community leadership that make ROSCAs successful.
14. Protocol Development Fund
1% of each payout is allocated to protocol development. This fund supports:
- • Ongoing protocol development and feature enhancements
- • Security audits and code reviews
- • Infrastructure costs and maintenance
- • Developer grants and bug bounties
- • Documentation and community resources
14b. Treasury vs Security Reserve
PoolFi maintains two distinct funds with separate responsibilities:
Protocol Treasury (1%)
Funded by the 1% protocol development fee. Used exclusively for:
- • Ongoing protocol development
- • Security audits and code reviews
- • Infrastructure and maintenance
- • Developer grants and bug bounties
The treasury does not compensate pool member losses.
Security Reserve
A proposed portion of the 5% protocol fee may be allocated to the Security Reserve (pending final policy). Used for protocol-level emergencies:
- • Smart contract vulnerability incidents
- • Protocol-wide edge cases
- • Ecosystem resilience during stress
- • Emergency interventions at protocol discretion
The security reserve is not a guarantee of individual pool loss recovery.
15. Security Reserve
The Security Reserve is a proposed protocol-wide protection fund designed to absorb unexpected protocol-level losses and edge cases. A portion of the 5% protocol fee may be allocated to this reserve, pending final reserve policy approval (Issue #40). The Security Reserve is maintained separately from the Protocol Treasury. This reserve:
- • Provides an additional layer of protection beyond individual collateral at the protocol level
- • Covers smart contract vulnerabilities and protocol-level edge cases
- • Ensures ecosystem resilience during market stress
- • Can be used for emergency interventions at protocol discretion
Important: The security reserve is a protocol-level fund maintained separately from the Treasury, not an insurance product. It does not guarantee full reimbursement of individual pool losses resulting from member defaults.
16. The Introducer Role
The Introducer is a key trust layer in the PoolFi ecosystem. In the MVP phase, all pools are private and invite-only—only participants introduced by a trusted member may join. This replicates how traditional ROSCAs work in practice: most people join because someone they personally trust invited them. Introducers receive 1% of payouts from participants they bring into the protocol.
How It Works
- 1An Introducer invites someone to join PoolFi using their unique referral link
- 2The invited participant joins a pool and participates normally
- 3When the participant receives a payout, 1% goes to their Introducer
Why This Matters: Introducers have a financial incentive to bring in trustworthy participants rather than simply maximizing signups. This creates a network of accountability where people are introduced by friends, family members, colleagues, or community leaders who vouch for their reliability.
The Introducer model transforms PoolFi from a purely technical solution into a reputation-driven community finance network that scales through trusted relationships.
Liability Note: Introducers share reputational accountability for the participants they bring in. Repeated introductions of defaulting members will negatively impact the Introducer's own reputation score, reducing their access to pools and queue priority.
17. The Pool Creator Role
The Pool Creator (or Pool Leader) receives 1% of payouts from the pools they create. This role is essential for maintaining healthy pools and ensuring participant success.
Pool Creator Responsibilities
- • Set fair and sustainable pool parameters
- • Recruit and vet participants
- • Monitor pool health and participant engagement
- • Provide support and guidance to participants
- • Help resolve disputes or issues
- • Ensure pool completes successfully
Aligned Incentives: Because Pool Creators earn from successful pool completions, they are incentivized to:
- • Recruit reliable participants who will complete the full cycle
- • Set realistic contribution amounts that participants can sustain
- • Provide ongoing support to reduce default rates
- • Build a reputation as a trusted community leader
This mirrors traditional ROSCA organizers who take responsibility for bringing the group together and ensuring its success. The Pool Creator fee rewards this essential human coordination work.
18. Why Solana
PoolFi is built on Solana for several key reasons:
Low Transaction Costs
Sub-cent fees make small recurring contributions viable
Fast Finality
400ms block times ensure quick contribution processing
Mature Stablecoin Ecosystem
Robust USDC and USDT support
Growing DeFi Infrastructure
Integration opportunities with existing protocols
19. Market Opportunity
Millions of people worldwide participate in informal savings groups known by different names such as kutu, arisan, susu, hui, tanda, and ROSCA. These systems coordinate billions of dollars annually but remain largely offline and trust-based.
PoolFi addresses this massive market by bringing these coordination mechanisms on-chain, adding transparency, security, and global accessibility while preserving the community dynamics that make these systems effective.
20. Roadmap
Landing & Validation
User Onboarding
Hybrid MVP — On-Chain Custody + Off-Chain Coordination
Solana Program — Audit & Expansion
Scale & Reputation
Governance (Optional)
20b. Risk Disclosures
Default Risk
Collateral reduces but does not eliminate the risk of loss from a member default. If a defaulting member has already received a payout and their collateral is insufficient, remaining members may absorb part of the shortfall.
MVP Uses Hybrid Architecture
All user fund custody (collateral, contributions, escrow) is enforced on-chain by the Solana program. Off-chain state (Supabase) covers coordination metadata only and cannot override the on-chain program. Supabase/admin cannot arbitrarily release or withdraw user funds. Emergency rescue requires multisig.
Public Pools are a Future Phase
In the MVP, all pools are private and invite-only. Open, permissionless public pool creation is planned for a later phase once trust mechanics and on-chain reputation are sufficiently validated.
On-Chain Reputation is a Future Phase
Reputation in the MVP phase is tracked off-chain. Portable on-chain reputation scoring is planned for Phase 4 and 5 after on-chain infrastructure is deployed and audited.
Security Reserve is Not Insurance
A proposed portion of the 5% protocol fee may be allocated to the Security Reserve (pending final policy). The reserve is a protocol-level fund maintained separately from the Treasury. It is not an insurance product and does not guarantee full reimbursement of individual pool losses.
21. Long-Term Vision
PoolFi aims to become the standard infrastructure for decentralized savings coordination, enabling communities worldwide to access transparent, secure, and efficient savings pools. We envision a future where:
- • Community savings are coordinated transparently on-chain
- • Portable reputation unlocks financial opportunities across protocols
- • Global communities can save together regardless of geography
- • Transparent, auditable coordination replaces informal cash-based systems
22. Disclaimer
PoolFi Protocol is a hybrid savings coordination platform: on-chain fund custody and enforcement from day 1, with off-chain coordination. This is not a speculative trading platform, lending protocol, yield farming protocol, or investment vehicle. PoolFi does not guarantee returns. Users participate in pools at their own risk. This litepaper describes intended functionality and does not constitute financial advice. The protocol is currently under development and has not launched on mainnet.