Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is dmt-nat Safe?

DMT-NATEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed2 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The Tap Bridge protocol consists of a bridge contract and a token contract.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 50%
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 50% (100.0% total → 66.4% effective; 44.0% in EOAs, 56.0% in contracts — heavy)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 73% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 73% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockLocked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
56.0%Contracts44.0%Wallets
56.0%Contracts44.0%Wallets
ContractsWalletsBubble area = share of supply
100.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking56.0%
  • Walletsanonymous holders, free to sell44.0%
Effective concentrationwhat the score reads66.4%
How holder types affect the score

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.21M across 5 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$885.8KShare of depth73.1%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x60b7…02c7

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

1 High2 Medium1 Low1 Info
High

Immutable Fee Recipient Address

The admin address, which receives fees in bridgeIn and bridgeOut functions, is set in the constructor and declared as private. This makes it immutable after deployment. If the ADMIN_ROLE (which controls setFee and setDiscount) is transferred to a new entity, the original deployer will continue to receive all collected fees, creating a misalignment between control and revenue, and potentially leading to operational issues or disputes. (7.3 Access Control, 7.4 Economic, 7.8 Operations)H-01

Issue

The admin address, which receives fees in bridgeIn and bridgeOut functions, is set in the constructor and declared as private. This makes it immutable after deployment. If the ADMIN_ROLE (which controls setFee and setDiscount) is transferred to a new entity, the original deployer will continue to receive all collected fees, creating a misalignment between control and revenue, and potentially leading to operational issues or disputes. (7.3 Access Control, 7.4 Economic, 7.8 Operations)

Fix

Introduce a function, restricted to the ADMIN_ROLE, to allow updating the admin address responsible for receiving fees. This would provide necessary flexibility and ensure that the fee recipient can be aligned with current governance or operational needs. Consider using a dedicated FEE_RECIPIENT_ROLE if the fee recipient is distinct from the general ADMIN_ROLE.

Status

Unresolved

Medium

Non-Upgradeable Cloned Token Instances

While TapToken is an ERC20Upgradeable contract, the TapBridge contract uses Clones.clone(tokenTemplate) to deploy new token instances. These cloned instances are direct copies of the tokenTemplate implementation and are not upgradeable themselves. If a critical vulnerability or bug is discovered in the TapToken implementation, all already deployed token instances cannot be patched or upgraded. Only new token deployments would benefit from an updated tokenTemplate pointing to a new implementation. (7.7 Upgrades)M-01

Issue

While TapToken is an ERC20Upgradeable contract, the TapBridge contract uses Clones.clone(tokenTemplate) to deploy new token instances. These cloned instances are direct copies of the tokenTemplate implementation and are not upgradeable themselves. If a critical vulnerability or bug is discovered in the TapToken implementation, all already deployed token instances cannot be patched or upgraded. Only new token deployments would benefit from an updated tokenTemplate pointing to a new implementation. (7.7 Upgrades)

Fix

Re-evaluate the upgradeability strategy for cloned tokens. If upgradeability for individual token instances is desired, consider deploying proxy contracts (e.g., UUPS proxies) for each new token instead of direct clones. Alternatively, clearly document this limitation and ensure the TapToken implementation is thoroughly audited to minimize the risk of unpatchable vulnerabilities.

Status

Unresolved

Medium

Centralization Risk via Canister Key

The bridgeIn function relies on a signature from the canister address to authorize token minting. This design introduces a significant centralization risk (7.6 External). If the private key associated with the canister address is compromised, an attacker could mint an arbitrary amount of any bridged token, leading to hyperinflation, a complete loss of trust, and potential economic collapse of the bridged assets. (7.4 Economic, 7.8 Operations)M-02

Issue

The bridgeIn function relies on a signature from the canister address to authorize token minting. This design introduces a significant centralization risk (7.6 External). If the private key associated with the canister address is compromised, an attacker could mint an arbitrary amount of any bridged token, leading to hyperinflation, a complete loss of trust, and potential economic collapse of the bridged assets. (7.4 Economic, 7.8 Operations)

Fix

Implement robust security measures for the canister's private key, such as multi-signature wallets (e.g., Gnosis Safe), hardware security modules (HSMs), or a distributed key management system. Consider adding a time-lock or a governance-controlled pause mechanism for bridgeIn operations in case of a suspected compromise.

Status

Unresolved

Low

Anti-Contract Check in bridgeOut Function

