Status & Roadmap

Where Cardano Builders Fund stands

The operational truth in one place: what is live as a public preview, what is explicitly not live, and the production gates ahead. This is controlled readiness — built in the open, honest about its stage.

Prototype foundation. Not accepting real funds yet.

Not live yet

Explicitly not active. These are directions and plans — not features you can use today. No real funds, custody, KYC, swaps, or settlement are live.

Real contributions
Production custody
Wallet signing & transactions
DB-backed campaign creation
KYC / KYB
Stablecoin swaps
Governance deposit pools
Production settlement

Current operational state

The hard facts behind the previews, stated plainly.

Wallet connection

Read-only foundation with global control, session restore, and detection diagnostics. Latest manual test: Typhon, Eternl, and VESPR connect (VESPR auto-connects); Lace is detected but the connection did not complete; Yoroi and Gero were not detected. Not universal — use Typhon, Eternl, or VESPR, and a preview/preprod/testnet wallet for testing. Test-safe; mainnet real funding disabled.

Real funding

Not live. No contributions, no custody, and no KYC.

Oracle

Mock in production. A live preprod rehearsal is pending real Kupo/Charli3 values.

Database

Database schema applied — Migration 000001 applied; schema up to date. Tables empty, no seed. Application DB writes: not enabled yet. Pre- and post-migration backups verified. No real funds, custody, or settlement enabled.

Builder applications & profiles

Live private intake at /builder-onboarding → manual review at /admin-preview (Basic Auth): masked list, status controls (NEW/REVIEWING/ARCHIVED), and operator-gated promotion to a public BuilderProfile (creates User + BuilderProfile only). Promoted profiles appear on /builders. Email acknowledgement foundation exists but is disabled (no email sent). No applicant details on public pages.

Campaign drafts

Private, admin-only campaign draft preparation (/admin-preview, behind Basic Auth) for promoted builders. Drafts are never public, never shown on /campaigns, and have no funding fields (publicPreviewEnabled is false). Public campaign creation, contributions, funds, custody, settlement, payment, and signing all remain disabled.

Campaign & builder data

Read-only DB foundation wired — campaign list + detail (/campaigns, /campaigns/[id]), builder list + detail (/builders, /builders/[handle]), milestone/evidence (/milestone-evidence), contribution transparency (/contributor-transparency, count-only), and a read-only admin/ops dashboard (/admin-preview, counts + status breakdowns) read from the database; writes not enabled; admin writes not enabled; records currently empty. Demo entries are preview examples, not records.

Contribution interest (intent only)

Public DRAFT campaigns offer a private “register interest for later” form storing a ContributionIntent (optional contact + free-text note). Reviewed at /admin-preview (Basic Auth) with status labels NEW/REVIEWED/ARCHIVED. This is interest, NOT a contribution: no wallet address, no amount, no transaction, no payment, no custody, no settlement, no signing. It is never counted as a Contribution — the public Contribution count stays 0. Real contributions, funding, and settlement remain disabled.

Wallet proof of control (signData only)

/wallet-preview can sign a human-readable proof message via CIP-30 signData and optionally save it as a WalletProof (signed message + signature + public wallet details). Reviewed read-only at /admin-preview (Basic Auth), masked. This is signature only — proving control of an address, NOT custody, NOT a transaction, NOT funding. No signTx/submitTx, no amount, no transaction hash, no seed/private key. WalletProof is separate from the funding Wallet table, which stays at 0. Verification-as-contribution, funding, and settlement remain disabled.

Funding config (schema only, fail-closed)

The CampaignFundingConfig table exists (migration 000007 applied) with 0 rows and fail-closed defaults (mode DISABLED, status DISABLED, emergency stop on, public visibility off). It stores no full address (masked only), no key, no seed, and no payment/amount/settlement fields. No funding config rows exist, no address is configured, no payment address is shown, no QR, and funding activation is not enabled.

Observer dry-run readiness

