Quantum Audit Logo
Launch App

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

Is tap Safe?

TAPEthereum
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 · 2 Low · 1 Info6
SummaryAI Copilot

The TapBridge protocol consists of a main bridge contract and dynamically deployed ERC20 TapToken contracts.

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 > 30%
  • Liquidity < $50k
  • LP top1 unlocked holder = 98.2%
  • 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
  • 2 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 > 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

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
47.9%Contracts16.6%Wallets35.6%Everyone else
47.9%Contracts16.6%Wallets35.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
64.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking47.9%
  • Walletsanonymous holders, free to sell16.6%
  • Everyone elsethe rest of the supply35.6%
Effective concentrationwhat the score reads35.7%
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$28.3K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$27.6KShare of depth97.4%
Top-1 Unlocked Holder98.2%
Top-3 Unlocked100.0%
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.

Security Findings

1 High2 Medium2 Low1 Info
High

Irrecoverable admin and canister Addresses

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

Issue

The 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).

Fix

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

Status

Unresolved

Medium

Initial Misconfiguration of discountToken

In 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).M-01

Issue

In 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).

Fix

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

Status

Unresolved

Medium

Centralization Risk via ADMIN_ROLE

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

Issue

The 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).

Fix

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

Status

Unresolved

Low

bridgeOut Restriction for Contracts

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

Issue

The 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).

Fix

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

Status

Unresolved

Low

TapToken decimals() Override Inconsistency

The 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).L-02

Issue

The 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).

Fix

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

Status

Unresolved

Info

Lack of Event for Critical Parameter Setup

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

Issue

The 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).

Fix

Emit 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);.

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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

Governance1/10High risk

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

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

It is strongly recommended to implement mechanisms for securely updating critical operational addresses, such as admin and canister, preferably through a multi-signature wallet or a robust governance process, to mitigate single points of failure and ensure long-term protocol resilience.

The initial misconfiguration of the discountToken should be corrected to ensure the fee discount mechanism functions as intended from deployment. Further consideration should be given to the bridgeOut function's restriction on contract callers to evaluate if the trade-offs in composability are acceptable for the protocol's vision. Additionally, emitting events for all critical parameter settings, including admin and canister addresses, would significantly enhance transparency and monitoring capabilities.

Contract & Record

1 audit on record
TypeTapToken
NetworkEthereum
Token age1y
Contract0x5e7f…7454
Deployer0xbfeb…6c7e
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
tap 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, 202694Critical
  2. Aug 15, 202683High

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

Related Audits

6 more on the recordAll audits
VisionVSN · Ethereum95CriticalPunkStrategyPNKSTR · Ethereum92CriticalNEAREthereum96CriticalHumanityH · Ethereum97CriticalusocksEthereum91CriticalApple (Ondo Tokenized)AAPLON · Ethereum97Critical

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 Is this your token? Publish your own audit on this page