Honeypot, rug-pull and ownership checks

Is CAT a Scam?

BNB 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 4, 2026 · 1 audit on record

Chart

82/ 100

High RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance1/10 Upgrades6/10 Checks passed3 of 5 Findings1 High · 3 Medium · 1 Low · 1 Info6

SummaryAI Copilot

The project comprises an ERC-20 token (CATToken), a claim distribution contract (CatClaim), and an ERC-721 NFT collection (PolyJetClub).

Read the full analysis

What raised the score

Ownership not renounced — strong Multisig
Top-10 concentration > 30%
Liquidity not locked
LP top1 unlocked holder = 63.1%
LP top3 unlocked holders = 99.7%
1 High finding(s) from audit
3 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Ownership NOT renounced — strong Multisig (3-of-5)
Top-10 concentration > 30% (95.1% total → 41.3% effective; 5.5% in EOAs, 89.7% in contracts — moderate)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
LP top1 unlocked holder = 63.1% (exit-liquidity risk)
LP top3 unlocked holders = 99.7% (exit-liquidity risk)
1 High finding(s) from audit
3 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

Our automated scanner reviewed CAT (CAT) on BNB Chain. 3 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 43 of 5 checks passed

Contract verifiedVerified

OwnershipRetained

MintNo mint

Liquidity lockNot locked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

95.1%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking89.7%
Walletsanonymous holders, free to sell5.5%
Everyone elsethe rest of the supply4.9%

Effective concentrationwhat the score reads41.3%

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$15.52M across 3 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$15.52MShare of depth100.0%

Top-1 Unlocked Holder63.1%

Top-3 Unlocked99.7%

Unlocked LP held by

0x0385…c4f80x8abe…7ba40x2494…1a270x80fd…7e360x0123…426a0xdff8…99ca0x1c70…460c0xa3e5…15940x818e…8b2f0x80b9…8ca8

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

Security Findings

1 High3 Medium1 Low1 Info

High

Centralized Control Across All Contracts

All three contracts (CATToken, CatClaim, PolyJetClub) are Ownable and explicitly prevent ownership renouncement. This design concentrates extensive power in a single 3/5 multisig address, which controls all critical operations including token blacklisting, fund transfers from blacklisted accounts, claim amount management, NFT minting, and pausing. This introduces a significant single point of control and high trust requirement in the owner (7.3, 7.5, 7.8).H-01

Issue

Fix

Consider implementing time-locks for highly sensitive owner-controlled functions to introduce a delay before execution, allowing for community review or emergency intervention. Explore progressive decentralization strategies, such as transitioning to a DAO-based governance model for critical decisions like blacklisting or major fund movements, reducing reliance on a single multisig.

Status

Unresolved

Medium

Owner's Power Over Blacklisted Funds

In CATToken, the transferBlackFunds function allows the owner to unilaterally transfer all tokens from a blacklisted address to any non-blacklisted recipient. While intended for recovery or enforcement, this grants significant power to the owner over user funds, which could be misused or lead to disputes if not handled transparently (7.3, 7.4).M-01

Issue

Fix

Implement a clear policy and transparent process for the use of transferBlackFunds, communicating the conditions under which it will be invoked. Consider requiring a multi-signature approval or a time-lock for such transfers to add an additional layer of security and accountability.

Status

Unresolved

Medium

Owner's Control Over Claimable Amounts and Funds

In CatClaim, the owner has exclusive control over setting and resetting claimable amounts for any user via setClaimableAmount and setClaimableAmounts. Additionally, the owner can deposit and withdraw all CAT tokens from the contract using depositCat and withdrawCat. This centralization means the owner has full discretion over who can claim, how much, and can manage or drain the contract's funds at any time (7.3, 7.4).M-02

Issue

Fix

If possible, explore mechanisms to decentralize the setting of claimable amounts, perhaps through a pre-defined schedule or a community-governed process. For fund withdrawals, consider implementing a time-lock or requiring a higher threshold of multisig signers for large amounts to enhance security and trust.

Status

Unresolved

Medium

Owner's Control Over NFT Minting and Metadata

In PolyJetClub, the owner possesses exclusive rights to mint all NFTs up to MAX_SUPPLY via mint and batchMint, and can change the baseURI at any time using setBaseURI. This centralization allows the owner to control the entire distribution and metadata of the NFT collection, potentially impacting its perceived value or authenticity if the owner's key is compromised or acts maliciously (7.3, 7.4).M-03

Issue

Fix

