Abstract
Gas sponsorship began as a user-experience patch: hide gas from the user so a transaction can complete. This publication argues that once an application takes sponsorship seriously, the paymaster stops being a UX detail and becomes a control surface — one that most providers keep for themselves. Trustware's paymaster system inverts that model. Applications deploy, fund, control, and operate their own paymaster contracts, with policy and accounting exposed through the Trustware dashboard, and with funds Trustware cannot move.
The control problem with provider-managed sponsorship
In the common model, an application deposits funds into a provider-managed balance and the provider decides how sponsorship is executed. The application answers the questions that matter — when do we sponsor, what do we sponsor, how much, how do we track it — but the provider holds the funds and owns the contract behind the experience. That hands a critical part of the transaction path to a third party.
Trustware's position is the opposite: the teams closest to the user should control the systems that move, settle, and sponsor value on their behalf. Clients do not build their own paymaster contracts, policy engine, dashboard, activity tracking, or gas accounting from scratch — Trustware productizes all of it — but ownership of the contract and sole control of the sponsorship funds stay with the client.
Smart accounts without changing the user's EOA
Under ERC-4337, gas sponsorship applies only to UserOperations, and those originate from smart accounts. EOA transactions never touch the EntryPoint. EIP-7702 offers one path around this by letting an EOA delegate to account code. Trustware took a different path: it deploys deterministic light smart accounts for wallets that interact with the paymaster.
These accounts are execution-only. The user's EOA stays primary and remains the signer, and Trustware never controls the smart account. The user signs a Permit2 authorization with their EOA key, which lets the smart account pull the token from the EOA; the account then executes the route with the paymaster covering the gas. The user holds their funds the entire time and, after the one-time Permit2 authorization, signs once per route.
Sponsorship as policy, not as a black box
Sponsorship is tied to API keys, projects, senders, costs, and usage limits. Applications control their own budgets and rules, and paymasters are deployed and run per chain and per project, so a single application can operate multiple projects in production. Users complete supported actions without holding a separate native gas token: gas is sponsored, or drawn from the asset they are already moving.
Integrated with the Route Handler
The paymaster was built to plug directly into Trustware's Route Handler. Route providers share no common standard, so the Route Handler normalizes their endpoints, runs one user intent across several providers at once, and takes the best route returned. Because the paymaster sits behind that layer, it works with any route the Route Handler produces, from any provider or solver network. The client defines the destination state, the user brings what they have, and Trustware handles routing, settlement, and sponsored completion between those two points without ever taking custody.
Security and control posture
- Sponsorship funds under the client's sole control
- Full owner-gated funding, withdrawal, and upgrades
- Policy and dashboard controls built for application teams
- All of it integrated into a broader routing and settlement layer
The market has seen the pieces before — paymaster contracts, gas sponsorship, account abstraction, dashboard-managed policies. What has not been productized is the full system: a client-owned, non-custodial paymaster that applications can deploy, fund, control, and operate directly.
The broader Trustware thesis
Trustware is building the Universal Deposit Layer for onchain and offchain applications. Any application should be able to accept any value from users across assets, chains, and wallets, then receive the destination state they need without rebuilding routing, settlement, gas sponsorship, and reconciliation themselves.
The status quo for accepting value onchain is the deposit address: the application hands the user an address and waits. That assumes the user already holds the right asset on the right chain and the native gas to send it. When they have the asset but not the gas, the deposit stalls at the exact moment the application is trying to onboard someone. A route is not enough if the user stalls before they can submit it.
Crypto has long been split between trustless and touchless. Exchanges are touchless but custodial; self-custody is trustless but makes the user touch everything. The paymaster is the proof that applications do not have to choose: sponsored, abstracted gas on a contract the application owns, with funds Trustware cannot move. Touchless on the surface, trustless underneath.
This document is provided for informational purposes only and describes the Trustware paymaster system as of August 2026. It is not financial, legal, investment, or technical advice. Some capabilities described are in development or rolling out and may change, and nothing here guarantees future availability or performance.
Visit docs.trustware.io for more on the Trustware API and SDK.