Quantum Audit Logo
Launch App

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

Is BTR token Safe?

BTRBNB Chain
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 5, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance3/10Upgrades2/10Checks passed3 of 7Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

This audit covers OpenZeppelin's standard ERC1967 (UUPS) proxy implementation.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mint capability UNKNOWN
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 67.6%
  • LP top3 unlocked holders = 86.4%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (4-of-6)
  • Mint capability UNKNOWN (implementation ABI unreadable)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (81.4% total → 49.2% effective; 27.8% in EOAs, 53.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 67.6% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 86.4% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 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 53 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintUnknown
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 5, 2026
53.6%Contracts27.8%Wallets18.6%Everyone else
53.6%Contracts27.8%Wallets18.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
81.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking53.6%
  • Walletsanonymous holders, free to sell27.8%
  • Everyone elsethe rest of the supply18.6%
Effective concentrationwhat the score reads49.2%
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 5, 2026

Liquidity

as of audit · Sep 5$559.4K across 5 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$552.0KShare of depth98.7%
Top-1 Unlocked Holder67.6%
Top-3 Unlocked86.4%
Unlocked LP held by
0x575e…fe980xaaf2…a6010x19af…376c0x5c71…39c90xc786…e28e0x3262…f28a0xaa3e…fc430x4157…63e40x5574…9a450x3fe2…2daf

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

Centralized Control of Upgrade Mechanism

The ERC1967Proxy relies on an external admin to manage upgrades via ERC1967Utils.upgradeToAndCall and ERC1967Utils.changeAdmin. While this is standard for UUPS, the security of the entire system is dependent on the robustness of the access control mechanism implemented by the admin contract (not provided in this scope). A compromise of the admin key or governance mechanism would allow an attacker to deploy a malicious implementation, potentially leading to asset loss or system manipulation.H-01

Issue

The ERC1967Proxy relies on an external admin to manage upgrades via ERC1967Utils.upgradeToAndCall and ERC1967Utils.changeAdmin. While this is standard for UUPS, the security of the entire system is dependent on the robustness of the access control mechanism implemented by the admin contract (not provided in this scope). A compromise of the admin key or governance mechanism would allow an attacker to deploy a malicious implementation, potentially leading to asset loss or system manipulation.

Fix

Ensure the admin role is secured by a robust, multi-signature wallet or a well-audited governance contract with appropriate time locks and veto powers. The prefill indicates a multisig owner, which is a strong mitigation.

Status

Unresolved

Medium

Risk of Storage Collisions in Implementation

The UUPS proxy pattern requires careful management of storage slots in the implementation contract to avoid collisions with the proxy's internal storage slots (e.g., IMPLEMENTATION_SLOT, ADMIN_SLOT, BEACON_SLOT). While OpenZeppelin's UUPS design mitigates this for the proxy itself, developers of the implementation contract must ensure their state variables do not unintentionally overwrite these critical proxy-related slots, especially during upgrades.M-01

Issue

The UUPS proxy pattern requires careful management of storage slots in the implementation contract to avoid collisions with the proxy's internal storage slots (e.g., IMPLEMENTATION_SLOT, ADMIN_SLOT, BEACON_SLOT). While OpenZeppelin's UUPS design mitigates this for the proxy itself, developers of the implementation contract must ensure their state variables do not unintentionally overwrite these critical proxy-related slots, especially during upgrades.

Fix

Strictly adhere to OpenZeppelin's upgradeable contract development guidelines, including using UUPSUpgradeable base contracts and _gap variables to prevent storage collisions. Conduct thorough storage layout compatibility checks before each upgrade.

Status

Unresolved

Medium

Ether Lock in Proxy Constructor with _data

The ERC1967Proxy constructor is payable. If msg.value > 0 is sent along with _data (i.e., a function call to the implementation), the ERC1967Utils.upgradeToAndCall function performs a delegatecall using Address.functionDelegateCall. The Address.functionDelegateCall function does not forward msg.value to the delegated call. Consequently, any Ether sent to the proxy constructor when _data is provided will remain locked in the proxy contract, as the proxy itself has no mechanism to retrieve or forward this Ether.M-02

Issue

The ERC1967Proxy constructor is payable. If msg.value > 0 is sent along with _data (i.e., a function call to the implementation), the ERC1967Utils.upgradeToAndCall function performs a delegatecall using Address.functionDelegateCall. The Address.functionDelegateCall function does not forward msg.value to the delegated call. Consequently, any Ether sent to the proxy constructor when _data is provided will remain locked in the proxy contract, as the proxy itself has no mechanism to retrieve or forward this Ether.

Fix

Avoid sending Ether to the ERC1967Proxy constructor if _data is provided. If the implementation requires an initial Ether balance, it should be sent to the proxy *after* deployment via a separate transaction, or the implementation should include a function to pull Ether from the proxy.

Status

Unresolved

Low

Re-initialization Attack Vector (if not protected)

The upgradeToAndCall function allows arbitrary data to be passed to the new implementation, enabling initialization logic during an upgrade. If the implementation contract's initializer function is not properly protected (e.g., with an initializer modifier from OpenZeppelin's Initializable contract), an attacker could potentially re-initialize the contract, resetting critical state variables or seizing control.L-01