A read-only observer dry-run surface exists (admin). It makes no external API call, no chain query, and no database write; it always reports zero candidates and zero writes. The ContributionObservation table exists (migration 000008 applied) — it stores public chain candidate data only and is never a Contribution. No Contribution/Wallet/SettlementRecord writes, no payment address, no QR, no funding activation. The observer is not live.

Observer candidate dry-run

Simulated only. An admin readiness view shows deterministic in-memory sample candidate observations (redacted fake tx hash + masked address). No chain query, no external API call, no database write, and no ContributionObservation/Contribution/Wallet/SettlementRecord rows. No payment address, no QR, no funding activation.

Observer provider readiness

Readiness only. Provider environment presence (Blockfrost/Koios/Ogmios) may be checked — values are never read or shown — and no provider API call is ever made. Selected provider none, live observer off, dry-run only, zero external API calls, zero DB writes. No funding activation.

Provider sandbox-ready gate (fail-closed)

A fail-closed sandbox-read gate exists. By default it makes zero external calls: a single harmless health/tip read (Blockfrost /health or Koios /tip) is permitted only when every flag is explicitly present (OBSERVER_SANDBOX_READY=true, OBSERVER_PROVIDER, OBSERVER_NETWORK=preview|preprod, provider credential) — mainnet is forbidden and secret values are never printed. Even when executed it performs exactly one read, in memory only: no database write, no ContributionObservation/Contribution/Wallet/SettlementRecord rows, no address query, no address scan, no payment address, no QR, no signing, and no funding activation. The result is never persisted.

Provider sandbox observation mapping (design)

Pure, in-memory design mapping only. A mapper function translates a clearly-labelled fake provider payload into a candidate observation preview (to show how a future sanitized read would map to ContributionObservation fields). It imports no Prisma, makes no fetch/HTTP call, reads no env, scans no address, and stores nothing. Would-create-ContributionObservation: no. Would-create-Contribution: no. External API calls: 0. DB writes: 0. Live observer: no. Funding active: no. Admin shows a fake preview only — no run button, no save, no provider call, no address, no QR.

ContributionObservation sandbox write rehearsal

A single guarded server helper can record one sanitized testnet/preprod CANDIDATE observation row (public chain candidate data), gated by fail-closed invariants (campaign DRAFT, funding TESTNET/CONFIGURED, emergencyStop true, publicVisible false, network preview/preprod only, no mainnet, masked address only, status DETECTED, positive amount, unique txHash/outputIndex). A ContributionObservation is candidate-only and is never a Contribution: no funds are accepted, no funding is activated, no payment address or QR is shown. The write path touches only the ContributionObservation table — no Contribution/Wallet/SettlementRecord write, no CampaignFundingConfig update, no external API call, no live observer, no address/UTxO scan. See the live Contribution observations count above.

ContributionObservation review/reject (design)

Design and readiness planning only for how an operator will later review and reject candidate observations (DETECTED → READY_FOR_OPERATOR_REVIEW → REJECTED; CONFIRMED is a separate future gate and never auto-creates a Contribution). A pure transition validator encodes the allowed transitions and fail-closed guards (campaign DRAFT, TESTNET/CONFIGURED, emergencyStop true, publicVisible false, preprod/preview, reason required to reject) but is wired to no write path — no status is changed. No contributionObservation update, no Contribution/Wallet/SettlementRecord, no external API, no live observer, no funding activation, no payment address, no QR.

ContributionObservation CONFIRMED (design)

Design and readiness planning only for the future CONFIRMED boundary (READY_FOR_OPERATOR_REVIEW → CONFIRMED). CONFIRMED would mean the operator accepts the candidate observation as chain evidence — it is still NOT a Contribution, NOT settlement, NOT payout, and does NOT activate funding. A pure precondition validator encodes the guards (status READY_FOR_OPERATOR_REVIEW, allowConfirmFutureGate explicitly true [default off], confirmations satisfied or waived, redacted note required, no Contribution exists, campaign DRAFT, TESTNET/CONFIGURED, emergencyStop true, publicVisible false) but is wired to no write path — no status is changed. There is NO auto-conversion to a Contribution; Contribution creation is a separate future gate. Public Contribution count remains 0. No contributionObservation update, no Contribution/Wallet/SettlementRecord, no external API, no live observer, no funding activation, no payment address, no QR.

