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
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...fceEADreceives 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 swapsapprove()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 callsbalanceOf()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()andtransferOwnership() - Assumed keeper role is restricted (based on transaction origin analysis)
- Assumed vault struct field order based on observed data
Function Behavior
executeTradeparameters inferred from input data decodingcloseTradepurpose inferred from parameter similarity and contextdepositfunction 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
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.