The Escrow Contract exhibits a potential vulnerability that may result in funds being indefinitely trapped in the contract in case of emergencies.
To start the auditing process, buyers deploy & fund the escrow contract, the funds are processed in two distinct ways:
Without an Arbiter: In this scenario, the funds can only be released to the seller by the buyer.
With an Arbiter: When an Arbiter is involved, the funds can be released to the seller by the buyer and the buyer/seller can initiate a dispute then only the Arbiter has the authority to decide how much funds should be released to the seller or returned to the buyer.
The protocol allows buyers to choose whether or not to include an Arbiter in the process.
The vulnerability lies in the first way, where there is no Arbiter involved. In such cases, the buyer lacks a mechanism to withdraw the funds in case of unexpected events.
For instance, consider a scenario where a buyer and seller have a history of successful transactions and mutual trust. They both trust each other more than their wives. The buyer initiates an audit with the same seller without an arbiter, who was ready to perform the agreed-upon work, even performing the audit. However, an unforeseen emergency happens, such as an accident, leads to the seller's death or poor health condition. Consequently, the buyer is left with no way to recover the funds, resulting in a permanent entrapment of funds within the escrow contract.
Although this represents the worst-case scenario, there are other potential situations. For instance, if the buyer funds the contract using a specific Token like USDT and subsequently discovers that the seller's account has been blacklisted by the USDT platform, now the Tokens cannot be sent to the seller nor taken out by the buyer, leading lock of funds in the escrow contract.
The identified vulnerability may result in the freezing of funds within the escrow contract.
Mandatory Arbiter Selection: It is strongly advised to make the selection of an Arbiter mandatory during the contract setup. Allowing the contract to proceed without an Arbiter should not be permitted. This measure will safeguard buyers in emergency situations, enabling them to retrieve their funds.
Allow setting for the arbiter during the audit (after deployment) by adding a setArbiter()
function in the escrow contract. In case of emergencies or disputes, this functionality will come in handy.
Or any other way for a buyer to pull out funds only in emergency situations. Which I think will be hard to implement & even risky for the sellers, so 1 & 2 both are the best options.
By implementing these recommendations, the Escrow Contract will be significantly strengthened, providing a more reliable and secure platform for all parties involved.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.