Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Satellite Doge-1 a Scam?

DOGE-1Ethereum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical3/10Governance5/10Upgrades8/10Checks passed5 of 5Findings2 Critical · 3 High · 2 Medium · 1 Info8
SummaryAI Copilot

The Satellite Doge-1 token contract implements standard ERC-20 functionality with reflection mechanics, high transaction fees, and anti-bot features.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 2 Critical finding(s) from audit
  • 3 High finding(s) from audit
  • 2 Medium finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (40.2% total → 24.1% effective; 13.5% in EOAs, 26.7% in contracts — mild)
  • 2 Critical finding(s) from audit
  • 3 High finding(s) from audit
  • 2 Medium 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 Satellite Doge-1 (DOGE-1) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
26.7%Contracts13.5%Wallets59.8%Everyone else
26.7%Contracts13.5%Wallets59.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
40.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking26.7%
  • Walletsanonymous holders, free to sell13.5%
  • Everyone elsethe rest of the supply59.8%
Effective concentrationwhat the score reads24.1%
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$61.4K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$61.4KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

2 Critical3 High2 Medium1 Info
Critical

Renounced Ownership Leads to Immutability of Critical Parameters

The provided information indicates that ownership of the contract has been renounced (ownership_renounced: true). This means the _owner address is set to address(0), rendering all onlyOwner functions inaccessible. Consequently, critical parameters such as transaction fees, max transaction/wallet limits, trading status, fee recipient addresses, and the Uniswap router address are permanently fixed to their current values. This prevents any future adjustments, bug fixes, or adaptation to market conditions (7.3 Access Control, 7.8 Operations).C-01

Issue

The provided information indicates that ownership of the contract has been renounced (ownership_renounced: true). This means the _owner address is set to address(0), rendering all onlyOwner functions inaccessible. Consequently, critical parameters such as transaction fees, max transaction/wallet limits, trading status, fee recipient addresses, and the Uniswap router address are permanently fixed to their current values. This prevents any future adjustments, bug fixes, or adaptation to market conditions (7.3 Access Control, 7.8 Operations).

Fix

This issue is inherent to the renounced ownership state and cannot be resolved without redeploying the contract with a different ownership strategy. Users should be fully aware that the contract is unmanageable and its parameters are immutable.

Status

Unresolved

Critical

Unlocked Liquidity Pool Poses Rug Pull Risk

The prefill data explicitly states lp_lock_status: unlocked. This indicates that the liquidity provided to the Uniswap pair is not locked and can be removed by the liquidity provider (likely the deployer or owner) at any time. This creates a severe 'rug pull' vulnerability (7.4 Economic).C-02

Issue

The prefill data explicitly states lp_lock_status: unlocked. This indicates that the liquidity provided to the Uniswap pair is not locked and can be removed by the liquidity provider (likely the deployer or owner) at any time. This creates a severe 'rug pull' vulnerability (7.4 Economic).

Fix

For any token, especially one with high fees and renounced ownership, locking the liquidity pool is paramount to building trust and preventing a rug pull. Without a locked LP, investors face a high risk of losing all funds. This issue cannot be resolved for the current deployment if ownership is renounced.

Status

Unresolved

High

Permanently High Transaction Fees

Given the renounced ownership, the initial high transaction fees (25% on buy, 45% on sell) are permanently fixed and cannot be adjusted. These extremely high fees will significantly deter trading activity and liquidity. Additionally, both _developmentAddress and _marketingAddress are set to the same address (0xA2a8…2B81), concentrating all collected fee revenue to a single, unchangeable recipient (7.4 Economic).H-01

Issue

Given the renounced ownership, the initial high transaction fees (25% on buy, 45% on sell) are permanently fixed and cannot be adjusted. These extremely high fees will significantly deter trading activity and liquidity. Additionally, both _developmentAddress and _marketingAddress are set to the same address (), concentrating all collected fee revenue to a single, unchangeable recipient (7.4 Economic).

Fix

This issue is a direct consequence of renounced ownership and the initial configuration. It cannot be resolved for the current deployment. Future projects should consider more sustainable fee structures and ensure flexibility for adjustments, or clearly communicate the fixed, high fees to users.

Status

Unresolved

High

Unmanageable Anti-Bot Mechanism

The contract includes an anti-bot mechanism using a bots mapping and _buyMap. However, due to renounced ownership, the setBots function is inaccessible. This means the list of bots cannot be updated, nor can legitimate users accidentally added to the bots list be removed. If sophisticated bots bypass the mechanism, or if it causes false positives, the contract owner cannot intervene (7.3 Access Control, 7.8 Operations).H-02

Issue

The contract includes an anti-bot mechanism using a bots mapping and _buyMap. However, due to renounced ownership, the setBots function is inaccessible. This means the list of bots cannot be updated, nor can legitimate users accidentally added to the bots list be removed. If sophisticated bots bypass the mechanism, or if it causes false positives, the contract owner cannot intervene (7.3 Access Control, 7.8 Operations).

Fix

This issue cannot be resolved for the current deployment. Anti-bot mechanisms are often complex and prone to issues; if implemented, they should be carefully designed and maintainable. Users should be aware of the potential for legitimate transactions to be blocked without recourse.

Status

Unresolved

High

Centralized Fee Distribution to a Single Address

Both the _developmentAddress and _marketingAddress are configured to be the same address (0xA2a8…2B81). This creates a single point of failure for all collected fees. If this address is compromised or becomes inaccessible, all accumulated fees would be lost or frozen. Furthermore, due to renounced ownership, these addresses cannot be changed (7.4 Economic, 7.8 Operations).H-03

Issue

Both the _developmentAddress and _marketingAddress are configured to be the same address (). This creates a single point of failure for all collected fees. If this address is compromised or becomes inaccessible, all accumulated fees would be lost or frozen. Furthermore, due to renounced ownership, these addresses cannot be changed (7.4 Economic, 7.8 Operations).

Fix

For future projects, consider distributing fees to multiple addresses or a multi-signature wallet to mitigate single points of failure. Ensure that fee recipient addresses are secure and, if possible, allow for their modification through a robust governance process. This issue cannot be resolved for the current deployment.

Status

Unresolved

Medium

Fixed Max Transaction and Wallet Size Limits

The contract enforces _maxTxAmount and _maxWalletSize limits. Due to renounced ownership, these limits are permanently fixed. While intended to prevent large dumps or whale accumulation, such limits can hinder legitimate large transactions and may be circumvented by splitting transactions. Their immutability means they cannot be adjusted to adapt to market dynamics or project growth (7.4 Economic, 7.8 Operations).M-01

Issue

The contract enforces _maxTxAmount and _maxWalletSize limits. Due to renounced ownership, these limits are permanently fixed. While intended to prevent large dumps or whale accumulation, such limits can hinder legitimate large transactions and may be circumvented by splitting transactions. Their immutability means they cannot be adjusted to adapt to market dynamics or project growth (7.4 Economic, 7.8 Operations).

Fix

This issue cannot be resolved for the current deployment. While limits can serve a purpose, they should ideally be adjustable by a trusted entity to maintain flexibility. Users should be aware of these fixed limitations on their trading and holding capacity.

Status

Unresolved

Medium

Potential for Sandwich Attacks on Swap-and-Liquify

The swapTokensForEth function performs a swap via Uniswap. While the lockTheSwap modifier prevents reentrancy, the swap operation itself can be vulnerable to sandwich attacks. If the _swapTokensAtAmount threshold is predictable, front-running bots can manipulate the price around the swap, extracting value and reducing the ETH received by the contract for fee distribution (7.2 Code Security, 7.6 External).M-02

Issue

The swapTokensForEth function performs a swap via Uniswap. While the lockTheSwap modifier prevents reentrancy, the swap operation itself can be vulnerable to sandwich attacks. If the _swapTokensAtAmount threshold is predictable, front-running bots can manipulate the price around the swap, extracting value and reducing the ETH received by the contract for fee distribution (7.2 Code Security, 7.6 External).

