Finding
Official documentation exposes bucketListHash, txSetHash,
txSetResultHash, LedgerCloseMeta, SCP envelopes, and archive retrieval in
separate places, but does not provide one current explanation of what a Stellar
transaction-inclusion proof is—or is not.
The resulting ambiguity encourages two opposite errors: describing the Bucket
List state commitment as a Bitcoin/Ethereum-style per-transaction Merkle proof,
or treating an RPC/Horizon/indexer row as a self-authenticating cryptographic
proof. Stellar does not expose a standard compact one-call per-transaction
Merkle branch through these surfaces.
Evidence
Current Docs explain ledgers, history archives, SCP, transaction sets, and close
metadata separately. A current repository and Docs-search recheck found no guide
for “transaction inclusion proof” that joins those commitments into a supported
verification procedure or explicitly distinguishes full-XDR recomputation from a
compact Merkle branch.
Additional recorded evidence:
- official Ledger, LedgerCloseMeta, and history/archive documentation
- stellar-xdr ledger/SCP value definitions
- stellar-core TxSetFrame and LedgerManager hash construction
- live recheck 2026-07-14: current stellar-docs search and repository code search expose the component concepts but no transaction-inclusion-proof guide or compact-proof claim boundary
- GT-41 recurrence: document timestamping guidance required historical transaction/result and ledger-close evidence because the current Manage Data entry is mutable
Recommendation
Add a transaction verification guide that distinguishes:
- Bucket List state commitments from transaction-set/result commitments;
scpValue.txSetHash over the full serialized transaction set and
txSetResultHash over the full result set;- retrieval evidence from cryptographic recomputation;
- ledger-header hash-chain verification from SCP/quorum finality assumptions.
Provide a reproducible full-XDR verification recipe and state explicitly that
it is not a compact standard per-transaction Merkle proof. Name any supported
light-client or archive tooling separately with its trust model.
Source Record
This was found by the downstream Raven eval/improvements loop and recorded as sd-014 (stellar-docs, discovered 2026-07-10).
Public source record: improvements/stellar-docs/sd-014-transaction-inclusion-proof-boundaries.md
Immutable source snapshot: a4608d080232
Resolution Handoff
When a fix is deployed, please link the resolving issue or PR to the source record above and notify Raven through:
https://github.com/kalepail/stellar-raven/issues/new?template=upstream-improvement-ready.yml&title=%5Bupstream-ready%5D%20sd-014%3A%20
Include the finding id, resolving issue/PR, deployed version or timestamp, and the smallest live recheck. Raven independently verifies the upstream surface before changing the finding to fixed-upstream; issue closure or a merged PR alone is not treated as proof. After a distinct reviewer repeats the live check, the active finding is retired to Raven's resolved ledger; a commit-pinned snapshot is preserved when available.
Finding
Official documentation exposes
bucketListHash,txSetHash,txSetResultHash, LedgerCloseMeta, SCP envelopes, and archive retrieval inseparate places, but does not provide one current explanation of what a Stellar
transaction-inclusion proof is—or is not.
The resulting ambiguity encourages two opposite errors: describing the Bucket
List state commitment as a Bitcoin/Ethereum-style per-transaction Merkle proof,
or treating an RPC/Horizon/indexer row as a self-authenticating cryptographic
proof. Stellar does not expose a standard compact one-call per-transaction
Merkle branch through these surfaces.
Evidence
Current Docs explain ledgers, history archives, SCP, transaction sets, and close
metadata separately. A current repository and Docs-search recheck found no guide
for “transaction inclusion proof” that joins those commitments into a supported
verification procedure or explicitly distinguishes full-XDR recomputation from a
compact Merkle branch.
Additional recorded evidence:
Recommendation
Add a transaction verification guide that distinguishes:
scpValue.txSetHashover the full serialized transaction set andtxSetResultHashover the full result set;Provide a reproducible full-XDR verification recipe and state explicitly that
it is not a compact standard per-transaction Merkle proof. Name any supported
light-client or archive tooling separately with its trust model.
Source Record
This was found by the downstream Raven eval/improvements loop and recorded as sd-014 (stellar-docs, discovered 2026-07-10).
Public source record: improvements/stellar-docs/sd-014-transaction-inclusion-proof-boundaries.md
Immutable source snapshot: a4608d080232
Resolution Handoff
When a fix is deployed, please link the resolving issue or PR to the source record above and notify Raven through:
https://github.com/kalepail/stellar-raven/issues/new?template=upstream-improvement-ready.yml&title=%5Bupstream-ready%5D%20sd-014%3A%20
Include the finding id, resolving issue/PR, deployed version or timestamp, and the smallest live recheck. Raven independently verifies the upstream surface before changing the finding to
fixed-upstream; issue closure or a merged PR alone is not treated as proof. After a distinct reviewer repeats the live check, the active finding is retired to Raven's resolved ledger; a commit-pinned snapshot is preserved when available.