Complex Template · Related Wallets at Scale

Use case 2: Related Wallets at Scale

From one seed address, batch related wallets with explainable evidence.

Use this template when
  • You have a seed address and want related wallets
  • Building a risk / investigation workflow
  • Need on-chain evidence for diligence
Audience: On-chain research, compliance, investigations
Output previewStatic sample · not live
Seed 0x1234…abcd
0xaa…11 · 0.92
0xbb…22 · 0.81
0xcc…33 · 0.74
3 candidates · shared funder + gas payer · window 30d
Coming soon Documented for discovery. Run in Playground unlocks when the domain / endpoint is GA.
Create API Key API Reference

API / MCP

The same template supports REST, Python, and MCP Prompt. Pick the entry you know.

import requests

BASE = "https://api.gatedata.ai/api/v1"
H = {"Authorization": "Bearer gd_live_…"}
addr = "0x1234abcd0000000000000000000000000000abcd"

profile = requests.get(f"{BASE}/wallets/{addr}", headers=H, timeout=15).json()
txs = requests.get(f"{BASE}/wallets/transactions",
                   params={"address": addr, "limit": 100}, headers=H, timeout=15).json()
risk = requests.get(f"{BASE}/risk/address",
                    params={"chain": "ethereum", "address": addr}, headers=H, timeout=15).json()

# Template layer: cluster by shared funder / gas payer / frequent counterparties
# candidates = cluster_related_wallets(profile, txs, risk, min_confidence=0.6)
print(profile, txs, risk)

Inputs

Changing parameters updates the code samples and request URL. Defaults are one-click runnable for live templates.

GET/api/v1/wallets/0x1234abcd0000000000000000000000000000abcd · /api/v1/wallets/transactions · /api/v1/risk/address

Output & interpretation

Static sample responseStatic sample · not live
{
  "seed_address": "0x1234abcd...",
  "counterparties": [
    { "address": "0xaa11...", "tx_count": 42, "value_usd": 812311.5 }
  ],
  "relationship_candidates": [
    {
      "address": "0xaa11...",
      "confidence": 0.92,
      "evidence": ["shared_funder:0xffff...", "gas_paid_by:0xffff..."]
    }
  ],
  "risk_tags": ["cex_deposit:binance", "high_activity"],
  "metadata": {
    "data_status": "ready",
    "object_refs": [
      {
        "type": "asset",
        "id": "asset_eth",
        "asset_id": "asset_eth",
        "entity_id": "entity_ethereum",
        "resolved_from": "query",
        "resolution_confidence": "default"
      }
    ]
  }
}
Field notes
  • seed_addressstring
    Input seed address
  • counterparties[]array
    Frequent counterparties with counts/value
  • relationship_candidates[]array
    Candidates with confidence + evidence
  • risk_tags[]array
    CEX / DEX / mixer / whale tags
  • evidence[]array
    Why related (shared funder, gas payer, …)
  • metadata.object_refs[]object[]
    Unified object references
  • object_refs[].typestring
    Object reference type
  • object_refs[].idstring
    Canonical object identifier
  • object_refs[].asset_idstring
    Canonical asset identifier
  • object_refs[].resolved_fromstring
    Input used to resolve the object
  • object_refs[].resolution_confidencestring
    Object resolution confidence
How to read results
  • Confidence ≥ 0.8 is usually worth human review
  • Empty evidence = weak signal
  • Mixer/bridge tags mean results may be incomplete

Boundaries & next steps

Do NOT use for
  • Not legal attribution of funds
  • Mixers / bridges may break provenance
Common boundaries & status
  • Candidates are template-layer, not a single related_wallets API
  • Scan in batches; use webhooks for incremental updates