Is BTR token (BTR) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Centralized Control of Upgrade Mechanism

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

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

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

StatusUnresolved

Medium

Risk of Storage Collisions in Implementation

M-01The 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.

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

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

StatusUnresolved

Medium

Ether Lock in Proxy Constructor with `_data`

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

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

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

StatusUnresolved

Low

Re-initialization Attack Vector (if not protected)

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

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

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

StatusUnresolved

Info

Dependency on External Libraries

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh3/10

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.

UpgradesHigh2/10

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.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint Function?

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Holder Composition

81.4% in top 10

27.8% in wallets53.6% in contracts

Effective Concentration49.2%

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

$559.4K across 5 pairs

Pancakeswap v3USDTanalysed$552.0K UniswapUSDT$7.4K Pancakeswap v2USDT$24 Pancakeswap v2Subject 3$3 Pancakeswap v2WBNB$2

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 Holder67.6%

Top-3 Unlocked86.4%

Key Addresses

11 addresses

Deployer

0x27e9…cda5

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.

What Raised This Score

10 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

Is BTR token Safe?

Security Findings

Centralized Control of Upgrade Mechanism

Risk of Storage Collisions in Implementation

Ether Lock in Proxy Constructor with `_data`

Re-initialization Attack Vector (if not protected)

Dependency on External Libraries

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 BTR token?