Phased plan from the current state through Split Mode mainnet, Fund Mode mainnet closed beta, Seeker / Telegram distribution, multi-chain funding, and non-crypto onboarding. See STATUS.md for the current checkpoint and PRD.md for the locked MVP shape.
Split Mode mainnet first. Fund Mode mainnet invite-only closed beta second. Fund Mode devnet remains the rehearsal and hardening environment until the trusted cohort path is ready. This roadmap supersedes the earlier "multi-chain at Summit" sequencing: LI.FI stays a top-up support layer today, while full multi-chain wallet/funding support comes after Seeker and Telegram distribution.
FundLabs umbrella: financial layer for groups — human or AI. Three products in market by Summit:
- FundWise — shared finance, Split + Fund Modes.
- Fundy — Telegram-native agent + MCP server. Live on Railway since 2026-05-15. Zerion CLI integration is live in Fundy for wallet analysis/readiness/verification. FundLabs product, not "just a surface" (ADR-0039).
- Receipt Endpoint — standalone Solana tx → structured receipt service. Railway-hosted, x402/MPP payable, MCP-catalog-listed. Ships by Summit (ADR-0040).
The current rollout order:
- Split Mode on Solana mainnet — public, open wedge. Settlement asset is USDC (ADR-011). Wallet-native Groups, verified transfers, session-gated ledger access, Receipts.
- Fund Mode on Solana mainnet — invite-only closed beta — trusted cohort, Squads-backed Treasury, Contributions, reimbursement Proposals, approval/rejection, proof/history, execution, and fee-flow validation. Devnet continues as rehearsal/hardening until the mainnet cohort is ready.
- Seeker app — distribution surface after Split Mode mainnet and Fund Mode closed beta are coherent. Reuses the same wallet-confirmed Settlement and Contribution flows; no separate ledger.
- Telegram bot + Telegram mini app — runs in parallel with Seeker distribution. Fundy is already live; this phase productizes the FundWise Agent experience for group coordination, reminders, drafts, and mini-app UX while money movement still returns to wallet confirmation.
- Full multi-chain funding/wallet support — add persistent secondary EVM funding wallet support and broader supported-chain UX. LI.FI/CCTP remain inbound rails that route funds into USDC on Solana; Solana remains the ledger and Settlement/Treasury venue.
- Non-crypto-native onboarding — embedded wallets, Bridge.xyz bank rails, and Visa/card payments. The goal is "anyone can join and fund a Group" without making non-crypto users understand wallets first.
Already-live or parallel FundLabs surfaces:
- Fundy — live on Railway, separate repo (ADR-0022), calls FundWise over public HTTP, exposes token-authenticated MCP tools, and runs Zerion CLI-backed wallet analysis/readiness/verification. Money movement deep-links to the web app for wallet confirmation. Tax advisory (ADR-0023) lives in Fundy.
- Agent Skill Endpoint — live at
https://fundwise.fun/skill.md. - Receipt Endpoint — standalone Railway service (ADR-0040). Solana tx sig in -> structured receipt JSON out, IPFS-pinned, payable per call via x402/MPP, listed in pay-skill / x402 MCP catalog. Any Solana tx accepted; FundWise Settlements = premium first-class source.
- Payable Settlement Requests + agent-paid Settlement — planned after Scoped Agent Access and Spending Policies are ready. Uses
settlement:payauthority with explicit caps, asset, expiry, and revocation. - Recurring Contributions via Tributary, devnet-first (ADR-0042, Proposed). Mainnet sequence remains Split Mode mainnet -> Fund Mode mainnet closed beta -> Tributary mainnet, additionally gated on Tributary audit, opt-in demand, and partnership terms. Devnet experimentation is open timing but must not displace Split/Fund/Seeker/Telegram sequencing.
Planning thesis: the market already has strong web2 substitutes and several crypto-native bill-splitting attempts. FundWise's wedge is verified USDC Settlement for real private Groups, with Settlement Request Links as the acquisition loop, and pooled USDC Treasuries as the durable-group product. Multi-chain is an inbound funding and wallet-support layer, not a multi-ledger settlement claim.
Goal: ship Split Mode publicly on mainnet, then open Fund Mode on mainnet as an invite-only closed beta for a trusted cohort. Fund Mode devnet remains the rehearsal lane until the closed beta gates are satisfied.
Already shipped:
- Group CRUD UI, zero-state Group creation, invite link + QR join flow
- Expense entry with equal / exact / percentage / shares split methods
- Balance computation and simplified settlement graph
- Settlement receipt route, Activity Feed
- Creator-owned Expense edit/delete with later-Settlement guard
- Settlement Request Link flow, total settled volume display, Group profile editing
- Responsive pass across landing, Group list, Group page, Receipt, modals
- Wallet-signed session cookies for protected actions
- Authenticated server-side ledger writes for Groups, Members, Expenses, Settlements, Contributions, profile updates
- Session-aware Group and Receipt reads (no public browser ledger reads)
- RPC verification before persisting Settlement and Contribution receipts
- Distributed rate limit on every money-moving route (FW-054)
Still to finish:
- Manual breakpoint QA across landing, Group list, Group page, join, dialogs, Receipt
- Mainnet USDC mint wiring, insufficient-USDC and insufficient-SOL states, ATA-creation messaging
- Production RPC and recipient USDC token-account auto-creation inside the Settlement flow
- Operator runbook execution (Supabase, Cloudflare, RLS verification) per docs/ops-runbook.md
- Mainnet cutover per docs/split-mode-mainnet-checklist.md
On-chain rule: keep Split Mode on the simplest credible path — direct USDC settlement plus the minimum on-chain handling required for safety. No new custom contracts on this surface.
Exit criterion: a real user opens the web app on mobile or desktop, joins a Group, logs Expenses, settles their net Balance in USDC on Solana mainnet, and lands on a usable Receipt.
Goal: graduate Fund Mode from invite-only devnet beta to mainnet as the hero product for durable Groups. Beta validation work is captured in docs/fund-mode-beta-checklist.md.
Already in the repo:
- Group creation supports Fund Mode
- Treasury initialization
- Contribution history and on-chain Treasury balance display
- Multisig + vault address storage
- DB migration
20260515100000_fund_mode_beta_completion.sql(roles, proposal kinds, monetization) - Server enforcement: role permissions, proposal kinds, monetization mutations, cluster-aware Fund Mode
- Role / creation-fee / monetization / leave / admin endpoints
- Fund Mode beta UI banners, exit survey, nullable proposal fields
Still to finish before closed beta opens:
- Proposal creation, approval/rejection, execution end-to-end with Squads-backed Treasury movement
- Proposal proof, comments, edit history, visible rejection history (no Group-wide chat)
- Reimbursement-first Proposals where Treasury payouts go to Member wallets only
- Threshold-approval execution callable by any Member
- Signer-management rules after Treasury initialization
- Better Contribution UX
- Mainnet cluster wiring + invite gate removal once stable
Exit criterion: a Fund Mode Group on mainnet can initialize a Treasury, accept Contributions, create a reimbursement Proposal, approve or reject it, and execute the approved reimbursement.
Fundy lives in a separate repository (ADR-0022) and calls FundWise over public HTTP plus the Agent Skill Endpoint. It is live on Railway, command-first in v1, and exposes token-authenticated MCP tools. The Zerion CLI integration is live in Fundy for wallet analysis, readiness, and verification.
The FundWise side of the linkage is shipped:
- Telegram link-code flow (
/api/telegram/link-code, wallet-session gated) - Service-key gated Fundy endpoints (
/api/telegram/linkGET/POST/DELETE) - DB tables with RLS on, service-role-only access
Capability scope at launch: personal finance for the individual user, read-only and draft-safe Group operations, group-chat mode after every Member authenticates. On-chain actions (settle, contribute, execute) deep-link back to the web app for wallet confirmation.
Goal: let Members with funds or wallets on EVM and other supported chains participate in Groups without forcing the FundWise ledger off Solana. This follows Seeker and Telegram distribution; it is not the current launch blocker.
Mechanism:
- Circle CCTP for native USDC across supported chains.
- LI.FI for source-asset and route selection when the Member doesn't already hold USDC on a CCTP-supported chain.
- Inbound funds always convert to USDC on Solana before they touch the FundWise ledger. Solana mainnet is still the only ledger and Settlement venue.
- Current surface stays in the Settlement / Contribution flow as
Route funds for SettlementandRoute funds for Contribution. - Later full support adds persistent secondary EVM funding wallet connection, saved route context, and clearer "fund from any supported chain, settle on Solana" UX.
Hard rules:
- Settlement asset stays USDC on Solana. CCTP/LI.FI is an inbound rail, not a multi-ledger product.
- Off-chain ledger model does not change.
- No full multi-chain wallet-support claims until EVM wallet connection, route execution, Solana receipt verification, and return-to-context all work end to end.
Already shipped:
lib/lifi-config.ts— EVM (Ethereum/Base/Arbitrum/Optimism/Polygon) + Solana providers wired, USDC addresses mappedlib/lifi-bridge.ts— full quote → sign → execute flow with status callbackscomponents/cross-chain-bridge-modal.tsx— bridge UI surfaced in Settlement (FW-004) and Contribution (FW-030) flowspnpm lifi:readiness— mainnet routes for Ethereum/Base/Arbitrum/Optimism/Polygon USDC → Solana USDC are validated
Still to ship for full multi-chain support:
- CCTP routing config in LI.FI (
preferBridges/allowBridges) — decision pending: CCTP-only vs prefer-CCTP-with-fallback - "Powered by Circle CCTP" branding inside the bridge modal; surface which rail the active quote used
- End-to-end mainnet test with a tiny (~1 USDC) Base → Solana route, documented and reproducible
- EVM wallet connector and persistent secondary funding-wallet model
- Route-success monitoring and recovery UX
Open verifications: fee/quote display polish, route-success monitoring, recipient ATA handling for cross-chain originated flows.
Goal: make FundWise usable by people who don't currently hold crypto or a wallet.
Stack direction:
- Embedded wallets — per-user wallet provisioning for people who should not have to install a wallet before joining a Group. Provider choice remains an implementation decision; Phantom Connect and Privy-style models are candidates, not public claims until selected.
- Bridge.xyz — bank rails (SEPA / SEPA Instant / IBAN / wire where supported) into USDC on Solana.
- Visa/card payments — card-funded entry and/or settle-to-spend partner rails once a concrete provider path is chosen.
- Squads Protocol — already integrated; each FundWise Group is a Squads multisig holding USDC. Contributions flow from the user's embedded or self-custody wallet -> the Group's Squads multisig.
Hard rules:
- Embedded wallet provisioning is opt-in. Self-custody via wallet-adapter remains the default for crypto-native users.
- KYC, holding limits, and offboarding rails follow what the partner provides — do not invent these in-house.
- Do not claim "no crypto needed" in copy until top-up → Group contribution actually works for a fiat-only user end-to-end.
Open verification before spike: does Bridge.xyz let SEPA/IBAN settle USDC directly to the selected embedded Solana wallet, or is there a "destination must be Bridge-provisioned" gotcha in the EU flow?
Sibling card-rail track (long-range): USDC settled in a Group should eventually be spendable at Visa merchants via a concrete card-issuing partner. Treat as partner work, not core product, until a concrete integration exists.
These move on Fundy's own track but depend on FundWise contracts staying stable.
- Agent Skill Endpoint (
/skill.md): live athttps://fundwise.fun/skill.md. Purpose, allowed/forbidden calls, auth, limits, errors. Any agent cancurlit. - Scoped Agent Access API: permission model for autonomous agents — scoped capabilities tied to Member wallet, Group, and action type (read, draft, comment). Money-moving action types still require direct wallet confirmation. Capability grants with expiration and revocation.
- Payable Settlement Requests (research, docs/agentic-settlement-endpoint.md): x402, MPP, pay.sh-style flows. First prototype is USDC-only, exact amount, short expiry, idempotent, Receipt-only after verified payment proof.
- Agent Spending Policy (docs/agent-payment-policy.md): Member-configured payment caps, Group scope, asset scope, counterparty scope, expiry, revocation, human fallback.
These should not appear in launch copy or be built into the core product unless a phase explicitly ships them:
- Multi-chain settlement (Solana stays the ledger)
- Any-chain or any-currency Settlement
- Gas abstraction / gasless settlement
- Social login as a replacement for wallet identity
- Embedded-wallet-only onboarding
- Live yield-bearing Treasuries
- AI-native expense entry beyond draft-safe Fundy/FundWise Agent flows
- Mini-games or prediction-market mechanics — out of FundWise entirely
- Autonomous-agent money movement (planned via Payable Settlement Requests post-Summit)
- Scoped Agent Access agent-as-Member full path (north-star direction; agent-as-hands token-scoped slice ships at Summit per ADR-0039)
- Receipt Endpoint as a coupled FundWise-only product (superseded — ships standalone per ADR-0040)
- Source Currency entry and Expense Proof upload until each is implemented end to end
- Unlimited agent spending, broad API keys, or prompt-only authorization for money movement
- Multi-stablecoin support
- Broader Source Currency capture with Exchange Rate Snapshot storage
- Native mobile app once the shared engine and secondary surfaces are stable
- Wallet mini-dapp distribution after the Seeker and Telegram phases are stable
- AI bill parsing beyond receipt-photo upload
- Yield routing (e.g. Meteora) for idle Treasury USDC, only after Fund Mode mainnet is stable
- Production card rails through Rain / KAST / Avici partners
- Activation, settlement, and treasury analytics; production monitoring; mainnet support tooling
- Privacy payments / private transfers. Member makes Contribution or Settlement without revealing wallet address to other Group Members. Research candidates: Umbra (Solana stealth-address protocol), Magic Block (ephemeral-rollup execution), other stealth-address + shielded-pool primitives. Member-pseudonymity concern emerges at scale (large DAO Treasuries, public Group profiles) — not at Summit, not at devnet beta. Will need a dedicated ADR and likely a new fenced module (
lib/privacy/) once a concrete primitive is picked. - FundLabs operational treasury (deferred — no ADR yet). Transparent on-chain treasury for company-level expenses: founder salary, maintenance fees (subscriptions / hosting / infra), and user cashback rewards (speculative). Public address + visible outflows = trust signal ("you can see where the money goes"). Multi-sig structure deferred — set up when team grows beyond solo OR when treasury holds meaningful funds. Will scaffold the
gateway.authorityrole in ADR-0042 when established. No token, ever, for this surface — utility treasury only.