As of 30 Oct 2026, Chiliz has 8 audit reports by 3 security firms on Trustblock; the latest is by Halborn, dated 29 Jan 2026. Those reports list no open critical findings. It also holds 1 deployed contract on 1 chain.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Oracle Contracts | Security firm: Halborn | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · halborn.com |
| Chiliz Chain | Security firm: Resonance Security | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · IPFS |
| Fan Token Swap | Security firm: Halborn | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · halborn.com |
| Fan Token Contract V2 | Security firm: Halborn | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · halborn.com |
| Chiliz - Pepper - Smart Contract Audit | Security firm: Halborn | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · halborn.com |
| Chiliz - V2 Genesis Contracts | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| Chiliz Token | Security firm: CertiK | Date: | Scope: 1 address on Ethereum | No open critical findings | Open · skynet.certik.com |
| Chiliz | Security firm: CertiK | Date: | Scope: Files named in the report | 1 critical finding, fixed | Open · skynet.certik.com |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 3 | 0 | 1 |
| Medium | 3 | 0 | 3 |
| Low | 10 | 1 | 24 |
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportIn 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).
Open the reportThe 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.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe function does not check if oldFTAmount is zero. This could allow zero-amount swaps, which may cause unnecessary events and state changes.
Open the reportThe 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.
Open the reportAccording to best practices, the inherited smart contracts should be initialized according to their inheritance order, from the most base-like to the most derived.
Open the reportThe 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.
Open the reportThe 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.
Open the reportInput 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.
Open the reportInput 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.
Open the reportThe 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.
Open the reportThe Swapped event in _swapWithBurnAndMint() fucntion does not include newFTAmount. This may affect potential off-chain accounting.
Open the reportThe ERC20BurnableMintable contract located in the Staking3.t.sol does not implement the burn() function. The tests that use this function will not work properly.
Open the reportIn 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.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the report| Address | Chain | Source code |
|---|---|---|
| 0x3506…b4af0x3506424f91fd33084466f402d5d97f05f8e3b4af | Chain: Ethereum | Source code: Verified source |
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="chiliz"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something 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