Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →
Datamine Network Inc logo

Datamine Network Inc

Audit name:

[SCA] Datamine Network | Datamine Crypto | Jul2026

Date:

Jul 22, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Datamine Network Inc. team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Datamine is a multi-token DeFi "FLUX economic model" protocol targeting Arbitrum L2, with Ethereum L1 counterparts bridged via the Arbitrum token bridge, in which a base ERC-777 token is locked into a token contract to continuously mint a secondary ERC-777 token over time, with burning the secondary token driving a reward multiplier. The key user-facing actions are locking base tokens, minting the secondary token, and burning it for a higher mint multiplier.

Document

NameSmart Contract Code Review and Security Analysis Report for Datamine Network Inc.
Audited ByOlesia Bilenka; Ivan Bondar
Approved ByKhrystyna Tkachuk
Websitehttps://datamine.network/→
Changelog06/07/2026 - Preliminary Report
13/07/2026 - Final Report
PlatformArbitrum
LanguageSolidity
TagsFungible Token; Yield Farming; Vault; Bridge; Factory;
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Repositoryhttps://github.com/Datamine-Crypto/white-paper→
Commit28c902f
Deployed Contracts0xF80D589b3Dbe130c270a69F1a69D050f268786Df→
0x64081252c497FCfeC247a664e9D10Ca8eD71b276→
0x454F676D44DF315EEf9B5425178d5a8B524CEa03→

Audit Summary

19Total Findings
0Resolved
19Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are detailed.

    • Project overview is detailed

    • All roles in the system are described.

    • Use cases are described and detailed.

    • For each contract, all futures are described.

    • All interactions are described.

  • Technical description is detailed.

    • Run instructions are provided.

    • Technical specification is provided.

    • The NatSpec documentation is sufficient.

Code quality

  • The development environment is configured.

  • The project uses an older Solidity version (0.6.x).

Test coverage

The project is covered by a Hardhat 3 test suite of 119 test cases. Branch coverage is not reported, as Hardhat 3's coverage engine does not emit branch data.

  • Deployment and basic user interactions are covered with tests; negative-path cases are largely missed.

  • The Flux L2 bridge token has no tests.

  • Tests live in a separate repository → from the audited code, which is a verified-equivalent copy of the tested contracts.

System Overview

The protocol implements a two-tier staking architecture where each layer follows a lock-mint pattern. At the base layer, FLUX tokens (bridged from Ethereum L1 via the Arbitrum gateway) are locked in the ArbiFluxToken contract to passively mint ArbiFLUX tokens. At the second layer, ArbiFLUX tokens are locked in the LockquidityToken contract to mint LOCK tokens. Both staking contracts share the same core mechanics: users lock tokens via lock, mint rewards via mintToAddress, and unlock via unlock. A delegated minter address can be specified at lock time to allow third-party minting on behalf of the lock holder.

Minting rewards are calculated based on the locked token amount, the number of blocks elapsed since the last mint, and two multiplicative bonuses. The time multiplier scales from 1x to 3x over a 28-day period following a 24-hour initial waiting period. The burn multiplier scales from 1x to 10x based on the ratio of burned tokens attributed to an address relative to the global network ratio. In ArbiFluxToken, burned tokens are destroyed via burnToAddress while incrementing the recipient's burn credit. In LockquidityToken, the burnToAddress function transfers LOCK tokens to the LockquidityVault rather than destroying them, allowing the vault to provide liquidity to Uniswap V2 via an optimal one-sided zap mechanism.

All three token contracts implement the ERC-777 standard with ERC-20 backward compatibility, registering interfaces via the ERC-1820 registry. The Flux L2 token implements the IArbToken interface for bridge mint/burn operations restricted to the Arbitrum gateway. Re-entrancy protection is implemented via a per-address mutex pattern in ArbiFluxToken and LockquidityToken, and same-block restrictions prevent lock/unlock/mint actions from occurring in a single block. The LockquidityFactory handles deployment of both the LockquidityToken and LockquidityVault contracts with atomic initialization.

  • arbiFlux.sol — Implements the ArbiFluxToken contract, an ERC-777 token that accepts FLUX token lock-ins and mints ArbiFLUX rewards based on block-elapsed time multipliers and burn multipliers. Provides lock, unlock, mintToAddress, and burnToAddress entry points.

  • fluxL2.sol — Implements the Flux contract, an ERC-777 token representing FLUX on Arbitrum L2. Exposes bridgeMint and bridgeBurn functions restricted to the L2 gateway for cross-chain token transfers via the Arbitrum bridge.

  • lockquidity.sol — Contains LockquidityToken (an ERC-777 token that locks ArbiFLUX to mint LOCK with the same multiplier mechanics as ArbiFluxToken), LockquidityVault (receives LOCK tokens via burnToAddress and provides Uniswap V2 liquidity via optimal swaps), and LockquidityFactory (deploys and atomically initializes both contracts).

