batch_payments::create_batch payment IDs can collide across concurrent batches

[martinzhames]

Category: bug

Problem

In dabdub_contracts/contracts/batch_payments/src/lib.rs, create_batch's payment ID derivation (lines 137-143) is:

let seed: u64 = (env.ledger().sequence() as u64) * 1000 + i as u64;
let id_bytes: BytesN<32> = env.crypto().sha256(&Bytes::from_slice(&env, &seed.to_be_bytes())).into();

The seed depends only on the current ledger sequence number and the item's index within its own batch (i, 0..19) — it does not include the calling merchant, any per-invocation nonce, or the batch's contents. The author's own comment acknowledges this: "In production this would be a proper UUID or hash of inputs." Separately, the PaymentRecord struct (lines 30-38) is defined but never constructed or stored anywhere in the contract — grep -n "PaymentRecord" src/lib.rs only matches its own definition.

Impact

Two different merchants (or the same merchant twice) invoking create_batch within the same ledger — plausible any time multiple batch-payment transactions land in the same ~5-second ledger close — will independently compute identical seed values for equal indices and therefore generate identical id_bytes for unrelated payments. Since the contract emits these IDs as the sole PaymentCreated event identifier and stores no on-chain record to detect or reject a duplicate, an off-chain indexer keying on this ID can silently conflate two different merchants' payments.

Suggested fix

Include merchant and a monotonically increasing per-contract counter (or the full PaymentInput contents) in the hash preimage, matching the approach already used in admin_timelock::schedule_change (Counter in storage, hashed together with content). Either persist PaymentRecords on-chain for auditability or remove the unused struct.

[shemaiahdelia03-cmd]

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

Hi! I would like to work on this issue for this wave. I have experience with this stack, understand the requirements, and I'm ready to submit a clean, well-tested PR once assigned. Could you please assign it to me?

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

[WALEY-OPS]

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

Hi. Let me work on the issue.

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

[ibochivincent-lang]

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

I’d like to work on Issue #1024 because the current payment ID generation can produce the same ID for unrelated payments created in the same ledger. This can cause off-chain systems to treat different merchant payments as if they were the same payment.

I will first review contracts/batch_payments/src/lib.rs and the existing ID-generation patterns in related contracts, especially admin_timelock::schedule_change, to understand how counters and hashed inputs are currently handled.

I will then update create_batch so each payment ID is derived from data that uniquely identifies the payment. I will use the merchant identity together with a persistent per-contract counter or the full payment input, following the safest pattern already established in the repository.

The counter will be stored in contract storage and advanced safely for each generated payment ID, ensuring separate calls made in the same ledger cannot accidentally produce identical IDs.

I will also review the existing PaymentRecord definition. If the record is intended to support on-chain auditability, I will determine how it should be stored and used. If it is genuinely unnecessary for the current contract design, I will avoid leaving unused structures that imply functionality the contract does not provide.

I will add regression tests covering two different merchants creating batches in the same ledger, repeated batch creation by the same merchant, multiple payment indices within a batch, and concurrent-style calls. The tests will verify that every generated payment ID remains unique.

I will also check the emitted PaymentCreated events to ensure the new identifiers remain

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

[MJigah]

@MJigah 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 @MJigah to this issue.

[drips-wave]

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

🧑‍💻 @MJigah: 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 🌊