PoolFi is currently in private MVP development. Dashboard features are prototypes only. No live pools, deposits, or withdrawals are available.Join Waitlist →
Litepaper

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:

Kutu (Malaysia)
Arisan (Indonesia)
Susu (Ghana)
Hui (China)
Tanda (Mexico)
Chit Funds (India)
Panderos (Philippines)
ROSCA (Global)

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

1

Pool Creation

Organizer creates a private invite-only pool (max 10 members, USDC, fixed 3× collateral). Pool PDA is initialized on-chain.

2

Collateral Lock

Participants submit JoinPool on-chain instruction — deposits fixed 3× contribution as collateral into program-owned collateral vault.

3

Scheduled Contributions

Participants submit DepositContribution on-chain each cycle, transferring USDC to program-owned contribution vault.

4

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.

5

Reputation Building

Successful completion builds reputation (off-chain in MVP), improving future queue positions.

6

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

Phase 0

Landing & Validation

Current
Landing pageLitepaperWaitlist with email captureCountry & referral tracking
Phase 1

User Onboarding

Upcoming
Wallet connect (Phantom, Backpack)Profile creationIntroducer referral flowBasic dashboard shell
Phase 2

Hybrid MVP — On-Chain Custody + Off-Chain Coordination

Upcoming
Private invite-only pools (max 10 members, USDC)On-chain collateral, contribution & escrow vaultsC2 escrow-adjusted payout releaseProgressive escrow release on-chainDeterministic default waterfallMultisig-gated admin controls
Phase 3

Solana Program — Audit & Expansion

Future
External security auditDevnet → Mainnet deploymentPool size cap expansionUSDT supportRelayer/crank incentive model
Phase 4

Scale & Reputation

Future
On-chain reputation scoringDynamic collateral based on reputationPublic pool discoveryLarger pools & multi-region support
Phase 5

Governance (Optional)

Future
DAO governance (only if meaningful utility)Cross-chain explorationAdvanced pool types

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.