02 / Financial infrastructureOn-chain grant infrastructureTestnet productDemo

DefundU

On-chain infrastructure for creating, funding, and releasing named student grants.

Student profiles, backer workflows, grant creation, a grant state machine, release requests, and a custom escrow contract — the full lifecycle from a named opportunity to an approved release. The grant product and testnet escrow workflow are implemented and run end to end on Base Sepolia; real-money operation is intentionally disabled pending production financial safeguards.

Open deployed build ↗ opens in a new tab

Demo.

The product experience: a student's named grant, a backer funding it, the funds held until they're needed, and the release once the student requests them. The engineering underneath — the state machine, the escrow contract, the reconciliation logic — is covered below.

Why it exists.

Traditional student lending creates debt and interest for opportunities that are often small, specific, and one-time: a certification exam, a conference ticket, a piece of equipment. DefundU is the plumbing for a no-repayment alternative, where a backer funds one verified opportunity and the money is provably escrowed and released only after admin review.

Enforced in code

No repayment, interest, yield, equity, ownership, or tradable asset — enforced as checked code paths and a dedicated money-config test suite, not just policy language.

The grant lifecycle.

01A student publishes a profile and a specific unlock — a named opportunity with cost, deadline, and proof requirements.
02An admin reviews and approves the unlock and its proof.
03A backer browses the private Grant Room and names a grant for an approved unlock.
04The backer accepts an explicit no-repayment acknowledgement before the grant can be funded.
05The backer pays in CAD; an admin confirms the payment was received.
06DefundU funds the grant escrow from its treasury, and the app verifies the on-chain transaction.
07The student requests release to a verified wallet.
08An admin approves the release, and it executes on Base.

What is built.

67pages across the student, backer, and admin flows
54API routes implementing the grant lifecycle
7Supabase migrations modelling the state machine
Student

Profiles, unlocks, grants

Profile submission and review, unlock creation and proof, grant records, updates, and release requests.

Backer

Discovery and funding

The private Grant Room of approved unlocks, grant creation, the no-repayment acknowledgement, and per-grant records.

Admin

Review and money state

Access control, application and proof review, reconciliation, release approval, on-chain event inspection, and release executions.

Infrastructure

State machine and escrow

A funding state machine in app/lib/money/, per-provider adapters, and a custom escrow contract deployed to Base Sepolia.

The escrow contract.

GenesisGrantEscrow.sol is a single contract that manages many grants keyed by bytes32 grant ID, with the funding token fixed at deployment and designed for USDC settlement on Base. Mock USDC and fee-token contracts accompany it for testing.

  • Funded once

    Each grant is funded exactly once. Partial funding is rejected; fee-on-transfer mismatches are rejected.

  • No backer control

    After funding, the backer has no release control. Partial release is not supported.

  • Admin release

    A restricted releaser executes release only after an off-chain admin approval; unresolved grants can be refunded.

  • Reconcilable

    GrantFunded, GrantReleased, GrantRefunded, and pause events are emitted for the app's on-chain listener.

The escrow flow runs on Base Sepolia with automated coverage across funding, pause, release, refund, and admin-role paths.

Three sources of truth.

A grant is not treated as funded until three independent records agree. Most of the state-machine complexity is in handling partial and out-of-order confirmation.

Payment

The CAD payment confirmation, or a provider event.

On-chain

The escrow's own GrantFunded event, read by the listener.

Internal

The app's money status, advanced only when the other two reconcile.

Provider adapters are in place for Coinbase, Crossmint, Stripe Onramp, Banxa, a direct-USDC rail, and the manual-CAD treasury path, which is wired end to end.

Under the hood.

  • App

    Next.js 16 and React 19 with TypeScript; API routes handle application, review, and dashboard flows.

  • Data

    Supabase Postgres holds application state, migrations, and the audit trail for admin actions, provider events, and on-chain events.

  • Money

    app/lib/money/ keeps provider-specific logic isolated from core escrow reconciliation.

  • Chain

    Solidity via Hardhat, deployed to Base Sepolia; viem and wagmi for on-chain reads and the event listener.

What's implemented, and what production needs.

The grant lifecycle, the state machine, the escrow contract, and the manual-CAD treasury rail are built and tested on testnet. Turning on real money is a deliberate, gated step — the four remaining requirements come verbatim from the contract's own README:

  • Security review

    Independent audit of the escrow contract and an admin multisig.

  • Live payment rails

    Production integrations and webhook handling for the CAD and USDC providers.

  • Key management

    Production key custody, financial controls, and monitoring.

  • Compliance

    Legal and compliance review of the grant, escrow, and release model.

Live on testnet.

The grant, escrow, and release flows run end to end on Base Sepolia.