Skip to content

Methodology

DISCLAIMER // NFA // DYOR

This analysis is based on decompiled bytecode — the contract source code is not verified on Etherscan. Function names, parameter types, and internal logic are inferred from selector matching, transaction input decoding, and event log analysis. We are not smart contract security experts. This document should not be considered a comprehensive security audit or financial advice. Always verify critical information independently.

⊙ generated by robots | curated by humans

METADATA
Contract Address 0x99c96efF...Ab2dCC (etherscan)
Network Ethereum Mainnet
Analysis Date 2026-03-29
Analyst Claude Opus 4.6 (AI)
Verification Status Unverified Source Code

Overview

This document describes the methodology used to analyze contract 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC. Because the contract source code is NOT verified on Etherscan, all analysis was performed using bytecode disassembly, function selector matching, storage slot inference, transaction pattern analysis, internal transaction tracing, and event log decoding.

The analysis follows a structured multi-phase approach adapted for unverified contracts, prioritizing observable behavior over source code review. This contract presented additional complexity due to its large function dispatch table (44 selectors) and custodial trading vault architecture involving interactions with Uniswap V3.


Thought Process

%%{init: {'theme': 'base'}}%%
mindmap
  root((Contract Analysis))
    Phase 0 Reconnaissance
      Etherscan API
        Source Status NOT VERIFIED
        101 Transactions
        Deployed 2026-03-28
      Bytecode Acquisition
        19.8 KB bytecode
        44 Function Selectors
      Proxy Check
        EIP-1967 Slots Empty
        Standalone Contract
    Phase 1 Functions
      Selector Extraction
        44 Total from Dispatch Table
      Signature Matching
        28 Matched via 4byte + cast
        16 Unmatched Custom
      Categorization
        4 User + 2 Keeper + 4 Admin + 18 View
    Phase 2 Storage
      11 Slots Identified
        Slot 0 Owner
        Slot 5 Keeper
        Slot 6 Fee Recipient
        Slot 7 Deposit Fee
      Dynamic Mappings
        Vaults 11-field struct
        Users Array
    Phase 3 Transactions
      101 Transactions Analyzed
        47 Deposits
        26 Trade Executions
        20 TopUps
        5 Close Trades
        2 Withdrawals
      Internal Transactions
        WETH Wrapping
        Fee Payments 0.005 ETH
    Phase 4 Events
      4 Event Topics Found
        OwnershipTransferred
        VaultDeposit 28x
        TradeExecuted 13x
        TopUpOrWithdraw 8x
    Phase 5 External Calls
      WETH deposit + approve
      Uniswap V3 exactInputSingle
      SENT Token balanceOf
    Phase 6 Risk Assessment
      Custodial Fund Risk
      Keeper Authority
      No Audit or Verification
      Young Contract 1 day

Phase 0: Initial Reconnaissance

Objective: Gather basic contract information and determine analysis approach.

Etherscan API Queries

  • Checked verification status: NOT VERIFIED
  • Checked proxy status: Not a proxy
  • Recorded deployment block: 24,755,545
  • Recorded deployment timestamp: 1774694615 (2026-03-28 10:43:35 UTC)
  • Recorded deployer: 0x9fBcc72A6bc74D0060e14Fe8b8f4b7CcFA63eA03
  • Transaction count: 101

Bytecode Acquisition

cast code 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC > artifacts/bytecode.txt

Size: 19,799 bytes

Proxy Pattern Check

# EIP-1967 implementation slot
cast storage 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC \
  0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
# Result: 0x00...00 (empty — not a proxy)

# EIP-1967 admin slot
cast storage 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC \
  0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103
# Result: 0x00...00 (empty — not a proxy)

Confirmed: Standalone contract, not a proxy.


Phase 1: Function Identification

Objective: Extract and map all function selectors to their signatures.

Bytecode Disassembly

Disassembled the full bytecode using cast disassemble and extracted the function dispatch table. The dispatch table begins at offset 0x1c and contains 44 PUSH4/EQ/JUMPI patterns.

Selector Extraction

All 44 selectors extracted from the dispatch table:

0x06e20080, 0x1360003f, 0x1a519533, 0x2e1a7d4d, 0x365b98b2,
0x3fc8cef3, 0x444cef88, 0x46904840, 0x4af9daa8, 0x553a9a93,
0x5b451dff, 0x63d9df85, 0x66c91379, 0x6f747452, 0x748747e6,
0x7bbfc69e, 0x8b4c6df1, 0x8c07635a, 0x8da5cb5b, 0xa0aca335,
0xa8c94d1b, 0xa9bbd114, 0xaced1661, 0xae1e9118, 0xb3051d6e,
0xb5cb15f7, 0xbda962d5, 0xc31c9c07, 0xc59d4847, 0xc84d5389,
0xc9b6e079, 0xcbb117a3, 0xcbe9e55e, 0xd0fd9cad, 0xd2a037ab,
0xd86938ba, 0xda91a291, 0xdca11ab8, 0xde643a71, 0xe74b981b,
0xe7ba4fe5, 0xe87ce5ee, 0xea0ccfae, 0xf1cb0216, 0xf2fde38b,
0xf8b8790f