Privileged roles

ArbiFluxToken (arbiFlux.sol)

  • minterAddress (per-address delegation): Designated address authorized to mint ArbiFLUX tokens on behalf of a FLUX lock-in holder.

    • Can call mintToAddress to mint ArbiFLUX tokens from the delegator's locked-in position to any specified target address.

Flux (fluxL2.sol)

  • l2Gateway: L2 bridge gateway address set at construction; controls token supply for cross-chain bridging.

    • Can call bridgeMint to mint FLUX tokens to any account when tokens are bridged from L1.

    • Can call bridgeBurn to burn FLUX tokens from any account when tokens are withdrawn to L1.

LockquidityToken (lockquidity.sol)

  • minterAddress (per-address delegation): Designated address authorized to mint LOCK tokens on behalf of an ArbiFLUX lock-in holder.

    • Can call mintToAddress to mint LOCK tokens from the delegator's locked-in position to any specified target address.

LockquidityVault (lockquidity.sol)

  • First initializer: The first caller to invoke init before isInitialized is set; determines the token address used by the vault.

    • Can call init once to set the LOCK token address and permanently enable the vault.

LockquidityFactory (lockquidity.sol)

  • No privileged roles. Contract is deployed via constructor only, creating the LockquidityVault and LockquidityToken instances with atomic initialization. All configuration is fixed at deployment time.

Potential Risks

L2 Gateway Privileged Control: The Flux L2 token grants exclusive minting and burning authority to the l2Gateway address via the onlyGateway modifier on bridgeMint and bridgeBurn. The gateway address is set at construction with a zero-address initialization check preventing reassignment; the security of the L2 token supply is entirely dependent on the trustworthiness and security of the external Arbitrum bridge infrastructure.

Permanently Locked Liquidity Provider Tokens: The LockquidityVault contract's _addLiquidity function sends LP tokens to address(this) with no mechanism to withdraw or transfer them. Any LP tokens received from Uniswap V2 liquidity provisioning are permanently locked in the vault, eliminating governance or recovery options for the protocol.

ERC1820 Registry Dependency: All three token contracts (ArbiFluxToken, Flux, and LockquidityToken) depend on the global ERC1820 Registry at the hardcoded address 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24. The tokens register their ERC777 interfaces during construction and query the registry for send/receive hook implementers on every transfer. If the registry becomes unavailable or behaves unexpectedly, token operations may fail or behave unpredictably.

Hardcoded Uniswap V2 Arbitrum Addresses: The LockquidityVault contract hardcodes Uniswap V2 deployment addresses for Arbitrum (FACTORY: 0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9, ROUTER: 0x4752ba5DBc23f44D87826276BF6Fd6b1C372aD24, WETH: 0x82aF49447D8a07e3bd95BD0d56f35241523fBab1). If these Uniswap contracts are upgraded, deprecated, or if the protocol is deployed to a different network, all vault swap and liquidity functionality will fail.

Dependency on External Token Addresses: The LockquidityFactory constructor hardcodes the ArbiFLUX token address 0x64081252c497FCfeC247a664e9D10Ca8eD71b276 for the LockquidityToken dependency. The ArbiFluxToken similarly depends on an external FLUX token address provided at construction. The behavior and security properties of these external tokens are outside the scope of this audit.

ERC777 Hook Reentrancy Surface: All three token contracts implement ERC777, which invokes external tokensToSend and tokensReceived hooks via the ERC1820 registry during transfers. While ArbiFluxToken and LockquidityToken implement a custom preventRecursion mutex modifier to mitigate reentrancy, the Flux L2 token does not implement such protection on its bridgeMint and bridgeBurn functions, relying solely on the onlyGateway modifier for access control.

Uniswap Swap with Minimal Slippage Protection: The LockquidityVault function _swap calls swapExactTokensForTokens with amountOutMin set to 1, and _addLiquidity calls addLiquidity with minimum amounts of 0, 0. These parameters provide negligible slippage protection, making the sweep operation vulnerable to sandwich attacks and unfavorable trade execution when processing accumulated LOCK tokens.

Restrictive Token Reception Logic: The tokensReceived implementations in ArbiFluxToken and LockquidityToken require that the operator parameter equals address(this), meaning only the contract itself can send tokens to itself. If FLUX or ArbiFLUX tokens are sent directly to these contracts by users via external send or operatorSend calls, those transactions would be rejected by the hook and revert.

Burn Multiplier Relative to Global State: The burn multiplier calculation in ArbiFluxToken and LockquidityToken (getAddressBurnMultiplier) compares an individual address's burn ratio against the global burn ratio. Large participants who burn significant amounts can dilute the global ratio, reducing the effective multiplier for smaller participants. The formula computes min(_maxBurnMultiplier, myRatio * _percentMultiplier / globalRatio + baseMultiplier), meaning early movers or large stakers can establish favorable positions that are difficult for later entrants to match.

Vault Initialization Front-Running Window: The LockquidityVault init function uses a simple require(!isInitialized) check without access control. While the LockquidityFactory constructor atomically deploys and initializes the vault, standalone deployment of LockquidityVault would create a window where any address could call init with an arbitrary token address, potentially rendering the vault unusable or malicious.

L1/L2 Token Supply Synchronization: The Flux L2 token relies on the Arbitrum bridge gateway to maintain supply parity with L1. The bridgeMint function increases L2 supply when tokens are deposited on L1, and bridgeBurn decreases L2 supply for withdrawals. If message passing between L1 and L2 experiences delays, failures, or reorgs, temporary supply inconsistencies may occur until finality is achieved on both chains.

Findings

F-2026-1796Unbounded burnToAddress Credit Inflates globalRatio, Enabling Sustained Reward Denial
Status
accepted
Severity

High
F-2026-1794Unprotected sweep Enables Atomic Sandwich Extraction of Protocol LOCK
Status
accepted
Severity

High
F-2026-1796Reward Multipliers Read at Mint Time Are Applied Retroactively to the Whole Window
Status
accepted
Severity

Medium
F-2026-1795Emission Schedule Miscalibrated for Arbitrum Block Cadence
Status
accepted
Severity

Medium
F-2026-1794Reception-Ack Requirement Strands Bridge Deposits and Locked Principal for Contract Recipients
Status
accepted
Severity

Medium
F-2026-1797Integer Division Truncation in getMintAmount Results in Zero Rewards for Small Lock Amounts
Status
accepted
Severity

Low
F-2026-1796LockquidityVault init Function Lacks Access Control
Status
accepted
Severity

Low
F-2026-1795Misleading burnToAddress Function Transfers Tokens to Vault Instead of Burning
Status
accepted
Severity

Low
F-2026-1795Delegated Minter in mintToAddress Redirects Accrued Rewards
Status
accepted
Severity

Low
F-2026-1794Silent No-Op in preventRecursion Modifier Results in Undetected Failed Transactions
Status
accepted
Severity

Low
Code
―
Title
Status
Severity
F-2026-1796Unbounded burnToAddress Credit Inflates globalRatio, Enabling Sustained Reward Denial
accepted

High
F-2026-1794Unprotected sweep Enables Atomic Sandwich Extraction of Protocol LOCK
accepted

High
F-2026-1796Reward Multipliers Read at Mint Time Are Applied Retroactively to the Whole Window
accepted

Medium
F-2026-1795Emission Schedule Miscalibrated for Arbitrum Block Cadence
accepted

Medium
F-2026-1794Reception-Ack Requirement Strands Bridge Deposits and Locked Principal for Contract Recipients
accepted

Medium
F-2026-1797Integer Division Truncation in getMintAmount Results in Zero Rewards for Small Lock Amounts
accepted

Low
F-2026-1796LockquidityVault init Function Lacks Access Control
accepted

Low
F-2026-1795Misleading burnToAddress Function Transfers Tokens to Vault Instead of Burning
accepted

Low
F-2026-1795Delegated Minter in mintToAddress Redirects Accrued Rewards
accepted

Low
F-2026-1794Silent No-Op in preventRecursion Modifier Results in Undetected Failed Transactions
accepted

Low
1-10 of 19 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/Datamine-Crypto/white-paper→
Commit28c902ff56b1126228ec8dcbb5e244b9b6729842
Deployed Contracts0xF80D589b3Dbe130c270a69F1a69D050f268786Df→
0x64081252c497FCfeC247a664e9D10Ca8eD71b276→
0x454F676D44DF315EEf9B5425178d5a8B524CEa03→
Whitepaperhttps://github.com/Datamine-Crypto/white-paper/blob/master/README.md→
Requirementshttps://github.com/Datamine-Crypto/white-paper/tree/master/docs→
Technical Requirementshttps://github.com/Datamine-Crypto/white-paper/tree/master/docs→

Assets in Scope

arbiFlux.sol - arbiFlux.sol
fluxL2.sol - fluxL2.sol
lockquidity.sol - lockquidity.sol

Appendix 3. Additional Valuables

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Frameworks and Methodologies

This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.

Disclaimer