[milestone_escrow] release_milestone() has a defensive balance check but no protection against concurrent release races

[Wilfred007]

Description

release_milestone() checks for insufficient escrow balance defensively, but there's no mechanism preventing two release calls for different milestones on the same escrow from being processed in a way that double-counts available balance. In a single-threaded Soroban execution model this may not be exploitable today, but the lack of an explicit invariant check (e.g. re-deriving available balance from storage right before transfer) makes this fragile under future contract changes (e.g. batched or cross-contract calls).

Where

contracts/milestone_escrow/src/lib.rs (~line 381-385)

Acceptance Criteria

• Document the current concurrency model assumptions explicitly in code comments
• Add an invariant assertion that re-derives remaining balance from milestone state before transfer
• Add a test simulating sequential releases across milestones and asserting balances never go negative or double-spend

[leocagli]

Hi, I'd like to work on this issue. I can add a test that verifies release_milestone() fails when the balance drops below the expected amount (defensive check path). Could you assign me?

[leocagli]

Leo Cagliero (Starmaker, trabajando en Cosmos LATAM y Open Stellar). Usar una bandera released por milestone en el storage. En release_milestone(), verificar primero que milestone.released == false antes de proceder. Si ya está marcado, retornar AlreadyReleased en lugar del panic defensivo. ¿Me asignan?

[AugistineCreates]

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

PLEASE ASSIGN

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

[Timrossid]

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

Hi maintainer, I’ve reviewed this issue and I would love to work on this. I've worked on similar issues and I am confident that I will be able to resolve it neatly. I can have a PR ready for review soon.

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

[RemmyAcee]

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

I can take this on. I've gone through the details and will provide a well-tested solution aligned with the project standards.

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

[devonahi]

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

Hello maintainer, I can handle this issue.

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

[drips-wave]

Congratulations, @devonahi! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

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