Skip to content

[SECURITY][IDEMPOTENCY] Scope contract references by operation, pool, and actor to prevent cross-pool preemption #181

Description

@Obiajulu-gif

Summary

Reference receipts use a single global key. An unrelated user can submit a predictable reference first on another pool/operation, causing the legitimate request to fail as a duplicate.

Repository evidence

  • contracts/chainmove-pool/src/lib.rs defines DataKey::Reference(String) without operation, pool, or actor scope.
  • Replay validation rejects the same key when stored receipt fields differ.

Scope

  • Derive the idempotency key from domain/version, operation kind, pool ID, actor/participant, and external reference.
  • Provide a compatibility rule for existing receipts.
  • Hash or bound composite keys to control storage cost.

Acceptance criteria

  • The same external reference can safely exist in unrelated scoped domains.
  • A duplicate within the same scope remains idempotent and conflicting payloads are rejected.
  • No user can preempt another pool/actor solely by guessing its reference.

Tests

  • Cross-pool, cross-operation, cross-actor, exact-retry, and conflicting-retry tests.
  • Migration test for legacy global receipts.

Non-goals

  • Extending receipt retention; that is tracked separately.

Activity

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 OSSMaybe RewardedIssue may be eligible for a GrantFox rewardThird CampaignCampaign: Third Campaign

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions