[DBIP] Normalize oracle dataTypes: the column mixes data categories, asset symbols, APIs, and SDK libraries

[MDHaarith]

Proposal type

Modify column

Affected scope (files/folders/chains)

references/offers/oracles.csv; listings/all-networks/oracles.csv; listings/specific-networks/*/oracles.csv; Oracles wiki documentation; oracle schema/validation

Motivation / problem statement

The current oracle dataTypes field mixes several different concepts instead of consistently describing the types of data delivered by an oracle.

In the canonical references/offers/oracles.csv, the field currently contains:

• Semantic data categories such as Asset Prices, Randomness, Equities, Commodities, and Prediction Market Data.
• Individual asset symbols such as BTC, ETH, USDC, ATOM, AVAX, and others.
• API/interface concepts such as APIs, Feeds, and Web2 API data.
• SDK/library descriptions such as JavaScript/TypeScript Libraries and Rust Libraries.

For example, Switchboard's dataTypes contains JavaScript/TypeScript and Rust library descriptions even though the row already has a separate sdk column for TypeScript, Rust, and JavaScript.

This makes dataTypes difficult to filter or compare consistently. The same broad concept can currently appear as Asset Prices, Token Prices, Cryptocurrency Prices, Crypto Assets, Real-time Price Feeds, or individual asset symbols.

Users and downstream consumers would benefit from dataTypes having one predictable meaning: semantic categories describing what data an oracle provides.

This is separate from #2552, which proposes normalizing how oracle updates are delivered (push, pull, request-response). This proposal concerns what kind of data the oracle delivers.

Detailed proposal

If proposing column change(s):

• Category/table (rpc | wallet | explorer | indexing | bridge | analytic | devTool | oracle): oracle

• Column name: dataTypes

• Change type (add | remove | modify): modify

• New/updated definition:
  A machine-readable list of semantic categories describing the kinds of data delivered by an oracle. The field should describe the nature of the delivered data rather than individual asset symbols, programming languages, SDK/library names, or API/interface names.

• Value type and allowed values:
  JSON array of normalized strings.

Suggested initial values:

asset-prices
randomness
fx
equities
commodities
indices
prediction-markets
volatility
sports
supply-chain
healthcare
cross-chain-data
web2-data
arbitrary-data
ai-data

Blank should be allowed where the data type has not been verified.

• Examples (concise):

API3:
["asset-prices","randomness"]

Pyth:
["asset-prices","fx","commodities"]

Switchboard:
["asset-prices","randomness"]

Band:
["asset-prices"]

• Notes (constraints, normalization guidance):

1. dataTypes should contain semantic data categories only.

2. Individual asset symbols such as BTC, ETH, USDC, ATOM, AVAX, etc. should not be stored as data types.

3. Programming languages or SDK/library descriptions should remain in the existing sdk column.

4. API/interface information should remain in availableApis where applicable.

5. Values should use one canonical spelling and format so exact filtering works reliably.

6. Do not infer data capabilities merely from a provider or product name. Existing verified data and primary provider documentation should be used when normalizing rows.

7. Leave the value blank when it cannot be confidently verified rather than guessing.

Optional follow-up:
If maintainers want to preserve individual asset/feed information in structured form, a separate assetSymbols field could later be considered, for example:

["BTC","ETH","USDC"]

This optional companion field is not required for the core dataTypes normalization and can be discussed separately if maintainers prefer to keep this proposal narrowly scoped.

Relationship to existing proposal:
This does not duplicate #2552. #2552 concerns oracle update/delivery models (push, pull, request-response), while this proposal concerns the semantic type of data being delivered.

AI disclosure:
AI assistance was used to analyze the current repository data and draft this proposal. The examples were checked against the current canonical oracle data.

Contact (optional)

GitHub: @MDHaarith

Rewards address (optional)

0xe4064deaeA293c56059faCe1075A83FA23f4e1E4

[foxxx009]

/bounty claim — implementing...

Rewards address: 0x2409b47a530be3831158f10b08ac93f7d08c1ff2

[foxxx009]

PR: #3680 — 34 dataTypes cells normalized to the proposed vocabulary (27 canonical + 7 listings); validate_csv / csv_to_json / validate all pass.

[foxxx009]

Hi @MDHaarith — nothing you need to act on. It's the standard claim syntax used in this repo to register the payout address of whoever is implementing a proposal (you'll see the same pattern on other DBIP issues here). In this case it marks me as the implementer of your dataTypes normalization — see PR #3680. If the PR gets merged, the implementation reward goes to the address in the claim; your own proposal reward would go to the address you listed at the bottom of the issue body.

[MDHaarith]

So it is kind of you get yours I get mine. Or is it fully yours alone and not mine. I am first here man I just don't know. @foxxx009

[foxxx009]

It's the first one: you get yours, I get mine — they're two separate rewards. Your proposal reward goes to the address you listed in the issue body, and it's earned by your proposal being accepted. Mine is tied to implementing it (PR #3680), paid per normalized cell if the PR is merged. You were first — this is your proposal, I just did the data work. Fair warning though: I can't speak for the maintainers, so whether and how much the proposal reward pays is their call (see Discussion #41 for the DBIP program terms).

[MDHaarith]

@foxxx009 thanks for explaining bro. 😁