Skip to main content

Maple Finance - Maple Token

Smart Contract Security Assessment

Mar. 12, 2021

Maple

SUMMARY​

ID
Description
STATUS
L1
Non-ERC20 tokens will fail on transfer
dismissed
A1
Unused modifier
resolved
A2
Compiler bugs
resolved

ABSTRACT​

Dedaub was commissioned to perform a security audit on Maple Finance’s MPL token smart contracts. The audit was performed on commit 2a7ba59c355d6b31cc0d251a5f967b21753f566.

Two auditors worked on this task. We reviewed the code in significant depth, assessed the economics of the protocol and processed it through automated tools. We also decompiled the code and analyzed it, using our static analysis (incl. symbolic execution) tools, to detect possible issues.


SETTING AND CAVEATS​

The audit was conducted in parallel, and should be considered together, with our audit of the maple-core module. The two codebases share code (almost the entire MPL token functionality is used in the FDT token variants of maple-core).

The token has finite minting, built into its constructor. 10M MPL are ever minted. Burn functionality is included but is unused. The documentation clearly states how the tokens are to be used (in a Balancer pool). This constitutes an element of trust outside the smart contracts themselves.


VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues that affect the functionality of the contracts. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

Category
Description
CRITICAL
Can be profitably exploited by any knowledgeable third-party attacker to drain a portion of the system’s or users’ funds OR the contract does not function as intended and severe loss of funds may result.
HIGH
Third-party attackers or faulty functionality may block the system or cause the system or users to lose funds. Important system invariants can be violated.
MEDIUM
Examples:
  • User or system funds can be lost when third-party systems misbehave.
  • DoS, under specific conditions.
  • Part of the functionality becomes unusable due to a programming error.
LOW
Examples:
  • Breaking important system invariants but without apparent consequences.
  • Buggy functionality for trusted users where a workaround exists.
  • Security issues which may manifest when the system evolves.

Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.


CRITICAL SEVERITY​

[No critical severity issues]


HIGH SEVERITY​

[No high severity issues]


MEDIUM SEVERITY​

[No medium severity issues]


LOW SEVERITY​

L1​

Non-ERC20 tokens will fail on transfer​

L1LOW
Non-ERC20 tokens will fail on transfer
dismissed

Dismissed

MPL token fundsToken will always be USDC which is fully compliant.

The ERC20 transfer operations in ERC2222 will fail, if the underlying fundToken is not fully compliant with the ERC20 standard, as it is possible that they do not return a boolean value to indicate the success of the call (most notable exception is USDT).

It is recommended that the OpenZeppelin SafeERC20 wrappers be used, to ensure compatibility with such tokens.



OTHER/ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend addressing.

A1​

Unused modifier​

A1ADVISORY
Unused modifier
resolved

The onlyFundsToken modifier in MapleToken is dead code. It is suggested that the unused modifier be removed.

A2​

Compiler bugs​

A2ADVISORY
Compiler bugs
resolved

The contracts were compiled with the Solidity compiler v0.6.11 which has some known minor issues (but relatively few, compared to earlier versions). We have reviewed the issues and do not believe them to affect the contract. More specifically, at the time of writing, there are 2 known compiler bugs associated with the Solidity compiler v0.6.11:

  • Copying an empty bytes or string array from memory to storage can cause data corruption:

  • This could affect the name and symbol fields (without leading to any exploits). Assuming that the Maple Token contract is deployed correctly, with a non-empty name and symbol, this should not be an issue.

  • Direct assignments of storage arrays with an element size <= 16 bytes (more than one values fit in one 32 byte word) are not correctly cleared if the length of the newly assigned value is smaller than the length of the previous one. (No such array is ever stored.)



DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.


ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.