Is Satellite Doge-1 (DOGE-1) a Scam? Security Analysis

Security Findings

2 Crit3 High2 Med1 Info

Critical

Renounced Ownership Leads to Immutability of Critical Parameters

C-01The 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).

IssueThe 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).

FixThis 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.

StatusUnresolved

Critical

Unlocked Liquidity Pool Poses Rug Pull Risk

C-02The 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).

IssueThe 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).

FixFor 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.

StatusUnresolved

High

Permanently High Transaction Fees

H-01Given 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).

IssueGiven 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).

FixThis 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.

StatusUnresolved

High

Unmanageable Anti-Bot Mechanism

H-02The 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).

IssueThe 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).

FixThis 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.

StatusUnresolved

High

Centralized Fee Distribution to a Single Address

H-03Both 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).

IssueBoth 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).

FixFor 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.

StatusUnresolved

Medium

Fixed Max Transaction and Wallet Size Limits

M-01The 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).

IssueThe 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).

FixThis 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.

StatusUnresolved

Medium

Potential for Sandwich Attacks on Swap-and-Liquify

M-02The `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).

IssueThe `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).

FixConsider 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.

StatusUnresolved

Info

Reflection Mechanism Complexity

I-01The 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).

IssueThe 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).

FixThorough 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.

StatusUnresolved

Category Ratings

TechnicalHigh3/10

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).

GovernanceMedium5/10

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).

UpgradesLow8/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

40.2% in top 10

13.5% in wallets26.7% in contracts

Effective Concentration24.1%

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

$61.4K

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

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

1 addresses

Deployer

0xa2a8…2b81

What Raised This Score

4 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

Is Satellite Doge-1 a Scam?

Security Findings

Renounced Ownership Leads to Immutability of Critical Parameters

Unlocked Liquidity Pool Poses Rug Pull Risk

Permanently High Transaction Fees

Unmanageable Anti-Bot Mechanism

Centralized Fee Distribution to a Single Address

Fixed Max Transaction and Wallet Size Limits

Potential for Sandwich Attacks on Swap-and-Liquify

Reflection Mechanism Complexity

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 Satellite Doge-1?