Skip to content

escrow::create_escrow allows arbiter to equal depositor or beneficiary, defeating dispute protections #18

Description

@abayomicornelius

Problem (spike / open-ended)

escrow::REFUND_GRACE_SECONDS (escrow/src/lib.rs line 47) is a compile-time constant fixed at one week (7 * 24 * 60 * 60), applied uniformly to every escrow created by the contract regardless of the escrow's amount, duration until unlock_time, or the relationship between the parties.

Why this is worth investigating

The module doc comment explains the grace period's purpose clearly: it exists so "a depositor [can't] griev[e] the beneficiary by yanking funds back right as they become claimable." But a single fixed value has real tradeoffs depending on use case: a short-duration escrow (e.g. unlock_time only a day out) with a full extra week of grace-period lock-up afterward may be disproportionate for time-sensitive use cases, while a very long-duration, high-value escrow might reasonably want a longer grace period than one week to give the beneficiary more room to notice and act. Making it a per-escrow parameter (with sane bounds) would let create_escrow callers tune this tradeoff, but that raises genuinely open design questions rather than a mechanical fix.

Open questions

  • Should grace_seconds become a new create_escrow parameter, and if so, what bounds should be enforced (a minimum to preserve the anti-griefing property meaningfully, a maximum to avoid indefinitely locking depositor funds even when no dispute exists and the beneficiary has simply vanished)?
  • Should the grace period scale with unlock_time - creation_time (e.g. a percentage of the lock duration) rather than being an absolute value, so short and long escrows get proportionally appropriate protection?
  • Interacts with the "no early mutual-consent exit" gap (separate issue in this batch) — if both parties could agree to close an escrow early, the grace-period tuning question becomes less urgent for the cooperative case and matters primarily for the adversarial one.

Investigation steps

Review how comparable escrow designs (traditional multisig/timelock escrow patterns) parameterize dispute/grace windows, and prototype a per-escrow grace_seconds: u64 field with MIN_GRACE_SECONDS/MAX_GRACE_SECONDS bounds enforced in create_escrow, then evaluate whether the added Escrow struct field size/storage cost is justified relative to the fixed-constant status quo.

Testing strategy

Once a design is chosen: bounds-validation tests (grace_seconds below MIN/above MAX rejected), and a test confirming refund_escrow's grace-period check now reads the per-escrow value instead of the global constant.

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardOfficial Campaign | FWC26Campaign: Official Campaign | FWC26contractsSmart contract logicsecuritySecurity concernvery hardVery difficult / senior-level bounty issue

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions