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.

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