CertiK reviewed Decentraland (Decentraland Token) on 11 Sep 2021: 10 findings, 0 critical; none marked fixed.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 1 | 0 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 9 | 0 | 0 |
In the contract `MANAToken`, the role `owner` has the authority over the following function: - `mint()` - `finishMinting()` - `transferOwnership(address newOwner)` - `pause()` - `unpause()` Any compromise to the `owner` account may allow the hacker to take advantage of this and: - transferring ownership to the malicious account address. - mint an uncapped amount of tokens to any user including the owner itself. - maliciously pausing and unpausing the contract
The following functions are not invoked in any of the contracts contained within the project's scope: - `transferOwnership()` - `pause()` - `unpause()` - `approve()` - `mint()` - `finishMinting()` - `allowance()` - `balanceOf()` The functions that are never called internally within the contract should have external visibility.
The `require` function should be used to ensure valid conditions that cannot be detected until execution time. This includes conditions on inputs or return values from calls to external contracts.
The zero address is not verified when calling the following function. - `transfer()` - `transferFrom()` - `approve()` - `mint()`
Functions that affect the status of sensitive variables should be able to emit events as notifications to customers. - `transferOwnership()`
All variable types within Solidity are initialized to their default "empty" value, which is usually zeroed out representation. Particularly: - `uint` / `int`: All `uint` and `int` variable types are initialized at `0` - `address`: All `address` types are initialized to `address(0)` - `byte`: All `byte` types are initialized to their `byte(0)` representation - `bool`: All `bool` types are initialized to `false` - `ContractType`: All contract types (i.e. for a given `contract ERC20 {}` its contract type is `ERC20`) are initialized to their zeroed out address (i.e. for a given `contract ERC20 {}` its default value is `ERC20(address(0))`) - `struct`: All `struct` types are initialized with all their members zeroed out according to this table
The contract has an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging as compiler-specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.
The return values `balance` and `remaining` are not used.
`assert` should only be used when the condition should never happen.
The linked variable declarations do not have a visibility specifier explicitly set.
| Address | Chain | Source code |
|---|---|---|
| 0x0f5d…c9420x0f5d2fb29fb7d3cfee444a200298f468908cc942 | Chain: Ethereum | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us