How to Stake CLO

Cold staking is a protocol that rewards long-term coin holders for staking their Callisto coins.
Blog

Maker (MKR) Security Audit Report

Maker (MKR) Security Audit Report

Here is the report of the Maker (MKR) Security Audit performed by the Callisto Network security department in March 2019.

About Callisto Network and the security department:

Utilizing Callisto Network capabilities, we have established a free-for-all system of smart-contracts auditing, to this end, Callisto Network has founded the Callisto security department and deploys treasury funds to pay security auditors for auditing smart-contracts, to reduce risk/flaw in smart-contracts and improve the adoption of programmable blockchains for the whole crypto industry.

Maker (MKR) specificities :

Deployed at :

https://etherscan.io/address/0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2#code

Source Code:

https://gist.github.com/yuriy77k/527895b7b7a1c00c867970cc9450aa60

Platform: ETH

Number of lines: 236

Maker (MKR) Security Audit Report

1. Summary

Maker (MKR) smart contract security audit report performed by Callisto Security Audit Department

Audit Top 200 CoinMarketCap tokens.

MakerMKR
Circulating Supply1 000 000
Total Supply1 000 000
Max SupplyNo Data

https://makerdao.com/

2. In scope

  1. DSToken.sol

3. Findings

In total, 5 issues were reported including:

  • 5 low severity issues.

No critical security issues were found.

3.1. Known vulnerabilities of ERC-20 token

Severity: low

Description

  1. It is possible to double withdrawal attack. More details here.
  2. Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here.

Recommendation

Add the following code to the transfer(_to address, ...) function:

require( _to != address(this) );

3.2. ERC20 Compliance — event missing

Severity: low

Code snippet

  1. initial supply; mint function
  2. burn function and Transfer event

Description

  1. According to ERC20 standard when coins are minted a Transfer event should be emitted.
  2. The burn function also should emit the Transfer event.

3.3. It is necessary to check the input address of transfer function.

Severity: low

Code snippet

Description

  1. In the transfer and transferFrom functions, input destination address is not checked for a null value and the funds can be transferred to a 0x0-address.
  2. Also it is needed to check input address for setOwner and setAuthority function.

3.4. Default approve value

Severity: low

Code snippet

Description

In case if the approve function is called with only “beneficiary” address parameter then max-uint value(!) of token will be approved to recipient.

Also the approved value doesn’t decrease when trnsferFrom called in case of max-uint approved value. It is some sort of ERC20 discrepancy.

3.5. Owner’s Privileges

Severity: low

Code snippet

Description

The contract owner allow himself to pause functions of contract (transfer, transferFrom, approve, mint, burn).

4. Conclusion

The audited smart contract can be deployed. Only low severity issues were found during the audit.

5. Revealing audit reports

https://gist.github.com/yuriy77k/02f341422e1fef9497e952914df2094f

https://gist.github.com/yuriy77k/d79699c49391902276555b5c731c8ead

https://gist.github.com/yuriy77k/1a7589c329e88736d9066effde0fc902

Topics: