​

Phases

SCF status note: Everything in this document related to the Stellar Community Fund (application, tranches, grant funding) is a draft. The application has not been submitted and there is no short-term plan to submit it. Do not read any SCF-tied line item, date, or amount below as scheduled or committed.

Phase 0          Phase 1          Phase 2          Phase 3
Research    ──►  Foundation  ──►  Launch      ──►  Scale
✓ COMPLETE      ● CURRENT        Q4 2026          2027

​

Phase 0: Research & Validation (COMPLETE)

​

Key Findings

• Stateless SPV on Soroban is feasible: ~37-55M instructions per full verification, within the 100M instruction budget
• Protocol X-Ray (Protocol 26) BN254 host functions reduce ZK verification cost significantly
• P2WSH locking script design complete and tested on Bitcoin Signet
• SCF Build Award strategy defined ($92K, Open Track, one-time application)

​

Research Produced

​

Phase 1: Foundation (CURRENT)

​

What’s Complete ✓

​

What Remains

​

Phase 1 Exit Criteria

• SPV contract verifies a real Bitcoin transaction on Soroban testnet ✓
• P2WSH locking and release tested E2E on Bitcoin Signet ✓
• ZK commitment-tree full cycle verified on Soroban testnet ✓
• SCF application submitted (draft only - no submission planned short-term)
• Trusted setup ceremony planned and participants identified
• SCF Tranche #0 received (~$9,200) (contingent on submission above; not scheduled)

​

Phase 2: Launch (Q4 2026)

​

Remaining Work

• Update co-signing key architecture using delegate_account_auth
• Update SDK imports (breaking change in @stellar/stellar-sdk)

• get_btc_price_stroops in contracts/contracts/private-lend/src/oracle.rs still returns a hardcoded STUB_PRICE_STROOPS_PER_BTC (TODO Phase 2 in the code) - this is a hard dependency for real liquidations and has no owner or target date yet
• Wire real SEP-40 cross-contract call to RedStone (primary) + Pyth (secondary), median aggregation per docs/research/oracle-design.md
• This also unblocks commitment-tree liquidation. With the current fixed-price stub and no ZK-compatible accrual mechanism, no position can legitimately move from the ≥150% ratio borrow requires down to the <120% liquidate requires - see docs/security/security-model.md, “Keeper model and liquidation permissionlessness”
• Implement the 60-minute staleness check and “price paused” fallback state described in docs/research/oracle-design.md and docs/security/security-model.md - neither exists in code today
• Do not schedule a mainnet date until this has an owner and a start date.

• Trusted setup ceremony: Powers of Tau Phase 2 for all 3 circuits (plus zero_debt, per docs/scf/milestone-plan.md)
• Blocking sub-task with no owner or date yet: identify 5+ independent ceremony participants. Ceremony tooling exists (circuits/scripts/ceremony/), but the participants themselves are not identified - this is the actual bottleneck, not the tooling
• Publish ceremony transcript publicly
• Recompile liquidation circuit artifacts after usdc_debt signal addition before running the ceremony - running the ceremony against circuits that still need this change risks having to redo it

• Submit intake form - currently blocked: the readiness criteria in docs/security/audits.md gate this on “SCF Build Award received,” and the SCF application has no short-term submission plan (see Phase 1). Either confirm an SCF-independent Audit Bank qualification path, or define an alternative audit-funding plan; do not assume this unblocks itself
• Readiness review (~4 weeks)
• Veridise audit: ZK circuits
• OtterSec/Zellic audit: Soroban contracts
• Remediate all Critical/High/Medium findings

• Current state: single founder-developer, sole custodian of protocol design knowledge and (pending KMS enforcement) the co-signing key process - see docs/security/security-model.md
• The only mitigation on record (hiring a second developer) is funded by the SCF grant, which is not being pursued short-term - this leaves bus-factor risk unmitigated with no funding-independent fallback
• Needs an explicit plan that does not depend on SCF: candidates include a paid technical advisor for spot-reviews, a documented incident-response runbook co-owned by someone outside the founder, or scoping a minimal paid contractor engagement funded from another source

• Stellar Wallets Kit integration | Done. Wired into the /app dashboard, reading live testnet contract state (pool state, Merkle root)
• Bitcoin wallet connection | Done. Bitcoin wallet button live in the /app dashboard
• KMS-backed cosigning and deposit address UX | Done. Backend cosign API route and auto-cosign repay watcher shipped
• Deposit flow UI: connect Bitcoin wallet → P2WSH → SPV proof → ZK commitment | In progress
• Borrow/repay UI with local position decryption | In progress
• Position dashboard (health factor, interest accrued) | In progress
• /stats public dashboard: TVL, utilization, protocol revenue | Not started
• WASM ZK prover in browser (no server-side proving) | Not started
• Accessibility (WCAG 2.1 AA) audit of the deposit/borrow/repay/release flow | Not started - see docs/design/accessibility-strategy.md. Deliberately sequenced after the flows above leave “in progress,” not before, so the audit isn’t wasted on UI that’s still actively changing
• Guided in-app recovery flows (manual proof submission fallback, emergency Path B recovery) | Not started - see docs/design/guided-recovery-spec.md. Both flows currently require running Node.js scripts by hand; not a blocker for mainnet gating by TVL cap, but should ship before the whitelist restriction lifts and volume grows
• Liquidation status detection and notification | Not started - see docs/design/liquidation-notification-spec.md. The PositionStatus type and frontend display for a liquidated position now exist; the relayer-side event watcher that sets that status does not
• Contract migration runbook | Written, not yet rehearsed end-to-end on a live deployment - see docs/architecture/contract-migration-runbook.md. Recommends a Blend-style wind-down model (old contract stays live for existing positions, no forced state transplant) rather than a forced migration, which is also the only thing architecturally possible for commitment-tree’s ZK positions. Both prerequisite gaps it surfaced are now closed: Config.paused + set_paused exist on both lending contracts (blocks new deposits/borrows/supply, leaves repay/withdraw/liquidate open), and both emit supply/withdraw events so lenders can be enumerated. Remaining open item: an import_position admin function for private-lend’s Track 2 forced-migration path, not yet built (deliberately - see the runbook’s rehearsal checklist)
• SPV checkpoint staleness monitoring | Script written (contracts/scripts/check-checkpoint-age.sh), not yet wired into a scheduled job. Closes the gap where set_checkpoint requires a weekly manual refresh with no on-chain alert if it lapses - see docs/security/security-model.md
• Relayer backfill runbook rehearsal | Written, not yet rehearsed - see docs/developers/relayer-backfill-runbook.md. Rate limiting was added to /api/cosign (Node-process in-memory limiter, resets on redeploy - no shared store across instances since nothing in this stack runs multi-instance today), but the relayer itself is still a single unreplicated process; this runbook is the mitigation for that until real redundancy exists

• All four contract admin accounts configured as 2-of-3 (or stricter) multisigs - not yet done for private-lend/commitment-tree. Only bitcoin-spv/zk-verifier were previously called out for this in docs/security/security-model.md; that document now extends the same requirement to all four, since private-lend/commitment-tree’s admins gate equally sensitive functions (insert_commitment, set_oracle, set_keeper, set_relayer). External Stellar-account configuration, not a contract code change.
• Legal entity formed and operating - hard gate, not yet started. Deploying contracts that custody real user BTC/USDC without a legal entity behind them is a founder personal-liability exposure, not just a compliance nicety. Budgeted at $8K for a Swiss GmbH in docs/scf/application.md, but that budget line is part of the SCF grant, which is not being pursued short-term - this needs its own funding source and owner (the founder) before it can be treated as scheduled. Do not launch mainnet with real funds before this is resolved.
• TVL cap: $50,000 (raised to$250K after 30 days clean operation)
• Whitelist-only for first 30 days. Selection criteria and application process not yet defined (owner: growth/community, before launch): default proposal - self-serve application form gated on (1) a connected wallet with prior testnet activity on Writz, or (2) referral from an existing testnet tester/community member, reviewed manually given expected low volume at this stage
• Protocol fee: 0% for 90-day bootstrap period (requires a launch-time change to PROTOCOL_FEE_BP in contracts/contracts/private-lend/src/rates.rs, currently hardcoded to 15% - not yet implemented, treat as a pre-mainnet task)
• Protocol-owned USDC seed: $50,000 (funding source unresolved - see docs/research/growth-strategy.md)
• DeFiLlama submission (day 1)
• Points program launch (pre-WRTZ)

​

SCF Tranche Delivery

​

Phase 2 Exit Criteria

• Legal entity formed and operating (hard gate before real-fund mainnet launch - see “Mainnet launch (gated)” above; not yet started, funding source unresolved)
• Real oracle integration live (RedStone + Pyth median, staleness check) - replaces the current hardcoded stub; no owner or date assigned yet
• Trusted setup ceremony: 5+ independent participants identified and ceremony run - participants not yet identified
• Key-person / bus-factor mitigation plan in place, independent of SCF funding
• Mainnet deployment with passing Audit Bank audit (0 critical findings) - contingent on resolving the Audit Bank/SCF gating dependency above
• 10+ real deposits processed with no security incidents
• $50K TVL cap reached
• TVL cap raised to $250K after 30 days clean operation
• Open-source SPV SDK published (GitHub + npm)
• DeFiLlama listing live
• All SCF tranches delivered (only applicable if the SCF application is submitted - not currently planned)

​

Phase 3: Scale (2027)

​

Product Expansion

​

TVL Progression

​

WRTZ Token (Q2–Q3 2027)

​

Stellar Ecosystem Alliance

• Contribute Writz SPV SDK as Stellar ecosystem infrastructure
• Propose a SEP standard for Bitcoin SPV on Stellar
• Co-market with SDF as the flagship BTCfi protocol on Stellar
• Apply for SCF Growth Hack Program (after 60+ days mainnet, completed audit, no active SDF grants)
• Apply for SCF Liquidity Award (after $250K TVL sustained 7 days)

​

Wallet Integrations

• Xverse: BTC DeFi section with PrivateLend
• Freighter: BTC collateral option in the lending section
• Lobstr: BTC yield product in the savings section

​

Institutional BD

• Direct outreach to crypto hedge funds, family offices, BTC mining companies
• Compliance documentation package (ASP attestations, audit reports, regulatory positioning)
• Target: 3–5 institutional deposits of $100K+ each

​

Success Metrics