Digiverse security record
As of 3 Nov 2026, Digiverse has 3 audit reports by 2 security firms on Trustblock; the latest is by CertiK, dated 15 Jan 2024. Those reports list 2 criticals acknowledged and not fixed. It also holds 1 deployed contract on 1 chain.
Record last updated . It holds audits, findings and contracts up to Nov 2026, and incidents up to Oct 2026. Trustblock does not review code.
Audits3
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| DigiVerse - Audit Addendum | Security firm: CertiK | Date: | Scope: 1 address on BNB Chain | 1 critical acknowledged, not fixed | Open · skynet.certik.com |
| DigiVerse Staking - Audit | Security firm: CertiK | Date: | Scope: Files named in the report | 1 critical acknowledged, not fixed | Open · skynet.certik.com |
| DIGIVERSE | Security firm: CFG Ninja | Date: | Scope: 1 address on BNB Chain | No open critical findings | Open · IPFS |
Findings25
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 2 | 1 |
| High | 0 | 4 | 4 |
| Medium | 1 | 1 | 1 |
| Low | 0 | 7 | 4 |
CriticalCentralization Risks in DIGIVERSE.solDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
In the contract `DIGIVERSE` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and include/exclude address from fees, enable/disable swap and liquify process, change threshold for triggering swap and liquify process, transfer ETH or tokens out of the contract, change marketing wallet address and change configuration for antisnipe.  In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and transfer/renounce the ownership of the contract. 
Open the reportCriticalFinancial modelDigiVerse Staking - Audit · CertiK · 5 Jan 2024Acknowledged
The staking contract employs a hierarchical referral system, where participants earn commissions or rewards for recruiting new members. The reward seems to be distributed to the contract by the project team. However, if the token is not filled to the contract company, either the user cannot withdraw his deposits, or user's deposit can be withdrawn by other people.
Open the reportHighCentralized Token Holding PositionDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
All of the swapped native tokens are sent to the marketing wallet. This imposes a centralization risk. Any compromise to the address may allow a hacker to transfer those tokens from the address, resulting in severe damage to the project.
Open the reportHighInitial Token DistributionDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
All of the DIGI tokens are sent to the contract deployer. This is a centralization risk because the deployer 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 reportHighCentralization Risks in digistake.solDigiVerse Staking - Audit · CertiK · 5 Jan 2024Acknowledged
In the contract `DigiStake` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change important parameters about the staking contract and transfer ERC 20 token other than staking token out of the contract. 
Open the reportHighLack of TestsDigiVerse Staking - Audit · CertiK · 5 Jan 2024Acknowledged
There is no unit tests for the provided codebase. Testing programs are a very important aspect of proving program correctness, preventing regressions, and release engineering. Without tests, there is no way to know if the program works as expected. The fact that the code was submitted for review with such a significant flaw is regarded as an indicator of issues within the release engineering procedures. This could potentially result in unintended changes being deployed to the production environment.
Open the reportMediumPotential Sandwich AttackDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
A sandwich attack may happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) a transaction to sell the asset. The following function is called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: - `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens`
Open the reportLowConfusing usage of AntisnipeDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
The antisnipe feature is specifically disabled in function `swapAndLiquify`. This function is used for swapping DIGI token in the token contract to native tokens. This indicates that the following line may return false: ```solidity= antisnipe.assureCanTransfer(token_contract_address, from, to, amount); ```
Open the reportLowFinancial modelDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
Users will pay fees when buying or selling tokens. In this project, it seems that users will only pay fees when buying/selling tokens and does not have anything in return, which does not incentivize users purchasing tokens in the first place.
Open the reportLowInconsistencies with PinkSale Lock across differeDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
It is observed that on some chains, some DIGI tokens are locked in Pinksale, while others are not. We would like to confirm if it is the intended design.
Open the reportShow 4 more
LowPotential Reentrancy Attack (Sending Tokens)DigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. ### External call(s) ```solidity=698 _transfer(sender, recipient, amount); ``` * This function call executes the following external call(s). * In `DIGIVERSE.transferToAddressETH`, * `(succ,None) = recipient.call{value: amount}("")` * In `DIGIVERSE.swapTokensForEth`, * `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens(tokenAmount,0,path,address(this),block.timestamp)` * In `DIGIVERSE._transfer`, * `antisnipe.assureCanTransfer(msg.sender,from,to,amount)` ### State variables written after the call(s) ```solidity=699 _approve(sender, _msgSender(), currentAllowance - amount); ``` * This function call executes the following assignment(s). * In `DIGIVERSE._approve`, * `_allowances[_owner][spender] = amount` --- ### External call(s) ```solidity=749 antisnipe.assureCanTransfer(msg.sender, from, to, amount); ``` ```solidity=763 swapAndLiquify(); ``` * This function call executes the following external call(s). * In `DIGIVERSE.transferToAddressETH`, * `(succ,None) = recipient.call{value: amount}("")` * In `DIGIVERSE.swapTokensForEth`, * `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens(tokenAmount,0,path,address(this),block.timestamp)` ### State variables written after the call(s) ```solidity=773 _tokenTransfer(from, address(this), fee); ``` * This function call executes the following assignment(s). * In `DIGIVERSE._tokenTransfer`, * `_tOwned[sender] -= amount` * In `DIGIVERSE._tokenTransfer`, * `_tOwned[recipient] += amount` ```solidity=777 _tokenTransfer(from, to, amount); ``` * This function call executes the following assignment(s). * In `DIGIVERSE._tokenTransfer`, * `_tOwned[sender] -= amount` * In `DIGIVERSE._tokenTransfer`, * `_tOwned[recipient] += amount`
Open the reportLowPotentially inaccurate variable valueDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
Based on the naming, the auditor assumes that `marketingTokensCollected` represents how many tokens are there in the contract, `totalMarketingTokensCollected` represents how many tokens has been/will be swapped to ETH and send to the marketing wallet. In rare cases where tokens are directly sent to the contract, these tokens are swapped to ETH but not considered in these two variables.
Open the reportLowRedundant Code ComponentsDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
Function `swapETHForTokens` is never used in this contract. And it is unclear how does this function served as a fallback to the `swapAndLiquify`.
Open the reportLowThird-Party Dependency UsageDigiVerse - Audit Addendum · CertiK · 15 Jan 2024Acknowledged
The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=593 IUniswapV2Router02 public immutable uniswapV2Router; ``` - The contract `DIGIVERSE` interacts with third party contract with `IUniswapV2Router02` interface via `uniswapV2Router`. --- ```solidity=600 IAntisnipe public antisnipe; ``` - The contract `DIGIVERSE` interacts with third party contract with `IAntisnipe` interface via `antisnipe`.
Open the reportContracts1
| Address | Chain | Source code |
|---|---|---|
| 0x4f35fdbcde54d01610cdcb5615187d252e66638c | Chain: BNB Chain | Source code: Verified source |
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
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.
Style
Format
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="digiverse"></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