Signature Matching

Used cast 4byte and 4byte.directory API. Of 44 selectors:

  • 28 matched to known or inferred signatures
  • 16 returned no match (custom function signatures)
SOURCE SELECTORS MATCHED
cast 4byte / 4byte.directory totalProfitGenerated, users, weth, sentToken, feeRecipient, presaleContract, withdrawPartial, setKeeper, vaults, owner, isTracked, setPresaleContract, keeper, getUserCount, swapRouter, getStats, SWAP_DEADLINE_BUFFER, getUserTier, MAX_TRADE_ETH, totalTradesExecuted, getEligibility, setFeeRecipient, transferOwnership, topUp, withdraw
Transaction input analysis deposit (0x4af9daa8), executeTrade (0xea0ccfae), closeTrade (0xd86938ba)

Special Selector: 0xf8b8790f

The bytecode shows this selector returns a hardcoded value of 0x3635c9adc5dea00000 (1000 × 10^18). Appears to be a constant like TOTAL_SUPPLY or MAX_CAPACITY.


Phase 2: Storage Layout Analysis

Objective: Map storage slots to state variables.

Sequential Storage Read (Slots 0-20)

for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do
  cast storage 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC $i
done

Cross-Reference with View Functions

  • Slot 0 value matches owner() return
  • Slot 5 value matches keeper() return
  • Slot 6 value matches feeRecipient() return
  • Slot 9 (0xa2 = 162) matches totalTradesExecuted()
  • Slot 3 (0x55 = 85) matches getUserCount()
  • Slot 10 matches totalProfitGenerated()

Vault Struct Analysis

Called vaults(address,uint256) for known depositors and decoded the 11-field return value against known data points (deposit amounts, timestamps, token addresses).


Phase 3: Transaction Analysis

Objective: Understand contract behavior through transaction patterns.

Full Transaction History

Retrieved all 101 transactions via Etherscan API. Categorized by method ID:

METHOD ID COUNT FUNCTION
0x4af9daa8 47 deposit
0xea0ccfae 26 executeTrade
0xde643a71 20 topUp
0xd86938ba 5 closeTrade
0x2e1a7d4d 2 withdraw
0x60e03461 1 (creation)

Internal Transaction Analysis

20 internal transactions examined, revealing two outflow patterns:

  • 0x90fF7835...fceEAD receives 0.005 ETH per deposit (fee recipient)
  • 0xC02aaA39...756Cc2 (WETH) receives ETH during trade execution (wrapping)

Trade Execution Deep Dive

Examined full transaction receipt for 0x1cdd8480... revealing the complete trade flow:

  • WETH deposit (wrap ETH)
  • WETH approve to SwapRouter
  • USDC Transfer from Uniswap pool to contract
  • WETH Transfer from contract to pool
  • Uniswap V3 Swap event
  • Contract TradeExecuted event

Input Data Decoding

Decoded executeTrade parameters:

  • user address, vault ID, target token, Uniswap fee tier, ETH amount, min output, direction
  • Observed fee tier: 500 (0.05% pool)
  • Observed tokens: USDC, USDT

Phase 4: Event Log Analysis

Objective: Identify and decode all contract events.

Event Log Retrieval

Fetched logs via Etherscan getLogs API. Found 4 unique event topics:

TOPIC EVENT COUNT
0x8be0079c... OwnershipTransferred 1
0xed9d3a11... VaultDeposit 28
0x0134eeea... TradeExecuted 13
0x91ede45f... TopUpOrWithdraw 8

Event Data Decoding

  • VaultDeposit: (address indexed user, uint256 indexed vaultId, uint256 ethAmount, uint256 sentAmount)
  • TradeExecuted: (address indexed user, uint256 indexed vaultId, address indexed token, uint256 ethAmount, uint256 tokenAmount, uint256 direction, uint256 timestamp)

Phase 5: External Call Analysis

Objective: Identify and analyze external contract dependencies.

WETH Integration

  • deposit() called to wrap ETH before swaps
  • approve() called to authorize SwapRouter
  • Canonical WETH9 at 0xC02aaA39...756Cc2 — verified, trusted

Uniswap V3 SwapRouter

  • exactInputSingle() used for WETH → token swaps
  • Canonical SwapRouter at 0xe592427A...861564 — verified, trusted
  • Pool interactions observed: WETH/USDC (0x88e6a0c2...)

SENT Token

  • Referenced in slot storage and via sentToken() view function
  • getEligibility() likely calls balanceOf() on SENT token
  • Same SENT token analyzed in SENT Token Analysis

Phase 6: Risk Assessment

