> ## Documentation Index > Fetch the complete documentation index at: https://docs.fundwork.app/llms.txt > Use this file to discover all available pages before exploring further. # Gasless Transactions and Paymaster Design > How Fundwork plans to sponsor eligible Base transactions so users don't need to acquire ETH to interact with normal marketplace flows. Fundwork intends to sponsor eligible Base transactions before public launch, where doing so meaningfully improves the user experience. The goal is that a normal user should not need to acquire ETH simply to interact with core Fundwork flows. 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 Fundwork does not promise that every transaction will always be gasless. Sponsorship is policy-controlled, subject to limits, and may be adjusted based on cost, abuse patterns, and product needs. ## How Sponsorship Will Work At a conceptual level, the flow is: The user approves a Fundwork flow such as a milestone approval or an escrow initialization. The backend prepares a UserOperation representing the intended onchain action, targeting the specific contract and function required. Fundwork's paymaster policy decides whether to sponsor gas for this UserOperation based on the action type, contract, function, user history, and rate limits. If sponsorship is granted, a Base-compatible paymaster provider signs the UserOperation to cover gas. 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](/technical/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 Base Account integration and USDC settlement on Base. Users may pay gas directly today for onchain actions they initiate outside the sponsorship path. Paymaster integration with a Base-compatible provider, allowlist policy, per-user and per-transaction limits, rate limiting, and monitoring. Session-scoped sponsorship for multi-step flows and sponsorship for specific integrations. Broader sponsorship coverage as costs and abuse patterns are understood at scale.