Paymaster

A paymaster is a contract that pays the gas cost for another account's AA transaction. Paymasters make it possible for users to interact with Armchain without holding ARM, and allow dApp developers and service providers to offer sponsored transactions to their users.

Armchain ships a Foundation Paymaster as a system contract deployed at genesis. Any other entity can also deploy and operate their own paymaster.

Foundation Paymaster

The Foundation Paymaster is a protocol-level contract funded with ARM tokens. Its primary role is to sponsor contract deployments for new users who do not yet have ARM in their accounts.

This solves the bootstrapping problem: a new user who wants to deploy a smart account or interact with an AA contract for the first time needs gas. The Foundation Paymaster covers that initial gas cost, letting users get started without acquiring ARM first.

What the Foundation Paymaster Covers

Smart account (AA wallet) deployments for new users
Initial contract interactions where the account balance is zero or insufficient
Deployments routed through the Factory Registry system contract

The Foundation Paymaster is not intended to sponsor arbitrary transactions indefinitely. It covers the onboarding moment: once an account is deployed and operational, users are expected to hold ARM for ongoing transaction fees.

Staking and Economic Policy

To prevent abuse and DDoS attacks against the paymaster system, all paymasters, including the Foundation Paymaster, operate under a staking-based economic policy embedded in the AA mempool rules.

The core principle is that paymasters must put economic value at risk to participate. A paymaster that sponsors invalid or malicious transactions loses stake. This creates a direct cost for bad actors trying to exploit sponsored transactions to flood the network.

The policy is enforced at the mempool layer, not the contract layer, so it applies to all incoming AA transactions before they consume node resources:

┌──────────────────────────────────────────────────────┐
│                   AA Mempool Rules                    │
├──────────────────────────────────────────────────────┤
│  1. Paymaster must have a stake deposit > minimum     │
│  2. Paymaster deposit must cover the gas limit        │
│  3. Transactions from penalized paymasters rejected   │
│  4. Stake slashed for verified malicious behavior     │
└──────────────────────────────────────────────────────┘

This design mirrors economic incentive structures from established paymaster ecosystems (such as those on Ethereum), adapted to Armchain's native AA architecture and ARM staking model.

Third-Party Paymasters

Any entity can operate a paymaster on Armchain. Common paymaster models from the Ethereum ecosystem apply:

Paymaster Model

Description

Free sponsorship

Covers all fees for users of a specific dApp

Token paymaster

Users pay in an ERC-20 token; paymaster converts to ARM

Subscription paymaster

Users pay off-chain (monthly plan); paymaster covers on-chain gas

Allowlist paymaster

Sponsors only transactions for whitelisted accounts or contracts

Infrastructure providers, wallet teams, and dApp developers can deploy their own paymasters to give users a seamless experience. To operate a paymaster, an entity must:

Deploy a paymaster contract conforming to the AA system contract interface
Register the paymaster in the AA mempool (by staking ARM as a deposit)
Maintain a sufficient ARM deposit to cover sponsored transactions

Note: Paymaster contracts that interact with AA-specific opcodes must be written in Yul. See System Contracts for details on the compiler constraint.

How Paymaster Gas Accounting Works

When an AA transaction specifies a paymaster:

Pre-validation: The AA mempool checks that the paymaster has a deposit covering the maximum possible gas cost (gasLimit × maxFeePerGas).
Paymaster validation call: Before execution, the paymaster contract's validation function is called. It confirms it accepts this specific transaction.
Execution: The user's AA transaction executes normally.
Post-execution: Actual gas used is deducted from the paymaster's deposit. Unused gas is returned.
Deposit replenishment: Paymaster operators must top up their deposits periodically to keep the paymaster active.

If a paymaster's deposit runs out mid-operation, transactions specifying that paymaster are rejected at the mempool level until the deposit is replenished.

Deposit vs. Stake

The paymaster system distinguishes between two types of ARM holdings:

Type

Purpose

Lock-up

Deposit

Covers gas costs for sponsored transactions

Withdrawable after a delay

Stake

DDoS deterrence, slashable on bad behavior

Longer lock-up, slashable

All paymasters must maintain both a deposit (sufficient to cover expected gas) and a stake (as a security bond). The stake is at risk if the paymaster is found to behave maliciously, such as approving transactions it later fails to cover, or participating in transaction spam.

Good night