Skip to content

payment-router: guard against double-release and reentrancy #58

Closed

Description

@joelpeace48-cell

Problem

Once value movement lands, the classic failure is a state transition that is
checked but not committed before an external call — allowing a second release
against the same escrow.

What to do

  • Apply checks-effects-interactions: validate, write the state transition,
    then call the token contract. Never the other way round.
  • Make release and refund idempotent — a second call on a settled escrow
    returns AlreadySettled, not another transfer.
  • Add invariant tests: the sum of all escrow balances always equals the
    contract's token balance; no escrow ever pays out more than it took in.
  • Review every cross-contract call for what a hostile token implementation
    could do on the callback path.

Acceptance criteria

  • Checks-effects-interactions applied to all value paths
  • Double-release returns an error and moves no funds
  • Balance-conservation invariant asserted in tests
  • Adversarial token-contract case considered and documented

Notes

This is the issue an external auditor will look at first. Worth writing the
invariants down before the implementation, not after.

Activity

  1. definurse13 commented on Aug 24, 2026

    @definurse13
    Contributor

    Hi Team, I’m a full-stack developer with a strong blockchain background, and I’m confident I can resolve this issue quickly and effectively. I’ll deliver a clean, reliable solution with immediate attention to detail, ensuring it’s completed as soon as possible. Please assign it to me—I’m ready to get started right away.
    ETA6hrs.

  2. joelpeace48-cell commented on Aug 24, 2026

    @joelpeace48-cell
    ContributorAuthor

    @definurse13 , you are assigned, ensure all ci pipeline passes

  3. grantfox-oss commented on Aug 24, 2026

    @grantfox-oss

    🦊 GrantFox — @definurse13 has been assigned to this issue as part of the Third Campaign campaign!

    Next steps:

    1. Open a Pull Request referencing this issue (e.g., Closes #58)
    2. Your PR will be reviewed by the FinesseStudioLab maintainers

    Good luck! Track your progress on GrantFox.

  4. grantfox-oss commented on Aug 24, 2026

    @grantfox-oss

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

    @definurse13's PR #86 was approved and merged by @joelpeace48-cell.

    🏆 @definurse13: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (48 total points). Track your full progress on GrantFox.

    👏 Great work, @definurse13! Keep contributing to FinesseStudioLab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSThird CampaignCampaign: Third Campaignarea:payment-routerSettlement contractdifficulty:expertFunds, auth, or consensus-critical; needs reviewpriority:criticalBlocks everything else; security or build-breakingtype:securityAuth, funds, secrets, or abuse surface

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions