Smart contract risk
The program does what the code says - not what was meant
What can happen
A smart contract can as a rule no longer be changed once published. What is in it stands.
A flaw in it is therefore something other than a flaw in an ordinary application. In a banking app a flaw is noticed, somebody fixes it, done. In a smart contract the flaw keeps running - and anyone can read the code and find it.
Typically one of three things happens:
| The order can be turned around | The program pays out and updates the balance afterwards. Anyone who asks again in between is paid again - the balance has not been updated yet. |
|---|---|
| A calculation is wrong | A value is rounded wrongly, scaled wrongly or compared in the wrong unit. The program calculates correctly with a wrong figure. |
| A check is missing | A function only the operator should call does not check who is calling it. |
In none of these cases was anything “cracked”. There is no password that was guessed and no server anyone broke into. The attacker uses the program exactly as written.
How that turns into a financial loss
Not every flaw costs money. What matters is whether the contract holds funds and whether the flaw allows them to be moved.
Putting money into a protocol hands it to the contract. It is then no longer in your own wallet but in the program. If it flows out from there, there is no place that fetches it back: no bank, no reversal, no deadline.
The loss does not only hit whoever exploited the flaw or let it be exploited. It hits everyone whose funds were in the same contract - often pro rata, sometimes in full.
A documented case
DOCUMENTED CASEThe DAO, June 2016
The case is still the textbook example, because it shows both properties: the contract did exactly what it was programmed to do, and the only way to reverse it was to split the entire blockchain. That is not a remedy available for an individual case.
Can this be the subject of a cover?
In principle yes. Smart contract risk is the risk with the longest history of cover products.
The reason is that it describes well: a particular contract, at a particular address, loses funds in a particular period. That is a condition that can be verified - on the blockchain every movement is visible.
What the wording has to answer
Seven questions. Anyone who works through them on a real product knows more than any product description will tell them.
| Which contract exactly? | An address, not a product name. Protocols consist of several contracts - rarely are all of them covered. |
|---|---|
| What counts as the event? | Is an outflow of funds enough? Does it have to be permanent? Does it have to exceed a minimum amount? |
| From when does it count as having occurred? | With the transaction, with the determination, or only on confirmation by a named body? |
| What is excluded? | Commonly excluded: price losses, the user’s own mistakes, attacks on the blockchain itself, events outside the named contract. |
| What if funds come back? | In larger incidents part is sometimes returned. Does that reduce the payment, and how is it calculated? |
| Who determines that something happened? | The provider, a vote, an expert - and how long may that take? |
| What is the payment denominated in? | The same token, a stablecoin, or an amount? And at what rate? |
Terms used here
-
What it is, why it cannot be changed and why anyone can read the code.
-
Several smart contracts that together make an application.
-
Where your own assets sit as long as they are not in a contract.