XCAmpleforth

CertiK1 Feb 2021Files named in the report

Audit

CertiK reviewed AMPL (XCAmpleforth) on 1 Feb 2021: 14 findings, 0 critical; all marked fixed.

No open critical findings

Open the report Open AMPL’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings14

Statuses are the security firm’s own, from its report.

Severity	Open	Acknowledged	Fixed
Critical	0	0	0
High	0	0	0
Medium	0	0	2
Low	0	0	12

MediumPotential Loss of PrecisionFixed

The Ampleforth protocol follows a strict rebase policy whereby consequent rebases will never incur loss of precision in the underlying values used to transact with the currency as denoted by their `uFragments.sol` supply adjustment analysis. Multiple epoch rebases that can accumulate, however, do not guarantee the same constraints in the rebase operation of the cross-chain Ampleforth in comparison to the main-chain Ampleforth.

MediumPotential Loss of PrecisionFixed

LowApproval Amount DesyncFixed

As the Ampleforth is unique in the sense that it is a rebasing token, a set amount of permitted tokens to be transmitted via an approval can have a different underlying gon value due to supply rebases.

LowFunction SimplificationFixed

The linked functions toggle the `bool` state of the `whitelistedBridgeGateways` mapping to adjust whether a particular bridge is whitelisted to burn and mint tokens in the satellite chain.

LowFunction SimplificationFixed

The linked functions toggle the `bool` state of the `whitelistedBridgeGateways` mapping to adjust whether a particular bridge is whitelisted to withdraw and deposit tokens to the vault.

LowIncorrect Utilization of `chainid`Fixed

The linked code relates to the utilization of the `chainid` variable which is meant to represent the current chain's ID for usage in the EIP-712 and EIP-2612 standards. As noted in the EIPs, by computing the `chainid` once the standards' functions are susceptible to cross-chain attacks in case of a fork.

LowInexistent Error MessageFixed

Error messages should always accompany a `require` invocation to aid in both explaining what the imposed check is meant to achieve as well as aid in debugging processes.

LowInexistent Error MessageFixed

Error messages should always accompany a `require` invocation to aid in both explaining what the imposed check is meant to achieve as well as aid in debugging processes.

LowMutability Specifiers MissingFixed

The linked variables are assigned to only once, either during their contract-level declaration or during the `constructor`'s execution.

LowMutability Specifiers MissingFixed

The linked variables are assigned to only once, either during their contract-level declaration or during the `constructor`'s execution.

Show 4 more

LowPotential Incompatibility w/ Underlying TokenFixed

The vault is meant to be utilized with the Ampleforth main-chain currency on Ethereum which currently conforms to the ERC-20 standard properly, however, this may not always be the case.

LowUsage of Deprecated RepresentationFixed

The maximum value of `int256` is currently represented by the contract using bitwise shifts and negations whereas the current standard utilizes the special type keyword to wrap the type and access the max member i.e. `type(int256).max` , as introduced in Solidity 0.6.8.

LowUsage of Deprecated RepresentationFixed

The maximum value of `uint256` and `uint128` is currently represented by the contract using bitwise negations whereas the current standard utilizes the special type keyword to wrap the type and access the max member i.e. `type(uint256).max` , as introduced in Solidity 0.6.8.

LowUsage of memory Variable Over storageFixed

The linked line performs a `return` statement on the `globalAMPLSupply` stored in `storage` after performing a successful equality check of this value with the in-memory `newGlobalAMPLSupply` variable.