Polygon apps can sponsor gas for user-signed actions through relayers

Native and ERC-2771 meta-transactions need compatible contracts

A native or ERC-2771 meta-transaction needs a funded relayer and compatible contracts, even when the wallet connects successfully.

Polygon’s native meta-transaction pattern uses executeMetaTransaction for signature verification inside the target contract. An ERC-2771 integration uses a trusted forwarder to verify authorization before calling the target. The receiving contract recognizes the original signer through that forwarding arrangement. These approaches require different request formats and entry points. The app must prepare the message its deployed verifier accepts, including the exact action and destination.

For ERC-2771 calls, the target’s immediate caller is the forwarder. Its permission checks need the original signer’s identity through sender-aware logic such as _msgSender(). Polygon PoS supports Ethereum Virtual Machine (EVM) contracts, but EVM compatibility does not automatically add this logic. Eligible uses include contract-supported voting and non-fungible token (NFT) minting, where the app offers sponsorship.

Who pays for a gasless Polygon action?

The relayer pays the network fee for a sponsored meta-transaction, while the app decides how to fund that payment. An app may operate its own relayer or fund a service handling submissions. Gasless describes the user’s experience of that eligible action: the network still charges for execution. A sponsorship offer can cover selected contract functions without covering every action available in the app. Any reimbursement or charge to the user belongs to the particular funding arrangement.

Network gas, application charges, and native-token value sent with a contract call are separate costs. Covering gas does not automatically fund a purchase or provide the tokens an action uses. Spending permissions also remain necessary wherever the token operation requires them.

Typed signatures can bind authorization to a particular deployment

EIP-712 gives a signed message a structured format and a signing domain, allowing authorization to refer to a particular contract deployment. Domain fields can include the chain identifier, verifying contract, name, and version. Their actual selection depends on the implementation. With the OpenZeppelin forwarder discussed below, the verifying contract is the forwarder itself. It has a different address from the application contract receiving the forwarded call.

EIP-712 does not provide replay protection by itself. The verifier needs a nonce or another application-level rule governing repeated messages. The signed function and arguments define the action the user authorizes. Signing happens offchain and incurs no network gas, yet that signature can authorize later asset movement. Reviewing the intended call therefore remains necessary even when a wallet displays no immediate gas charge.

Forwarder request fields define the authorized call

OpenZeppelin Contracts 5.4.0 provides a concrete format through ERC2771Forwarder. Its signed requests include the following fields alongside a signer-specific nonce. The value-matching rule here describes its single-request execute method; other forwarder implementations can use different formats and validation rules.

Open full-size image

The forwarder reads its nonce for the signer and includes it in the signed message. This is separate from the gas-paying account’s transaction nonce. In this implementation, the submitted request structure omits a separate nonce field because verification reads it from contract state. A changed nonce makes a signature built for the previous nonce invalid.

Token permits authorize spending, while paymasters can fund gas

A token permit authorizes spending, while a paymaster can fund execution through account abstraction. ERC-2612 lets a compatible token accept a signed allowance approval. The owner authorizes a spender and an allowance amount, which the token records when the permit executes. That permit alone does not perform a transfer or purchase. An application needs the token’s actual permit support and a compatible spending operation.

ERC-4337 uses a different architecture available for compatible account-abstraction setups on Polygon PoS. The account authorizes a UserOperation, and a bundler submits it through an EntryPoint contract. An optional paymaster can cover its gas using a deposit at that contract, subject to the paymaster’s validation policy. Without a paymaster, gas funding comes from the account’s deposit at the EntryPoint. A bundler packages operations, while the paymaster supplies the sponsorship decision and funding.

A supported account can call a target as the account itself, without requiring the target to recognize an ERC-2771 forwarder. Compatibility depends on the supported account and its integration, with authorization and an operation format distinct from a native meta-transaction or forwarded-call request.

Sponsorship limits and forwarder trust govern access

Applications can restrict sponsored requests to particular contracts and functions, or impose spending limits. A valid signature establishes authorization, not an entitlement to the app’s gas budget.

A relay service chooses which requests it broadcasts. Its funding, availability, and eligibility rules can prevent submission before any transaction reaches the chain. Changing a wallet’s RPC endpoint cannot supply a sponsor’s budget or make an incompatible target accept forwarded calls. A direct paid call is an alternative only where the contract supports it.

The trusted forwarder carries a separate security responsibility: the target relies on its verification when recognizing the original signer. A malicious trusted forwarder can forge that identity. Where the forwarder is upgradeable, this trust also includes the authority controlling its upgrades. Where the receiving contract allows changes to its trusted-forwarder configuration, access to those changes needs protection. These controls protect authorization independently of the relayer’s willingness to pay gas.

Open full-size image

For the forwarder described above, an expired deadline or changed nonce requires fresh authorization. Resubmitting an unchanged signed payload cannot restore its validity. If the target does not trust this forwarder, that method remains blocked until the trust configuration or chosen integration changes.

How do you confirm a relayed action succeeded?

Confirm a relayed action with the transaction receipt and the requested action’s outcome in contract state or relevant events. A relay service’s request identifier tracks its job. A transaction hash identifies a transaction; it does not establish block inclusion or successful execution.

Open full-size image

For ordinary EVM transactions, receipt status 1 means the top-level transaction succeeded, and 0 means it failed. Some batch modes permit individual calls to fail while the outer transaction succeeds. Request-level results and the target’s actual effects establish what each action accomplished. A missing receipt leaves inclusion and execution unconfirmed.

With the single-request execute method described above, a reverted target call reverts the enclosing transaction and leaves the forwarder’s nonce unconsumed. The gas payer still covers computation the chain performed. Sponsorship for another attempt remains an application decision.