> For the complete documentation index, see [llms.txt](https://mau-eth.gitbook.io/mau/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mau-eth.gitbook.io/mau/account-abstraction/required-entry-point-contract-functionality/paymaster-extension.md).

# Paymaster extension

**Extended Logic for Transaction Sponsorship**

The entry point's capabilities are expanded to cater to 'paymasters'. Paymasters are entities that can cover transaction fees on behalf of others. This is especially handy for:

* **Developers Subsidizing Fees**: Application creators can cover the fees to enhance user experience.
* **Paying Fees with ERC-20 Tokens**: Users can offset transaction fees using different types of tokens.
* **Other Uses**: This feature opens up various transaction fee-related possibilities.

If the paymaster isn't just a placeholder (not a zero address), the entry point follows a special procedure to manage these sponsored transactions.

<figure><img src="/files/zEVOGn6K4287bQzz2BiY" alt=""><figcaption></figcaption></figure>

**Enhanced Verification for Paymaster-Sponsored Transactions**

In the verification loop, the `handleOps` execution takes on some extra tasks when dealing with paymaster-sponsored transactions:

1. **Initial Verification**: Besides just calling `validateUserOp`, it checks if the paymaster has enough ETH deposited at the entry point to cover the transaction.
2. **Paymaster's Approval**: The `handleOps` execution calls `validatePaymasterUserOp` on the paymaster. This ensures the paymaster agrees to bear the operation's costs. Notably, the `validateUserOp` is now invoked with a `missingAccountFunds` set to 0, showing the account's deposit isn't used for this particular transaction.
3. **Context Handling**: If the paymaster's `validatePaymasterUserOp` sends back a “context”, then after the main execution call, `handleOps` needs to invoke `postOp` on the paymaster. For guaranteed execution of `postOp`, the main execution is run in an inner call context. If this inner context is reverted, `handleOps` tries again using an outer call context.
4. **Security Against Malicious Paymasters**: There are concerns about paymasters intentionally disrupting the system. To handle this, a reputation mechanism is in place. Any paymaster must either:

   * Keep their storage usage in check, or
   * Maintain a certain stake.

   Further details can be found in the section about reputation, throttling, and banning.