Numoen security record

As of 14 Oct 2026, Numoen has 1 audit report on Trustblock, by CertiK, dated 7 Dec 2022. That report lists 1 open critical finding.

Critical findings
1 open critical finding
Reported in “Numoen” by CertiK, Dec 2022. Not marked fixed in that report. See the findings
Open the latest report
Your label, live
Get the label for your site

Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Statuses are the security firms’ own. Trustblock does not review code.

Audits1

Newest first

AuditSecurity firmDateScopeCritical findingsReport
NumoenSecurity firm: CertiKDate: Scope: Files named in the report1 open critical findingOpen · skynet.certik.com

Findings8

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

SeverityOpenAcknowledgedFixed
Critical100
High000
Medium000
Low304
LowCustom errors require solidity version 0.8.4 andNumoen · CertiK · 7 Dec 2022Fixed

An issue relating to custom error messages used in contracts can occur with the current solidity compiler settings. The solidity version is currently set to `pragma solidity ^0.8.0`, however the solidity version needs to be at least 0.8.4 or above to [support custom errors](https://blog.soliditylang.org/2021/04/21/custom-errors/).

Open the report
LowFunction `transfer` of Contract `ERC20` Does NotNumoen · CertiK · 7 Dec 2022Fixed

It is expected that calls of the form `transfer(recipient, amount)` fail if the recipient address is the zero address.

Open the report
LowFunction Should Be Declared ExternalNumoen · CertiK · 7 Dec 2022Fixed

The functions which are never called internally within the contract should have external visibility for gas optimization. #### ERC20.sol ```solidity=61 function approve(address spender, uint256 amount) public virtual returns (bool) { ``` --- ```solidity=69 function transfer(address to, uint256 amount) public virtual returns (bool) { ``` --- ```solidity=83 function transferFrom( ``` --- ```solidity=109 function permit( ```

Open the report
LowPotential Loss of Precision Could lead to revertNumoen · CertiK · 7 Dec 2022Fixed

The loss of precision on the calculation in L161~162 could cause the invariant check revert. ```solidity=161 uint256 amount0 = PRBMath.mulDiv(r0, liquidity, _totalSupply); uint256 amount1 = PRBMath.mulDiv(r1, liquidity, _totalSupply); if (!verifyInvariant(amount0, amount1, liquidity)) revert InvariantError(); ``` The `verifyInvariant()` requires the exact number of two tokens to be matched according to the formula. However, the loss of precision could cause the two token's amount to be unmatched, thus causing the revert on the invariant check.

Open the report

Contracts

No deployed address is recorded for these audits.

The reports name a repository or files. Open a report to see its scope.

The repositories and files the reports name

Show this on your site

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.

Content

Facts

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.

Fixed as
Language

Style

Layout
Theme
Accent
Corners

Format

Size
Date
Embed as
HTML
<head>
<script src="https://widget.trustblock.run/project-widget.min.js" defer></script>
</head>
<body>
<div
data-tb-project-widget
data-tb-project-slug="numoen"
></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