Quantum Audit Logo

Is DebtReliefBot Safe?

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

DebtReliefBot DRB
0x3ec2…8ea2
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The ClankerToken contract is an ERC-20 token utilizing OpenZeppelin standards. It includes extensions for voting, burning, and cross-chain functionality via a Superchain Token Bridge. The contract exhibits good code quality but has centralized control points for certain administrative functions and relies on external bridge security.

2 Medium1 Low1 Informational
Volume 24h
$399.7K
Liquidity
$1.35M
Price
$0.0001577
Token Age
1y
Top 10 Holders
23.0%

Security Findings

2 Med1 Low1 Info
Medium

Centralized Control of `updateImage` Function

M-01The `updateImage` function can only be called by the `_deployer` address. While this function only modifies a metadata string, a compromised `_deployer` key could lead to unauthorized changes to the token's associated image, potentially impacting branding or user trust.
IssueThe `updateImage` function can only be called by the `_deployer` address. While this function only modifies a metadata string, a compromised `_deployer` key could lead to unauthorized changes to the token's associated image, potentially impacting branding or user trust.
FixConsider if this function truly needs to be mutable post-deployment. If so, evaluate whether a more decentralized approach (e.g., governance vote, time-locked changes) or a multi-signature wallet for the `_deployer` address would be appropriate.
StatusUnresolved
Medium

Initial Token Supply Centralization

M-02The entire `maxSupply_` of the token is minted to `msg.sender` (the deployer) in the constructor. This grants the deployer significant control over the initial token distribution, which could lead to concerns about centralization, potential for market manipulation, or a single point of failure for distribution.
IssueThe entire `maxSupply_` of the token is minted to `msg.sender` (the deployer) in the constructor. This grants the deployer significant control over the initial token distribution, which could lead to concerns about centralization, potential for market manipulation, or a single point of failure for distribution.
FixFor new token launches, consider distributing the initial supply through more decentralized or transparent mechanisms, such as a vesting contract, a liquidity pool, or a public sale, rather than holding the entire supply in a single address. Clearly communicate the distribution plan to the community.
StatusUnresolved
Low

Dependency on External Superchain Token Bridge

L-01The `crosschainMint` and `crosschainBurn` functions rely on the `Predeploys.SUPERCHAIN_TOKEN_BRIDGE` address for authorization. The security and integrity of the token's supply across chains are entirely dependent on the robustness and security of this external bridge contract. Any vulnerability or compromise in the bridge could directly impact the ClankerToken.
IssueThe `crosschainMint` and `crosschainBurn` functions rely on the `Predeploys.SUPERCHAIN_TOKEN_BRIDGE` address for authorization. The security and integrity of the token's supply across chains are entirely dependent on the robustness and security of this external bridge contract. Any vulnerability or compromise in the bridge could directly impact the ClankerToken.
FixEnsure that the `SUPERCHAIN_TOKEN_BRIDGE` contract is thoroughly audited, regularly monitored, and maintained with the highest security standards. Implement robust incident response plans for potential bridge exploits.
StatusUnresolved
Info

Redundant `_decimals` State Variable

I-01The contract declares a `private immutable _decimals` state variable, but it is never initialized or used. The `ERC20` base contract already handles the `decimals()` function, which defaults to 18. This redundant variable adds unnecessary complexity and could be misleading.
IssueThe contract declares a `private immutable _decimals` state variable, but it is never initialized or used. The `ERC20` base contract already handles the `decimals()` function, which defaults to 18. This redundant variable adds unnecessary complexity and could be misleading.
FixRemove the `private immutable _decimals` declaration as it is not used and the `ERC20` base contract correctly handles the `decimals()` function.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract (7.1 Architecture, 7.2 Code Security) is well-structured, inheriting from battle-tested OpenZeppelin ERC20 standards, including ERC20Permit, ERC20Votes, and ERC20Burnable. This significantly reduces the risk of common vulnerabilities like reentrancy or integer overflows. Custom logic is minimal and correctly implemented, such as the `_update` override and `supportsInterface` function. A minor observation is the redundant `_decimals` state variable, which is declared but unused, as ERC20 defaults to 18 decimals.

GovernanceLow7/10

The contract (7.3 Access Control, 7.4 Economic, 7.5 Governance) implements centralized access control for specific functions. The `_deployer` address has exclusive permission to call `updateImage`, which could be a single point of failure if the deployer key is compromised. Additionally, the initial `maxSupply_` is minted entirely to the deployer's address, granting significant control over the token's initial distribution. Cross-chain minting and burning operations are restricted to `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`, making the token's supply integrity dependent on the security of this external bridge (7.6 External).

UpgradesLow9/10

The ClankerToken contract (7.7 Upgrades) is implemented as a standard, non-upgradeable ERC20 token. This design choice eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs or upgrade path vulnerabilities. Once deployed, the contract's logic is immutable, providing predictable and stable behavior.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

23.0% in top 10
18.6% in wallets4.4% in contracts
Effective Concentration20.3%

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

$1.42M across 21 pairs
Uniswap v3WETHanalysed$1.35M94.6%Uniswap v4ETH$27.1K1.9%Uniswap v4USDC$23.8K1.7%AerodromeWETH$21.6K1.5%AerodromeWETH$1.5K0.1%AerodromecbBTC$1.1K0.1%
Show 4 more pairsShow less
Uniswap v4USDC$7870.1%Hydrex CLAMMWETH$5460.0%AerodromeKIBSHI$1470.0%AerodromeUSDC$1070.0%

The 11 remaining pairs hold $198 between them and are not listed.

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 Holder95.0%
Top-3 Unlocked98.2%

Key Addresses

11 addresses
Deployer
0x002f…074c
Unlocked LP Held By
0x5ec4…3d860x5581…06b10x5e64…9f050x7d27…fd550x13d2…fe040x0527…fc4e0xd392…74700x715e…ec210x3d70…2f650xb7e7…1151

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

What Raised This Score

6 factors
  • Top-10 concentration > 20% (23.0% total → 20.3% effective; 18.6% in EOAs, 4.4% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 95.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 98.2% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • 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

Related Audits

6 more on the record
RUSSELLLow RiskCoinye West (COINYE)Low RiskClawBankLow RiskBriun Armstrung (BRIUN)Low RiskVEIL Token (VEIL)Low RiskBasecatLow Risk

Would You Like a More Detailed Audit of DebtReliefBot?

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

Get Detailed Audit