A blockchain funds tracing API should preserve the evidence behind a transfer path. Model addresses and transfers separately from inferred entities, and retain chain identifiers and transaction hashes. An attribution label can help an investigator, but it is not proof that two addresses have the same owner. This guide focuses on the data model used to represent a trace.
Represent observed transfers as source records
Keep the chain, transaction reference, asset, amount and block or time context for every observed transfer. Preserve native units and any normalized amount explicitly. A record should identify where the observation came from so an investigator can inspect the chain evidence rather than trusting a graph label alone.
Model attribution as a separate evidence layer
An address label or inferred entity relationship is different from a transfer. Store attribution with its source and assessment time where available. A later label change should not erase the underlying observation. Avoid representing a provider’s inferred relationship as a confirmed ownership claim without supporting evidence.
Make path boundaries and query scope explicit
Record starting addresses or transactions, direction, traversal depth and filters. Include response pagination and limits so a truncated graph cannot appear complete. Distinguish an end of returned data from a demonstrated absence of further transfers. Test the expected behavior on addresses with no covered history and unsupported networks.
Keep cross-chain links explainable
A bridge relationship can connect activity across networks, while assets, amounts and timing may differ. Preserve both source and destination references and identify whether the connection is observed, provider-inferred or unresolved. A transaction hash is meaningful with its network context. Do not merge similarly formatted addresses across chains into an assumed entity.
Version assessments and retain uncertainty
Store the assessment timestamp and provider context with the response. Add later results as new assessments when labels or models change. Keep missing coverage, unknown attribution and unavailable queries distinct from a completed low-risk result. The consuming application can then apply a documented review policy to evidence rather than treating missing data as certainty.
Validate the model against a reviewer’s task
Use the exposure review guide to check whether each relationship can be explained. Confirm the actual response fields from AML Intelligence before designing an adapter. Preserve source responses alongside normalized records, and use the case export guide when evidence must be reviewed later.
Frequently Asked Questions
Is an address label the same as an identified owner?
A label can be attribution evidence supplied by a data source. It should retain its source and limitations rather than being converted automatically into a verified identity claim.
How should missing graph data be represented?
Separate unsupported coverage, a query failure, a traversal limit and a completed empty result. They have different meanings for review and should not share one low-risk state.
Can tracing responses be normalized across networks?
Yes, with explicit chain identity, native units and source references. Preserve chain-specific information and any inference behind cross-chain links.