How Smart Is Your Smart Contract?
Free Article Limit This Month
As some recent incidents have shown, sometimes smart contracts might not be "smart" (i.e., flawless) enough to achieve what people intend them to achieve, and sometimes even an unintended error in smart contracts could result in substantial, unbearable losses to developer teams and/or investors.
One example of loss due to unintended errors in smart contracts is the launch and sale of Akutars on April 22, which is a "collection of unique 3D avatars based on [Micah Johnson's] popular Aku NFT series" that generated over $19 million in sales with support of celebrities. While the "big mint" was set to occur, it was unexpectedly halted shortly after the launch because a user named "USER221" discovered vulnerabilities of the smart contract underlying the project and temporarily suspended the withdrawals and refunds to urge the Aku team to fix the vulnerabilities. The launch was then halted again after it resumed for only a few hours, and this time, as a result of the smart contract failing to "account for multiple NFT mints within the same transaction," 11,539 ETH (then worth $34 million) were locked and remained inaccessible "forever."
Despite this unfortunate development, several sources had pointed out that such incident could have been avoided if mitigating measures had been adopted to remediate the smart contract errors or if preventive steps had been put in place to lower the risk. While we are unable to share coding tips that make the smart contracts "smarter," we certainly can share some contract tips that reduce potential risk exposures and thus make the development and use of smart contracts "safer." If you are thinking about retaining a team to code and deploy smart contracts for you, it would be best to reflect (some of) the items listed below in the contract governing the development, deployment or audit of smart contracts.
(i) Parties' Responsibilities:
It goes without saying that the party retained to code and deploy smart contracts will bear the responsibility to deliver operational smart contracts. However, the hiring party may consider enumerating certain non-conventionally-included requirements as part of the retained party's default responsibilities, such as (a) the retained party must set up a bug bounty program (with the bounty awards being fully or partially funded by the hiring party) before the smart contract is put into work, or (b) the smart contract is subject to an independent third party's review and verification (based on preset standards mutually agreed upon by the contracted parties), and the retained party's performance will not be deemed complete until the third party concludes its review in accordance with the preset standards.
(ii) Fail-safe and Fallback Mechanisms:
Given the nature of smart contracts, the hiring party could request the retained party in the agreement to develop an embedded fail-safe mechanism for the contracted smart contract so that the hiring party could elect to "kill" the smart contract and release the funds/tokens when certain issues arise. Also, because external data might sometimes be used to make smart contracts operable or operational, the hiring party could also specify in an agreement that certain back-up oracles should serve as the reference in the event the primary oracle lapses or becomes unavailable (rather than allowing the retained party to resort to other external data source at its own discretion).
Notice of Smart Contract Malfunction or Breach
The concept of reporting an (infrastructure) malfunction or breach is most commonly seen in highly-regulated industries. For instance, financial institutions licensed to operate in New York are mandated to disclose certain cybersecurity events to the competent authority. Depending on the nature of the project and the risk exposures, the hiring party may also require the retained party to notify the hiring party of certain events relating to smart contract malfunction or breach within a prescribed period of time (e.g., 24 hours) from the time such event is known to the retained party. The hiring party could also specify the mitigating or remedial steps that the retained party must follow in the agreement, such as (a) performing a thorough review and error shooting for the whole smart contract pursuant to a mutually agreed upon standards and procedures, (b) terminating the smart contract and transferring all the tokens stored therein to the hiring party's designated address, and/or (c) indemnifying the hiring party for the loss incurred from the described malfunction or breach (such stipulation would usually require corresponding stipulations in representations and warranties, indemnity clause and the provisions governing the parties' obligations).
Although codes can never be completely error-free, parties involved in developing and deploying codes could still mitigate such risks through contractual arrangement. Having obligations and agreed upon arrangements in writing might not prevent a smart contract from crashing (or being hacked), but it can certainly help the parties avoid the worst outcome when such crash occurs.
ALM expressly disclaims any express or implied warranty regarding the OnPractice Content, including any implied warranty that the OnPractice Content is accurate, has been corrected or is otherwise free from errors.