Quantum Audit Logo

Is tap Safe?

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

Is this your token? Publish your own audit on this page →

tap TAP
0x5e7f…7454
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The TapBridge protocol consists of a main bridge contract and dynamically deployed ERC20 TapToken contracts. The system facilitates cross-chain asset transfers using signature verification and a fee mechanism. While the architecture leverages standard and secure components like OpenZeppelin's upgradeable contracts and ECDSA for signatures, several critical and medium-severity issues were identified, primarily related to the immutability of key operational addresses, initial configuration, and centralization risks. These issues could impact the protocol's long-term operability and security.

1 High2 Medium2 Low1 Informational
Volume 24h
$4.4K
Liquidity
$27.6K
Price
$0.07175
Token Age
1y
Top 10 Holders
64.4%

Security Findings

1 High2 Med2 Low1 Info
High

Irrecoverable `admin` and `canister` Addresses

H-01The `admin` address, responsible for receiving bridge fees, and the `canister` address, which is the sole authorized signer for `bridgeIn` transactions, are set in the `TapBridge` constructor and cannot be modified post-deployment. If the private keys associated with these addresses are lost, compromised, or become inaccessible, the protocol's ability to collect fees or process `bridgeIn` operations would be permanently impaired or compromised. This introduces a significant single point of failure and operational risk (7.8 Operations, 7.3 Access Control).
IssueThe `admin` address, responsible for receiving bridge fees, and the `canister` address, which is the sole authorized signer for `bridgeIn` transactions, are set in the `TapBridge` constructor and cannot be modified post-deployment. If the private keys associated with these addresses are lost, compromised, or become inaccessible, the protocol's ability to collect fees or process `bridgeIn` operations would be permanently impaired or compromised. This introduces a significant single point of failure and operational risk (7.8 Operations, 7.3 Access Control).
FixImplement a mechanism to allow for the secure update of the `admin` and `canister` addresses. This could involve a multi-signature wallet, a time-locked update function, or integration with a robust governance system. For example, add `setAdmin(address newAdmin)` and `setCanister(address newCanister)` functions protected by the `ADMIN_ROLE` with a timelock or multi-sig confirmation.
StatusUnresolved
Medium

Initial Misconfiguration of `discountToken`

M-01In the `TapBridge` constructor, `discountToken` is initialized to `tokenTemplate`. `tokenTemplate` is an address used by `Clones.clone` as the blueprint for new `TapToken` instances, not a deployed ERC20 token itself. Consequently, `TapToken(discountToken).balanceOf(_msgSender())` will likely revert or return 0, rendering the fee discount mechanism non-functional until the `setDiscount` function is explicitly called by an `ADMIN_ROLE` to set a valid `discountToken` address. This leads to an unexpected initial state for users (7.4 Economic, 7.8 Operations).
IssueIn the `TapBridge` constructor, `discountToken` is initialized to `tokenTemplate`. `tokenTemplate` is an address used by `Clones.clone` as the blueprint for new `TapToken` instances, not a deployed ERC20 token itself. Consequently, `TapToken(discountToken).balanceOf(_msgSender())` will likely revert or return 0, rendering the fee discount mechanism non-functional until the `setDiscount` function is explicitly called by an `ADMIN_ROLE` to set a valid `discountToken` address. This leads to an unexpected initial state for users (7.4 Economic, 7.8 Operations).
FixInitialize `discountToken` to `address(0)` or a pre-deployed, valid discount token address in the constructor. Ensure that the `setDiscount` function is called immediately after deployment to configure the correct discount token and threshold, or consider making `discountToken` configurable during deployment.
StatusUnresolved
Medium

Centralization Risk via `ADMIN_ROLE`

M-02The `ADMIN_ROLE` in `TapBridge` holds significant power, including the ability to set bridge fees (`setFee`) and discount parameters (`setDiscount`). While this flexibility is useful, it introduces a centralized point of control. If the `ADMIN_ROLE` key is compromised or misused, an attacker could manipulate fees to drain funds or disrupt the protocol's economic model. This poses a governance risk (7.3 Access Control, 7.5 Governance).
IssueThe `ADMIN_ROLE` in `TapBridge` holds significant power, including the ability to set bridge fees (`setFee`) and discount parameters (`setDiscount`). While this flexibility is useful, it introduces a centralized point of control. If the `ADMIN_ROLE` key is compromised or misused, an attacker could manipulate fees to drain funds or disrupt the protocol's economic model. This poses a governance risk (7.3 Access Control, 7.5 Governance).
FixConsider implementing a multi-signature wallet for the `ADMIN_ROLE` or integrating with a decentralized governance system to distribute control and reduce the risk associated with a single point of failure. For critical operations like setting fees, consider adding a timelock to allow users to react to impending changes.
StatusUnresolved
Low

`bridgeOut` Restriction for Contracts

L-01The `bridgeOut` function includes a check `if (_msgSender().code.length > 0) revert Errors.LikelyContract(_msgSender());` which prevents calls from other smart contracts. While this might be intended to prevent certain complex reentrancy or unintended interactions, it significantly limits composability. Legitimate contract wallets, proxy contracts, or other DeFi protocols would be unable to use the `bridgeOut` functionality, potentially hindering integration and user experience (7.1 Architecture, 7.4 Economic).
IssueThe `bridgeOut` function includes a check `if (_msgSender().code.length > 0) revert Errors.LikelyContract(_msgSender());` which prevents calls from other smart contracts. While this might be intended to prevent certain complex reentrancy or unintended interactions, it significantly limits composability. Legitimate contract wallets, proxy contracts, or other DeFi protocols would be unable to use the `bridgeOut` functionality, potentially hindering integration and user experience (7.1 Architecture, 7.4 Economic).
FixRe-evaluate the necessity of restricting `bridgeOut` calls from contracts. If the primary concern is reentrancy, ensure that the Checks-Effects-Interactions pattern is strictly followed, which is already largely the case. If the restriction is deemed critical, clearly document this design choice and its implications for users and integrators.
StatusUnresolved
Low

