Skip to main content
Fundwork is a layered system that combines a web application, an authentication provider, a smart wallet account, a backend service, a database, and a settlement network. This page walks through each layer, what it is responsible for, and how the pieces fit together.
Fundwork is currently in alpha. This page describes the architecture as it exists today and, where noted, the direction it is moving in before public launch. Sections that describe planned or exploratory work are labeled explicitly.

​
Layered View

At a high level, a request in Fundwork moves through the following layers:
Each layer has a narrow, well-defined responsibility. The frontend is never trusted to be the source of truth for authorization or payment state; the backend verifies actions against the database and, for payments, against the Base network.

​
Layer Responsibilities

​
Frontend

The Fundwork web application is the primary user surface. It is responsible for:
  • Marketplace UX and navigation
  • Profiles for talent, clients, and organizations
  • Opportunity creation flows
  • Applications and proposals
  • Submissions and revision requests
  • Approval workflows
  • Presenting payment state that the backend has confirmed
The frontend renders state; it does not decide state. Approvals, payments, and status changes are always confirmed by the backend before the UI treats them as final.

​
Privy (authentication)

Privy provides authentication and session management. Its responsibilities are:
  • Signing users in via email, social, or wallet flows
  • Issuing a stable Privy user ID that Fundwork uses as the canonical user identifier
  • Managing the authenticated session
  • Coordinating linking of a Base Account to the Privy identity
Fundwork does not use wallet addresses as the canonical application user identity. The authenticated Privy user ID is the internal user record. Base addresses are linked payment identities associated with that user.

​
Base Account (smart wallet)

Base Account is a smart-wallet-backed account that gives users an onchain identity and transaction capability without requiring them to manage seed phrases or hold ETH directly. In the Fundwork architecture it is responsible for:
  • Providing a Base-compatible address for receiving USDC
  • Signing transactions users authorize inside Fundwork flows
  • Serving as the linkage point for gas sponsorship in the planned architecture
See Accounts & Authentication for a detailed discussion of the account model.

​
Backend

The Fundwork backend is the authoritative service. It owns:
  • Profile and marketplace state
  • Authorization checks for every mutating action
  • Opportunity, application, and submission state machines
  • Milestone state
  • Payment verification against the Base network
  • Audit records for security-relevant events
The backend is the only layer that can mark a payment as confirmed, an opportunity as funded, or a submission as approved.

​
Database

The database stores durable application state, including:
  • Profiles
  • Organizations
  • Opportunities
  • Applications
  • Submissions
  • Milestones
  • Messages
  • Payment records
Access to the database is mediated by the backend. Row-level authorization checks are used to restrict access to records the requesting user is entitled to see or modify.

​
Base network

Base is the Ethereum L2 that Fundwork settles on. It provides:
  • The settlement network for USDC transactions
  • Smart-wallet infrastructure via Base Account
  • The environment where future onchain escrow contracts will run
See Why Base for background on the network choice.

​
USDC settlement layer

USDC on Base is the unit of account for all marketplace payments. Payments move as ERC-20 transfers. The backend verifies each transfer against Base before treating a payment as complete. See Payment Architecture for the full verification model.

​
Identity Model

Fundwork separates three notions of identity that are often conflated: A single Privy user may be linked to a Base Account, which in turn may have a human-readable name. Only the Privy user ID is used to gate access to Fundwork records.

​
Request Flow Example

A client approving a milestone illustrates how the layers interact:
1

Client action in the frontend

The client presses Approve on a submission. The frontend sends the approval request with the authenticated Privy session.
2

Authorization in the backend

The backend confirms the Privy user is the client on the opportunity, that the submission is in an approvable state, and that no conflicting action has already been recorded.
3

Payment authorization

The backend prepares the payment. In the current alpha this is a direct USDC transfer. In the planned escrow architecture, this is a release from an escrow contract.
4

Onchain settlement

The USDC transfer is submitted to Base. Base processes the transaction and returns a transaction hash.
5

Verification and state update

The backend independently verifies the transaction on Base (existence, success, network, asset, amount, sender, recipient, and that the transaction has not already been consumed) before updating the opportunity or milestone state to Paid.

​
What This Architecture Is Not

To avoid confusion, a few explicit non-claims about the current alpha:
  • Fundwork does not use wallet signatures as the primary application login mechanism.
  • Fundwork does not treat frontend success as evidence that a payment occurred.
  • Fundwork does not custody user funds in a shared platform wallet.
  • Fundwork has not deployed production escrow contracts.
  • Fundwork has not deployed a production paymaster of its own.
Where related capabilities are planned, they are described on the pages linked below.

​
Where to Read Next

Accounts & Authentication

Privy identity, Base Account, and the ERC-4337 account abstraction model.

Payment Architecture

How USDC settlement is prepared, submitted, and verified.

Escrow Design

The planned escrow state machine and design principles.

Security

Current security practices and planned pre-launch work.