Issue

The upgradeToAndCall function allows arbitrary data to be passed to the new implementation, enabling initialization logic during an upgrade. If the implementation contract's initializer function is not properly protected (e.g., with an initializer modifier from OpenZeppelin's Initializable contract), an attacker could potentially re-initialize the contract, resetting critical state variables or seizing control.

Fix

Ensure all implementation contracts use OpenZeppelin's Initializable pattern and protect initializer functions with the initializer modifier to prevent multiple invocations.

Status

Unresolved

Info

Dependency on External Libraries

The ERC1967Proxy and ERC1967Utils rely heavily on other OpenZeppelin libraries such as Proxy, Address, StorageSlot, and Errors. While these are highly audited and battle-tested, the overall security of the system is contingent on the continued security and correct functioning of these external dependencies.I-01

Issue

The ERC1967Proxy and ERC1967Utils rely heavily on other OpenZeppelin libraries such as Proxy, Address, StorageSlot, and Errors. While these are highly audited and battle-tested, the overall security of the system is contingent on the continued security and correct functioning of these external dependencies.

Fix

Maintain awareness of security updates and advisories for all external dependencies. Regularly review the versions used and consider pinning specific versions to avoid unexpected changes.

Status

Unresolved

Analysis

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

This audit covers OpenZeppelin's standard ERC1967 (UUPS) proxy implementation. The provided contracts, including ERC1967Proxy and ERC1967Utils, are foundational components for upgradeable smart contracts. The code is highly robust and battle-tested, reflecting OpenZeppelin's high security standards. Key risks identified are primarily related to the management of the upgrade authority and potential pitfalls in integrating custom implementation contracts, rather than vulnerabilities within the proxy code itself. The prefill indicates a multisig owner, which significantly mitigates the practical risk of centralized control.

Technical8/10Low risk

The technical architecture utilizes OpenZeppelin's battle-tested ERC1967 (UUPS) proxy pattern, providing a robust and widely adopted upgradeability mechanism (7.1 Architecture). The code demonstrates strong security practices, including checks for empty code addresses during implementation updates and non-payable checks for empty data calls (7.2 Code Security). Access control for critical upgrade functions is delegated to an external admin contract, which is standard for this proxy type (7.3 Access Control). However, the system's overall security heavily relies on the proper implementation and security of this external admin.

Governance3/10High risk

The economic risk is low as the proxy itself does not handle any direct economic logic or asset management (7.4 Economic). Governance risk is medium due to the centralized control over upgrades inherent in the UUPS pattern (7.5 Governance). The admin role, responsible for initiating upgrades and changing the admin, holds significant power. While the prefill indicates a multisig setup, the potential for a compromised governance mechanism remains the primary economic and governance concern.

Upgrades2/10High risk

The upgrade mechanism is based on the ERC1967 UUPS standard, allowing for flexible and controlled updates to the underlying implementation logic (7.7 Upgrades). This enables bug fixes and feature enhancements without redeploying the proxy. Key strengths include the upgradeToAndCall function for seamless transitions and initialization. However, the upgradeability introduces a high risk if the admin's access control is compromised, as it could lead to the deployment of malicious code. Careful management of storage slots in implementation contracts is also crucial to prevent collisions during upgrades.

Final RecommendationWhat to do about this score

Prioritize the security of the proxy's admin key or governance mechanism, ideally using a robust multi-signature wallet with a high threshold and potentially time-locks for critical operations.

Implement comprehensive testing, including unit, integration, and upgrade tests, for all new implementation contracts to ensure storage compatibility and prevent re-initialization vulnerabilities. Conduct thorough audits of all proposed implementation upgrades before deployment to production.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkBNB Chain
Token age1y
Contract0xfed1…5c51
Deployer0x27e9…cda5
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Badge for your website
BTR token 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 5, 202662Medium

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

Related Audits

6 more on the recordAll audits
Starpower NetworkSTAR · BNB Chain62MediumXRP TokenXRP · BNB Chain62MediumIrysBNB Chain62MediumBNB AttestationBAS · BNB Chain61MediumCalderaERA · BNB Chain63Medium0GBNB Chain63Medium

Would You Like a More Detailed Audit of BTR token?

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