How ST0x Uses DIA Oracles for Tokenized Equity Trading

Tokenized equities now trade and settle across DeFi, but the feed underneath a tokenized stock still references an equity. It has regular hours, extended sessions, holidays, and corporate actions. Onchain, the price looks like any other feed, a number on a heartbeat, and that number alone says nothing about which market state it belongs to.

ST0x is where that gap gets concrete. It runs a decentralized exchange for 24/7 trading of tokenized equities and ETFs on Base mainnet, where users place intent-based orders that solvers execute against liquidity spread around a live oracle price, each token backed one-to-one by shares held with a regulated broker.

ST0x tokens differ from most tokenized equities in what they legally entitle the holder to. Most products give a claim on a token’s monetary value, redeemable with the issuer, and the token is not a direct claim on the underlying share. An ST0x token carries the right to redeem for the underlying share itself.

That changes issuance and redemption. When a product redeems for cash value, the issuer has to buy or sell the underlying share as users enter and exit, which introduces execution risk into the reserves backing the token. Redeeming for the share removes that step and keeps a tighter link between the token and the asset it represents.

Crypto spot markets trade continuously. U.S. equities do not. That gap barely matters when a price sits in a portfolio view. It becomes everything when a price sets where trades clear.

In traditional brokerage interfaces, placing an order and executing it are often separate steps. A user submits an order outside market hours and execution waits for the next session. Tokenized-equity applications face the same design question with onchain constraints, because the order, the price feed, and the execution logic can all be programmatic.

For a venue like ST0x, users do not trade against the oracle directly. The oracle is the reference midpoint the venue quotes its liquidity around, and users trade the resulting order book. That puts the oracle underneath the whole book: if the midpoint reflects the wrong market state, every quote spread around it is mispriced. A regular-hours price, an extended-hours price, and a stale post-close price can all point to the same security, and they are not equivalent reference points. That is why a tokenized-equity oracle cannot be a generic last-price feed.

In ST0x’s order logic, that same midpoint sets the quotes users see, so the oracle’s freshness flows straight into the prices they trade against. That puts weight on freshness.

At least three timestamps or thresholds matter, and they are not the same:

• Market observation time: when the underlying price was valid.
• Oracle update time: when the value was written onchain.
• Application staleness threshold: how old a price can be before the venue should stop relying on it.

An onchain update can be recent while the underlying equity price is not. A feed heartbeat can behave exactly as designed while the referenced market has moved from regular trading into an extended session or a closed period. A venue that treats every freshness signal as equivalent anchors its whole book to the wrong market state. For tokenized equities, freshness is a product decision.

This is what DIA’s Real feeds are built to meet for ST0x, and it is where feed design does the work a raw price cannot. Two properties matter most.

Freshness is verifiable. DIA delivers price values signed together with their timestamp, so the consuming contract can check when the market value was actually observed rather than trust that a recent onchain write implies a recent price. For a venue quoting liquidity around that price, that check separates tracking the live market from tracking a value that only looks current.

The feed is session-aware. Pre-market and post-market feeds are separated from regular-session feeds, and freshness logic is not applied identically across market states. That keeps the burden of knowing which session a price belongs to inside the oracle layer, where it can be reasoned about consistently, instead of on every application that consumes the price. Building session state into the feed, so each venue does not have to reconstruct it, is becoming a baseline requirement for real-world-asset oracles.

This runs on Lasernet, DIA’s own oracle L2, where feed configuration, update conditions, and the signed values themselves are auditable onchain.

DIA provides the oracle infrastructure behind ST0x’s tokenized-equity trading on Base: custom equity and ETF feeds requested by ST0x, delivered in a format its trading system consumes, and configured through heartbeat and deviation parameters tuned per asset. Live feeds include major names such as NVDA, TSLA, COIN, and MSTR. Pre-market and post-market support is production-ready across the requested assets, which lets ST0x’s order book stay aligned with the market outside regular trading hours.

DIA Real is built for real-world asset price feeds such as equities, ETFs, commodities, and FX. In the ST0x implementation, that is the difference between publishing an equity price onchain and supporting tokenized-equity trading infrastructure.

Tokenized equities are getting easier to distribute across crypto-native platforms, and issuers, trading venues, wallets, and DeFi protocols are all moving toward onchain rails for securities exposure. The more those assets are used in trading, lending, and structured products, the more each integrating protocol has to tell price apart from market state.

For ST0x, the next step runs in that direction. Its wrapped equities are built as vault shares meant to serve as collateral in DeFi lending, which would put the same feed behind liquidations in lending markets beyond ST0x itself. The requirements this article describes only compound there: a price carried over from a closed session, or left unsynchronized through a corporate action, stops being an execution question and becomes collateral risk.