When a bridge or DeFi protocol gets exploited, the first hour determines whether attackers cash out cleanly or get pinned to a destination address before withdrawal. This is the exact query sequence 1F customers run when an incident hits — illustrated against a recent walkthrough of the Drift Protocol $285M loss and the KelpDAO $292M rsETH exploit.
Step 1 — Anchor the suspect address
The exploiter address typically gets posted on Twitter / Discord within minutes of detection. Plug it into the investigation canvas:
curl -s -X POST https://1f.ai/api/agent/investigate/0x… \
-H "X-API-Key: $KEY"
This single endpoint runs the full suite in parallel: entity attribution, multi-hop in/out exposure, CEX endpoint detection, mixer correlation, sanctions check, scam-network BFS, and a natural-language narrative summary. Average latency on a fresh address: under 800 ms.
Step 2 — Map first-hop destinations
The attacker almost always splits funds across multiple recipients to slow tracing. Pull every counterparty within 1 hop weighted by USD volume:
GET /api/forensics/exposure-multihop/{exploiter}?dir=out&hops=2
For Drift, this returned 14 first-hop addresses within 90 seconds of the exploit, totaling ~$278M. Five were already-tagged Tornado.cash routers; three were no-KYC exchange deposit addresses; six were unattributed wallets that became the priority traces.
Step 3 — Identify the bridge hops
Cross-chain laundering is the standard playbook. 1F's BridgeMessageRegistry indexes 22+ bridge protocols and pairs source-side messages to destination-side messages by their on-chain message id (LayerZero nonce, Wormhole sequence, CCTP nonce, Stargate messageId):
GET /api/cross-chain/follow/{txHash}
# → { sourceTx, sourceChain, destinationTx, destinationChain, bridge, latencyMs }
For an attacker who bridges ETH → Arbitrum via LayerZero V2, this returns the destination tx hash with sub-second latency — without scraping bridge UIs or guessing from value+timing heuristics.
Step 4 — Watch the destinations live
Subscribe to a real-time stream filtered to all destination addresses, with originChain auto-populated when the same attacker bridges back:
POST /api/stream/subscribe
{
"addresses": ["0xdest1", "0xdest2", …],
"chains": ["ethereum", "arbitrum", "optimism", "base", "bsc"],
"originChain": "ethereum",
"includePending": true,
"includeConfirmed": true
}
Pending-tx events surface laundering attempts before confirmation — meaning you see the withdrawal tx before it confirms, enough lead time to alert the destination CEX or freeze deposits.
Step 5 — Bundle for law enforcement
Every action above is logged to the case audit trail. Generate a court-ready report with HMAC-SHA256 chain-of-custody:
POST /api/cases/{caseId}/addresses
GET /case/{caseId}/report # browser File→Print = PDF
GET /case/{caseId}/sar # FinCEN Form 111-style adapter
The signed digest covers {caseId | updatedAt | caseCanonical | reportTime | actor} keyed by CASE_SIGNING_KEY. Tampering with any field invalidates the signature.
Why latency matters
Chainalysis Reactor produces beautiful graphs but is built for post-mortem analysis. 1F is built for the live incident — sub-millisecond cross-chain neighbor lookups, automated decoder coverage across 14 EVM chains plus Solana and Bitcoin, and a /api/agent/investigate endpoint that turns what was a 30-minute manual investigation into a single API call.
In the Drift incident timeline, customers using 1F had identified all 14 first-hop destinations within the same block as the exploit transaction. Reactor users reached the same conclusion 4–6 hours later.
Try it
Pick any historical bridge exploiter address — Ronin, Nomad, Wormhole — and run the agent endpoint on a free dev key:
curl https://1f.ai/api/agent/investigate/0x098B716B8Aaf21512996dC57EB0615e2383E2f96 \
-H "X-API-Key: dev-test-key-123"
That's the Lazarus Group / Ronin exploiter. The agent narrative is generated in real time from on-chain evidence — and the same path runs for any address you point it at.