Tokenized equities
Token instruments distinct from underlying corporate shares.
#Formal definition
A Stock Token is a tokenized instrument associated with economic exposure to an equity reference. It is not represented as direct ownership of the underlying corporate share.
Tokenized equities is treated as a typed part of an agent mandate, not as marketing language. The definition is stored before an output exists so it cannot be changed to explain a favorable result after the fact. Product pages keep the relevant definition beside live state, and the decision ledger retains the version needed to reconstruct how an emitted stance was produced.
#Configuration
OVERWEIGHT records the token identity and the deployment returned for Robinhood Chain ID 4663.
Configuration is validated at the boundary. Symbols must follow the application symbol format, numeric limits must remain inside the documented range, and any creator-supplied text is stored as user-generated content. Built-in definitions are static product configuration; published definitions are database records. Neither category is evidence of market activity until real observations are associated with it.
#Runtime behavior
Market and portfolio surfaces work with the token contract, token balance, and Stock Token quote source. They do not silently substitute an underlying exchange feed.
The runtime refuses to bridge missing information with a default financial value. A missing quote remains unavailable, a stale input blocks conviction, and a halted asset does not become an observation. The current state therefore describes what the engine can prove at the latest successful cycle. READY means the complete gate is satisfied; it does not mean the model is correct or profitable.
#Audit trail
Every value related to tokenized equities has a declared source type: live external data, onchain state, an engine derivation, a database row, static configuration, or user-generated configuration. Source timestamps and application receipt timestamps remain separate. This makes it possible to distinguish when the upstream venue generated a quote from when OVERWEIGHT received and persisted it.
For a decision, the audit path continues through input snapshot IDs, model version, component contributions, thresholds, output stance, and freshness. Reprocessing the same agent, source timestamp, and stance uses the same decision ID. The database primary key prevents a second write from creating a duplicate public record.
#Worked example
An NVDA Stock Token balance is an onchain token balance. Its indicative value joins that balance with the current Stock Token bid/ask midpoint.
The example is explanatory rather than a seeded production record. Numbers in documentation illustrate arithmetic only and are never imported into application routes. Production components receive values through typed selectors. When the corresponding runtime value does not exist, the component renders an em dash, NO DATA, or another explicit unavailable state instead of copying the example.
#Failure states
Relevant failure states include MARKET API UNAVAILABLE, RPC UNAVAILABLE, DATA DELAYED, STALE, MARKET HALTED, NO DATA, and an incomplete observation count. Each state answers a different question: whether the source responded, whether the response is current, whether a market is halted, and whether the model has enough complete data. Those states are not interchangeable.
A failed request cannot become an observation. Duplicate source timestamps are ignored by a unique database index. Missing benchmark data prevents a benchmark-relative score. A user-published definition with no scheduled worker reports NO DATA rather than CALIBRATING, because calibration would imply that collection is actively progressing.
#Limits
Legal rights, counterparty exposure, market hours, liquidity, settlement, and corporate-action treatment can differ from the underlying share.
OVERWEIGHT agents currently publish research states. They do not take custody of a user account, execute an order, guarantee a fill, or guarantee an outcome. The transparent schema makes a model inspectable, but inspection does not remove model risk, venue risk, tokenized-instrument risk, or the statistical weakness of a short record.