Asset and Instrument Identity in Agentic Trading Data

A trading agent may consult several markets for one displayed asset name. We propose separate asset and instrument keys so the harness can explain which market each feature and action actually refers to.

A short symbol is convenient for display and risky for joins. The same letters can label different assets, and the same underlying asset can appear in several markets. A dataset needs identifiers that match the question being asked, with display labels kept separately.

Keep these market rows distinct

Assume a synthetic dataset containing ALPHA-USD on Venue A and ALPHA-USDC on Venue B. A join on ALPHA merges their prices even though the quote assets and execution venues differ. Add a third onchain token named ALPHA on another chain, and the label becomes more ambiguous.

Create an instrument key that distinguishes venue, venue product identifier, base identity, and quote identity. For an onchain asset, include chain and contract address. Keep the display symbol as a separate attribute. This schema is a proposed engineering convention, with a scope defined by the collector.

Coinbase's trading-pair reference exposes product identifiers and base and quote currency fields. These fields give a consumer more information than a ticker label alone. Other providers require their own documented mapping.

Separate assets from markets

An asset table answers what the quantity represents. A market table answers where and against what it is quoted. Retain this distinction even when one venue offers a single obvious pair. A feature combining markets must state its conversion and aggregation assumptions.

For illustration, 100 USD and 100 USDC are distinct quoted amounts until an explicit conversion policy says otherwise. This is a unit-accounting statement, with exchange value left unresolved in this example. A historical conversion should use its own timestamp and availability rule.

Preserve mappings over time

Store metadata observations with effective intervals or observation dates. If a provider changes a display label, older rows should retain their original source identifier and remain resolvable. Preserve historical event keys and document any naming migration.

Where identifiers are unavailable, label the mapping uncertain. A manually reviewed mapping can be useful, but it should carry the evidence and scope of the review. Symbol similarity alone is insufficient evidence that two contracts or two market products are interchangeable.

A collision test

Build a fixture with the two venue pairs, the unrelated onchain token, and a renamed display label for Venue A's existing product. The first three should remain separate instrument identities. The renamed label should resolve to the existing identity only when the provider identifier and recorded mapping justify it.

Check joins for unexpected many-to-many expansion. Count rows before and after metadata enrichment. A doubling of event rows can reveal duplicate mapping records even when prices still look reasonable.

Identity and economic equivalence

A stable key prevents accidental mixing; economic equivalence and coverage remain separate questions. Aggregation across venues remains a separate research decision. A useful dataset publishes both its identity rules and unresolved mappings so readers can understand which comparisons the records support.

Place this check in the agent loop

Our state and memory framework explains how this input contract fits a persistent trading agent. Use the harness-transfer test design to distinguish a data-adapter change from a change in model behavior.