As of 4 Nov 2026, Trossard has 1 audit report on Trustblock, by CertiK, dated 30 Jun 2023. That report lists no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Nov 2026. Trustblock does not review code.
Newest first
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 2 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 0 | 11 | 0 |
In the contract `BEP20` the role `_owner` has authority over the functions shown in the diagram below.  - `Frozening(address _addr)`: This function freezes the account at address `_addr`, preventing it from conducting any transactions. The privileged role that can call this function is the `owner`. - `deleteFromFrozen(address _addr)`: This function unfreezes the account at address `_addr`, allowing it to conduct transactions again. The privileged role that can call this function is the `owner`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the projects. --- In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.  - `transferOwnership(address newOwner)`: This function allows the current owner to transfer the ownership of the contract to a new owner. The privileged role that can call this function is the current `owner`. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the projects.
Open the reportAll of the `TROSS` tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.
Open the reportIt is expected that invocations of the form `transfer(recipient, amount)` succeed and return `true` if * The address in `recipient` is not the zero address, * `amount` does not exceed the balance of address `msg.sender`, * transferring `amount` to the address `recipient` does not lead to an overflow of the recipient's balance, and * the supplied gas suffices to complete the call. Nevertheless, the `transfer` function of `BEP20` fails in some of those admissible cases.
Open the reportIt is expected that invocations of the form `transfer(recipient, amount)` where the address in `recipient` equals the address in `msg.sender` (i.e. self-transfers) succeed and return `true` if * The value in `amount` does not exceed the balance of `msg.sender` and * the supplied gas suffices to complete the call. Nevertheless, the `transfer` function of `BEP20` fails in some of those admissible cases.
Open the reportIt is expected that invocations of the form `transfer(recipient, amount)` succeed and return `true` if * The address in `recipient` is not the zero address, * `amount` does not exceed the balance of address `msg.sender`, * transferring `amount` to the address `recipient` does not lead to an overflow of the recipient's balance, and * the supplied gas suffices to complete the call. Nevertheless, the `transfer` function of `BEP20` fails in some of those admissible cases.
Open the reportIt is expected that invocations of the form `transfer(recipient, amount)` where the address in `recipient` equals the address in `msg.sender` (i.e. self-transfers) succeed and return `true` if * The value in `amount` does not exceed the balance of `msg.sender` and * the supplied gas suffices to complete the call. Nevertheless, the `transfer` function of `BEP20` fails in some of those admissible cases.
Open the reportIt is expected that invocations of `transferFrom(from, dest, amount)` succeed and return `true` if * the value of `amount` does not exceed the balance of address `from`, * the value of `amount` does not exceed the allowance of `msg.sender` for address `from`, * transferring a value of `amount` to the address in `dest` does not lead to an overflow of the recipient's balance, and * the supplied gas suffices to complete the call. Nevertheless, the `transferFrom` function of `BEP20` fails in some of those admissible cases.
Open the reportIt is expected that invocations of `transferFrom(from, dest, amount)` where the address in `dest` equals the address in `from` (i.e. self-transfers) succeed and return `true` if: * The value of `amount` does not exceed the balance of address `from`, * the value of `amount` does not exceed the allowance of `msg.sender` for address `from`, and * the supplied gas suffices to complete the call. Nevertheless, the `transferFrom` function of `BEP20` fails for some self-transfers in these admissible cases.
Open the reportIt is expected that invocations of `transferFrom(from, dest, amount)` succeed and return `true` if * the value of `amount` does not exceed the balance of address `from`, * the value of `amount` does not exceed the allowance of `msg.sender` for address `from`, * transferring a value of `amount` to the address in `dest` does not lead to an overflow of the recipient's balance, and * the supplied gas suffices to complete the call. Nevertheless, the `transferFrom` function of `BEP20` fails in some of those admissible cases.
Open the reportIt is expected that invocations of `transferFrom(from, dest, amount)` where the address in `dest` equals the address in `from` (i.e. self-transfers) succeed and return `true` if: * The value of `amount` does not exceed the balance of address `from`, * the value of `amount` does not exceed the allowance of `msg.sender` for address `from`, and * the supplied gas suffices to complete the call. Nevertheless, the `transferFrom` function of `BEP20` fails for some self-transfers in these admissible cases.
Open the reportThe linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.
Open the reportThe `_transfer` function of the provided contract does not check whether the `sender` and `recipient` are the same address. This oversight may lead to unnecessary contract calls and event emissions, wasting gas and potentially causing confusion.
Open the reportIt is not recommended to use Solidity's `transfer()` and `send()` functions for transferring native tokens, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=555 0x06806458405C55E40D75Bd0fE1732500Cd1C229c.transfer(msg.value); ``` - `TROSSToken.constructor` uses `transfer()`.
Open the reportThe reports name a repository or files. Open a report to see its scope.
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="trossard"></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