Polygon FastLane
  • What is Polygon FastLane?
    • Overview
    • Design Principles
    • Components
    • Component Diagram
  • Getting Started as a Validator
    • Getting Started as a Validator
    • Connecting to a FastLane Sentry Node
      • Finding Your Enode Address & Peer ID
      • Adding FastLane as a Static Peer
    • Patching Your Sentry Nodes With The FastLane Patch
      • Installing from source
        • Patch Download
        • Patch Installation
      • Installing from packages
  • Withdrawing Validator Revenue
    • Validator Vault
      • Connect an Eligible Wallet
      • Revenue Redemption (withdrawal)
  • Searcher Guides
    • Getting Started as a Searcher
      • Solver Call Data
      • Submission Methods
      • Migration Guide for Searchers
    • Bundles (Backruns)
      • Bundle Format
      • Bid Submission
      • Bundle Requirements
      • Full Example
      • Subscribe Events
    • 4337 Bundles Integration Guide
      • Overview
      • How it works
      • RPC Reference
      • Examples
    • Searcher Contract Integration
      • Safety Considerations
      • atlasSolverCall
      • Direct Implementation
      • Proxy Implementation
      • Solver Concepts
      • Altas Bonding Concept
      • Bond atlETH
      • Estimating Solver Gas Charges
    • Addresses & Endpoints
    • Helpers
    • Common Mistakes
    • Atlas SDK's
  • Tools and Analytics
    • FastLane Bundle Explorer
      • Features Overview
      • Key Components
      • Usage Example
      • Error Codes & Troubleshooting
  • Key Concepts
    • Transaction Encoding
  • INFRASTRUCTURE
    • Health Status Endpoint
  • Reference
    • Relay JSON-RPC API
    • Relay REST API
    • Glossary of Terms
Powered by GitBook
On this page
  1. Searcher Guides
  2. 4337 Bundles Integration Guide

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.

PreviousOverviewNextRPC Reference

Last updated 6 months ago