You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
escrow::contribute and milestones::contribute accept new funds after deadline + GRACE_PERIOD, when anyone can already refund or cancel #568
Neither contribute checks the deadline. Once now >= deadline + GRACE_PERIOD, escrow's refund and milestones' cancel_milestone_after_deadline are permissionless, yet both contracts still take new contributions. A late sponsor's tokens go into an escrow or milestone that's already in its wind-down window: they can be refunded (or pro-rata redistributed, for milestones) by any third party in the next transaction, and the sponsor pays fees for a contribution that can never fund work.
Suggested fix
Reject contribute with InvalidDeadline (or a new DeadlinePassed) once now >= deadline, and test both contracts.
Submitted PR #571 resolving this issue across both escrow and milestones.
Details
In escrow::contribute, reject calls with Error::InvalidDeadline if env.ledger().timestamp() >= escrow.deadline.
In milestones::contribute, reject calls with Error::InvalidDeadline if env.ledger().timestamp() >= milestone.deadline.
Added InvalidDeadline = 22 to milestones::Error.
Added unit tests in both crates verifying rejection at the exact deadline timestamp, past the deadline, and past the grace period, while verifying valid contributions succeed prior to the deadline.
Submitted PR #763 rejecting escrow::contribute with Error::InvalidDeadline and milestones::contribute with Error::DeadlinePassed once now >= deadline, with regression unit tests for both contracts: #763
I am interested in taking up "escrow::contribute and milestones::contribute accept new funds after deadline + GRACE_PERIOD, when anyone can already refund or cancel" and implementing a production-grade solution.
I have reviewed the problem description and acceptance criteria for this issue. I have a clear, tested implementation ready with defensive error handling and 100% green CI proof.
I will deliver a clean, well-tested, and production-ready PR promptly upon assignment. Kindly assign this issue to me.
Activity
urielit1313-creator commentedon Oct 13, 2026
Submitted PR #571 resolving this issue across both
escrowandmilestones.Details
escrow::contribute, reject calls withError::InvalidDeadlineifenv.ledger().timestamp() >= escrow.deadline.milestones::contribute, reject calls withError::InvalidDeadlineifenv.ledger().timestamp() >= milestone.deadline.InvalidDeadline = 22tomilestones::Error.Payout Address (Base USDC):
0xfE777c43e4B0A24fFA1527eD520d1E7f9ECED483huangji6693-max commentedon Oct 26, 2026
Submitted PR #763 rejecting
escrow::contributewithError::InvalidDeadlineandmilestones::contributewithError::DeadlinePassedoncenow >= deadline, with regression unit tests for both contracts: #763ranjeet150 commentedon Oct 26, 2026
Hello,
I am interested in taking up "escrow::contribute and milestones::contribute accept new funds after deadline + GRACE_PERIOD, when anyone can already refund or cancel" and implementing a production-grade solution.
I have reviewed the problem description and acceptance criteria for this issue. I have a clear, tested implementation ready with defensive error handling and 100% green CI proof.
I will deliver a clean, well-tested, and production-ready PR promptly upon assignment. Kindly assign this issue to me.
Thank you!