Source concepts. Explicit interpretations.
Read the protocol and evidence concepts behind the guides, with a clear boundary between documented facts and proposed data-engineering choices.
Identity is not a display label
The guides distinguish native assets from token records and use network-specific identifiers as the foundation of the schema. Solana mint identity and Ethereum contract-interface concepts come from the named protocol references. Common envelopes, field naming, provenance policies, and acceptance tests are proposed design choices, not universal protocol requirements.
A source node’s chain view
The documented response includes the chain name, validated block count, best block hash, and synchronization-related information. Our Bitcoin guide uses those fields to explain why collection time and source context should accompany an observation. The guide does not prescribe a transaction approval threshold.
Blocks and active-chain context
The reference describes block hash, height, previous-block linkage, and confirmations. A confirmation value of −1 indicates that the block is not in the active chain. The suggested revision and replay model is an engineering recommendation for preserving that context in a downstream dataset.
Mints and token accounts
A mint account identifies a token and stores core fields such as supply and decimal precision. A token account records a holding for a mint and owner. The documentation describes multiple token accounts for an owner and mint and the associated-token-account convention. These distinctions inform the example identity model.
Owner queries have a defined scope
The method returns token accounts for the specified owner with a mint or program filter. The proposed feed design retains that filter and its observation context rather than describing a limited query as an unqualified inventory of every possible holding.
Raw amounts and display representations
The response includes a raw amount and decimal precision alongside user-interface representations. The guides recommend retaining raw numerical values with their precision and applying display formatting separately. Any numerical examples are arithmetic illustrations, not current asset observations.
Observation settings remain visible
The documentation defines processed, confirmed, and finalized commitment settings. The articles recommend preserving the requested setting and relevant response context. The consuming application must choose an observation policy appropriate to its task; a sample schema does not make that operational decision.
Capabilities depend on program context
Token extensions add optional functionality and state to the token model. The documentation describes initialization constraints and incompatible combinations. The guides recommend distinguishing a verified absence of a capability from an unsupported decoding result. Technical configuration is not a legal or economic assurance.
A standard interface with optional metadata
The specification defines token balance and supply methods, transfer-related methods, allowances, and events. Name, symbol, and decimals are optional interface methods. The articles therefore keep unavailable metadata distinguishable from an observed zero or an empty label; they do not assume uniform economic behavior across contracts.
Calls and logs need state context
The documentation describes eth_call for a call in a specified state context and eth_getLogs for matching logs. Block and transaction context inform the proposed event identifiers and correction workflow. Reconciliation and history-retention policies in the guides are application-level design recommendations.
Representation structures are not interchangeable
The educational material distinguishes issuer-sponsored, custodial, and synthetic arrangements. Our RWA guide uses that limited distinction to motivate an evidence record describing what a source says a token represents. It does not classify a specific asset, determine legal rights, verify an issuer, or provide investment advice.
AI risk work is a separate discipline
NIST provides a voluntary AI risk framework and companion generative-AI material. The AI article’s proposed workflow emphasizes evaluation, evidence-linked outputs, versioned transformations, and the ability to decline unsupported conclusions. These are design recommendations, not a claim of certification or NIST endorsement.
How the guides use evidence
Protocol statements use the named primary documentation. Proposed schema fields, acceptance cases, review states, and delivery patterns are editorial recommendations. Current availability, commercial scope, source rights, and operational requirements must be confirmed for an actual service. Article publication and substantive review dates are shown separately.