`TapToken` `decimals()` Override Inconsistency

L-02The `TapToken` contract explicitly overrides the `decimals()` function to return a custom `_decimals` value set during initialization. However, the inherited `ERC20Upgradeable`'s internal `_decimals` variable (which defaults to 18) remains unchanged because `__ERC20_init` does not take a `decimals_` argument. While the public `decimals()` getter correctly returns the intended value, this internal inconsistency could lead to confusion or unexpected behavior if external tools or contracts rely on the default `ERC20Upgradeable` internal state or assumptions about `_decimals` being directly set by `__ERC20_init` (7.2 Code Security).
IssueThe `TapToken` contract explicitly overrides the `decimals()` function to return a custom `_decimals` value set during initialization. However, the inherited `ERC20Upgradeable`'s internal `_decimals` variable (which defaults to 18) remains unchanged because `__ERC20_init` does not take a `decimals_` argument. While the public `decimals()` getter correctly returns the intended value, this internal inconsistency could lead to confusion or unexpected behavior if external tools or contracts rely on the default `ERC20Upgradeable` internal state or assumptions about `_decimals` being directly set by `__ERC20_init` (7.2 Code Security).
FixTo maintain consistency and clarity, consider using the `__ERC20_init(name_, symbol_, decimals_)` constructor if available in the specific OpenZeppelin version, or ensure that the custom `_decimals` variable is clearly documented as overriding the default behavior. Alternatively, if `ERC20Upgradeable`'s `_decimals` is accessible, update it directly.
StatusUnresolved
Info

Lack of Event for Critical Parameter Setup

I-01The `admin` and `canister` addresses, which are critical parameters for the `TapBridge` contract's operation, are set in the constructor. However, no events are emitted to log these values upon deployment. Emitting events for such critical configurations enhances transparency, allows for easier monitoring by off-chain systems, and provides an immutable record of the contract's initial setup (7.8 Operations).
IssueThe `admin` and `canister` addresses, which are critical parameters for the `TapBridge` contract's operation, are set in the constructor. However, no events are emitted to log these values upon deployment. Emitting events for such critical configurations enhances transparency, allows for easier monitoring by off-chain systems, and provides an immutable record of the contract's initial setup (7.8 Operations).
FixEmit events in the `TapBridge` constructor to log the `admin` and `canister` addresses. For example: `event AdminSet(address indexed admin);` and `event CanisterSet(address indexed canister);`.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The technical architecture of the bridge, utilizing `Clones.clone` for efficient token deployment and `ECDSA.recover` for secure cross-chain message verification, is robust. The contract employs Solidity 0.8.x, mitigating integer overflow/underflow risks. However, a significant concern is the immutability of the `admin` and `canister` addresses, which are critical for fee collection and `bridgeIn` operations, posing a high operational risk if compromised or lost (7.8 Operations). Additionally, the `bridgeOut` function's restriction on contract callers limits composability (7.1 Architecture).

GovernanceHigh1/10

The economic model incorporates a fee mechanism with a discount based on a specified token balance, which is a positive feature. The `ADMIN_ROLE` provides necessary control over fees and discount parameters, allowing for protocol adjustments (7.5 Governance). However, the initial configuration of `discountToken` to `tokenTemplate` is a misconfiguration, rendering the discount inactive until manually updated (7.4 Economic). The centralized control of the `ADMIN_ROLE` also presents a governance risk (7.3 Access Control).

UpgradesHigh1/10

The `TapToken` contract is designed with upgradeability in mind, utilizing OpenZeppelin's `Upgradeable` contracts and an `initialize` function, which is a strong practice for future extensibility. The `TapBridge` contract, however, is not designed to be upgradeable, being a standard contract with a constructor. This means core bridge logic cannot be modified post-deployment without a full redeployment, which is a design choice but limits future adaptability (7.7 Upgrades).

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

64.4% in top 10
16.6% in wallets47.9% in contracts
Effective Concentration35.7%

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

$28.3K across 3 pairs
Uniswap v2USDTanalysed$27.6K97.4%Uniswap v4dmt-nat$6002.1%Uniswap v4ETH$1340.5%

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 Holder98.2%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0xbfeb…6c7e
Unlocked LP Held By
0x53e5…e50a0x919d…81bb

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

What Raised This Score

12 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 > 30% (64.4% total → 35.7% effective; 16.6% in EOAs, 47.9% in contracts — moderate)
  • Liquidity < $50k ($28,337 across 3 pairs — thin market)
  • LP top1 unlocked holder = 98.2% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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

Related Audits

6 more on the record
Vision (VSN)Critical RiskPunkStrategy (PNKSTR)Critical RiskHumanity (H)Critical RiskusocksCritical RiskCaldera (ERA)Critical RiskBluzelle Token (BLZ)Critical Risk

Would You Like a More Detailed Audit of tap?

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

Get Detailed Audit