BA-101 — Harden contract invocation replay and nonce handling

[MaryammAli]

• Type: Security
• Affected area: contracts service, contract interfaces
• BackendAcademy
• Summary: Invocation history and feature flags need durable replay protection before accepting state-changing calls.
• Acceptance criteria: Nonces or idempotency keys are required, stored atomically, and rejected when reused or stale.

[339mon]

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

Hello! I’d be glad to take ownership of this issue.

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

[Talentgift24-ux]

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

i would love to work on this issue

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

[Oluwasegun6921]

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

Hello , I’d be happy to work on this issue and submit a clean pull request once the implementation is complete.

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

[aliyuzuliehat25]

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

Hi, I’d like to work on this security issue.

Affected area
I’ll first trace the contracts service invocation flow and contract interfaces to understand how state-changing calls are currently authenticated, constructed, submitted, and persisted. I’ll also identify where invocation history and feature flags interact with these calls.

Proposed approach
I’ll implement durable replay protection using the repository’s existing persistence and contract patterns, preferring nonces or idempotency keys as appropriate.

The implementation will ensure that:

• Every applicable state-changing invocation carries a nonce or idempotency key.
• The replay-protection state is persisted atomically with the relevant state transition.
• Reused identifiers are deterministically rejected.
• Stale nonces/requests are rejected according to a clearly defined validation rule.
• Failed transactions do not consume or leave behind inconsistent replay-protection state.
• Concurrent submissions cannot bypass the replay check.
• Existing compatible callers are preserved or given an explicit migration path.

I’ll document the security invariants and failure behavior so the replay-protection guarantee is reviewable.

Test strategy
I’ll add focused coverage for:

• Valid first-time invocations.
• Replayed/non-reused identifiers.
• Stale nonces.
• Concurrent duplicate submissions.
• Failed state-changing calls and retry behavior.
• Atomic persistence/rollback behavior.
• Existing contract-interface compatibility.
• Regression coverage for current feature-flag behavior.

Validation
I’ll run the relevant contract-service and contract tests, build/type checks, linting, and the complete repository CI suite, including applicable security/contract checks. I’ll provide the exact commands and results in the PR.

Estimate
I estimate 2–3 days for investigation, implementation, security-focused testing, and validation.

I’ll wait for assignment before starting implementation.

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

[dollfins]

@dollfins 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 by implementing an atomic check-and-set mechanism for nonces within the contracts service to ensure state-changing calls are properly protected against replay. I plan to focus on the storage layer to ensure these keys are persisted durably before the execution of any contract invocation.

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

[Timrossid]

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

Hi maintainer, I’ve reviewed this issue and I would love to work on this. I am confident that I will be able to resolve it neatly.

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

[drips-wave]

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

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

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@Timrossid's PR #738 was approved and merged by @MaryammAli.

🏆 @Timrossid: You earned 35 FoxPoints for this contribution! Your current tier: Builder (1,028 total points). Track your full progress on GrantFox.

👏 Great work, @Timrossid! Keep contributing to BlockDash-Studios.

[drips-wave]

This issue has been completed by @Timrossid as part of the Stellar Wave Program's 8th Wave 🥳

😎 @Timrossid: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.