reconciliation contract keeps only the latest Merkle batch, breaking old proofs

[martinzhames]

Category: bug

Problem

dabdub_contracts/contracts/reconciliation/src/lib.rs's submit_merkle_root (lines 46-65) writes the new ReconciliationBatch to the single key DataKey::CurrentBatch, unconditionally overwriting whatever batch was previously stored — there is no historical list or mapping of past batches. verify_settlement (lines 68-86) always reads DataKey::CurrentBatch and compares a caller-supplied Merkle proof against only that one, current root.

Impact

Once a new batch is submitted (presumably on a recurring cadence, e.g. daily), any Merkle proof generated for a payment that was reconciled in a previous batch becomes permanently unverifiable via verify_settlement, even though it was validly included and provable at the time — the proof will compute a root that no longer matches DataKey::CurrentBatch. Any auditor, dispute-resolution flow, or downstream contract that needs to verify a settlement from more than one reconciliation cycle ago has no on-chain way to do so. (Separately, verify_settlement's return value is inverted from what its name suggests — it returns true when a mismatch is detected per its own doc comment, which is a footgun for any integrator who assumes true means "verified OK".)

Suggested fix

Store batches keyed by an incrementing batch ID or by submitted_ledger (e.g. DataKey::Batch(u32)) in addition to (or instead of) a single "current" pointer, and let verify_settlement accept a batch identifier so proofs remain verifiable against the historical root they were actually generated for. Also consider renaming verify_settlement or flipping its return semantics to reduce integrator error.

[Adeyinka0123]

@Adeyinka0123 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello Maintainer, I’d be happy to take ownership of this issue and deliver a quality pull request once completed.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Adeyinka0123 to this issue.

[basseyanam03-dev]

@basseyanam03-dev has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d be happy to take this issue. I’ve looked through the requirements and have a plan for approaching the implementation. I’ll investigate the existing code and dependencies, make the required changes, verify the behaviour with tests, and provide a concise PR explaining what was changed. I can start immediately and will communicate any blockers during development.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @basseyanam03-dev to this issue.

[echoripplestudio]

@echoripplestudio has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @echoripplestudio to this issue.

[drips-wave]

Congratulations, @echoripplestudio! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @echoripplestudio: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