Skip to content

Request: authenticated Flashblocks WebSocket endpoint (/ws/ssz) with full receipt metadata #1136

@dzhelezov

Description

@dzhelezov

Who we are

We operate SQD (https://sqd.dev) data infrastructure — high-throughput indexing/RPC services running Flashblocks-aware nodes for Base mainnet. We're building low-latency receipt/log delivery on top of the
Flashblocks preconfirmation feed and need a higher-throughput, structurally-complete stream than the public rate-limited endpoint provides.

What we're requesting

An authenticated Flashblocks WebSocket endpoint with minimal rate limiting, per the note in the node-operators docs (https://docs.base.org/base-chain/flashblocks/node-providers) ("If you operate a large number
of nodes, you can reach out to have an authenticated endpoint provided with minimal rate limiting").

Specifically:

  1. Authenticated access to the SSZ feed (wss://mainnet.flashblocks.base.org/ws/ssz, currently 401 without credentials), or whichever endpoint carries the full FlashblocksPayloadV1 SSZ payload.
  2. Confirmation that the authenticated payload retains metadata.transactions[].{status, gas_used, contract_address} (the receipt scalars) and the accounts state-delta fields. We observe the public JSON /ws
    endpoint omits the receipt metadata that the SSZ spec defines — we want the complete payload so we can derive receipts without re-execution.
  3. Logs: confirmation of how to receive full transaction logs (e.g. the newFlashblockTransactions full: true subscription, if that's the mechanism).
  4. The rate-limit tier / expected throughput of the authenticated endpoint, and any usage expectations on our side.

Context

  • Mainnet (Base mainnet, chain 8453).
  • We're consuming the feed for receipt/log enrichment at tip; the public endpoint's rate limit and stripped metadata are the two blockers.
  • Happy to share more about volume/architecture privately if useful, or move this to a more appropriate channel.

Credentials handling

Whatever auth mechanism you provide (bearer token, mTLS, IP allowlist), we can accommodate. Let us know the preferred provisioning flow.

Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions