Is Wrapped Trust Bitcoin (WTBC) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High2 Med2 Low

Critical

High Centralization of Administrative Roles

C-01The `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to grant `MINTER_ROLE` and `BURNER_ROLE`, update the validator wallet, and set fee exclusions. A compromised `DEFAULT_ADMIN_ROLE` or `MINTER_ROLE` could lead to unauthorized minting up to `MAX_SUPPLY`, manipulation of transaction fees, or diversion of validator funds, severely impacting the token's integrity and value. (7.3 Access Control, 7.4 Economic, 7.8 Operations)

IssueThe `DEFAULT_ADMIN_ROLE` holds extensive power, including the ability to grant `MINTER_ROLE` and `BURNER_ROLE`, update the validator wallet, and set fee exclusions. A compromised `DEFAULT_ADMIN_ROLE` or `MINTER_ROLE` could lead to unauthorized minting up to `MAX_SUPPLY`, manipulation of transaction fees, or diversion of validator funds, severely impacting the token's integrity and value. (7.3 Access Control, 7.4 Economic, 7.8 Operations)

FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `DEFAULT_ADMIN_ROLE` and `MINTER_ROLE` to require multiple approvals for critical operations. This significantly reduces the risk of a single point of compromise. Consider time-locks for sensitive administrative actions.

StatusUnresolved

High

Hardcoded Transaction Fees

H-01The `BURN_FEE` and `VALIDATOR_FEE` are defined as `public constant` variables, making them immutable after deployment. This lack of flexibility prevents any adjustments to the token's economic model in response to changing market conditions, community feedback, or unforeseen circumstances, potentially hindering the protocol's long-term sustainability or competitiveness. (7.4 Economic)

IssueThe `BURN_FEE` and `VALIDATOR_FEE` are defined as `public constant` variables, making them immutable after deployment. This lack of flexibility prevents any adjustments to the token's economic model in response to changing market conditions, community feedback, or unforeseen circumstances, potentially hindering the protocol's long-term sustainability or competitiveness. (7.4 Economic)

FixIntroduce administrative functions to allow the `DEFAULT_ADMIN_ROLE` (preferably via multi-sig) to update `BURN_FEE` and `VALIDATOR_FEE` within predefined, reasonable bounds. This provides necessary adaptability while preventing arbitrary changes.

StatusUnresolved

Medium

Single Point of Failure for Validator Wallet

M-01The `validator` address, which receives `VALIDATOR_FEE` from transactions, is a single address controlled by the `DEFAULT_ADMIN_ROLE`. If this `validator` address is compromised, all collected fees will be diverted to an attacker, leading to a loss of funds intended for the protocol's operations or beneficiaries. There is no built-in mechanism for multi-signature control or recovery for this specific wallet. (7.3 Access Control, 7.8 Operations)

IssueThe `validator` address, which receives `VALIDATOR_FEE` from transactions, is a single address controlled by the `DEFAULT_ADMIN_ROLE`. If this `validator` address is compromised, all collected fees will be diverted to an attacker, leading to a loss of funds intended for the protocol's operations or beneficiaries. There is no built-in mechanism for multi-signature control or recovery for this specific wallet. (7.3 Access Control, 7.8 Operations)

FixConsider using a multi-signature wallet for the `validator` address to secure the collected fees. Alternatively, implement a mechanism to distribute fees to multiple addresses or a contract that manages funds more securely, such as a timelock or a vesting contract.

StatusUnresolved

Medium

Irreversible Main Liquidity Pair Creation

M-02The primary liquidity pair with `USDT` is created once in the constructor using the provided `_router` address and is then stored as an `immutable` variable `pair`. While `updateLiquidityPair` allows managing *other* liquidity pairs, the main `pair` cannot be changed or removed. If the initial `_router` address is incorrect, or the associated DEX becomes deprecated or compromised, the core liquidity mechanism for WTBC could be permanently affected without recourse. (7.1 Architecture, 7.6 External)

IssueThe primary liquidity pair with `USDT` is created once in the constructor using the provided `_router` address and is then stored as an `immutable` variable `pair`. While `updateLiquidityPair` allows managing *other* liquidity pairs, the main `pair` cannot be changed or removed. If the initial `_router` address is incorrect, or the associated DEX becomes deprecated or compromised, the core liquidity mechanism for WTBC could be permanently affected without recourse. (7.1 Architecture, 7.6 External)

FixWhile direct modification of an immutable variable is impossible, consider a future version or a wrapper contract that allows for more flexible management of the primary liquidity source, perhaps by allowing the protocol to interact with multiple DEX pairs or to migrate liquidity if necessary. For the current contract, ensure the `_router` and `USDT` addresses are thoroughly verified before deployment.

StatusUnresolved

Low

Lack of Role Management Flexibility

L-01The contract uses OpenZeppelin's `AccessControl` but does not implement explicit functions for renouncing roles or transferring the `DEFAULT_ADMIN_ROLE` directly. While `_grantRole` and `_revokeRole` exist, a direct `transferAdmin` function or a `renounceRole` for the admin itself is not present, which could complicate governance transitions or reduce decentralization over time. (7.3 Access Control)

IssueThe contract uses OpenZeppelin's `AccessControl` but does not implement explicit functions for renouncing roles or transferring the `DEFAULT_ADMIN_ROLE` directly. While `_grantRole` and `_revokeRole` exist, a direct `transferAdmin` function or a `renounceRole` for the admin itself is not present, which could complicate governance transitions or reduce decentralization over time. (7.3 Access Control)

FixConsider adding a `transferAdmin` function that allows the current `DEFAULT_ADMIN_ROLE` to transfer its role to a new address, potentially with a two-step transfer mechanism for added security. Also, evaluate if `renounceRole` functionality for `DEFAULT_ADMIN_ROLE` is desired, understanding its implications.

StatusUnresolved

Low

Hardcoded USDT Address

L-02The `USDT` token address (0x55d3…7955) is hardcoded as a `public constant`. While this is common for specific deployments, it ties the contract to a particular token on a specific blockchain (BSC in this case). If the protocol were to expand to other networks or if the canonical USDT address were to change, the contract would need redeployment. (7.1 Architecture, 7.6 External)

IssueThe `USDT` token address () is hardcoded as a `public constant`. While this is common for specific deployments, it ties the contract to a particular token on a specific blockchain (BSC in this case). If the protocol were to expand to other networks or if the canonical USDT address were to change, the contract would need redeployment. (7.1 Architecture, 7.6 External)

FixFor future deployments or multi-chain considerations, consider making the `USDT` address configurable via a constructor parameter or an administrative function. For the current deployment, ensure the hardcoded address is indeed the correct and canonical USDT address on the target network.

StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract demonstrates good code quality, utilizing Solidity 0.8.28 which mitigates common integer overflow/underflow issues (7.2 Code Security). It correctly implements OpenZeppelin's ERC20 and AccessControl, providing a solid foundation. The fee mechanism in `_transfer` is logically structured and handles transfers to the burn address and validator wallet effectively. However, the immutability of the main liquidity pair created in the constructor introduces a potential architectural rigidity (7.1 Architecture), and the single `validator` address presents a single point of failure for collected fees (7.8 Operations).

GovernanceHigh1/10

The contract exhibits a high degree of centralization through the `DEFAULT_ADMIN_ROLE`, which can assign `MINTER_ROLE` and `BURNER_ROLE`, and control fee exclusions and validator wallet (7.3 Access Control). A compromised admin could lead to severe economic consequences, including unauthorized minting up to the `MAX_SUPPLY` (7.4 Economic). Furthermore, the `BURN_FEE` and `VALIDATOR_FEE` are hardcoded constants, preventing any future adjustments to the token's economic model based on market conditions or protocol needs (7.4 Economic).

UpgradesHigh3/10

The WTBC contract is not designed with an upgrade mechanism (e.g., proxy pattern) (7.7 Upgrades). This means the contract's logic is immutable once deployed, eliminating upgrade-specific risks but also precluding any future bug fixes or feature enhancements without a complete redeployment and migration.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

86.4% in top 10

26.8% in wallets59.7% in contracts

Effective Concentration50.6%

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

$3.17M

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 Holder86.1%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x018b…0ace

Unlocked LP Held By

0x6cfb…23b40xe065…1465

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 status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (86.4% total → 50.6% effective; 26.8% in EOAs, 59.7% in contracts — heavy)
LP top1 unlocked holder = 86.1% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
LP claimed locked but only 0.0% actually locked
1 Critical finding(s) from audit
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

Not Signed In

Is Wrapped Trust Bitcoin Safe?

Security Findings

High Centralization of Administrative Roles

Hardcoded Transaction Fees

Single Point of Failure for Validator Wallet

Irreversible Main Liquidity Pair Creation

Lack of Role Management Flexibility

Hardcoded USDT Address

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Wrapped Trust Bitcoin?