Perspectives | Questions that DeFi users should ask developers

Over the past few months, the DeFi ecosystem has experienced tremendous turmoil, and several unexplored defects have also been reported under several attacks.

Although bugs are unavoidable in the code, there are still many ways to reduce the frequency of defects and the negative effects of defects.

As an auditor, we want to help DeFi users ask some sharp questions; the purpose of asking these questions is to allow developers to seriously consider the priority of system security, and to allow users to distinguish the answer Get good deals, and then put money into those deals.

The following questions can help users understand the position of the DeFi development team on security. The answers may not be right or wrong, and not every team (or independent developer) has the resources to take all aspects into consideration. In any case, users have the right to know this information to determine the risks they are willing to take.

• Transfers are transactions. Decentralized transactions may look like this.
• Timestamp Capital | bZx Incident Research Report
• Viewpoint | Lightning loan risk may be higher than expected, security is a problem that DeFi boom must solve

We hope that the following questions will lead to more positive discussions.

Administrator rights

Most of the mainstream DeFi protocols have some centralized mechanism-allowing specific "administrator" addresses to intervene in the operation of the protocol in a tough way.

Although this is good for security, it means that you must trust that these "admins" will not abuse their privileges; and if these administrators are hacked, the consequences of their private key disclosure will be even more serious. serious.

The administrator account can be in the following forms: single address, multi-signature wallet, or voting process managed by DAO. Well,

• What can administrators do?
  • Pause the entire system?
  • Modify account balance?
  • Set up a token / user whitelist / blacklist?
  • Upgrade a subsystem?
  • Upgrade the entire system? (Equivalent to everything …)
  • Other permissions?
• If the above actions are taken, is there a mechanism to delay execution?
• If there is a delay, how long is it?
• How many people have administrator rights?
• How much administrator consent do I need to take before doing the above?
• What permissions are controlled by the on-chain governance program (that is, DAO)?
• Where should I go to learn about the proposal to update the agreement?

The answers to some of these questions can already be tracked through DefiWatch .

External dependencies

Because it is an open network, Ethereum is full of malicious attackers, so developers cannot assume what kind of behavior will be taken by contracts outside this system. But in many DeFi applications, this assumption has to be made, because the service itself is constructed on some existing contracts.

These questions can help users understand the risks of the project's external dependencies.

• What Oracle (oracle) does your system depend on?
• What exchange does your system depend on?
• What third-party smart contract (eg OpenZeppelin) do you use to build the system?
• What tokens does your system support, and what do you expect from the behavior model of these tokens (contracts)?

3. Reliable disclosure system and reward plan

For talented hackers, attacking the DeFi protocol has a strong monetary temptation to them. Creating a reward plan can motivate everyone to discover and expose loopholes, not to drill them. For white hat hackers, exposing code vulnerabilities through incentive systems is also a great way to increase their reputation-it's both good and not illegal.

Any company that wants to run a DeFi agreement or a business that involves hosting money online should have a reward system. You can ask the following questions about their reward plan and disclosure process:

• Is your contract code visible to everyone?
• Is it easy to find a secure contact from your website and git codebase?
• Does your contract have a rewards program?
• Which contracts are in the reward program?
• What is the specific amount of the reward plan?
• Have you paid the bonuses of the reward program?
• Have you ever refused to pay for a bug report?
• Can you easily find the details of the reward program from your website and git codebase?

Ideally, this information should be placed under the "website.com/security" page and used with Github's SECURITY.md feature.

4. Emergency plan

When faced with some security emergencies, new news is flowing like a tide, and users continue to ask tricky questions on Twitter, Telegram, Discord … At this time, it is difficult for developers to respond clearly. emergency.

So if there is an emergency plan, it can prove that the project is moving in a safe direction. It may not be realistic to ask the project to disclose their complete plan, but we can still ask the following basic questions to understand:

• Do you have an outline of a plan to deal with emergencies?
• What emergency situations does your emergency plan apply to?
• If your system is upgradeable, are these upgrade steps documented?
• If you find that a system loophole may put your funds at risk, can you preemptively protect your funds through emergency plans?

5. Audit and security development

The audit is not a panacea, and the content of the audit is more or less different, but it is a crucial step before any DeFi contract is deployed.

The following questions may not have "correct answers", but the knowledgeable community people should be able to see the development team's position on security from the project answers.

• When was your last audit?
• How much effort was put into this audit (one hour for a standard developer)?
• Which agency does the audit?
• Is the audit report public?
• Are there any parts of your system that are not covered by the audit?
• Have you updated your contract since the last audit? If so, what was updated?
• Which security team do you work with for a long time?
• Do developers do a code review of each other (at least check the Solidity files) before merging the code?
• What is the percentage of your contract code that has been unit tested?
• Have you used other security analysis tools during the audit?

Original link: https://diligence.consensys.net/blog/2020/03/questions-defi-users-should-be-asking-defi-developers/ Author: John Mardlin translation & proofreading: IAN LIU & A sword

We will continue to update Blocking; if you have any questions or suggestions, please contact us!