Rethinking DAPP security standards

Dexaran
4 min readAug 8, 2021

This article describes observations on general DAPP security enhancement approaches with the conception of layered security in mind.

For those not familiar with “layered security” I’d like to pinpoint it in a the following paradigm: You can’t design a perfect security enhancement method for your app. There is still some probability that it will fail. That’s why you must design your app while using multiple different security enhancement methods and the probability of that they will all fail at the same time is orders of magnitude lower.

The value of security

What determines how secure a DAPP is? — In most cases its how much money is lost due to software faults in this particular DAPP. Perfectly secure DAPP must not cause any (software-related) monetary losses.

It is easy enough to measure the value of money. A couple years ago I could buy a good PC with 1 BTC. Today I can buy a car with the same 1 BTC.

The whole term “security” is hyped in our industry even though normal users have little to no understanding of how exactly it is related to them. The value of security is ridiculously hard to measure for a normal user. It only becomes clear to them when something gets hacked and they lose money.

It is still hard for a normal user to measure a level of security of a DAPP if he has no experience in programming.

When we initially launched Callisto Network one of our goals was to solve the problems of hackable DAPPs. It became clear then that the main problem of DAPP hacks does not lie in the procedure of DAPP development. Instead the main problem is which DAPPs are getting adopdet across the platform.

Security for masses, security for humans

The main problem is that for the average user there is no method for determining whether it is safe put his money in a particular DAPP or not.

Indeed there are security audits and bug bounties. It is reasonable to assume that a DAPP that passed a security audit is better than a DAPP that did not. However the main goal is not to make one DAPP better than the other but to save user’s funds.

One security audit can be better than the other. One security auditor can be more experient than the other. Bugbounty can be too low to attract talented developers capable of revealing bugs prior to the launch. These aspects are totally unclear for an average user and only a security expert can evaluate it properly.

What happens if security auditor fails? — The user of a hacked DAPP will lose funds.

The problem of the current DAPP ecosystem is that it puts the burden of deciding whether something is safe or not on a mere user without giving him sufficient information to make the correct conclusion.

Designing a DAPP with 3 levels of defense

There are three levels of security that will make a DAPP as fault-tolerant as possible:

  • Top-level: Insurance (read this article for more info)
  • Medium-level: Security audits, bug bounties and other default security enhancement methods (read self-security systems for more info)
  • Low-level: Automated anomaly detection systems

A DAPP must be insured. If its insurance covers potential losses then it is clear for a user that it is safe to put the funds in a DAPP because he can get a refund in case of a hack.

A DAPP must be audited. What happens if security auditor fails now? — Insurance department will lose funds. Users will get a refund.

A DAPP must implement an anomaly detection system to reduce the amount of required insurance. In this system the anomaly detection is not a security enhancement measure on its own but the addendum to the insurance part.

More about insurance

There must be a separate pool of funds not used by the DAPP which is allocated to refund the losses in case of a hack. This can be done by the DAPP developers or a separate company.

The question is how much of the insurance does the DAPP require? — The contract developer must have the ability to cover the losses in case of a hack. As the result the contract must be insured with the same amount as the amount of funds it allows to go out.

For example it is reasonable to have an on-chain exchange contract insured with the same amount as its total daily withdrawal limit (or the max contract balance in most cases because the contract allows to withdraw all funds to all users at any time).

In the case of money printing contracts (such as swap contracts and bridges), it is prudent to insure them for as much as the total amount of the printing allowed.

Here comes the idea of reducing the allowed amount of funds that the exchange can allocate for withdrawals or a bridge can print.

The simplest anomaly detection

The primitive anomaly detection extends from the idea of restricting withdrawals and money printing capabilities of contracts.

The anomaly detection can be a simple script that halts the operability of a contract if it has exceeded the specific amount of funds in a limited period of time.

How often do exchange contracts get their total balances drained by 30% in a single day? — In this event it may be reasonable to investigate whether this is a result of a hacking attempt or just the significant market movement.

At the other hand this allows the contract developer to only insure the contract for 30% of its total balance because it can only lose 30% in case of a hack.

--

--