Skip to content

Potential Risks

DISCLAIMER // NFA // DYOR

This analysis is based on observations of the contract behavior. We are not smart contract security experts. This document aims to explain what the contract appears to do based on the code. It should not be considered a comprehensive security audit or financial advice. Always verify critical information independently and consult with blockchain security professionals for important decisions.

⊙ generated by robots | curated by humans

METADATA
Contract Address 0x8d33666c83f7f17a1b8dc0e950d8ff2e7e37c563 (etherscan)
Network Ethereum Mainnet
Analysis Date 2025-12-26

Centralization Points

Single Owner Control

RISK LEVEL FINDING
△ High Contract is controlled by a single EOA with no Multisig requirement

The owner address 0x8758Ca21d08c9bdA75D6114614DCE373bFD76968 has complete control over:

  • Starting and stopping the presale
  • Adding and removing supported tokens
  • Setting exchange rates for any token
  • Changing the beneficiary address
  • Withdrawing any funds from the contract
  • Transferring or renouncing ownership

Consideration: A compromised or malicious owner key could redirect all future funds, manipulate exchange rates, or end the presale at any time.

No Timelock Protection

RISK LEVEL FINDING
△ High All admin functions execute immediately with no delay

Admin actions that could benefit from timelocks:

  • setBeneficiary(address) - Can redirect funds instantly
  • endPresale() - Can stop presale without warning
  • transferOwnership(address) - Can transfer control instantly
  • addSupportedTokens(...) - Can change exchange rates instantly

Consideration: Users have no opportunity to react to adverse admin actions.

Beneficiary Changes

RISK LEVEL FINDING
△ Medium Beneficiary was changed post-deployment

The constructor argument set beneficiary to 0xbc6921... but it was later changed to 0x853319.... While this may be legitimate, it demonstrates that:

  • The beneficiary can be changed at any time
  • All future funds go to the new address immediately
  • No user notification or delay is required

Trust Assumptions

No On-Chain Token Distribution

RISK LEVEL FINDING
☒ Critical Users receive nothing on-chain for their payment

This is the most significant trust assumption:

  • Users send ETH or ERC20 tokens
  • Contract records purchase amounts in a mapping
  • Contract sends all funds to beneficiary immediately
  • Users receive no tokens, no receipts, no claims
  • The Sentinel token contract is not even set (address(0))

User Trust Required: Users must trust that the project team will:

  1. Deploy a Sentinel token contract
  2. Create some distribution mechanism (airdrop, claim contract, etc.)
  3. Honor the purchase amounts recorded in this contract
  4. Actually distribute the tokens

Rate Manipulation

RISK LEVEL FINDING
△ Medium Owner can set arbitrary exchange rates

The addSupportedTokens function allows the owner to set any exchange rate for any token. This means:

  • Rates could be changed mid-presale
  • Different users could get different rates
  • No price feed or oracle validation exists

Economic Risks

No Escrow or Refund Mechanism

RISK LEVEL FINDING
△ High Funds are sent immediately to beneficiary with no recovery option 
flowchart LR
    U[User] -->|Sends ETH/Tokens| C[Contract]
    C -->|Immediately Forwards| B[Beneficiary]
    B -->|Holds| F[$3.07M+ ETH]

    style B fill:#ffe1e1
    style F fill:#ffe1e1

Once funds leave the contract:

  • No refund mechanism exists
  • No escrow protects user funds
  • Beneficiary has full control of all raised funds
  • If project fails, users have no recourse

Significant Value at Risk

METRIC VALUE
ETH in Beneficiary Wallet ~1,048 ETH
USD Value ~$3,070,000
Tokens "Sold" ~3.49 billion
Token Contract Not deployed

Technical Risks

Unverified Source Code

RISK LEVEL FINDING
△ Medium Contract source code is not verified on Etherscan

This analysis was performed on reconstructed bytecode, which:

  • May not perfectly represent original source
  • Limits auditability by third parties
  • Reduces transparency

No Audit Evidence

RISK LEVEL FINDING
△ Medium No security audit is publicly available

For a contract handling millions in user funds, professional security audits are generally expected.

Sentinel Token Not Initialized

RISK LEVEL FINDING
△ Low sentinelToken remains at address(0)

The initializeSentinel(address) function has never been called. While this may be intentional (token not yet deployed), it's unusual for a presale that has raised significant funds.

Mitigating Factors

Despite the risks above, some positive observations:

  • ☑ Uses ReentrancyGuard on purchase functions
  • ☑ Validates token support before accepting payment
  • ☑ Validates rates are set before calculating amounts
  • ☑ Contract is standalone (not upgradeable)
  • ☑ Funds flow directly to beneficiary (no stuck funds risk)
  • ☑ Clear revert messages for debugging

Questions for the Team

If you are considering participating in this presale, we recommend asking:

  1. Why is the source code not verified on Etherscan?
  2. Has this contract been audited? If so, can you share the report?
  3. When will the Sentinel token contract be deployed?
  4. What is the distribution mechanism for purchased tokens?
  5. Why was the beneficiary address changed post-deployment?
  6. Is the owner address a multisig, and if not, why?
  7. Are there plans to add a timelock for admin functions?
  8. What happens if the project does not launch?

Risk Matrix

CATEGORY RISK SEVERITY LIKELIHOOD NOTES
Centralization Single owner control High Possible No multisig protection
Centralization No timelock High Confirmed All actions immediate
Trust No token distribution Critical Confirmed Users rely on off-chain promises
Trust Rate manipulation Medium Possible Owner controls rates
Economic No refunds High Confirmed By design
Economic Funds at risk High Confirmed ~$3M raised
Technical Unverified code Medium Confirmed Cannot verify source
Technical No audit Medium Confirmed Not publicly available

Conclusion

This presale contract functions as intended from a technical standpoint, but presents significant trust requirements:

  1. Users must trust the project team completely
  2. No technical safeguards protect user interests after payment
  3. All funds are immediately accessible to the beneficiary
  4. No mechanism exists to claim tokens or receive refunds

This is not necessarily indicative of malicious intent - many legitimate presales operate similarly. However, users should understand these risks before participating.

Professional Audit Recommended

For critical financial decisions involving this contract, we recommend consulting with professional blockchain security auditors and legal advisors.