Quantum Vault (QVLT) security report
Radar AI-scanned Quantum Vault (QVLT) on Ethereum. The verified token has fixed-supply ERC-20 behavior and no visible mint, blacklist, tax, or upgrade controls, but transfers synchronously depend on an external distributor contract.
The token does not expose an obvious mint, blacklist, fee, or upgrade mechanism in the verified source. The main identified risk is that the immutable distributor callback can revert or execute arbitrary logic during transfers, potentially blocking token movement if the configured distributor is unavailable or misbehaves.
Trust score: 72/100. Source verified: Yes. Chain: ethereum. Contract: 0xeac4794a21f75a81a9f13335c53532bec9f276de.
This report was last modified on 2026-10-10 and contains 2 material findings.
medium finding: External distributor callback can block all token transfers
Every transfer after deployment invokes the external distributor contract. If that contract reverts, runs out of gas, or is otherwise unavailable, the token transfer also reverts because the callback is not wrapped in a failure-tolerant mechanism. The distributor is selected in the constructor and cannot be changed through this token contract.
Evidence: In LaunchToken._update, after super._update executes, the contract checks `from != address(0) && distributor != address(0)` and then performs `IHolderDistributor(distributor).onTransfer(from, to, value, balanceOf(from), balanceOf(to));`. This external call occurs for transfers and transferFrom operations, while minting from address(0) skips the callback. The verified source does not include the distributor implementation.
Recommendation: Review and independently audit the deployed distributor implementation, verify that its onTransfer function cannot revert under normal conditions, and consider removing the synchronous mandatory callback or adding a carefully designed failure-isolation mechanism. Operational controls should include monitoring and a migration strategy for distributor-dependent functionality, although this token has no distributor update function.
medium finding: Constructor-selected distributor has arbitrary transfer-hook authority
The token delegates execution during every non-mint transfer to an externally supplied address. Because the distributor implementation is not included in the verified source, its behavior and privileges cannot be established from this audit. It may perform arbitrary external calls or reenter other application components during token movement, subject to the EVM call context and available permissions.
Evidence: The constructor stores the supplied `distributor_` address as an immutable `distributor`. LaunchToken imports `IHolderDistributor` and calls `onTransfer` on that address from `_update` without restricting the callee beyond the configured address. The interface also defines `initialize` and `notifyFee`, but their implementations are not present in the supplied source.
Recommendation: Publish and audit the exact distributor bytecode and configuration, document its trust assumptions, and verify that it cannot manipulate unrelated assets or introduce unsafe reentrancy paths. Avoid granting the distributor unnecessary token approvals or privileged access in surrounding contracts.