Gas sponsorship is planned for the public launch architecture and is not yet guaranteed for all alpha interactions. This page describes the intended design and the policy controls that will govern it.
Why Sponsor Gas
Requiring a user to hold ETH before they can do anything onchain is a real barrier. It forces new users through an exchange or bridge before they can set up an account, apply to work, or receive payment. For a paid-work marketplace, that friction directly reduces the pool of participants. Sponsoring gas for well-scoped Fundwork actions removes that step for the flows where it matters most, while leaving users free to hold and manage ETH themselves for anything outside the platform.What May Eventually Qualify for Sponsorship
The following categories are candidates for gas sponsorship. Actual eligibility will be defined by policy at launch, and any given transaction may or may not be sponsored based on that policy.- Account setup and Base Account linking
- Marketplace-related contract interactions (opportunity creation, applications)
- Escrow initialization once escrow contracts are live
- Milestone approval
- Submission-related transactions
- Other low-risk Fundwork protocol interactions
How Sponsorship Will Work
At a conceptual level, the flow is:1
User triggers a Fundwork action
The user approves a Fundwork flow such as a milestone approval or an escrow initialization.
2
Fundwork prepares a UserOperation
The backend prepares a UserOperation representing the intended onchain action, targeting the specific contract and function required.
3
Paymaster policy check
Fundwork’s paymaster policy decides whether to sponsor gas for this UserOperation based on the action type, contract, function, user history, and rate limits.
4
Paymaster signs
If sponsorship is granted, a Base-compatible paymaster provider signs the UserOperation to cover gas.
5
Execution on Base
The UserOperation is submitted and executed on Base. The user does not need to hold ETH for gas.
Policy Controls
Sponsorship is not open-ended. The intended design uses several layered controls.Contract and function allowlists
Only explicit combinations of contract address and function selector are eligible for sponsorship. This prevents a compromised or malicious frontend from spending Fundwork’s gas budget on arbitrary onchain calls.Per-user limits
Each user has a bounded sponsorship budget over a rolling window. This limits the blast radius of a single abused account and keeps costs predictable.Per-transaction limits
Individual UserOperations are subject to gas ceilings so that a single expensive operation cannot drain the sponsorship budget.Rate limiting
Requests to the sponsorship endpoint are rate-limited per user and per session to prevent scripted abuse.Abuse prevention and monitoring
Sponsorship activity is monitored for unusual patterns: sudden spikes, atypical destinations, and repeated failures. Suspected abuse can trigger automatic denial or manual review. See Security for the broader monitoring model.Where the Paymaster Lives
Fundwork intends to use a compliant Base-compatible paymaster provider rather than exposing unrestricted sponsorship. Two important implications follow from that choice.The paymaster endpoint is not a frontend credential
A paymaster endpoint with unrestricted sponsorship capability must never be embedded directly in the frontend as a public credential. Anyone with access to that credential could use it to sponsor arbitrary transactions. Instead, sponsorship requests are proxied or policy-controlled where appropriate. The frontend asks the Fundwork backend to sponsor an action; the backend applies policy and, if approved, obtains sponsorship from the paymaster provider on the user’s behalf.Policy lives close to Fundwork
The backend is the natural place to enforce allowlists, per-user limits, and abuse detection because it already has the authenticated user context and application state. The paymaster provider handles the mechanics of sponsoring UserOperations; Fundwork handles the policy of deciding when to sponsor.Status
Currently available
Base Account integration and USDC settlement on Base. Users may pay gas directly today for onchain actions they initiate outside the sponsorship path.
Planned before public launch
Paymaster integration with a Base-compatible provider, allowlist policy, per-user and per-transaction limits, rate limiting, and monitoring.
Under evaluation
Session-scoped sponsorship for multi-step flows and sponsorship for specific integrations.
Future
Broader sponsorship coverage as costs and abuse patterns are understood at scale.