Objective: Identify security concerns and trust assumptions.

Custodial Fund Analysis

  • Contract holds ~4.84 ETH of user funds directly
  • Keeper has unrestricted trade authority
  • No on-chain trading strategy or safeguards
  • No user consent for individual trades

Centralization Analysis

  • Owner = Keeper = Deployer (same single EOA)
  • No Multisig, no timelock, no governance
  • All administrative functions are immediate

Profit Verification

  • totalProfitGenerated = ~0.018 ETH (self-reported)
  • No independent profit verification mechanism
  • Cannot validate without tracing every trade round-trip

Contract Age Assessment

  • 1 day old at time of analysis
  • 101 transactions, 85 users
  • Rapid adoption for an unaudited, unverified contract

Tools & Resources Used

TOOL PURPOSE USAGE
Foundry cast On-chain queries Storage reads, function calls, tx decoding, bytecode disassembly
Etherscan API v2 Transaction history & metadata Full tx list, internal txs, event logs
4byte.directory Function signature matching API queries for 44 selectors
Python Data decoding Wei/ETH conversions, timestamp conversion, hex decode
Mermaid Diagram generation Architecture and flow visualization

Command Examples

# Bytecode retrieval
cast code 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC

# Bytecode disassembly
cast disassemble <BYTECODE>

# Storage reading
cast storage 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC [slot]

# View function calls
cast call 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC "owner()"
cast call 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC "getStats()"
cast call 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC "vaults(address,uint256)" [ADDRESS] [ID]

# Transaction decoding
cast tx [TX_HASH] input
cast receipt [TX_HASH]

# Balance check
cast balance 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC --ether

Limitations & Assumptions

Unverified Source Code

  • Cannot verify variable names or original logic
  • 16 of 44 function selectors remain unidentified
  • Complex assembly sections not fully analyzed
  • Vault struct field names are inferred, not confirmed

Young Contract

  • Only 101 transactions to analyze
  • Behavioral patterns may not be established
  • Edge cases not exercised

Trade Verification

  • Cannot independently verify profit calculations
  • Would require tracing every swap at market rates
  • Token balances held by contract not fully enumerated

Keeper Behavior

  • Only observed 26 trade executions and 5 close trades
  • Long-term keeper behavior unknown
  • Cannot predict future trade patterns or risk

Assumptions Made

Standard Patterns

  • Assumed Ownable pattern based on owner() and transferOwnership()
  • Assumed keeper role is restricted (based on transaction origin analysis)
  • Assumed vault struct field order based on observed data

Function Behavior

  • executeTrade parameters inferred from input data decoding
  • closeTrade purpose inferred from parameter similarity and context
  • deposit function behavior inferred from event data and internal transactions

Fee Structure

  • Assumed 0.005 ETH flat fee based on internal transaction analysis
  • Storage slot 7 discrepancy (0.01 ETH) not fully explained

Verification Steps for Readers

To independently verify this analysis:

Reproduce Storage Reads

cast storage 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC 0  # owner
cast storage 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC 5  # keeper
cast storage 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC 6  # feeRecipient

Call View Functions

cast call 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC "getStats()"
cast call 0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC "getUserCount()"

Review Transaction History

Visit: https://etherscan.io/address/0x99c96efFDbd52C6868CB500f10350DF444Ab2dCC

Verify Internal Transactions

Check internal transactions tab on Etherscan for fee payments and WETH wrapping.

Examine Trade Receipts

cast receipt 0x1cdd8480bdc3b31c8f21466238e1099851a645baa5c8ce61e128af60b665e251

Token Cost Breakdown

PHASE DESCRIPTION TOKENS
Phase 0 Initial Reconnaissance & Bytecode 8 tok
Phase 1 Function Identification (44 selectors) 10 tok
Phase 2 Storage Layout Analysis 8 tok
Phase 3 Transaction Analysis (101 txs) 10 tok
Phase 4 Event Log Analysis 5 tok
Phase 5 External Call Analysis 5 tok
Phase 6 Risk Assessment 10 tok
Documentation Writing & Formatting (6 files) 19 tok
TOTAL Complete Contract Analysis 75 tok

Note: Token costs are estimates based on typical conversation lengths and complexity. Actual consumption may vary by ±10-15% depending on API responses, iterative refinement, and verification steps.


Conclusion

This analysis employed a multi-phase approach to understand a complex unverified smart contract through bytecode disassembly, storage inspection, transaction tracing, event log decoding, and risk assessment. The contract implements a custodial trading vault — a pattern with inherently high trust requirements.

The methodology prioritizes observable behavior and transparent verification steps, enabling readers to independently confirm findings. All tools, commands, and data sources are documented for reproducibility.

Users should understand the significant trust assumptions involved with custodial trading vaults, especially when combined with unverified source code, a single-EOA owner/keeper, and no independent audit. This analysis cannot replace a full security audit with access to verified source code.