Chiliz Chain

Resonance Security20 Aug 2025Files named in the report

Resonance Security reviewed Chiliz (Chiliz Chain) on 20 Aug 2025: 14 findings, 0 critical; 13 marked fixed, 1 open.

No open critical findings

Open the report Open Chiliz’s security record

Report stored on IPFS. Content hash QmeStSagkKWN6iarSnhSzD2rTjebwwygT8fhETVn4YB8Uh

Trustblock does not review code.

Findings14

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

Severity	Open	Fixed
Critical	0	0
High	1	0
Medium	0	2
Low	0	11

MediumDecimals Calculation May Be WrongFixed

In the FTSwap protocol, the owner updates or adds new pairs. In case any of these old Fan Tokens have decimals, the calculation of the new Fan Tokens would be incorrect, since the formula used would return fewer tokens than expected.Suppose:oldFT has 2 decimals (unexpected).newFT has 18 decimals.If a user swaps 1 oldFT token, the calculation is:newFTAmount = 1 * 10**18 / 10**2 = 1 * 1e18 / 100 = 1e16So the user receives 0.01 of the intended amount (1e16 instead of 1e18).

MediumMissing Initializer Call For Parent ContractFixed

The Staking3 contract does not call __ReentrancyGuard_init() in the initialize() function, which means that the internal reentrancy status variable will not be set. This can lead to the nonReentrant modifier not blocking reentrant calls, leaving the contract vulnerable to reentrancy attacks or, in some cases, functions with nonReentrant may revert unexpectedly because the guard is in an uninitialized state.

Low_swapWithBurnAndMint Allows 0 Amount SwapsFixed

The function does not check if oldFTAmount is zero. This could allow zero-amount swaps, which may cause unnecessary events and state changes.

LowFloating PragmaFixed

The project uses floating pragmas ^0.8.23.This may result in the contracts being deployed using the wrong pragma version, which is different from the one they were tested with. For example, they might be deployed using an outdated pragma version which may include bugs that affect the system negatively.

LowIncorrect Initialization Order On initialize()Fixed

According to best practices, the inherited smart contracts should be initialized according to their inheritance order, from the most base-like to the most derived.

LowMissing Limits In setUnstakePeriod()Fixed

The setUnstakePeriod() function does not have an upper limit of the seconds needed to claim tokens. This may affect the user experience and it may not be practical.

LowMissing Reentrancy Guard Modifier On swapStakedTokens() And swapStaked()Fixed

The swapStakedTokens() function unstakes, claims, swap tokens transfers them back from user to stake the new token. The swapStaked() function calls burn and mint functions in _swapWithBurnAndMint(). As these functions transfer tokens to user and call external contracts, it is important to use the nonReentrant modifier in the same way as in the rest of the protocol.

LowMissing Zero Address Validation On setFtStaking()Fixed

Input parameter in setFtStaking() function is not being validated against the Zero Address.Mistakes can be made by the owner of the smart contract, allowing for unwanted transactions to take place in the future.

LowMissing Zero Address Validation On setFtSwap()Fixed

Input parameter in setFtSwap() function is not being validated against the Zero Address.Mistakes can be made by the owner of the smart contract, allowing for unwanted transactions to take place in the future.

LowMixed Usage Of Initializing Functions In initialize()Fixed

The initialize() function in the Staking3 contract uses both internal and external functions to set roles grantRole() and _grantRole(). Using both works, but is not necessary. Using only _grantRole is simpler and more efficient for setup, as it is possible to avoid unnecessary access checks during initialization.

Show 3 more

LownewFTAmount Is Not EmittedFixed

The Swapped event in _swapWithBurnAndMint() fucntion does not include newFTAmount. This may affect potential off-chain accounting.

LowTest Cases Not Working ProperlyFixed

The ERC20BurnableMintable contract located in the Staking3.t.sol does not implement the burn() function. The tests that use this function will not work properly.

LowUnnecessary Initialization Of Variables With Default ValuesFixed

In the Solidity programming language, all variables are automatically initialized to a default value corresponding to their type when they are declared. For example, integer types are initialized to 0, boolean types to false, and address types to 0x0000000000000000000000000000000000000000. Explicitly initializing variables to these default values when they are declared is therefore redundant, and since each operation in a contract costs gas, it results in unnecessary gas costs. This could potentially impact the contract's efficiency and the cost of executing its functions.Several instances of this issue are found across the code base.