The bridgeOut function includes a check if (_msgSender().code.length > 0) revert Errors.LikelyContract(_msgSender()); which prevents contract addresses from calling this function. While intended to mitigate certain risks (e.g., reentrancy from malicious contracts), this check can restrict legitimate use cases, such as users interacting via smart contract wallets, multi-signature wallets, or other DeFi protocols. (7.1 Architecture)L-01

Issue

The bridgeOut function includes a check if (_msgSender().code.length > 0) revert Errors.LikelyContract(_msgSender()); which prevents contract addresses from calling this function. While intended to mitigate certain risks (e.g., reentrancy from malicious contracts), this check can restrict legitimate use cases, such as users interacting via smart contract wallets, multi-signature wallets, or other DeFi protocols. (7.1 Architecture)

Fix

Carefully consider the trade-offs of this restriction. If the intention is to prevent reentrancy, ensure other safeguards are in place. If the goal is to prevent specific types of contract interactions, evaluate if this blanket restriction is necessary or if more targeted checks could be implemented. Removing this check would increase composability but might require additional security considerations.

Status

Unresolved

Info

Inconsistent AccessControl Versions

The TapToken contract imports AccessControlUpgradeable, while the TapBridge contract imports AccessControl (the non-upgradeable version). While TapBridge is not currently upgradeable, this inconsistency could lead to confusion or potential issues if TapBridge were to be made upgradeable in the future without careful consideration of the AccessControlUpgradeable pattern. (7.1 Architecture)I-01

Issue

The TapToken contract imports AccessControlUpgradeable, while the TapBridge contract imports AccessControl (the non-upgradeable version). While TapBridge is not currently upgradeable, this inconsistency could lead to confusion or potential issues if TapBridge were to be made upgradeable in the future without careful consideration of the AccessControlUpgradeable pattern. (7.1 Architecture)

Fix

For consistency and future-proofing, consider using AccessControlUpgradeable in TapBridge if there's any long-term plan for it to become upgradeable. If TapBridge is definitively not intended to be upgradeable, this is a minor stylistic inconsistency rather than a vulnerability, but it's good practice to maintain consistency across related contracts.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Tap Bridge protocol consists of a bridge contract and a token contract. The bridge facilitates cross-chain transfers by minting and burning tokens, utilizing a centralized canister for signature verification and an ADMIN_ROLE for configuration. While the code leverages OpenZeppelin libraries and includes custom error handling, several significant risks were identified, including an immutable fee recipient, non-upgradeable cloned token instances, and a high reliance on the security of a single off-chain key.

Technical4/10Medium risk

The technical architecture (7.1) utilizes OpenZeppelin contracts for ERC20 and AccessControl, enhancing code security (7.2). Custom error handling and event logging are well-implemented. However, a significant technical risk (7.3 Access Control) is the immutable admin address for fee collection, which cannot be changed even if the ADMIN_ROLE is transferred. Additionally, the reliance on a single canister key for bridgeIn operations (7.6 External) introduces a critical single point of failure.

Governance1/10High risk

The economic model (7.4) includes a fee mechanism and a discount system, configurable by the ADMIN_ROLE (7.5 Governance). However, the admin address designated to receive fees is immutable, creating a potential misalignment if governance roles change. The centralized canister key for minting new tokens represents a significant economic risk, as its compromise could lead to arbitrary token minting and value dilution.

Upgrades1/10High risk

While the TapToken contract is designed as an upgradeable ERC20, the TapBridge contract itself is not upgradeable (7.7 Upgrades). More critically, when TapBridge deploys new token instances using Clones.clone, these cloned tokens are not upgradeable. This means that if a vulnerability is discovered in the TapToken implementation, existing deployed token instances cannot be patched, only future deployments would benefit from an updated tokenTemplate.

Final RecommendationWhat to do about this score

It is strongly recommended to address the identified high and medium severity issues.

Prioritize making the fee recipient address configurable by the ADMIN_ROLE to ensure proper governance and operational flexibility. Evaluate the upgradeability strategy for cloned tokens to allow for future bug fixes and enhancements. Implement robust security measures and multi-signature controls for the canister key to mitigate the significant centralization risk.

Contract & Record

1 audit on record
TypeTapToken
NetworkEthereum
Token age10mo
Contract0x2491…1247
Deployer0x2a6f…b0d4
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
dmt-nat security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202688Critical
  2. Aug 11, 202676High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
COTIEthereum88CriticalJPY CoinJPYC · Ethereum88CriticalAlloraALLO · Ethereum89CriticalGensynAI · Ethereum86CriticalCalderaERA · Ethereum90CriticalBluzelle TokenBLZ · Ethereum90Critical

Would You Like a More Detailed Audit of dmt-nat?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page