How to Stake CLO

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

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

Source Code



Number of lines


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.

Circulating Supply1 000 000
Total Supply1 000 000
Max SupplyNo Data

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


  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.


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


  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


  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


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


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