UUNSE - Audit

CertiK1 address on BNB Chain

CertiK reviewed UUNSE (UUNSE - Audit) on 18 Oct 2022: 9 findings, 0 critical; 1 acknowledged, 8 open.

No open critical findings
Open the reportOpen UUNSE’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings9

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

SeverityOpenAcknowledgedFixed
Critical000
High010
Medium000
Low800
LowDeclaration Naming ConventionOpen

One or more declarations do not conform to the [Solidity style guide](https://solidity.readthedocs.io/en/v0.7.3/style-guide.html#naming-conventions) with regards to its naming convention. Particularly: - `camelCase`: Should be applied to function names, argument names, local and state variable names, modifiers - `UPPER_CASE`: Should be applied to `constant` variables - `CapWords`: Should be applied to contract names, struct names, event names and enums Constant variable `_maxSupply` is not in `UPPER_CASE`: ```solidity=345 uint256 private constant _maxSupply = 10000000000 * 1e18; ```

LowFunction Should Be Declared ExternalOpen

The functions which are never called internally within the contract should have external visibility for gas optimization.

LowOpenZeppelin library code included in source codeOpen

It is highly recommended NOT to include OpenZeppelin library code directly in source code, but import the original library to minimize risk because even slight changes to the library code may lead to critical/major vulnerabilities/bugs. The latest version of the OpenZeppelin libraries is 4.7.3.

LowPotential Risks on Approval/TransferFrom MethodsOpen

The `approve` function could be used in an attack that allows a spender to transfer more tokens than the owner of the tokens ever wanted to allow the spender to transfer. Here is a possible attack scenario: Alice allows Bob to transfer N of Alice's tokens (N>0) by calling approve method on token smart contract passing Bob's address and N as method arguments. After some time, Alice decides to change from N to M (M>0) the number of Alice's tokens Bob is allowed to transfer, so she calls `approve()` method again, this time passing Bob's address and M as method arguments. Bob notices Alice's second transaction before it was mined and quickly sends another transaction that calls `transferFrom()` method to transfer N Alice's tokens somewhere. If Bob's transaction will be executed before Alice's transaction, then Bob will successfully transfer N Alice's tokens and will gain the ability to transfer another M tokens. Before Alice noticed that something went wrong, Bob calls `transferFrom()` method again, this time to transfer M Alice's tokens. So, Alice's attempt to change Bob's allowance from N to M (N>0 and M>0) made it possible for Bob to transfer N+M of Alice's tokens, while Alice never wanted to allow so many of her tokens to be transferred by Bob. ERC20 API: An Attack Vector on Approve/TransferFrom Methods: https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#heading=h.m9fhqynw2xvt

LowRedundant Code ComponentsOpen

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

LowToo Many DigitsOpen

Literals with many digits are difficult to read and review. ```solidity=345 uint256 private constant _maxSupply = 10000000000 * 1e18; ```

LowVariables Could be Declared as `constant`Open

Variables `_name`, `_symbol` and `_decimals` could be declared as `constant` since these state variables are hardcoded in the constructor and never to be changed.

LowVariables That Could Be Declared as ImmutableOpen

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Contracts in scope1

AddressChainSource code
0xa39964d6212c3753c3ef8dada0d46311504ea18bChain: BNB ChainSource code: Verified source

Part of UUNSE’s security record

UUNSE
Audits1 audit by 1 firmLast audit Oct 2022, by CertiK.
Critical findingsNo open critical findingsIn 1 report.
Open UUNSE’s security record

Security firm

CertiK

1,044 projects reviewed · 1,375 reports · latest May 2025

See CertiK’s audits

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