Fix

Consider implementing anti-sandwich measures such as setting a minimum amountOutMin with a reasonable slippage tolerance, or using a more sophisticated swapping mechanism. While difficult to fully prevent, reducing predictability can help. This is a general risk for such automated swap mechanisms.

Status

Unresolved

Info

Reflection Mechanism Complexity

The contract utilizes a reflection mechanism (_rOwned, _tOwned, _rTotal, _tTotal, tokenFromReflection, _getRate) to distribute fees to holders. While SafeMath is used to prevent basic arithmetic overflows, reflection mechanisms are inherently complex. The interaction of varying buy/sell fees with the reflection logic can be difficult to reason about and increases the surface area for subtle bugs (7.1 Architecture, 7.2 Code Security).I-01

Issue

The contract utilizes a reflection mechanism (_rOwned, _tOwned, _rTotal, _tTotal, tokenFromReflection, _getRate) to distribute fees to holders. While SafeMath is used to prevent basic arithmetic overflows, reflection mechanisms are inherently complex. The interaction of varying buy/sell fees with the reflection logic can be difficult to reason about and increases the surface area for subtle bugs (7.1 Architecture, 7.2 Code Security).

Fix

Thorough testing and formal verification are recommended for complex reflection mechanisms to ensure correct behavior under all scenarios. While no specific vulnerability was identified, complexity always increases risk. Ensure clear documentation of the reflection logic.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Satellite Doge-1 token contract implements standard ERC-20 functionality with reflection mechanics, high transaction fees, and anti-bot features. A critical finding is the renounced ownership, which renders all administrative functions inaccessible, permanently fixing all contract parameters. This, combined with an unlocked liquidity pool, presents severe economic and operational risks. The high, unchangeable transaction fees are likely to deter trading, and the anti-bot mechanism cannot be managed.

Technical3/10High risk

The contract implements standard ERC-20 functionality with SafeMath for arithmetic safety (7.2 Code Security). It includes a reflection mechanism and a swap-and-liquify feature, protected by a reentrancy guard (lockTheSwap). However, the anti-bot mechanism is complex and unmanageable due to renounced ownership, potentially blocking legitimate users (7.3 Access Control). Critical parameters like max transaction/wallet sizes are fixed, limiting operational flexibility (7.8 Operations).

Governance5/10Medium risk

The economic model features extremely high, fixed transaction fees (25% buy, 45% sell) due to renounced ownership, which will severely deter trading (7.4 Economic). All collected fees are directed to a single, fixed address. Critically, the provided information indicates the liquidity pool is unlocked, posing a significant 'rug pull' risk (7.4 Economic). The renounced ownership also means no governance functions can be executed, leaving the contract unmanageable (7.5 Governance).

Upgrades8/10Low risk

The contract is not designed with any upgradeability mechanism (7.7 Upgrades). This means its logic and parameters are immutable once deployed and ownership is renounced, preventing any future modifications or bug fixes. This design choice eliminates upgrade-related risks but introduces significant inflexibility.

Final RecommendationWhat to do about this score

Given the renounced ownership and unlocked liquidity, the project carries extremely high risks.

It is strongly recommended that potential users exercise extreme caution and understand that all contract parameters are permanently fixed and cannot be adjusted. The unlocked liquidity pool presents a direct and immediate risk of total loss of funds for investors. Users should be aware that the high, unchangeable transaction fees will significantly impact trading profitability.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age3y
Contract0xc5b0…c105
Deployer0xa2a8…2b81
Badge for your website
Satellite Doge-1 security record badge

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
  1. Jul 29, 202644Medium

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

Related Audits

6 more on the recordAll audits
Euro CoinEURC · Ethereum44MediumWorld Liberty FinancialWLFI · Ethereum44MediumPolkastarterTokenPOLS · Ethereum44MediumBiconomyBICO · Ethereum45MediumLiskLSK · Ethereum45MediumsendEthereum43Medium

Would You Like a More Detailed Audit of Satellite Doge-1?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page