Quantum Audit Logo

Is Dogshit a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

Dogshit DOGSHIT
0x389c…6666
BNB Chain
Not verifiedThis 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 7d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit report covers the provided Solidity source code for the 'Dogshit Token' project. Due to the truncation of the main ERC20 contract, a comprehensive security assessment of all functionalities, especially dividend distribution and DEX interactions, could not be performed. The visible code snippets demonstrate good practices like SafeMath usage and a robust IterableMapping library. However, the unprovided sections represent significant unaudited attack surfaces, leading to a Medium overall risk level.

1 Medium2 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$188.8K
Liquidity
$57.5K
Price
$0.0000000192
Token Age
3d
Top 10 Holders
26.5%

Security Findings

1 Med2 Low2 Info
Medium

Unaudited Critical Functionality Due to Truncated Code

M-01The provided source code for the main ERC20 contract is truncated. Specifically, the implementation details for core ERC20 functions (e.g., `_transfer`, `_mint`, `_burn`), the `decimals()` function, and any custom logic related to dividend distribution (implied by `DividendPayingTokenInterface`) or DEX interactions (implied by `IRouter`, `IFactory`, `IPair`) are missing. This prevents a comprehensive security assessment of potentially complex and high-risk areas, leaving significant attack surfaces unaudited.
IssueThe provided source code for the main ERC20 contract is truncated. Specifically, the implementation details for core ERC20 functions (e.g., `_transfer`, `_mint`, `_burn`), the `decimals()` function, and any custom logic related to dividend distribution (implied by `DividendPayingTokenInterface`) or DEX interactions (implied by `IRouter`, `IFactory`, `IPair`) are missing. This prevents a comprehensive security assessment of potentially complex and high-risk areas, leaving significant attack surfaces unaudited.
FixProvide the complete and untruncated source code for all contracts, especially the main ERC20 token contract. A full audit cannot be performed without access to the entire codebase, particularly for functionalities involving external calls, complex arithmetic, or state changes that are common sources of vulnerabilities like reentrancy, economic exploits, or access control bypasses.
StatusUnresolved
Low

Centralization Risk with Ownable Pattern

L-01The contract utilizes the `Ownable` pattern, granting a single external address (the `owner`) exclusive control over sensitive administrative functions. While common, this introduces a single point of failure. If the owner's private key is compromised, malicious actors could gain full control over the contract, potentially leading to asset loss or manipulation.
IssueThe contract utilizes the `Ownable` pattern, granting a single external address (the `owner`) exclusive control over sensitive administrative functions. While common, this introduces a single point of failure. If the owner's private key is compromised, malicious actors could gain full control over the contract, potentially leading to asset loss or manipulation.
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract owner to enhance security. For highly critical functions, explore time-locks or a decentralized governance mechanism to distribute control and introduce a delay for sensitive operations, allowing for community review or emergency intervention.
StatusUnresolved
Low

Potential Gas Costs with Large IterableMapping

L-02The `IterableMapping` library provides efficient O(1) operations for `set` and `remove` (amortized for array push/pop). However, if the `keys` array grows to an extremely large size, the underlying `push` and `pop` operations, while efficient, can still incur non-trivial gas costs. While not a direct vulnerability, this could lead to higher transaction fees for users interacting with functions that modify the map, especially if many entries are added or removed in a single transaction.
IssueThe `IterableMapping` library provides efficient O(1) operations for `set` and `remove` (amortized for array push/pop). However, if the `keys` array grows to an extremely large size, the underlying `push` and `pop` operations, while efficient, can still incur non-trivial gas costs. While not a direct vulnerability, this could lead to higher transaction fees for users interacting with functions that modify the map, especially if many entries are added or removed in a single transaction.
FixMonitor the growth of the `IterableMapping`'s `keys` array in production. If the array is expected to contain an extremely large number of elements (e.g., millions), consider alternative data structures or strategies to manage the scale, or ensure that functions interacting with the map are designed to handle potential gas cost increases without hitting block gas limits.
StatusUnresolved
Info

