CodeHawks Escrow Contract - Competition Details

Summary

No time enforcements in Escrow contracts

Vulnerability Details

There is no specification or timelines, time bounds or time constraints in the Escrow contracts or logic to ensure functions can be called in certain order e.g initiateDispute() must never be called too early

1. There is no indication how long seller can take on job

2. There is no indication after how long seller signal or offchain delivery finishes buyer must call confirmReceipt() or initateDispute()

3. There is no indication after how long dispute is initiated arbiter must resolve dispute

Impact

Medium: This lack of clarity around timelines leads to problems as parties can take as long or too early as they want disadvantaging the other parties. Consider arbiter who will just continue feedbacking offline they are still arbitrating but continue to delay because nothing is enforced in contracts
By having clear timelines and constraints it ensures fairness, protections of parties involved as stated seller may never call confirmReceipt, arbiter may never resolve dispute

Tools Used

Manual Analysis

Recommendations

It is recommended each Escrow contract has parameters that may be unique to it or universal across all Escrow related to the following

1. uint256 timeJobCompletion; -> the time until which seller must complete job else buyer now allowed to call initiateDispute if time lapses

2. uint256 timeArbitration -> time constraint in which arbiter must resolve dispute

3. uint256 timeConfirmReceipt -> if there is a function or timestamping when seller/auditor finishes job, then buyer must either confirmReceipt or initiateDispute within a period since seller/arbiter finished else arbiter can be allowed to initiateDispute()

The above needs to be thought through thoroughly to ensure what time contraints can be implemented and if those times lapse or are too early who can call which functions and in which order