Skip to content

Refactor the CryptoWallet schema #250

@nvmbrasserie

Description

@nvmbrasserie

The CryptoWallet schema has three structural problems: the primary identifier field is misnamed and misdescribed (publicKey), blockchain context is absent, and the schema conflates fundamentally different custody models.

  • Add cryptoAddress as the new canonical address field, then remap every existing publicKey property assignment across the codebase.

The field currently named publicKey stores addresses, not public keys. These are distinct objects in the cryptographic identity stack:
private key → (elliptic curve) → public key → (hash function) → address
An address is a one-way hash of the public key. Public keys are only revealed on-chain when a transaction is signed; they almost never appear in sanctions data.

  • Keep publicKey as a separate optional matchable property

A public key is one level deeper in the identity stack — it can be used to cluster multiple addresses belonging to the same wallet owner, in the same way a master key can link many derived accounts. It appears in some OFAC SDN entries and blockchain forensics reports and has genuine intelligence value for entity resolution.

  • Add blockchain (controlled vocabulary, matchable)

An address is only meaningful within the context of a specific blockchain. The same character string can be a valid address on Ethereum, Polygon, Arbitrum, and other EVM-compatible chains simultaneously — referring to completely different owners. Without blockchain context, an address cannot be deterministically looked up, screened, or verified.

OFAC already encodes this in the SDN XML as Digital Currency Address - XBT, Digital Currency Address - ETH, etc.
Suggested values aligned with OFAC's identifiers: XBT, ETH, XRP, TRX, SOL, LTC, XMR, USDT, BCH, BSC, XLM, ZEC, DASH, ETC, ALGO etc. (extensible).

  • Clarify currency scope in documentation

currency describes the asset held in the wallet. blockchain describes the network it lives on. For major chains like Bitcoin these coincide (BTC / XBT), but the distinction is critical for stablecoins: USDT on Tron and USDT on Ethereum are the same asset, different networks, different address formats, and different screening toolchains. Using currency as a proxy for blockchain produces incorrect data in exactly these cases.

  • Add walletType (controlled vocabulary)

Not all records currently modelled as CryptoWallet represent the same custody arrangement:

  • Self-hosted: the sanctioned party has direct, unmediated control over funds and can move them at any time
  • Custodial: a regulated intermediary holds funds on their behalf, can freeze them, and is subject to FATF Travel Rule obligations

The enforcement response, legal process, and screening logic differ between these. Conflating them is analogous to using the same schema for cash in a safe and a balance in a bank account. Suggested values: selfHosted, custodial, multisig, smartContract etc.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestschemaChanges to FtM schema

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions