Cross Chain Address Reuse Privacy Risk

When to Use

Use this skill in institutional crypto trading desks and automated bot architectures to audit wallet address reuse across multiple blockchain networks (Ethereum, Arbitrum, Solana, Bitcoin). Using identical public key addresses or static EVM 0x... addresses across multiple chains enables on-chain analytics firms (Chainalysis, Elliptic, Nansen) to deanonymize proprietary trading strategies, track total fund AUM, and link private wallets to KYC exchange deposits. This module computes an Address Reuse Privacy Risk Score and recommends HD Wallet BIP-44 path isolation.

When NOT to Use

• As an on-chain scanner. CrossChainAddressPrivacyAuditor reads only the registry you hand it via register_wallet(). It opens no RPC connection, queries no explorer and imports nothing outside the standard library, so an address the desk never registered is invisible to it and scores as no risk. Completeness of the registry is a precondition, not an output — reconcile it against the chains before trusting a low score.
• As transaction or counterparty screening. The score measures your deanonymisation exposure: how readily an outside observer can link your wallets to each other and to a KYC'd deposit. It says nothing about who you are transacting with. Sanctions and counterparty exposure are sanctions-screening-for-counterparties-and-instruments; behavioural anomaly detection on flows is on-chain-transaction-monitoring-for-anomalies.
• As a key-management implementation. BIP-44 path isolation is the module's recommendation; it derives no keys, generates no addresses and rotates nothing. The implementation belongs to crypto-wallet-key-custody-security, hot-cold-wallet-split-for-trading-bots and shamir-secret-sharing-for-key-backup.
• As a bridge or protocol risk assessment. Reusing one address across chains is a privacy problem; moving value between those chains is a solvency problem. See cross-chain-bridge-risk-for-multi-chain-strategies.
• As an externally benchmarked score. The 0-100 scale, the HIGH_RISK $\ge 70$ / MEDIUM_RISK $\ge 40$ bands and the total_tracked_chains denominator are this module's own conventions. No regulator, standards body or analytics vendor defines them, and a score is comparable only against other runs with the same configuration.

Prerequisites

• Active wallet address registry containing chain_id, address, public_key, is_kyc_linked, and wallet_label attributes per WalletAddressRecord (empty, malformed, or duplicate registrations are rejected).
• public_key may be None when the key is not yet revealed on-chain — a Bitcoin P2PKH output keeps the key hashed until its first spend. Pass None, never a placeholder string: every record sharing a placeholder would be clustered together and a single KYC linkage would contaminate all of them.
• chain_id is a human-entered label, normalised for grouping by strip + case-fold, so Ethereum / ethereum / " Ethereum " are one chain.
• Risk score thresholds (defaults: HIGH_RISK $\ge 70.0$, MEDIUM_RISK $\ge 40.0$, both configurable) and the desk's total_tracked_chains denominator (default 5).

Workflow

1. Wallet Address Graph Ingestion: Ingest wallet records across chains ($C_1, C_2, \dots, C_m$).
2. Cross-Chain Linkage Detection:
   • Cluster records transitively: identical addresses (case-insensitive ONLY for 0x hex per EIP-55; base58 formats such as Bitcoin/Solana compared case-sensitively) OR identical public keys (links different address formats, e.g. a Bitcoin address to an EVM address sharing one secp256k1 key). A None public key forms no edge — two addresses are not linked merely because neither has revealed a key.
   • Identify clusters spanning $K > 1$ chains.
   • Detect if any address in the cluster has been linked to a KYC exchange deposit/withdrawal; one KYC linkage contaminates the whole cluster.
   • An address absent from the registry returns NOT_TRACKED (status unknown) — never interpret it as low risk.
3. Privacy Risk Score Calculation:
   • $\text{Reuse Weight} = 0$ when $K = 1$ (a single chain is by definition no reuse), else $\min\left(50.0, \frac{K_{\text{reused_chains}}}{M_{\text{total_chains}}} \times 50.0\right)$. Charging $K = 1$ would score a perfectly isolated address 50.0 (MEDIUM) on a desk configured with total_tracked_chains=1.
   • $\text{KYC Penalty} = 50.0$ if KYC-linked else $0.0$.
   • $\text{Risk Score} = \min(100.0, \text{Reuse Weight} + \text{KYC Penalty})$.
4. Remediation Directive Generation:
   • Enforce HD Wallet BIP-44 path separation: coin_type isolates chain families (Bitcoin $0'$, EVM $60'$, Solana $501'$ per SLIP-44), but an EVM key pair yields the identical 0x address on every EVM network — EVM-to-EVM isolation requires distinct account' indexes or separate seeds.
   • Mandate unique address rotation per sub-account.

Full procedure: see references/workflows.md. Standards reference: see references/standards.md. Printable pre-flight checklist: see assets/checklist.md.

Common Pitfalls

• Static 0x EVM Address Deployment: Deploying the exact same bot address across 8 EVM chains, making all multi-chain trading volume publicly linkable to a single entity. EVM address derivation takes no chain parameter, so one key pair produces one identical address everywhere.
• KYC Deposit Contamination: Depositing funds from a private strategy address directly into a KYC exchange account, deanonymizing the entire cross-chain wallet cluster.
• Ignoring Public Key Extraction: Assuming different chain address formats (e.g. Bitcoin vs Ethereum) prevent linking, forgetting that spending transactions reveal the underlying secp256k1 public key — the auditor links such records via public-key clustering.
• Lowercasing Addresses to Compare Them: In base58 (Bitcoin legacy, Solana) both letter cases are distinct alphabet characters, so two addresses differing only by case are different addresses; case-insensitive comparison is valid only for 0x hex (EIP-55 checksum).
• Treating Untracked as Safe: An address missing from the registry is NOT_TRACKED (unknown), not low risk — absence of data is not evidence of privacy.
• Placeholder Public Keys: filling public_key with "UNKNOWN" / "N/A" / "TBD" for keys not yet revealed on-chain makes every such record share a linkage edge. The auditor then reports one fictitious mega-cluster and propagates any single KYC linkage across wallets that have nothing to do with each other. Pass None.
• Free-Text Chain Labels: registering Ethereum and ethereum as separate labels used to count as two chains and manufacture a reuse finding for a single-chain wallet. Labels are now normalised, but keep them consistent — the registry is only as good as its identifiers.
• Reading a LOW Score as "No Findings": a 2-chain cluster with no KYC scores 20.0 → LOW, yet the reuse is real. Read remediation_actions, not just risk_level; the module no longer appends a clean bill of health when findings exist.

Verification

• Instantiate CrossChainAddressPrivacyAuditor. Register wallet 0x123...abc active on 5 EVM chains (Ethereum, Arbitrum, Optimism, Polygon, BSC). Mark 1 address as KYC-linked on Binance. Verify auditor flags a HIGH_RISK (Risk Score = 100.0) deanonymization alert and recommends BIP-44 path isolation.
• Register a Bitcoin base58 address and an EVM 0x address sharing one public_key; verify both are linked into a single 2-chain cluster with a PUBLIC KEY LINKAGE remediation.
• Audit an unregistered address; verify the verdict is NOT_TRACKED, not LOW.
• Register a single isolated address on an auditor with total_tracked_chains=1; verify the score is 0.0/LOW, not 50.0/MEDIUM.
• Register two public_key=None addresses on different chains, one KYC-linked; verify they do not cluster and the KYC flag does not propagate.
• Register a 2-chain reused address with no KYC (score 20.0, LOW); verify remediation_actions reports the reuse and does not claim "strong cross-chain privacy isolation".
• Run python -m unittest discover -s skills/cross-chain-address-reuse-privacy-risk/scripts.

Related Skills

• phishing-resistant-authentication-for-custody-access
• on-chain-transaction-monitoring-for-anomalies