Skip to main content
Fundwork combines two account concepts: an application identity managed by Privy and an onchain identity provided by Base Account. Together they give users a familiar sign-in experience and a smart-wallet-backed address for USDC settlement.
Fundwork is in alpha. This page describes the account model as implemented today and, where noted, the gas sponsorship and account abstraction work planned before public launch.

​
Two Layers of Identity

​
Privy user identity

When a user signs into Fundwork, Privy issues a stable user identifier and manages the authenticated session. Fundwork stores the Privy user ID as the canonical application identity. All profile records, opportunities, applications, and submissions are keyed to this identifier internally. This separation matters because it lets Fundwork:
  • Support multiple sign-in methods without changing the internal user record.
  • Allow a user to link, unlink, or rotate a Base Account without losing their history.
  • Avoid conflating “who is signed in” with “which address should receive payment”.

​
Base Account (smart wallet)

Base Account is a smart-wallet-backed account built on Base. It provides:
  • A Base-compatible address for sending and receiving USDC
  • Onchain transaction capability without seed-phrase management
  • A foundation for gas sponsorship in the planned architecture
Base Account is a smart contract account rather than an externally owned account (EOA). This is the same design pattern described by ERC-4337 account abstraction: the account is a contract that authorizes actions through logic rather than a single private key controlling an EOA.
“Smart wallet” and “smart contract account” refer to the same idea in this documentation: an onchain account whose behavior is defined by contract logic.

​
Traditional Wallet Flow vs. Fundwork Target UX

A traditional EOA-based wallet flow looks like this:
This works, but it forces every user to acquire ETH before doing anything and to reason about gas as part of every action. The target UX Fundwork is designing toward looks like this:
The explicit design goal is to make blockchain infrastructure largely invisible to normal users, so that a person hiring or being paid on Fundwork does not need to think about ETH, gas markets, or wallet mechanics unless they choose to.

​
ERC-4337 Concepts, at a High Level

Account abstraction under ERC-4337 introduces a few concepts that show up in Fundwork’s planned architecture. This is a conceptual summary rather than a specification.

​
Smart accounts

A smart account is a contract that acts as the user’s account. It defines its own rules for who can act on its behalf, how transactions are validated, and what recovery or session behavior is supported. Because the account is a contract, it can support features an EOA cannot, such as batching, session keys, and sponsored gas.

​
UserOperations

Instead of submitting a raw transaction, a smart account submits a UserOperation. This is a structured object describing the intended action, the account that authorizes it, and how gas should be paid. UserOperations flow through a dedicated mempool and are executed by an entry-point contract.

​
Paymasters

A paymaster is a contract that can agree to pay the gas for a UserOperation. This is the mechanism that makes sponsored transactions possible. When a paymaster signs off on a UserOperation, the user does not need to hold ETH to cover gas for that action. See Gasless Transactions for how Fundwork plans to use paymasters in practice.

​
Batched transactions

Because a smart account executes UserOperations rather than single opcodes, it can batch multiple actions into one authorization. This is useful for flows such as “approve token, then call contract” that would otherwise require two separate signatures on an EOA.

​
Sessions and authorization

Smart accounts can support scoped authorizations: for example, allowing a specific application to submit a bounded set of actions for a limited time. Fundwork is evaluating how session-style authorization can reduce prompt fatigue without weakening user control, but no specific session model is currently deployed.

​
Status

Currently available

Privy authentication and session management. Base Account linking as the user’s payment address. .base.eth name display on profiles and receipts.

Planned before public launch

Gas sponsorship for eligible Fundwork actions through a Base-compatible paymaster provider. Documented allowlists and per-user limits.

Under evaluation

Session-scoped authorizations, batched transactions for multi-step flows, and richer onchain identity linking.

Future

Agent-owned smart accounts participating in marketplace flows. See Agentic Transactions.
Fundwork has not deployed custom ERC-4337 infrastructure. The account abstraction capabilities described here rely on Base Account and, in the planned architecture, a Base-compatible paymaster provider.