Consider implementing a time-lock for setBaseURI to provide transparency before metadata changes. For minting, if a public sale or decentralized distribution is planned, ensure the owner's minting capabilities are limited or phased out after initial distribution, or integrate a transparent minting schedule.

Status

Unresolved

Low

Pausability Centralization

All contracts implement pausable functionality, allowing the owner to halt core contract operations (e.g., token transfers, claims, NFT minting) at will. While a common emergency mechanism, this feature is entirely controlled by the owner, which could disrupt user activity or be used to freeze assets without immediate recourse (7.3, 7.8).L-01

Issue

Fix

Clearly document the conditions under which the pause functionality would be invoked. For enhanced decentralization, consider requiring a multi-signature approval or a time-lock for pausing and unpausing, especially for prolonged periods, to prevent arbitrary halts.

Status

Unresolved

Info

Immutable Contract Design

The contracts are deployed as immutable implementations and do not incorporate any upgradeability mechanisms (e.g., proxy patterns). While this eliminates risks associated with complex upgrade processes, it means that any future bug fixes, feature enhancements, or changes to the protocol logic would necessitate a complete redeployment of the contracts and a migration of assets, which can be a complex and costly process (7.7).I-01

Issue

Fix

Ensure comprehensive testing and auditing are conducted prior to deployment, given the immutability of the contracts. For future projects, evaluate the trade-offs between immutability and upgradeability based on the project's long-term vision and potential for evolving requirements.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The project comprises an ERC-20 token (CATToken), a claim distribution contract (CatClaim), and an ERC-721 NFT collection (PolyJetClub). All contracts are built upon OpenZeppelin standards and utilize Solidity 0.8.28. The primary security concern is the high degree of centralized control across all contracts, where a 3/5 multisig owner holds extensive power over critical operations, including token blacklisting, fund management, claim distributions, and NFT minting. While technically sound, this centralization introduces significant trust assumptions and potential for economic manipulation.

Technical6/10Medium risk

The technical implementation demonstrates strong adherence to best practices, leveraging battle-tested OpenZeppelin libraries for ERC-20, ERC-721, Ownable, Pausable, and ReentrancyGuard functionalities. Solidity 0.8.28 is used, mitigating common integer overflow/underflow issues. For instance, CatClaim correctly employs ReentrancyGuard for its claim function, preventing reentrancy attacks. The code is generally clean, well-structured, and uses custom error messages effectively. No significant technical vulnerabilities like reentrancy (where not guarded), oracle manipulation, or complex logical flaws were identified (7.2).

Governance1/10High risk

The governance and economic model exhibits a high degree of centralization, with a 3/5 multisig owner retaining extensive control over all core contract functionalities. This includes the ability to blacklist token holders and transfer their funds in CATToken (7.4), manage all claimable amounts and withdraw funds from CatClaim (7.4), and control NFT minting and metadata in PolyJetClub (7.4). While a multisig mitigates single-point-of-failure, the concentration of power introduces significant trust assumptions and potential for economic manipulation or abuse (7.5). Ownership renouncement is explicitly disabled across all contracts, solidifying this centralized control (7.3).

Upgrades6/10Medium risk

The contracts are deployed as immutable, non-upgradeable implementations. This design choice eliminates risks associated with proxy patterns, such as storage collisions, logic errors during upgrades, or unauthorized upgrade paths (7.7). However, it also means that any future bug fixes, feature enhancements, or changes to the protocol logic would necessitate a complete redeployment of the contracts and a migration of assets, which can be a complex and costly process.

Final RecommendationWhat to do about this score

The project demonstrates robust technical implementation using established OpenZeppelin standards.

The primary area for improvement lies in decentralizing control where feasible. Consider implementing time-locks for critical owner-controlled functions or introducing community governance mechanisms for sensitive operations like blacklisting, fund withdrawals, or NFT metadata changes. For immutable contracts, ensure thorough testing and auditing before deployment, as any post-deployment changes require costly redeployment. Evaluate the long-term implications of centralized control over core assets and functionalities, and explore strategies to progressively decentralize power as the project matures to enhance trust and resilience.

Contract & Record

1 audit on record

TypeCATToken

NetworkBNB Chain

Token age2mo

Contract0x0667…9424

Deployer0x6a3b…2e69

Badge for your website

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

Aug 14, 202682High

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

Frequently Asked Questions

What is the CAT contract address?

The CAT contract on BNB Chain is 0x0667873e07ffec6509525b4e4cd97409e1fe9424. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.