Skip to content

Methodology

DISCLAIMER // NFA // DYOR

This analysis is based on decompiled bytecode and 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, but 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 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 (etherscan)
Network Ethereum Mainnet
Analysis Date 2025-12-26

Overview

This document describes the methodology used to analyze the Sentinel (SENT) token contract. Since the source code is not verified on Etherscan, analysis was performed using bytecode inspection and on-chain queries.

Thought Process

%%{init: {'theme': 'base'}}%%
mindmap
  root((SENT Token Analysis))
    Contract Discovery
      Fetch bytecode
      Extract function selectors
      Decode selector signatures
      Query storage slots
    Pattern Recognition
      Identify ERC-20 patterns
      Recognize Ownable pattern
      Spot custom functions
      Map storage layout
    Function Analysis
      Categorize by role
      Analyze parameters
      Trace state changes
      Document failure cases
    Risk Assessment
      Centralization points
      Trust assumptions
      Economic risks
      Code complexity
    Documentation
      Contract Analysis
      Functions Reference
      Storage Layout
      Risk Analysis
      Verification Guide

Verification Guide

This section provides the tools and commands used to perform this analysis. Anyone can reproduce these steps to verify our findings.

External Resources

RESOURCE PURPOSE
Etherscan View contract transactions and bytecode
Foundry Book Documentation for cast CLI tool
OpenZeppelin Contracts Reference for standard patterns
4byte.directory / OpenChain Function selector database

Command-line Tools

Tip

Commands below use cast from the Foundry Toolkit. To run the commands below, you must set the RPC URL environment variable:

export ETH_RPC_URL=https://eth.llamarpc.com

Fetch Contract Bytecode

# GET RUNTIME BYTECODE

cast code 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304

Extract Function Selectors

# EXTRACT ALL FUNCTION SELECTORS FROM BYTECODE

cast selectors $(cast code 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304)

Decode Function Selectors

# DECODE A FUNCTION SELECTOR TO ITS SIGNATURE

cast 4byte 0x06fdde03  # Returns: name()
cast 4byte 0x095ea7b3  # Returns: approve(address,uint256)
cast 4byte 0x18160ddd  # Returns: totalSupply()
cast 4byte 0x9c1f80a9  # Returns: initializeMinting(uint256,address,uint256)

Query Token Metadata

# GET TOKEN NAME

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "name()(string)"


# GET TOKEN SYMBOL

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "symbol()(string)"


# GET DECIMALS

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "decimals()(uint8)"


# GET TOTAL SUPPLY

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "totalSupply()(uint256)"

Query Contract State

# GET OWNER ADDRESS

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "owner()(address)"


# GET PRESALE WALLET

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "presaleWallet()(address)"


# GET PRESALE ALLOCATION

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "presaleAllocation()(uint256)"


# GET ORIGINAL TOTAL SUPPLY

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "TOTAL_SUPPLY()(uint256)"


# CHECK IF INITIALIZED

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "isInitialized()(bool)"

Query Storage Directly

# READ STORAGE SLOTS 0-9

for slot in 0 1 2 3 4 5 6 7 8 9; do
  echo "Slot $slot: $(cast storage 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 $slot)"
done

Query Token Balances

# GET BALANCE OF ANY ADDRESS

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "balanceOf(address)(uint256)" <ADDRESS>


# GET BALANCE OF PRESALE WALLET

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "balanceOf(address)(uint256)" 0xEa35cde1d1ac4e36Ca519dB0b38Fe28A2C477eFE


# GET BALANCE OF OWNER

cast call 0xe88BAab9192a3Cb2C0a50182AB911506e5aDc304 "balanceOf(address)(uint256)" 0x9c146431E3b7300FAaABC625Eeee3c7ec882A0DC

Query Deployment Information

# GET CREATION TRANSACTION DETAILS

cast tx 0xf9b0e3fa2be36dfb405ae5d51ad439c3d5a95c09d41d40fe4db303af1e1a2bf2


# GET DEPLOYMENT BLOCK TIMESTAMP

cast age 24098958

Analysis Process

Phase 1: Contract Discovery

  1. Verified contract status on Etherscan - Source not verified
  2. Fetched runtime bytecode - 12KB of compiled code
  3. Extracted function selectors - Identified 18 public functions
  4. Decoded selectors - Mapped to function signatures using 4byte directory

Phase 2: Pattern Recognition

  1. ERC-20 standard functions identified:
    - name, symbol, decimals, totalSupply
    - balanceOf, allowance
    - transfer, approve, transferFrom

  2. Ownable pattern identified:
    - owner, transferOwnership, renounceOwnership

  3. Custom functions identified:
    - initializeMinting (deferred minting pattern)
    - burn (deflationary capability)
    - TOTAL_SUPPLY, presaleWallet, presaleAllocation, isInitialized

Phase 3: Storage Analysis

  1. Queried storage slots 0-9 directly from blockchain
  2. Decoded string storage (name, symbol)
  3. Identified address storage (owner, presaleWallet)
  4. Verified numeric values (supplies, allocations)

Phase 4: Function Analysis

  1. Analyzed each function's purpose based on selector and parameters
  2. Traced state changes by correlating storage slot modifications
  3. Identified access controls (onlyOwner modifier pattern)
  4. Documented failure conditions from error messages in bytecode

Phase 5: Risk Assessment

  1. Evaluated centralization - Single owner, no multisig
  2. Assessed trust model - What users must trust
  3. Analyzed economic risks - Token distribution concentration
  4. Reviewed code complexity - Standard patterns, no unusual mechanics

Limitations

This analysis has the following limitations:

LIMITATION IMPACT
No verified source code Cannot guarantee exact logic
Bytecode analysis only May miss subtle vulnerabilities
No formal verification Cannot prove correctness
No audit review Not a security audit
Point-in-time analysis State may change

Reproducibility

All findings in this analysis can be independently verified using:

  1. Public RPC endpoints - No special access required
  2. Open-source tools - Foundry cast is freely available
  3. Public blockchain data - All queries are read-only
  4. Standard methods - Uses documented Ethereum APIs

Version Information

COMPONENT VERSION
Analysis Date 2025-12-26
Foundry Cast Latest
Ethereum Mainnet Block 24,098,958+
Contract Compiler Solidity 0.8.33