Is dmt-nat Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Immutable Fee Recipient Address

H-01The `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)

IssueThe `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)

FixIntroduce 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`.

StatusUnresolved

Medium

Non-Upgradeable Cloned Token Instances

M-01While `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)

IssueWhile `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)

FixRe-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.

StatusUnresolved

Medium

Centralization Risk via Canister Key

M-02The `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)

IssueThe `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)

FixImplement 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.

StatusUnresolved

Low

Anti-Contract Check in bridgeOut Function

L-01The `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)

IssueThe `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)

FixCarefully 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.

StatusUnresolved

Info

Inconsistent AccessControl Versions

I-01The `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)

IssueThe `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)

FixFor 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.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

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.

GovernanceHigh1/10

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.

UpgradesHigh1/10

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`.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

100.0% in top 10

44.0% in wallets56.0% in contracts

Effective Concentration66.4%

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.

Liquidity Depth

$1.21M across 5 pairs

Uniswap v4ETHanalysed$885.8K Uniswap v4USDC$256.0K Uniswap v4ETH$68.5K Uniswap v2WETH$901 Uniswap v4ETH$4

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x2a6f…b0d4

Unlocked LP Held By

0x60b7…02c7

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

What Raised This Score

11 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

Is dmt-nat Safe?

Security Findings

Immutable Fee Recipient Address

Non-Upgradeable Cloned Token Instances

Centralization Risk via Canister Key

Anti-Contract Check in bridgeOut Function

Inconsistent AccessControl Versions

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

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