Versions

Four EntryPoint singletons are deployed on C-Chain (chain 43114). They are separate contracts with separate deposits, nonces and event streams. An account or paymaster built for one version does not automatically work with another. When you read a transaction, the first question is always: which EntryPoint emitted the UserOperationEvent? Everything else (struct layout, hash formula, paymaster encoding) follows from that.

Sources used on this page:

• Release notes: v0.7.0, v0.8.0, v0.9.0.
• Source at release tags: v0.6.0 UserOperation.sol, v0.6.0 EntryPoint.sol, v0.7.0 PackedUserOperation.sol, v0.8.0 EntryPoint.sol, v0.8.0 Eip7702Support.sol, v0.9.0 UserOperationLib.sol.
• The standard: ERC-4337 (current text, which already describes the v0.9 features).
• Local: epi/constants.py, the earlier Oct 18 reports, and the parquet archive.

All four pages were fetched on 2026-10-19 and the statements below were checked against them.

What the archive shows, per version

Each small chart has its own y-scale: v0.7 is roughly a thousand times larger than v0.9. The numbers page has the combined chart and data tables.

1. Addresses and selectors

The v0.7, v0.8 and v0.9 addresses match the addresses printed in their release notes. The v0.6 address matches the earlier identity record.

Other selectors (computed in epi/constants.py SEL):

v0.7, v0.8 and v0.9 share a handleOps selector because the struct is the same. The selector alone cannot tell you the version; the to address (or, for wrapped calls, the address that emits UserOperationEvent) can.

Event topics are the same across all four versions (epi/constants.py TOPIC). For example, UserOperationEvent is 0x49628fd1…419f everywhere. Again, the emitter address tells you the version.

2. The struct: 11 fields (v0.6) vs 9 packed fields (v0.7+)

v0.6 UserOperation

address sender
uint256 nonce
bytes   initCode
bytes   callData
uint256 callGasLimit
uint256 verificationGasLimit
uint256 preVerificationGas
uint256 maxFeePerGas
uint256 maxPriorityFeePerGas
bytes   paymasterAndData      // paymaster address (20 bytes) + paymaster-specific data
bytes   signature

In v0.6 one verificationGasLimit covers both account validation and paymaster validation. The paymaster's postOp also runs under that limit. Because postOp could be called twice in v0.6, the required prefund with a paymaster is (callGasLimit + 3 × verificationGasLimit + preVerificationGas) × maxFeePerGas (v0.6 _getRequiredPrefund).

v0.7+ PackedUserOperation

address sender
uint256 nonce
bytes   initCode
bytes   callData
bytes32 accountGasLimits      // verificationGasLimit (high 16 bytes) | callGasLimit (low 16 bytes)
uint256 preVerificationGas
bytes32 gasFees               // maxPriorityFeePerGas (high 16 bytes) | maxFeePerGas (low 16 bytes)
bytes   paymasterAndData
bytes   signature

The v0.7 release notes explain the change: the off-chain UserOperation (what wallets send to bundlers) and the on-chain struct became separate. Four gas numbers were packed into two bytes32 words to save calldata. The paymaster got its own two gas limits, stored inside paymasterAndData.

paymasterAndData layout

The offsets 20/36/52 are the constants PAYMASTER_VALIDATION_GAS_OFFSET, PAYMASTER_POSTOP_GAS_OFFSET and PAYMASTER_DATA_OFFSET in UserOperationLib.sol. The v0.9 magic is PAYMASTER_SIG_MAGIC = 0x22e325a297439656, the first 8 bytes of keccak("PaymasterSignature"). (I recomputed this locally and it matches.)

What sits after the paymaster address or the gas limits is defined by each paymaster, not by the EntryPoint. Pimlico's singleton paymaster is an example. Its source is kept as a snapshot. Its data starts with one byte, mode << 1 | allowAllBundlers, where mode 0 is verifying and mode 1 is ERC-20. In verifying mode, that byte is followed by validUntil (6 bytes), validAfter (6 bytes) and a signature. So a Pimlico v0.6 verifying-mode paymasterAndData is 20 + 1 + 12 + 65 = 98 bytes, and the v0.7 one is 52 + 1 + 12 + 65 = 130 bytes. Both lengths appear in the Oct 18 data.

3. The userOpHash formula

The userOpHash is the operation's identity. It is topic1 of UserOperationEvent and AccountDeployed, and it is usually what the account signs. Use the wrong formula and nothing matches.

v0.6 (EntryPoint.getUserOpHash, UserOperationLib.pack):

inner = keccak(abi.encode(sender, nonce, keccak(initCode), keccak(callData),
                          callGasLimit, verificationGasLimit, preVerificationGas,
                          maxFeePerGas, maxPriorityFeePerGas, keccak(paymasterAndData)))
userOpHash = keccak(abi.encode(inner, entryPoint, chainId))

v0.7: same shape, with the packed fields:

inner = keccak(abi.encode(sender, nonce, keccak(initCode), keccak(callData),
                          accountGasLimits, preVerificationGas, gasFees, keccak(paymasterAndData)))
userOpHash = keccak(abi.encode(inner, entryPoint, chainId))

v0.8 and v0.9: EIP-712 typed data with domain name="ERC4337", version="1", chainId, verifyingContract=EntryPoint:

PACKED_USEROP_TYPEHASH = keccak("PackedUserOperation(address sender,uint256 nonce,bytes initCode,bytes callData,bytes32 accountGasLimits,uint256 preVerificationGas,bytes32 gasFees,bytes paymasterAndData)")
structHash = keccak(abi.encode(TYPEHASH, sender, nonce, keccak(initCode*), keccak(callData),
                               accountGasLimits, preVerificationGas, gasFees, keccak(paymasterAndData**)))