Contribution creation (design)

Design and readiness planning only for how a future Contribution could be created from a CONFIRMED observation — no Contribution record is created and no creation path is implemented. Finding: the existing Contribution model is UNSAFE for a sandbox/testnet rehearsal — walletAddress is required, there is no network/isSandbox field, and it is counted by public transparency, so any row would push the public count above 0. Recommendation: a dedicated SandboxContribution model (schema proposal only, no migration) so sandbox rows can never be miscounted as real support. A pure precondition validator encodes the guards and rejects using the existing model (allowCreateContributionFutureGate default off). Contribution 0, Wallet 0, SettlementRecord 0; public Contribution count stays 0. No Contribution/Wallet/SettlementRecord write, no observation update, no external API, no funding activation, no payment address, no QR.

SandboxContribution table (testnet, 0 rows)

A dedicated SandboxContribution table exists (migration 000009 applied) with 0 rows, for future testnet/preprod contribution rehearsals. It is entirely separate from the real Contribution table (no required walletAddress, a network field, an optional link to a CONFIRMED ContributionObservation, masked address/redacted tx hash only, status CREATED/REVIEWED/ARCHIVED), so the public Contribution count stays based only on Contribution and remains 0. A create-path design is prepared: a future guarded helper would create exactly one testnet rehearsal record from the CONFIRMED observation (copying network/amount/redacted tx hash/masked address), gated by fail-closed preconditions (observation CONFIRMED, allowCreateSandboxContributionFutureGate default off, network preview/preprod, no existing sandbox for the observation, real Contribution count 0, campaign DRAFT, TESTNET/CONFIGURED, emergencyStop true, publicVisible false) — but no create path is implemented and no row is created. No SandboxContribution/Contribution/Wallet/SettlementRecord write, no observation update, no external API, no funding activation, no payment address, no QR.

Gate prep

DB preflight template, swap provider research template, and oracle values checklist prepared.

Swap foundation

Architecture boundaries defined (quote → route → tx plan → signing → submission → settlement). A typed adapter boundary + deterministic mock quote preview exist on /swap-readiness; a provider research pack is prepared. No provider is selected or integrated, and live provider, transaction build, wallet signing, submission, and settlement recording are all disabled. No DEX calls, no funds.

Transactions

Disabled. Nothing is signed or submitted.

Settlement

Disabled. No settlement, payout, refund, or return is triggered.

Read-only production database counts

No writes are performed by this page. Counts are observability only. Writes not enabled. No real funds. No custody. No settlement.

Users

1

User · no auth, no writes

Builders

1

BuilderProfile · read-only; onboarding writes disabled

Campaigns

1

Campaign · read-only; campaign writes disabled

Milestones

3

Milestone · no evidence/review writes

Contributions

0

Contribution · no contribution writes, no funds

Wallets

0

Wallet · no wallet records stored

Audit log

0

AuditLog · no events recorded

Contribution observations

1

ContributionObservation · candidate-only, testnet/redacted; never a Contribution; no funds

Sandbox contributions

0

SandboxContribution · table exists; 0 rows; testnet-only, separate from Contribution; public count stays 0

Future production gates

The order of work ahead. Each is a deliberate, reviewed gate — especially anything that touches real funds.

  1. 1

    Database migration review and apply

  2. 2

    Wallet connect MVP (CIP-30, proof of control)

  3. 3

    Builder profile persistence

  4. 4

    Campaign draft persistence

  5. 5

    Real contribution records

  6. 6

    Milestone evidence storage

  7. 7

    Reviewer / admin permissions

  8. 8

    Oracle live-read approval

  9. 9

    Settlement and return rules

  10. 10

    Later: stable-value and governance-pool architecture

Cardano Builders Fund is a prototype foundation. It is not accepting real funds, holds no custody, performs no KYC, runs no swaps, and has no production settlement or governance deposit pools live. Nothing here is legal, tax, or financial advice.