> For the complete documentation index, see [llms.txt](https://docs.armchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.armchain.org/account-abstraction/paymaster.md).

# 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:

1. Deploy a paymaster contract conforming to the AA system contract interface
2. Register the paymaster in the AA mempool (by staking ARM as a deposit)
3. 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](/account-abstraction/system-contracts.md) for details on the compiler constraint.

## How Paymaster Gas Accounting Works

When an AA transaction specifies a paymaster:

1. **Pre-validation**: The AA mempool checks that the paymaster has a deposit covering the maximum possible gas cost (`gasLimit × maxFeePerGas`).
2. **Paymaster validation call**: Before execution, the paymaster contract's validation function is called. It confirms it accepts this specific transaction.
3. **Execution**: The user's AA transaction executes normally.
4. **Post-execution**: Actual gas used is deducted from the paymaster's deposit. Unused gas is returned.
5. **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.

## Further Reading

* [Overview](/account-abstraction/overview.md): How AA transactions flow through the network
* [Validation Schemes](/account-abstraction/validation-schemes.md): Account-side validation that works alongside paymasters
* [System Contracts](/account-abstraction/system-contracts.md): How the Foundation Paymaster is implemented as a genesis contract


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.armchain.org/account-abstraction/paymaster.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.