userOpHash = keccak(0x1901 ‖ domainSeparator ‖ structHash)

• * If initCode starts with the EIP-7702 marker, the initCode hash is replaced by keccak(delegate ‖ initCode[20:]), where delegate is read from the sender's code (v0.8 Eip7702Support._getEip7702InitCodeHashOverride).
• ** In v0.9 only, if paymasterAndData ends with the magic suffix, the paymaster signature and its 10-byte suffix are excluded from the hash. The 8-byte magic itself is kept. So the user's signature does not cover the paymaster's signature, and the two can sign in parallel (v0.9 release note §2; getPaymasterSignatureLength / paymasterDataKeccak).

The v0.8 domain constants DOMAIN_NAME = "ERC4337" and DOMAIN_VERSION = "1" are in v0.8.0 EntryPoint.sol. The earlier decoder implements all three formulas. All 1,397 Oct 18 UserOperations re-hash to their event topic1 under their own version's formula. Using the v0.7 formula on v0.9 operations fails even though the bytes have the same shape (all-versions report).

Walked example: Reading a transaction recomputes a v0.7 hash byte by byte.

4. Behavior differences that matter when reading data

Sources: v0.7, v0.8 and v0.9 release notes. The 40,000 threshold and the 10% figure are also in v0.8 EntryPoint.sol (PENALTY_GAS_THRESHOLD, UNUSED_GAS_PENALTY_PERCENT). The v0.6 postOp/prefund rule comes from v0.6 EntryPoint.sol.

Two consequences for analysis:

• v0.9 initCode no longer means "first operation". A nonzero initCode on an already-deployed v0.9 account is silently ignored. Count deployments from AccountDeployed events, never from "initCode was non-empty". (That is good practice in every version.)
• The user's gas price is min(maxFeePerGas, maxPriorityFeePerGas + basefee). It is computed from the UserOperation's own fields, not from the bundler's transaction gas price. This is why actualGasCost differs from the outer receipt fee (see the primer's money section).

5. EIP-7702 support: capability vs observed use

From v0.8, an EOA that has delegated its code via an EIP-7702 (type-4) transaction can act as a UserOperation sender. Such an operation marks its initCode with 0x7702 padded to 20 bytes. The EntryPoint then puts the delegate address into the hash instead of calling a factory.

What was observed on C-Chain:

• Oct 18 (earlier all-versions report): no EIP-7702 initCode marker in any v0.9 operation, and no type-4 outer transaction. The v0.9 sender is an ordinary Safe proxy.
• v0.8 history (a block-archive query, 2025-01-01 → 2026-10-18): all 258 transactions sent directly to v0.8 are type 2. None is type 4. I did not check v0.8 initCode bytes for the 0x7702 marker. Parquet has no calldata, so that check needs full calldata from the transaction database.

Capability is not usage. "Supports 7702" describes the contract version, not what the operations did.

6. What was actually observed on C-Chain

Oct 18, 2026 (earlier, verified population)

Whole-archive check of v0.8 (correction to an earlier note)

epi/constants.py says v0.8 "only sees deposits". That is wrong over the archive's history. It holds only for the days around Oct 18. I scanned the parquet archive from 2025-01-01 (start of the local archive; v0.8 was not released until 26 Mar 2025) through 2026-10-18:

So v0.8 is real but small: about 921 operations over 18 months, against millions on v0.7. On Oct 18 it had no operations. The deposits that prompted the "deposit-only" note are two 3-AVAX depositTo calls on Oct 17. A deposit funds a sender's or paymaster's balance inside the EntryPoint. It is not a user action. I verified the three tx hashes in the table above by indexed transaction-database hash lookup: each exists, has the expected to, selector and status, and the handleOps ones contain a v0.8 UserOperationEvent.

Update through 2026-10-25 (from epi history; the table above is the hand-verified snapshot to Oct 18): v0.8 reached 273 successful bundles and 927 UserOperations, the last on 2026-10-22. On that day one bundler, 0x4337000c…8680 (also v0.8's busiest bundler), sent 183 handleOps to v0.8 that reverted within about 30 minutes, alongside 67 more to v0.6 and v0.7. That brings v0.8's reverted bundles from 3 to 187.

For scale, in the archive window to Oct 18: v0.7 emitted 4,842,555 UserOperationEvents, v0.6 946,645, v0.9 8,927 (first at block 84,089,763) and v0.8 921. This is a count of events emitted, not a count of distinct users.

v0.9-specific features actually used on Oct 18 (earlier, verified)

• All 64 hashes use the EIP-712 formula.
• 19 operations carry the paymaster-signature suffix. The other sponsored operations do not.
• The account is Safe 0xa1fdd9daed9004f685b6900d5463f72d13dfccca evidence level: cluster with module 0x22939e839e3c0f479b713eaf95e0df128554aead evidence level: primary source. That module address matches Candide's published multichain-signature module. All 64 signatures use Merkle depth zero (single-chain branch).
• No EIP-7702 marker, no type-4 transaction.

7. Quick version checklist for a decoder

1. Find the UserOperationEvent emitter. That is the version. Don't infer the version from the selector.
2. Decode handleOps with the matching struct: 11 fields for v0.6, 9 packed fields otherwise. If to is not an EntryPoint, the call is wrapped. Find the embedded handleOps bytes and say explicitly that the wrapper's own behavior is unknown.
3. Recompute the userOpHash with the version's formula. Only then join ops to events by topic1, not by position.
4. Split paymasterAndData at 20 bytes (v0.6) or 20/36/52 bytes (v0.7+). In v0.9, check for the magic suffix.
5. Treat 7702, block-number validity and "ignored initCode" as v0.8/v0.9 capabilities to test for, not to assume.