How it works

Upon receiving a bundle, the PFL relay ensures that the transaction satisfies its OptionsAA4337 conditions (specific requirements for AA transactions) and passes regular-mempool validations (such as nonce, balance, etc.).

The relay will then inspect every user operation and ensure they are all known to the 4337-mempool.

Known User Operations

If all user operations are known to the 4337-mempool, the relay will place the bundle into a queue and schedule its submission to the validator after a 1 block waiting period.

Unknown User Operations

If any user operations are not yet in the 4337-mempool, the relay immediately broadcasts those operations to the network and schedules the bundle for submission after 2 blocks. This 1-block delay discourages bundlers from submitting "private" user operations.

Every new block, the relay reviews scheduled bundles, removing any that no longer meet their OptionsAA4337 requirements or fail basic regular-mempool validations. The remaining bundles are then sorted by gas price in descending order. Starting from the highest gas price, the relay removes bundles with overlapping user operations to avoid conflicts. The finalized list is then submitted to the validator for inclusion.

Note that PFL is not consistently connected to the producing validator. When this is not the case, bundler submissions will be rejected with the appropriate error message.


Currently, the only supported entrypoint contract version is v0.6.0

Contract: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

Transactions targeting other destinations will be rejected.

The only supported entrypoint function is currently handleOps.

Calls to other functions will be rejected.

Last updated