Fast Feed: Constitutional AIP

Abstract

This Constitutional AIP proposes to establish the Fast Feed, a paid, authenticated data streaming product for Arbitrum One. The Fast Feed allows subscribers to get updates on transactions, their relative ordering, and related transaction metadata earlier than they would otherwise via the regular feed. The Fast Feed makes that stream accessible to Arbitrum's ecosystem as a specialized, subscription-based data product.

This feed will be paid-only to mitigate against DoS risks and to help ensure a reliable and stable connection for teams who wish to use it. The Fast Feed's design should not introduce new types of MEV, frontrunning, nor sandwich attacks because the feed only publishes read-only information about the transactions after their order has been determined by the sequencer and enqueued for execution.

If approved, this AIP would:

• Be paired with an Arbitrum Nitro node software upgrade at the sequencer to expose a new endpoint for access to the Fast Feed.
• Deploy and use the Fast Feed Payment Contract, an audited smart contract on Arbitrum One, to manage access to the Fast Feed by allowing users to submit their API key hash when they send a paying transaction to the Fast Feed Contract. Upon payment, the Fast Feed Payment Contract records the hash of the key as the user's Subscription Credential, which the sequencer cross-references to admit or deny incoming Fast Feed connections.
  • The Fast Feed Payment Contract will use a RewardDistributor contract as a recipient of fees such that 97% of subscription revenue gets routed to the ArbitrumDAO and 3% to the Arbitrum Developer Guild. The RewardDistributor contract has been audited and a public audit report can be found here.
• Grant rights to Offchain to make adjustments from time to time for a period of two (2) years to the parameters in the Fast Feed Payment Contract.

Motivation

The Fast Feed is designed to serve any ecosystem participant that benefits from earlier visibility into ordered transaction flow (including MEV searchers, Proprietary Automated Market Makers (propAMMs) and latency-sensitive DeFi applications). Access to the Fast Feed is provided on a paid subscription basis, with the goal of using the proceeds to help ensure quality and consistent feed performance for all subscribers. The net revenue will be split between the ArbitrumDAO Treasury and the Arbitrum Developer Guild pursuant to the RewardDistributor contract deployed on-chain, following the same revenue split framework established by the Timeboost AIP.

Rationale

The Fast Feed distributes information from the sequencer before a full block is built, but because it is optional, supplemental, and costly to provide, it will be a paid product. Once ordering is resolved deterministically, that ordered stream carries clear economic value for latency-sensitive participants. Rather than letting this value accrue only to those who can co-locate or operate the fastest infrastructure, the Fast Feed packages it as a subscription product whose proceeds flow back to the ArbitrumDAO and the Arbitrum Developer Guild.

• Open, not exclusive: access is paid but permissionless; any participant willing to subscribe can obtain access, and there is no privileged or preferential access beyond payment.
• Ordering-neutral: the feed does not change transaction ordering, inclusion guarantees, or the priority or transaction fees any user pays. It only changes the timing by which subscribers are able to observe the ordered stream of transactions.
• Transparent, on-chain revenue: proceeds are split through the RewardDistributor and enforced on-chain (97% to the ArbitrumDAO Treasury, 3% to the Arbitrum Developer Guild), with every payment and distribution emitted as an on-chain event for public audibility.
• Consistent governance precedent: revenue routing follows the framework established by Timeboost and the proposed transition to use PGA, keeping Arbitrum's ordering-related revenue products aligned.
• The ArbitrumDAO retains control: the ArbitrumDAO and, if the DAO permits, Offchain can configure the new feed payment parameters (see section 1.3). The DAO alone can additionally control the revenue split.

Key Terms

Fast Feed: an authenticated, low-latency data stream that publishes the individual transactions, their relative ordering, and relevant metadata after they are ordered by the sequencer, available to paid subscribers.

Sequencer Feed Endpoint: the Fast Feed endpoint exposed by the sequencer by which authenticated subscribers can connect to for access to the Fast Feed.

Fast Feed Payment Contract: the audited smart contract on Arbitrum One that manages access to the Fast Feed.

Subscription Credential: the API key hash recorded by the Fast Feed Payment Contract upon payment, which the sequencer cross-references to admit or deny incoming feed connections.

propAMM (Proprietary Automated Market Maker): an automated market maker whose pricing relies on an external trusted price-pusher source to update quotes on-chain rather than relying solely on the constant-product curve and arbitrageurs. propAMMs are an emerging class of actors who offer attractive swap prices/quotes and usually bring their own liquidity on-chain to facilitate this.

---

Specification

We formally introduce the Fast Feed which consists of three components: 1) the Sequencer Feed Endpoint and payload, 2) the Subscription and Credential Management, and 3) the Payment Contract itself.

1.1 Sequencer Feed Endpoint and Payload Schema

A new WebSocket endpoint that publishes individual transactions once they are ordered but before a full block is constructed and emitted from the regular feed. The endpoint is authenticated: only clients presenting a valid subscription credential are admitted. Note that the Fast Feed will only publish information about transactions after these transactions have been sequenced for execution. The ordering cannot be influenced or changed past this point and, therefore, types of MEV like sandwiching or frontrunning should not be able to be performed.

Each transaction is wrapped in a FeedMessage envelope that provides ordering and timing metadata.

{
  "FeedMessage": {
    "description": "Envelope wrapping each transaction with ordering and timing metadata.",
    "fields": {
      "version": {
        "description": "Protocol version for forward compatibility",
        "type": "uint32",
        "json_type": "number"
      },
      "timestamp_ms": {
        "description": "Unix timestamp in milliseconds when the sequencer created this message",
        "type": "uint64",
        "json_type": "number"
      },
      "pga_round": {
        "description": "Number of the PGA round for the current block",
        "type": "uint64",
        "json_type": "number"
      },
      "transaction": {
        "description": "Transaction data and incomplete receipt",
        "type": "IncludedTransaction",
        "json_type": "object",
        "fields": {
          "block_number": {
            "description": "Tentative block number (not guaranteed to be finalized)",
            "type": "uint64",
            "json_type": "number"
          },
          "tx_index": {
            "description": "Transaction position within the block so far",
            "type": "uint32",
            "json_type": "number"
          },
          "raw_tx": {
            "description": "RLP-encoded signed transaction",
            "type": "bytes",
            "json_type": "string (hex-encoded)"
          },
          "tx_hash": {
            "description": "Transaction hash",
            "type": "bytes32",
            "json_type": "string (hex-encoded)"
          },
          "receipt": {
            "description": "Execution result. Incomplete because the block is not yet finalized; does not include block_hash.",
            "type": "IncompleteReceipt",
            "json_type": "object",
            "fields": {
              "status": {
                "description": "1 = success, 0 = failure",
                "type": "uint8",
                "json_type": "number"
              },
              "gas_used": {
                "description": "Gas consumed by this transaction",
                "type": "uint64",
                "json_type": "number"
              },
              "gas_used_for_l1": {
                "description": "Gas attributable to L1 data costs (Arbitrum-specific)",
                "type": "uint64",
                "json_type": "number"
              },
              "cumulative_gas_used": {
                "description": "Cumulative gas used in the block up to this transaction",
                "type": "uint64",
                "json_type": "number"
              },
              "effective_gas_price": {
                "description": "Actual gas price paid (relevant for PGA priority fee analysis)",
                "type": "uint256",
                "json_type": "string (hex-encoded)"
              },
              "base_fee": {
                "description": "Current block base fee",
                "type": "uint256",
                "json_type": "string (hex-encoded)"
              },
              "contract_address": {
                "description": "Set only if the transaction created a contract",
                "type": "address (optional)",
                "json_type": "string (hex-encoded)"
              },
              "logs": {
                "description": "Event logs emitted during execution",
                "type": "[]Log",
                "json_type": "array of objects",
                "array_item_fields": {
                  "address": {
                    "description": "Emitting contract",
                    "type": "address",
                    "json_type": "string (hex-encoded)"
                  },
                  "topics": {
                    "description": "Indexed event fields",
                    "type": "[]bytes32",
                    "json_type": "array of strings (hex-encoded)"
                  },
                  "data": {
                    "description": "Non-indexed event data",
                    "type": "bytes",
                    "json_type": "string (hex-encoded)"
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

1.2 Subscription and Credential Management

The Fast Feed Payment Contract governs subscription validity. Access to the Fast Feed is granted when a user submits a paying transaction to the Fast Feed Payment Contract that includes the Keccak-256 hash of their API key. Upon payment, the contract records this hash as the user's Subscription Credential. To connect, the user presents their raw API key to the sequencer, which hashes it with Keccak-256 and cross-references the result against the recorded credentials to admit or deny the connection.

Credential rotation and subscription renewals are handled through direct interaction with the Fast Feed Payment Contract by the subscriber.

1.3 Fast Feed Payment Contract

The Fast Feed Payment Contract is an audited, smart contract deployed on Arbitrum One. This contract will:

• Sell access to the feed with pricing determined using the same pricing mechanism in EIP-4844; market parameters are listed further below.
• Receive payments denominated in an ERC20, USD-backed stablecoin. We explicitly leave the asset selection to the Arbitrum Treasury Management (ATM) Council and OAT to ensure alignment with the portfolio's goals.
• Emit on-chain events for each subscription payment and distribution, enabling transparent public audibility of all revenue flows.
• Have 3 roles built-in:
  • DEFAULT_ADMIN -> controlled by the ArbitrumDAO and has admin permissions to assign all other roles to accounts.
  • BENEFICIARY_SETTER -> controlled by the ArbitrumDAO and has permissions to change the destination of the proceeds. This AIP proposes that this be set to the RewardDistributor contract address.
  • MARKET_PARAMS_SETTER -> proposed to be controlled by Offchain and the ArbitrumDAO such that either entity can change the parameters in Table 1 below.
• Send proceeds to the RewardDistributor contract, which is in charge of routing 97% of proceeds to the ArbitrumDAO and the remaining 3% to the Arbitrum Developer Guild. The RewardDistributor contract has been audited and a public audit report can be found here.
  • The RewardDistributor contract is deployed at 0xa4a8a4e2fe847af59d340926adcdef6e988bb1f1 and will route proceeds to the following addresses, with the above specified weights:
    • The ArbitrumDAO L2 Treasury Timelock (97% weight): 0xbFc1FECa8B09A5c5D3EFfE7429eBE24b9c09EF58
    • The Arbitrum Developer Guild (3% weight): 0x6A075E9a02eef6978DD66cB63DE430a8c0C419E9

The contract will be independently audited by Trail of Bits prior to deployment, with the audit report published publicly soon after (but before an eventual onchain vote). All contract addresses will be documented in the Arbitrum One developer documentation.

Should this AIP pass, the DAO grants Offchain the permission to change the Fast Feed Payment parameters listed below in Table 1. Note that the ArbitrumDAO may also change any of these parameters at any time via the MARKET_PARAMS_SETTER role in the Fast Feed Payment Contract described above.

Table 1: Fast Feed Payment contract parameters

Parameter name	Description	Proposed default value
Round duration (in hours)	Length of each sales round, the recurring period over which a fixed allotment of feed tickets is sold at a single uniform price before the mechanism re-prices and the next round opens. Also sets the cadence at which newly purchased tickets become active and prior-round tickets expire.	24
Target tickets per-round	The per-round sales volume the pricing curve targets, analogous to EIP-4844's target blob count.	100
Maximum tickets per round	Hard limit on feed tickets sold in any single round.	200
Minimum price (in USD)	The price floor for a ticket.	17
Price update fraction*	Sensitivity of the EIP-4844-style pricing curve, analogous to the blob base-fee update fraction.	144
Excess tickets sold	The running tally of tickets sold above target across all rounds that drives the pricing curve. Exposed as a settable parameter so the curve can be re-anchored to a chosen starting price when the floor or sensitivity is changed.	0
Grandfather period fraction	The portion at the start of each round reserved for renewals, during which only prior-round subscribers may repurchase, up to the number of tickets they held the previous round, before sales open to everyone.	128/256 (or ~0.5)

This yields a maximum next round price of ~2p and a minimum next round price of ~0.5p where p is price, derived by e^((max-target)/144) and e^((0-target)/144), respectively.

---

Steps to Implement

1. A post to the ArbitrumDAO Forums (this post) to initiate productive, collaborative discussions with the DAO and its members, followed by governance call(s) to answer any questions.
2. Temperature Check (Snapshot): This forum post will advance to a temperature check vote on Snapshot, targeting approximately 1-2 weeks after the initial Forum Post. The temperature check will gauge DAO sentiment on community support for the Fast Feed concept, pricing structure, and revenue split.
3. Smart contract audit: The Fast Feed Payment Contract will be independently audited by Trail of Bits prior to the on-chain Alt Arbitrum Gov vote, and we will publish an audit report publicly here. We are targeting an audit completion date sometime in July 2026.
4. Onchain vote (Alt Arbitrum Gov): Following a successful Snapshot temperature check, publication of the public audit report, and final testing: this proposal will proceed to an on-chain constitutional vote for ~14 days. The ArbitrumDAO will be notified on this thread and via official channels before the vote goes live. We intend for this onchain vote to take place sometime in July 2026, barring any delays.
5. Feed Activation: As soon as the same day the vote is passed, the Fast Feed Payment Contract will be deployed and the Feed will begin broadcasting.