AI CITATION READY
Direct answer for search and AI citations
5CIP's methodology is a public confidence-tier model for crypto forensic claims, requiring raw transaction evidence, source corroboration, token allowlists, and explicit limits on inferred attribution.
Andy Feng, Founder, 5CIP / CipherJudge Forensic Engine
Credentials: CISSP, CISA
Last updated: 2026-05-25
| Claim area | Evidence |
|---|---|
| Confidence tiers | Tier 1A, Tier 1B, Tier 2, Tier 3 |
| Verification | Etherscan, MistTrack, Arkham, Bitquery cross-source checks |
Evidence Confidence Tiers
Every claim in a 5CIP report is tagged with its confidence tier. Tier 3 claims are marked probable and must not be treated as confirmed facts in legal proceedings without additional corroboration.
| Tier | Label | Confidence | Definition |
|---|---|---|---|
| 1A | Direct On-Chain | ≥99% | Every hop from attacker address to destination has a TX hash on-chain. |
| 1B | Event Log Verified | ≥95% | Transfer event log confirmed against contract address + block number. |
| 2 | Intelligence-Labeled | ≥80% | CEX/VASP deposit confirmed by Arkham or MistTrack entity label. |
| 3 | Probable | ~50% | Nonce-0 + zero-balance heuristic. Marked probable; requires corroboration before legal action. |
Mandatory Data Sources
All four sources must be queried before any report is published. Reports from Etherscan alone are non-compliant.
| Source | Purpose | Minimum Coverage |
|---|---|---|
| Etherscan / Block Explorer | On-chain TX, balance, gas, internal calls | Every address |
| Arkham Intelligence | Entity labels, related clusters | Every address |
| MistTrack | Risk score, classification tags | Every address |
| Bitquery | Token transfers, DeFi interactions | Hub/consolidation addresses |
Token Contract Whitelist
Only the following contracts are accepted for USD-equivalent calculations. Any transfer from an unlisted contract is flagged ⚠️ and excluded from financial totals — this prevents address-poisoning attacks from inflating reported amounts.
| Token | Network | Contract Address |
|---|---|---|
| DAI | Ethereum | 0x6b175474e89094c44da98b954eedeac495271d0f |
| USDT | Ethereum | 0xdac17f958d2ee523a2206206994597c13d831ec7 |
| USDC | Ethereum | 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 |
| USDT | Tron | TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t |
| USDT | BSC | 0x55d398326f99059ff775485246999027b3197955 |
Evidence Integrity
WORM Storage + SHA-256 + verify_pipeline.py
- All evidence files stored in MinIO WORM buckets (Object Lock GOVERNANCE, 90-day minimum)
- SHA-256 hash manifest generated at time of creation; included in every package
- UTC block timestamps cross-referenced against block explorer APIs
- verify_pipeline.py runs 45-point checks before delivery: address existence, TX confirmation, balance matching (5% tolerance), block number precision, token whitelist
- Delivery blocked if any check fails — zero exceptions
Error Correction Policy
All delivered reports are stored under WORM Object Lock and cannot be overwritten. Corrections create a new versioned object with a SUPERSEDES header referencing the original SHA-256. The original v1.0 remains permanently in the evidence bucket.
Material Error Definition
Any of the following constitutes a material error requiring client notification:
- Any change to a wallet address (42-character identifier)
- Amount change exceeding 1% of total case value or USD $1,000, whichever is lower
- Attribution tier change (e.g., Tier 1A → Tier 2, or Tier 2 → Tier 3)
- Change to any named entity (exchange, VASP, individual, organization)
| Source | Trigger | Client Notification | WORM Action | Timeline |
|---|---|---|---|---|
| Pipeline Auto-Detect | verify_pipeline.py FAIL before delivery | None — delivery blocked | No new version; original corrected before first delivery | Must resolve before SLA clock expires |
| Analyst Discovery | Material error found post-delivery | Client notified within 24 hours | New v2.0 object; original v1.0 permanent; SUPERSEDES header added | 24h notification + 48h corrected delivery |
| Analyst Discovery | Non-material error found post-delivery | Logged in audit trail; client informed at next contact | New v1.1 object; original v1.0 unchanged | 72h logging; no mandatory notification window |
| Client Report | Material error reported by client | Acknowledge within 4 hours; corrected delivery within 48h | New v2.0 object; written confirmation sent to client | 4h ack + 48h correction |
| Client Report | Non-material discrepancy reported | Respond within 72h with assessment | v1.1 issued if correction warranted; otherwise documented as noted | 72h response |
Shared Infrastructure Exclusion Rules
Certain on-chain contracts process funds for many users simultaneously. Outflows from these contracts cannot be attributed solely to the subject of an investigation — including them would inflate reported stolen amounts and introduce false attributions, violating the evidence-integrity standard that tracked assets ≤ stolen assets.
Formal basis: a multi-user contract's outflow O cannot be assigned to party P unless P is the exclusive controller of that output path. Shared contracts fail this exclusivity test by design.
| Category | Examples | Exclusion Reason |
|---|---|---|
| DEX Routers | 1inch, 0x Protocol, Paraswap, Uniswap Router, PancakeSwap Router | Route trades for thousands of users per block; input and output cannot be isolated per user |
| Liquidity Pools | Uniswap V2/V3, SushiSwap, Curve, Balancer, Raydium | Pooled assets belong to all LPs; outflows represent any counterparty's trade, not a specific user |
| Bridge Contracts | Wormhole, Stargate, cBridge, Synapse, Across, Hop | Lock/mint or burn/mint mechanics pool cross-chain transfers; recipient mapping is off-chain unless emitted in logs |
| Lending Protocols | Aave, Compound, MakerDAO, dYdX, Venus | Collateral and borrows are fungible at the protocol level; liquidator outflows are third-party |
| MEV Bots & Relays | Flashbots relay, sandwich bots, backrun searchers | Operate on transaction ordering; any profit outflow is the bot operator's, not the investigation subject |
| Gas Relays | Biconomy, Gelato Network, OpenGSN | Pay gas on behalf of multiple callers; fee outflows are service-operator funds, not subject funds |
Exception Conditions
The exclusion rule has three documented exceptions. When an exception applies, attribution is possible at a reduced confidence tier with mandatory documentation.
tx.origin = attacker EOA
→ Attribution at Tier 1B
If the transaction's tx.origin is the attacker's externally-owned account, the smart-contract call is attributable to the attacker. Documents as Tier 1B via event log verification.
Amount + timing fingerprint
→ Attribution at Tier 2
When outflow amount matches stolen amount (within 1%) and timing falls within the same block or sequential block, probabilistic attribution at Tier 2. Requires corroboration.
Bridge with explicit cross-chain recipient
→ Attribution at Tier 1B
Bridge protocols that emit a cross-chain recipient address in logs (e.g., Stargate OFTReceived, Wormhole VAA payload) provide direct attribution to the destination address at Tier 1B.
Privacy Protocols
- Tornado Cash: Entry point and deposit amount documented at Tier 1A; exit address cannot be confirmed without additional intelligence — reported as trace gap
- Railgun: ZK-proof withdrawals break on-chain traceability; withdrawal address is excluded unless corroborated by off-chain intelligence
- Cross-chain bridges: Destination chain must be analyzed separately; entry documented at source chain, exit documented at destination chain independently
APAC Specialization
Per Chainalysis 2026 Crypto Crime Report: stablecoins now account for 84% of illicit transaction volume. TRON-based USDT is the dominant vehicle in APAC pig-butchering and romance fraud cases. 5CIP maintains enhanced coverage for:
TRON-USDT Pig-Butchering
Address labeling, OTC cluster detection
Chinese-Language Romance Fraud
Typology templates, fund flow patterns
Underground Banking / OTC
Cluster analysis, consolidation detection
Cross-Border USDT Settlement
Multi-chain trace: ETH → TRX → TRON
Supported Blockchains
All 9 networks below are supported in a standard engagement. Multi-chain cases spanning 3+ networks may require extended timelines — see the Delivery SLA table below.
| Chain | Abbr | Coverage | Capabilities |
|---|---|---|---|
| Ethereum | ETH | Full | ERC-20 token whitelist; Tornado Cash entry/exit; MEV/Bridge detection |
| BNB Smart Chain | BSC | Full | BEP-20 tokens; PancakeSwap flows; cross-bridge to/from ETH |
| TRON | TRX | Full | USDT-TRC20 (primary APAC illicit vehicle); OTC cluster labeling; TRON-USDT pig-butchering patterns |
| Solana | SOL | Full | SPL tokens; Raydium/Jupiter DEX flows; cross-bridge via Wormhole/Allbridge |
| TON | TON | Full + Poison Filter | Jetton transfers with §8 non-whitelist token exclusion; TON DNS entity resolution |
| Bitcoin | BTC | Full | UTXO clustering; CoinJoin detection; exchange deposit heuristics |
| Arbitrum | ARB | Full | ERC-20 trace; Arbitrum bridge events; shared Ethereum address space |
| Optimism | OP | Full | OP Stack bridge trace; cross-chain to L1 exit points |
| Polygon | MATIC | Full | PoS bridge; MATIC/USDT trace; Polygon zkEVM supported |
Delivery Timeline & SLA
All timelines are in business days from receipt of complete case intake materials. The clock starts when all required evidence (victim address, incident date, transaction scope) is submitted.
| Tier | Delivery | Price | Scope |
|---|---|---|---|
| Standard | 14 business days | $5,000 flat | Single chain, up to 50 addresses, one incident window |
| Expedited | 7 business days | $8,000 | Standard scope + priority analyst allocation (subject to availability) |
| Multi-Chain / Complex | 21 business days | Custom quote | Multi-chain trace (3+ networks), 50+ addresses, bridging/mixing involved |
Clock starts on receipt of completed Case Intake form at 5cip.com/case-intake. Delivery is blocked if verify_pipeline.py fails — a failed pipeline means the report is not ready, not that it is late.
Methodology Document
5CIP Forensic Methodology v1
Full methodology including confidence tiers, mandatory data sources, exclusion rules, and error correction policy. GPG-signed PDF.
Sample Evidence Package
Redacted Case Report
A redacted sample forensic report showing report structure, confidence tiers, fund-flow graphs, and exchange subpoena package — without confidential case data.
Request via case intake — select Sample Request as case type.
Request Sample →Ready to start an investigation under this methodology?