Potential Unchecked Return Values for External Calls

I-01While the provided code snippets do not show direct external calls to unknown contracts, interfaces like `IRouter` suggest that the full contract likely makes external calls. If not handled carefully, external calls to contracts like `transfer` or `approve` (which return a boolean) might not have their return values checked. Ignoring these return values can lead to unexpected behavior or failed operations going unnoticed.
IssueWhile the provided code snippets do not show direct external calls to unknown contracts, interfaces like `IRouter` suggest that the full contract likely makes external calls. If not handled carefully, external calls to contracts like `transfer` or `approve` (which return a boolean) might not have their return values checked. Ignoring these return values can lead to unexpected behavior or failed operations going unnoticed.
FixEnsure that all external calls to other contracts, especially those that return a boolean indicating success or failure (e.g., ERC20 `transfer`, `approve`), explicitly check their return values. Use `require()` statements to revert the transaction if the external call indicates failure, preventing silent failures and ensuring expected contract state.
StatusUnresolved
Info

Truncated `decimals()` Function in ERC20

I-02The `decimals()` function within the `ERC20` contract is truncated in the provided source code. While it is likely intended to return a standard `uint8` value (e.g., 18), its full implementation is not visible. This is a minor observation stemming from the incomplete code submission.
IssueThe `decimals()` function within the `ERC20` contract is truncated in the provided source code. While it is likely intended to return a standard `uint8` value (e.g., 18), its full implementation is not visible. This is a minor observation stemming from the incomplete code submission.
FixEnsure the `decimals()` function is fully implemented and returns the correct `uint8` value representing the token's decimal precision, adhering to the ERC20 standard. This is crucial for proper display and interaction with exchanges and wallets.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture leverages standard libraries like SafeMath for robust integer arithmetic, mitigating common overflow/underflow vulnerabilities (7.2 Code Security). The IterableMapping library provides an efficient way to manage iterable key-value pairs. However, the core ERC20 contract is truncated, preventing a full review of critical functionalities such as token transfers, minting/burning, and especially the dividend distribution logic suggested by `DividendPayingTokenInterface` and potential DEX interactions via `IRouter` (7.1 Architecture, 7.2 Code Security). These unreviewed sections could harbor significant vulnerabilities like reentrancy or economic exploits.

GovernanceLow7/10

The contract employs the Ownable pattern for access control, centralizing administrative privileges with a single owner (7.3 Access Control). This introduces a centralization risk, as the owner has significant control over the contract's operations. The presence of `DividendPayingTokenInterface` and DEX interaction interfaces (`IRouter`, `IFactory`, `IPair`) suggests complex economic mechanics, potentially involving tokenomics, fee structures, and liquidity management (7.4 Economic). Without the full implementation, the economic security, potential for oracle manipulation, or flash loan vulnerabilities related to these features cannot be assessed (7.6 External).

UpgradesLow10/10

Based on the provided information and the `is_proxy: false` flag, the contract does not appear to be implemented as an upgradeable proxy (7.7 Upgrades). Therefore, direct upgradeability risks are not applicable to this specific deployment. Any future changes would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

26.5% in top 10
1.3% in wallets25.2% in contracts
Effective Concentration11.4%

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

$57.5K

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x4295…9e2d
Unlocked LP Held By
0x1e78…7140

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

What Raised This Score

6 factors
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • LP claimed locked but only 0.0% actually locked
  • Token age < 7 days (early, volatile)
  • 1 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

Related Audits

6 more on the record
ZygoSwap (ZSWAP)Medium RiskSIRENMedium RiskANDYMedium RiskIBSLow RiskCZ Terminal Token (CZT)Low RiskMEET48 Token (IDOL)Medium Risk

Would You Like a More Detailed Audit of Dogshit?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit