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.
Problem (spike / open-ended)
escrow::REFUND_GRACE_SECONDS(escrow/src/lib.rsline 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 untilunlock_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_timeonly 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 letcreate_escrowcallers tune this tradeoff, but that raises genuinely open design questions rather than a mechanical fix.Open questions
grace_secondsbecome a newcreate_escrowparameter, 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)?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?Investigation steps
Review how comparable escrow designs (traditional multisig/timelock escrow patterns) parameterize dispute/grace windows, and prototype a per-escrow
grace_seconds: u64field withMIN_GRACE_SECONDS/MAX_GRACE_SECONDSbounds enforced increate_escrow, then evaluate whether the addedEscrowstruct field size/storage cost is justified relative to the fixed-constant status quo.Testing strategy
Once a design is chosen: bounds-validation tests (
grace_secondsbelowMIN/aboveMAXrejected), and a test confirmingrefund_escrow's grace-period check now reads the per-escrow value instead of the global constant.