Design: a signed, block-pinned chain-evidence bundle ("CEB") for the swarm

Right now, when Codex and Claude seats disagree on a chain question, the gap comes from network access, not skill. The fix is to move all network access to the server and give every seat the same frozen, self-verifying bytes. Each answer then rests on data anyone can re-check offline, so a verifier checks the data against Ethereum's own commitments rather than trusting the server.

1. Core idea

For each chain question, the server does four things:

1. Resolves the queries. It works out the queries the question needs: accounts, storage slots, calls, log filters and transactions.
2. Pins one finalized block. Every query is fixed to one finalized block, addressed by block hash rather than "latest". EIP-1898 lets JSON-RPC methods accept a block hash in place of a number or tag, and with requireCanonical the node "SHOULD additionally raise a JSON-RPC error if the block is not in the canonical chain."
3. Fetches the data with its proofs.
   • Account and storage values come with Merkle proofs from eth_getProof (EIP-1186). Its accountProof is an "Array of rlp-serialized MerkleTree-Nodes, starting with the stateRoot-Node". EIP-1186 notes these allow offline verification against the stateRoot in the block header.
   • Receipts and logs come as the raw receipt list of each relevant block, which recomputes to that header's receiptsRoot.
   • eth_call results come as a stateless re-execution witness: every account, code and slot the call touches, each with a proof.
4. Seals the bundle. It content-addresses the result, signs it and logs it publicly. The bundle is attached to the job verbatim, and every runtime answers from those bytes and cites them.

Because every item is proven against a header, the signature only vouches for which header was used. Everything below the header can be checked by anyone with a hash function and an RLP decoder.

2. Bundle format

It is one canonical file: deterministic CBOR (or JSON with sorted keys, no floats, and hex strings), zstd-compressed. Its ID is ceb_id = sha256(canonical_bytes).

{
  "v": "ceb/1",
  "job_id": "…",
  "question_sha256": "…",            // binds bundle to the exact prompt
  "chain_id": 1,
  "anchor": {
    "block_number": 21000000,
    "block_hash": "0x…",
    "header_rlp": "0x…",             // full RLP header; keccak(header_rlp) MUST == block_hash
    "finality": {                    // how we know this header is canonical
      "type": "beacon-finalized",
      "beacon_block_root": "0x…",    // execution header is committed in beacon block body
      "exec_payload_branch": ["0x…"],// SSZ branch: execution_payload.block_hash -> beacon body root
      "sync_committee_sig": {…}      // or a pointer to a light-client update (see §5)
    },
    "range_headers": ["0x…"]         // extra headers for log ranges, each chained by parentHash
  },
  "manifest": [                      // deterministic list of what was asked for (completeness!)
    {"id":"q1","kind":"storage","addr":"0x…","slots":["0x…"]},
    {"id":"q2","kind":"call","to":"0x…","data":"0x70a08231…","from":"0x0…"},
    {"id":"q3","kind":"logs","addr":"0x…","topics":[["0xddf2…"]],"from":20990000,"to":21000000},
    {"id":"q4","kind":"receipt","tx":"0x…"}
  ],
  "items": {
    "q1": {"account": {"nonce":…,"balance":…,"storageHash":…,"codeHash":…},
           "accountProof":["0x…"], "storageProof":[{"key":…,"value":…,"proof":["0x…"]}]},
    "q2": {"result":"0x…", "gas_used":…,
           "witness": {"accounts":{…eth_getProof per touched addr…},
                       "codes":{"<codeHash>":"0x…"},
                       "block_hashes":{…if BLOCKHASH used…}},
           "evm":"revm@X.Y.Z / fork=prague"},
    "q3": {"blocks": [
             {"n":20990123,"bloom_hit":true, "receipts_rlp":["0x…"], "matches":[{"tx_index":5,"log_index":2}]},
             …],
           "bloom_negative": "all other headers in range_headers; logsBloom excludes filter"},
    "q4": {"block": 20999999, "tx_index": 17, "tx_rlp":"0x…",
           "receipt_rlp":"0x…", "receipt_proof":["0x…"], "tx_proof":["0x…"]}
  },
  "provenance": [                    // which upstreams agreed (for audit, not for trust)
    {"rpc":"provider-A","header_hash":"0x…"}, {"rpc":"provider-B","header_hash":"0x…"}
  ],
  "sigs": [                          // k-of-n witness cosignatures over ceb_id (see §5)
    {"kid":"swarm-server-2026","alg":"ed25519","sig":"…"},
    {"kid":"witness-A","alg":"ed25519","sig":"…"}
  ],
  "tlog": {"log":"rekor-like","index":…,"inclusion_proof":[…],"checkpoint":"…signed tree head…"}
}

Design points:

• The manifest is generated before any fetch from the question: a small deterministic resolver plus an LLM-proposed query list that is frozen and hashed into the bundle. This makes omissions visible. A verifier can ask whether the manifest covers what the question needs, instead of only checking whether each item is true.

• Log completeness has two cases:

  • Blocks that could contain a match must ship all of their receipts, so the verifier can recompute receiptsRoot and see every match.
  • Blocks whose header logsBloom rules out the filter's address or topics need nothing more. A negative bloom result is definitive, so those headers alone prove the absence of matching logs.

  This is what makes "all Transfer events in range" verifiable rather than "trust me".

• eth_call results are backed by the touched state. The server collects every account, code and slot the call touches (e.g. via an access list), then fetches proofs for each. Any EVM can then replay the call statelessly and must get the same result. This is the same method light clients use: Helios says it "converts an untrusted centralized RPC endpoint into a safe unmanipulable local RPC for its users."

3. How answerers cite it

Seats get the bundle, or a decoded read-only view of it, and are told: no numbers except from the bundle. Citations use a fixed grammar:

[ceb:<ceb_id[:12]>#q2.result]                 → raw bytes
[ceb:<id>#q1.storageProof[0].value]
[ceb:<id>#q3.blocks[4].matches[1]]            → a specific log
[ceb:<id>#q2.result|abi:uint256|÷1e18]        → derivation pipeline, re-runnable

Rules:

1. Every numeric claim carries a pointer plus an explicit, mechanical derivation: ABI decode, decimals, sum over matches, and so on.
2. If a needed item is missing from the manifest, the seat must say EVIDENCE_GAP: <what>. Guessing and falling back to a methodology-only answer are both off the table. The server can then issue a supplementary bundle (parent: ceb_id), and all seats re-answer on the union.
3. Every seat's answer header includes ceb_id. Answers citing different IDs are not comparable, and the panel rejects the mismatch before any disagreement is scored.

The result: a Codex seat and a Claude seat are fed the same bytes and must cite the same pointers. Any remaining disagreement comes down to derivation or interpretation, which is a real skill difference.

4. Verification procedure (runs fully offline)

An independent verifier needs: the bundle, the trusted-keys and witness list, a checkpoint it trusts (a beacon weak-subjectivity checkpoint, or the latest signed tree head), keccak, RLP, SSZ, an MPT verifier and a pinned EVM.

1. Integrity. Recompute sha256(canonical) and require it to equal ceb_id. Check ≥k of n sigs over ceb_id from distinct operators. Verify the tlog inclusion proof against a signed checkpoint.
2. Binding. question_sha256 must equal the hash of the prompt the job actually carried.
3. Header. keccak256(header_rlp) == anchor.block_hash. Then:
   • Walk range_headers via parentHash back to the anchor.
   • Check finality: verify the SSZ branch from execution_payload.block_hash to the beacon block root, and the sync-committee aggregate signature over that root (the light-client path).
   • Weaker mode, if no consensus data is available: require the anchor hash to match ≥2 independent provenance sources and the witness cosigners.
4. Storage and accounts. For each proof, walk the MPT from header.stateRoot along keccak(addr), check the RLP account, then walk storageHash along keccak(slot). The values must equal the claimed ones, and non-inclusion proofs must terminate correctly.
5. Receipts and logs. For each shipped block, rebuild the receipts trie from receipts_rlp (keys rlp(index); typed receipts are prefixed by type) and require the root to equal header.receiptsRoot. Re-run the log filter locally, and the matches must equal matches exactly. For every other header in range, compute the bloom bits of the filter's address and topics; each must be absent from logsBloom, otherwise the bundle is incomplete and rejected.
6. Single receipt or transaction. Verify receipt_proof against receiptsRoot and tx_proof against transactionsRoot at tx_index.
7. Calls. Build an in-memory state DB only from proven witness accounts, slots and code, where keccak(code) == codeHash. Any read outside the witness is a hard failure, which shows the witness is incomplete. Execute the call at the header's context (number, timestamp, basefee, coinbase and prevrandao from header_rlp). The result must equal result, byte for byte.
8. Answer audit. Resolve each [ceb:…] pointer, re-run its derivation pipeline, and diff the output against the numbers in the answer.
9. Manifest adequacy (the only non-mechanical step). A verifier seat judges whether the manifest covers the question and flags EVIDENCE_GAP otherwise.

Steps 1–8 are deterministic; ship them as a ~1–2k-line reference tool (Rust or Python) so Codex and Claude seats run the same code.

5. Stopping the server from being a single point of trust

The server can attack in four ways: lie about values, pick a non-canonical or forked block, omit evidence, or equivocate by showing different seats different bundles. Each layer below closes one of these:

Threat	Mitigation
Fake values	Impossible without breaking keccak: every value is Merkle-proven to stateRoot or receiptsRoot (steps 4–7).
Fake or non-canonical header	Anchor to consensus, not the server: finalized beacon block plus sync-committee signature. The verifier trusts only a weak-subjectivity checkpoint. EIP-4788 puts beacon roots in the EVM because they "are cryptographic accumulators that allow proofs of arbitrary consensus state", which enables cross-checking the anchor from on-chain later.
Single upstream RPC lying or lagging	Fetch the header hash from ≥3 independent providers and/or self-run nodes, and record all of them in provenance. Any divergence → abort, never pick one.
Omission / cherry-picking	Manifest frozen before fetch. Bloom-negative completeness for log ranges. Stateless replay fails loudly on a missing witness. Seats may emit EVIDENCE_GAP.
Equivocation (different bundles to different seats)	Every seat echoes ceb_id. Bundles go into an append-only transparency log (Rekor-style: "Auditors can monitor the log for consistency, meaning that the log remains append-only and entries are never mutated or removed"). The job is valid only if all seats cite the same logged ID.
Server signing key compromise	k-of-n witness cosigning: e.g. 2–3 independent witnesses (a separate org or infra, or a non-sandboxed Claude seat acting as witness). Each re-runs steps 3–7 against its own node or light client before cosigning, and the verifier requires ≥k signatures.
Collusion of all witnesses	Still bounded: values remain proof-checked. Only the header anchor depends on them, and the light-client check removes even that. Random post-hoc audits: re-fetch a sample of bundles' block hashes from a public explorer later and publish mismatches.

The end state: trust reduces to Ethereum consensus plus a checkpoint. The server acts as a courier whose only unverifiable choice is the manifest, and that choice is public and challengeable.

6. Cost per job (my estimates, not sourced)

These are rough figures from typical Ethereum mainnet sizes. Measure them on your workload.

Component	Typical size / cost
Header RLP	~0.6 KB
Beacon finality branch + sync aggregate	~2–4 KB (or reference a shared light-client update, amortized ≈0)
One account proof	~3–6 KB (≈8–10 trie nodes of ≤532 B)
+ each storage slot proof	~1.5–4 KB
eth_call witness (ERC-20 balanceOf)	~10–20 KB (1–2 accounts + code ~5–20 KB + few slots)
Complex call (DEX quote, 5–20 contracts)	~100–500 KB, mostly bytecode (dedupe by codeHash across jobs)
Receipt proof (single tx)	~3–10 KB
Log range, 10k blocks	headers ~6 MB raw (~2–3 MB zstd), plus full receipts for bloom-hit blocks at ~50–300 KB each

For log ranges, cache headers globally: fetch each header once per chain and reference it by hash, and the marginal cost per job falls to the bloom-hit blocks only.

Typical job: 3–10 items with one short log range, giving a 50–500 KB bundle compressed, 20–200 upstream RPC calls across the 3 providers, and ~1–5 s of fetch time.

Money: fractions of a cent in RPC credits for small jobs. Log-heavy jobs over wide ranges cost the most: tens of MB of receipts, and possibly $0.01–0.10 at commercial RPC pricing. Run your own archive node and the marginal cost is ≈0.

Compute:

• Ed25519 signing and verifying: µs.
• MPT verification: ms.
• Stateless EVM replay: ms to low seconds.
• Receipts-root rebuilds: ~10–50 ms per block.
• Witness cosigning roughly doubles fetch cost, since each witness re-fetches the header plus proof roots and can spot-check a random subset.

Tokens: the big cost is the model context, so don't paste raw proofs into prompts. Give seats a decoded view (values plus pointers, ~1–5 KB, roughly 0.5–2k tokens), with the raw bundle as an attached file and the verifier tool as a callable. That keeps per-seat token overhead roughly constant and identical across runtimes.

7. Rollout

1. v0: a signed bundle with multi-provider header agreement, eth_getProof, receipts and call witnesses; seats must cite pointers.
2. v1: add a transparency log and ceb_id echo checks for equivocation.
3. v2: add beacon light-client finality and k-of-n external witnesses, removing trust in the server's header choice.
4. Grading: the panel scores only answers whose ceb_id matches and whose pointers verify. Disagreements then reflect reasoning, not sandboxing.

The swarm should receive a content-addressed Chain Evidence Bundle (CEB) with the question. Answerers never query RPC; they consume the same bundle and cite byte offsets or object digests within it.

1. Evidence-bundle format

Use a deterministic archive—CARv2 or a sorted tar—with a JCS-canonicalized JSON manifest. JCS exists specifically to make hashing and signing repeatable across implementations (RFC 8785).

ceb/
  manifest.jcs.json
  requests/<sha256>.json
  responses/<sha256>.json
  chain/
    execution-header/<block-hash>.rlp
    beacon-bootstrap.ssz
    beacon-updates/*.ssz
  state/
    <block-hash>/<address>/account-proof.rlp[]
    <block-hash>/<address>/<slot>/storage-proof.rlp[]
    <code-hash>.bin
  receipts/
    <block-hash>/<tx-index>.typed-rlp
  witnesses/
    <request-hash>.json
  attestations/
    <collector-key-id>.dsse.json
  transparency/
    inclusion-proof.json

The manifest should contain:

Build a content-addressed evidence bundle before dispatching the question, then mount the same immutable bundle in every seat. Require answers and panel evaluations to identify its digest. Treat evidence acquisition failures separately from reasoning failures.

The following is a proposed protocol, Chain Evidence Bundle v1 (CEB1). Its schema, policies, and budget assumptions are design choices; the linked specifications support the underlying verification mechanisms.

Bundle format

Use a directory containing manifest.json, objects/sha256/<digest>, and attestations.json. Transport it as an archive, but identify it by the canonical manifest digest rather than archive metadata.

Canonicalize JSON with RFC 8785 JCS; reject duplicate keys and encode chain integers as strings to avoid precision loss. Hash binary objects exactly as stored. These choices follow JCS’s canonicalization and numeric constraints. RFC 8785

Manifest field	Required contents
schema	"ceb/1"
job	Original question digest, query-plan digest, job ID, evidence revision
chain	Chain ID, execution genesis hash, consensus network identity, fork-configuration digest
snapshot	Anchor block number/hash/timestamp, required finality, selection rule, acquisition time, freshness deadline
blocks[]	Number, hash, parent hash, raw header object reference; state, transaction and receipt roots
queries[]	Stable query ID, exact method/parameters, block references, result/error object reference, assurance label, proof references
coverage	Requested addresses/topics/ranges, ordered block-hash list, executed subqueries, omissions, truncation/error flags
decoding	ABI object hashes, decoder version, units and rounding rules; provenance for ABI assumptions
objects[]	SHA-256 digest, byte length, media type and encoding for every referenced file
verification	Required proof/attestation policy, verifier specification version, trust-policy digest

A concrete queries[] entry would contain:

• id: "q17"
• method: "eth_call"
• params: [<fully specified call object>, {"blockHash":"0x…","requireCanonical":true}]
• response: "sha256:…"
• assurance: "quorum-attested" or "execution-replayed"
• proofs: ["sha256:…"]

The call object must fix sender, recipient, calldata, value, gas and applicable fee/access-list fields. Specify the RPC execution semantics and prohibit state/block overrides in v1. Store successful return bytes, EVM reverts and acquisition errors distinctly.

Use block hashes for calls and account proofs: EIP-1898 explicitly supports eth_call and eth_getProof, including requireCanonical. That flag expresses the responding node’s canonicality judgment; it is not itself a consensus proof. EIP-1898

For logs, execute a block-hash filter for each covered block; do not combine blockHash with fromBlock/toBlock. Range collection can be optimized internally, but the published coverage must resolve to an exact ordered block list. A receipt query uses the transaction hash; reject a returned receipt whose block differs from the selected snapshot. Ethereum JSON-RPC

Preserve original RPC response bytes as provenance, plus a deterministic normalized result for comparison across collectors. Exclude transport request IDs from result agreement; retain all semantic fields and errors.

Define bundle_id = SHA256(JCS(manifest)). Each collector signs a canonical statement containing that ID, query IDs covered, normalized-result digests, acquisition time, completeness assertions and assurance level. Domain-separate the signed bytes with CEB1-ATTESTATION and use Ed25519. The server can separately sign a delivery envelope binding job, revision and bundle ID. Ed25519 specification

What “verified” means

Do not collapse everything into one green checkmark. Require these distinct labels:

Label	Required evidence
quorum-attested	Independent collectors signed agreement on precisely identified queries/results
state-proven	Account/storage proofs checked against an authenticated state root
receipt-proven	Consensus-encoded receipt inclusion checked against an authenticated receipt root
logs-complete	Every covered block’s complete receipts authenticated, then filtered locally
execution-replayed	Exact call replayed using authenticated state/code and fixed execution context

Account and storage proofs come from eth_getProof; they authenticate values relative to a block header’s state root. They do not directly prove an arbitrary function’s return bytes. EIP-1186

For execution-replayed, construct a witness containing every accessed account/storage proof, bytecode matching proven code hashes, and required authenticated block context/history. Run a fork-correct EVM locally against the pinned block’s state. Missing witness reads must fail verification, never silently become zero. Compare return bytes or revert bytes. This is a proposed verifier built on Ethereum’s state commitments and EVM execution model, rather than a claim that ordinary RPC supplies a call-result proof. Ethereum trie structure, EVM documentation

For receipts, preserve the actual consensus encoding, including typed envelopes. The trie key is RLP(transactionIndex). If citing a transaction hash, also authenticate the transaction at that index against transactionsRoot; receipt contents alone do not establish that hash. Derived JSON fields must be recomputed or separately labeled as attested. EIP-2718

For complete logs, v1 should use a deliberately simple procedure: include all receipts for every block, rebuild each receipts trie, compare its root, and apply the exact address/topic filter locally. Inclusion proofs for returned matches do not establish that other matches were omitted nowhere. This completeness requirement follows from the receipt commitment structure. A signed complete: true is an attestation unless the reconstruction passes. Ethereum receipt tries

Independent, offline verification

Ship a separately maintained verifier with each runtime, installed independently of the bundle. A proposed invocation is ceb verify /evidence --offline --policy /trusted/policy.json. That is an interface to implement, not an existing command.

Its procedure:

1. Check identity and bytes. Match the question, job revision and expected bundle ID from the job envelope. Strictly parse the manifest; recompute its canonical digest and every object’s hash/length. Reject missing objects, duplicate query IDs and unsupported versions.

2. Check signatures and policy. Verify signatures against externally provisioned keys. Count independent operator identities, not merely keys. Check coverage, timestamps and the locally required assurance level; the bundle cannot lower that requirement.

3. Authenticate the chain anchor. Starting from a separately trusted checkpoint, process supplied consensus light-client bootstrap/updates, committee transitions, signatures and finality branches under the configured fork rules. Verify the execution-payload binding and its block hash. For earlier queried blocks, verify a supplied ancestry chain to the authenticated anchor. Ethereum light clients explicitly require out-of-band configuration and a trusted root; execution-payload branches connect execution data to beacon headers. Light-client bootstrap requirements, Sync protocol, Execution-payload binding

4. Verify each query according to its label. Check state proofs, receipt/transaction inclusion, complete receipt reconstruction, or witnessed execution as described above. Attestation-only entries remain explicitly attestation-only.

5. Check coverage and freshness. Require contiguous requested ranges, exact filters, no silent truncation and no error converted into an empty result. For “latest” questions, enforce an age bound against a trusted clock. A stale but valid snapshot is not a fresh answer.

6. Recompute interpretation. Decode bytes using the referenced ABI; rerun aggregation, decimal conversion and rounding. A proven byte string does not authenticate an incorrect ABI or the analyst’s interpretation.

Emit a machine-readable report with separate outcomes for transport integrity, signer policy, anchor authentication, query correctness, completeness and freshness. Store its digest with the answer.

For other chains, require a chain-specific header/finality adapter. Do not let “EVM-compatible” automatically select Ethereum’s consensus verifier.

How answerers cite and use it

Require citations such as:

Balance: X tokens as of block N (0x…).
[ceb:sha256:<bundle-id>/q17#/decoded/balance; execution-replayed]

An aggregate should cite both its source records and a reproducible calculation artifact:

Total: Y across blocks A–B.
[ceb:<id>/q21; logs-complete; calculation=sha256:<digest>]

The resolver should expose exact raw bytes, decoded values, relevant block identities and verification results. Examples above are citation syntax, not actual chain results.

Mount all referenced objects locally before dispatch; a URL alone does not solve network sandboxing. Give every seat the same deterministic index and local query interface. Record a runtime-computed digest receipt, and have the panel refuse cross-bundle comparisons.

If a seat needs another query, collect it centrally and publish an append-only revision to all seats before rescoring. Prohibit private live-data supplementation in the scored answer. Missing evidence should produce a specific missing-query report, rather than count as a reasoning failure.

Per-job cost

Here is an illustrative cold-cache job, using three independent collectors. Assume each retrieves ten calls, five receipts, five single-block log queries, six block objects and three account-proof queries.

Alchemy’s current method table lists 26 CU per call, 60 per log query, and 20 each for the other methods in this example. Its pricing page lists $0.525 per million CU. These are a costing reference; independent operators will have different contracts. Method costs, Pricing

Acquisition item	CU per collector
10 calls	260
5 receipts	100
5 log queries	300
6 block objects	120
3 account proofs	60
Total	840

Thus the illustrative RPC acquisition charge is:

3 × 840 × $0.525 / 1,000,000 = $0.001323 per cold job.

That is an attested acquisition baseline, not an all-in price for complete logs or witnessed calls.

For full log verification over those five blocks, five eth_getBlockReceipts requests add 100 CU per collector under the same table, or $0.0001575 across three collectors. Receipt payload volume, reconstruction work, historical availability and provider support still need measurement. Tracing and additional witness acquisition are outside this estimate. Method costs

Use this all-in accounting formula:

cost = RPC + witness/replay compute + signing/verification compute + storage + delivery + allocated node operations

For planning—not as measured vendor prices—assume a 1 MB bundle, six seats, $0.10/GB delivery and $0.03/GB-month storage. That adds about $0.0006 delivery and $0.00003 for one month’s storage. Allocate another $0.001–$0.01 for ordinary verification and service overhead until benchmarked: approximately $0.003–$0.012 per small cold job, excluding model tokens and substantial witness generation.

Cache exact query/block-hash objects across jobs. A hit avoids reacquisition, while verification, delivery and freshness checks remain. Set explicit limits on blocks, receipts, bytes and execution gas; wide historical scans need separate budgets, not the small-job estimate.

Removing the server as the trust authority

Use three complementary controls:

• Independent collectors: require, for example, two matching signatures from three separately operated collectors with distinct infrastructure and upstream nodes. Collectors execute the signed query plan themselves. Under the stated assumption of at most one dishonest collector, a false result cannot obtain two honest-policy signatures. Three keys owned by the swarm server do not satisfy this model.
• Independent roots and verification: distribute trust keys, checkpoint policy and verifier releases outside the server’s control. Prefer cryptographic proofs plus local replay. The residual assumptions are the checkpoint, consensus security and verifier correctness; proof verification cannot create its own trustworthy starting root. Ethereum light-client requirements
• Detect equivocation and preserve availability: publish job/revision-to-bundle mappings in an append-only log witnessed by independent operators. Have seats exchange their computed digests and require witnessed log consistency. Mirror content-addressed objects outside the server. Freeze the question’s query plan and coverage so selective evidence collection is reviewable.

In attestation mode, independent collectors remain trusted for truth and completeness. In proof mode, the server’s role becomes packaging and delivery; withholding can still stop a job, but acceptance of false evidence requires defeating the independently configured verification policy.

---

Sources offered but not confirmed by this machine:

• https://eips.ethereum.org/EIPS/eip-2718 — does not contain the quoted text
• https://ethereum.github.io/consensus-specs/specs/altair/light-client/light-client/ — does not contain the quoted text
• https://github.com/ethereum/consensus-specs/blob/master/specs/altair/light-client/sync-protocol.md — does not contain the quoted text