How it works

You already know how to read a normal C-Chain transaction: an EOA signs it, pays gas, and calls a contract. An EntryPoint transaction looks like that from the outside. Inside, it is a container: someone else's signed instructions, executed by someone else's smart account, paid for by possibly a third party. This primer explains what the container is for, who the parties are, how the money moves, and how to attribute what you see without over-claiming.

Every example is a real C-Chain address or transaction, mostly from UTC day 2026-10-18, the day measured in the earlier research. Each cited tx hash was looked up by hash in the transaction database while writing this.

Companion docs: Reading a transaction (one transaction, byte by byte), Versions (v0.6 / v0.7 / v0.8 / v0.9), Glossary.

1. Why the EntryPoint exists

What a plain EOA cannot do

An EOA is one secp256k1 key with a balance and a nonce. The protocol hard-codes its rules:

A smart contract wallet can do all of that, because its rules are code. Before ERC-4337, though, a contract cannot start a transaction. Someone's EOA still had to send it and pay, and every wallet vendor built its own relayer.

How ERC-4337 fixed it without changing the chain

ERC-4337 ("Account Abstraction Using Alt Mempool") adds no new transaction type or consensus rule. Its abstract: users send a pseudo-transaction called a UserOperation "into a separate mempool". Bundlers package these into one ordinary transaction calling handleOps on "a special contract", the EntryPoint.

So the design has exactly two shared pieces:

1. An alternative mempool of UserOperations, off chain. Bundlers gossip and simulate them. (You never see it on chain. You only see the bundles that made it in.)
2. One singleton EntryPoint contract per version per chain, which every account, paymaster and bundler trusts. It validates each operation, makes sure someone has paid for it, executes it, and settles the gas.

Because it is "just a contract", the same addresses exist on every EVM chain, including C-Chain. Four versions are deployed here:

The one-sentence model: An EntryPoint transaction is a bundler saying "here are N signed requests from N smart accounts; EntryPoint, please check each one is authorized and paid for, run it, and reimburse me."

2. The cast

Each role below has one real C-Chain example. Most come from the transaction walked through in detail in Reading a transaction: 0xddda920f2fd5092c727088b9916f632bd61628bfa118c6ddd5a2356827214ffe, which deploys a smart account and deposits 64.96 USDC into Relay.

Paymasters: verifying mode vs ERC-20 mode

Pimlico's singleton paymasters run in two modes, which the first data byte selects:

• Verifying mode (0): Pimlico's server signs "I'll sponsor this op until time T". The chain charges Pimlico's deposit and nothing else. Who pays Pimlico (the app, via a subscription or invoice) is off chain. Example: the walk-through tx above.
• ERC-20 mode (1): the paymaster pays the AVAX, then in postOp pulls tokens from the account. Example: 0x0c9f5c6d48bbbf7261d1464920524feab7235362817dd6620e9602a93e225dd4 explained → (v0.6). Its UserOperationSponsored event reports mode 1, token USDt 0x9702230a8ea53601f5cd2dc00fdbc13d4df4a8c7 evidence level: primary source, 13,386 base units (0.013386 USDt). The matching token Transfer goes to a configured settlement recipient, not the paymaster address (all-versions report).

On Oct 18, Pimlico emitted 735 UserOperationSponsored records: 734 verifying, 1 ERC-20. Other paymasters seen that day include 0x25ff7720cff5e7c479cad2a8b48f99561f7c8df9 evidence level: hint (175 ops, the signed-result workload), 0x5fa66dfe8a3983e55071e8c4631ab43b5f33a4ab evidence level: hint (169), 0x3f383d232344e297c1d98ea4b59217ae338b6223 evidence level: cluster (117) and 0xca944fb73fa5191969014ded9bb075381d59c7de evidence level: primary source (v0.9). Their modes and operators are not established here.

3. The lifecycle of one handleOps

handleOps(ops[], beneficiary) runs two loops. All validation finishes before any execution starts. That ordering protects the bundler: an op that can't pay is rejected before anything runs.

Validation loop, for each op (v0.7 _validatePrepayment; see source links in Versions):

1. Deploy if needed. If initCode is non-empty, call the factory (through a helper, SenderCreator) and check it created exactly sender. Emit AccountDeployed(userOpHash, sender, factory, paymaster).
2. Compute the max cost = (all gas limits + preVerificationGas) × maxFeePerGas.
3. account.validateUserOp(op, userOpHash, missingFunds). The account checks the signature (any scheme it likes). If there is no paymaster, it tops up its EntryPoint deposit with missingFunds. In that no-paymaster case, the EntryPoint then debits the max cost from the account's deposit.
4. Check the nonce (192-bit key + 64-bit sequence).
5. If there is a paymaster: debit the max cost from the paymaster's deposit, then call paymaster.validatePaymasterUserOp(op, userOpHash, maxCost). It may return a context for postOp.
6. Check validity time windows. Any failure here reverts the whole bundle with an AAxx code.

Then emit BeforeExecution(), the boundary.

Execution loop, for each op:

7. Call the account with callData (e.g. execute(...), which then calls the target apps). A failure here does not revert the bundle. The op is marked failed and still pays.
8. postOp, if the paymaster returned context (e.g. an ERC-20 paymaster pulls tokens now).
9. Compute actualGasCost, refund the unused prefund to whoever paid (paymaster or account deposit), and emit UserOperationEvent(userOpHash, sender, paymaster, nonce, success, actualGasCost, actualGasUsed).

Finally, compensate: send the sum of all actualGasCost to beneficiary in AVAX (_compensate, a plain value transfer with no event).

This diagram is wider than the screen: scroll sideways inside its frame.

sequenceDiagram
    autonumber
    participant B as Bundler EOA<br/>(tx.from)
    participant EP as EntryPoint
    participant F as Factory
    participant A as Smart account<br/>(sender)
    participant P as Paymaster
    participant T as Target app(s)
    participant Ben as Beneficiary

    B->>EP: handleOps([op...],<br/>beneficiary)<br/>(bundler pays<br/>native gas)
    Note over EP: ── validation loop<br/>(per op) ──
    opt initCode non-empty
        EP->>F: create account (via<br/>SenderCreator)
        F-->>A: deploy (CREATE2)
        EP-->>EP: emit<br/>AccountDeployed
    end
    EP->>A: validateUserOp(op,<br/>userOpHash,<br/>missingFunds)
    A-->>EP: validationData (+<br/>deposit top-up if<br/>self-paying)
    opt paymaster set
        EP-->>EP: debit paymaster<br/>deposit (max cost)
        EP->>P: validatePaymasterUserOp(op,<br/>userOpHash,<br/>maxCost)
        P-->>EP: context,<br/>validationData
    end
    EP-->>EP: emit<br/>BeforeExecution
    Note over EP: ── execution loop<br/>(per op) ──
    EP->>A: callData (e.g.<br/>execute /<br/>executeBatch)
    A->>T: approve / swap /<br/>transfer / ...
    T-->>A: app logs (Transfer,<br/>Deposit, ...)
    opt paymaster returned context
        EP->>P: postOp(mode,<br/>context,<br/>actualGasCost,<br/>gasPrice)
    end
    EP-->>EP: refund unused<br/>prefund to deposit,<br/>emit<br/>UserOperationEvent
    EP->>Ben: send Σ<br/>actualGasCost<br/>(AVAX, no event)

Seeing the lifecycle in logs

The walk-through transaction shows the phases directly. Its logs, in order: account init (RootValidatorUpdated, OwnerRegistered) → AccountDeployed → Pimlico UserOperationSponsored → BeforeExecution → USDC Approval, USDC Transfer, Relay RelayErc20Deposit, USDC Approval(0) → UserOperationEvent. Everything before BeforeExecution is validation. Everything between BeforeExecution and an op's UserOperationEvent is that op's execution. With several ops, each op's window starts after the previous op's UserOperationEvent. Example with two ops in one outer: 0xfff9a920901823e8f6f2cca4ac9daf7d386cc95027af190cb9603c8ffef0475f explained → (v0.6, two collateral withdrawals from two different accounts).

Inner failure, outer success

The outer receipt can succeed while an op fails. 0x77b4647ea6918be8a39ac32c88745ffb7a817c241db0fe974a7035c61c6d1777 explained → (v0.7) has status 1, but its only UserOperationEvent says success = false. The account had requested a Circle CCTP depositForBurn on 0x28b5a0e9c621a5badaa536219b3a228c8168cf5d, and it didn't happen. The op still paid gas through its paymaster 0x03df76c8…103b evidence level: hint. It was the single failed op among Oct 18's 1,397. Never credit an op's requested action when success = false. Even when success = true, an account can catch a failing sub-call internally, so check the target's own logs.

4. Money flows

Two different fees exist in every EntryPoint transaction. Mixing them up is the most common analysis error.

Why the first two differ. The bundler picks its own gas price for the outer tx. The op pays at the price it signed for, plus a preVerificationGas allowance for overhead the EntryPoint can't meter. The difference is the bundler's margin, which can be negative. In the walk-through tx, the bundler paid 0.002152 AVAX and was paid 0.002347 AVAX, a gain of 0.000194 AVAX, because the op allowed a 1.02 gwei tip and the bundler tipped only 0.555 gwei.

Across all of Oct 18 (earlier report, same outers):

Beneficiary is not always the submitter (5 of 1,396 differ), so read this as an aggregate shape, not a per-bundler P&L. Rules from the handoff, in plain terms:

• Count each outer fee once. For day totals, sum gas_used × effective_gas_price per transaction. Don't add actualGasCost on top; that would count the same gas twice from two sides.
• Don't spread the fee over legs and sum. A 3-leg batch has one fee. If you report "fees by target", a transaction appears under several targets and those rows overlap. Say so.
• actualGasCost is not bundler profit. Profit = actualGasCost received − receipt fee paid, and only when beneficiary = bundler.

"Sponsored" doesn't mean "free to the user." A nonzero paymaster proves only that the paymaster's deposit paid the AVAX for this op. The user may have paid in tokens (ERC-20 mode: 0x0c9f5c6d… pulled 0.013386 USDt). The app may have paid a monthly bill. The "sponsor" may even be the user's own company. The chain shows the deposit debit and nothing about the business arrangement.