ERC-8392 proposes a status layer for tokenized stocks

The NYSE runs 32.5 hours a week. Tokenized stocks are transferable around the clock.

On Aug. 24, 2026, a proposal published on ethereum-magicians.org tried to put a name to that problem. ERC-8392 would standardize how tokenized assets report whether they can currently be valued, redeemed, or used as collateral. Continuous onchain availability lasts roughly 5.2 times as long as the NYSE’s stated trading schedule, and for lending markets whose contracts never sleep, that ratio is where the exposure lives.

The proposal’s author, econoar, described the missing information directly: “The state that determines whether one of these tokens can be safely valued or used as collateral — is the reference market open, is it halted, is the valuation feed stale because it’s Sunday or stale because it’s broken, can anyone actually redeem right now — is not observable through ERC-20, and today every issuer exposes it differently.”

ERC-8392 answers that with a small set of token-level views discoverable through ERC-165. The mandatory interface, IAssetStatus, covers lifecycle and operational status. Three optional interfaces sit on top of it: IReferenceMarketStatus for reference-market state, IReferenceValuationStatus for pricing condition, and IAssetPrimaryStatus for issuance and redemption window availability.

What each interface exposes

IReferenceMarketStatus carries three pieces of market-state data. Its session field reports REGULAR, EXTENDED, AUCTION or CLOSED. Its interruption field reports NONE, PRICE_CONSTRAINED, ASSET_HALTED or VENUE_HALTED. It also includes marketId, encoded using the ISO 10383 MIC standard.

IReferenceValuationStatus separates a stale valuation because no update is scheduled from a stale valuation because something has gone wrong. The desk regards that as a meaningful difference: treating both cases identically creates a risk that a lending protocol could liquidate against a price nobody would have traded at.

IAssetPrimaryStatus reports whether issuance and redemption windows are open, including NAV cutoffs. The point is to give consumers a dedicated signal for primary-market access rather than letting them treat secondary-market transferability as evidence that redemption is currently possible. Those two things are not the same.

Across all views, every enum carries UNKNOWN = 0. Views must never revert, must not depend on msg.sender, and emit no events.

The practical exposure for borrowers and protocols is direct: closed reference markets, abnormal valuation staleness, or unavailable redemption can leave borrowers subject to issuer- and protocol-specific collateral or liquidation rules with no shared surface for understanding why. Econoar wrote, “The first time a lending market liquidates borrowers against a Friday-stale price during a Sunday-night gap, this stops being theoretical.”

ERC-8392 produces no aggregate safe/unsafe signal. The document states that safety depends on the consumer’s use case, so the interface standardizes the questions and leaves the trust decision to whoever reads the answers. That puts the burden on curators and protocol teams to translate status fields into collateral, LTV or liquidation policy. The standard supplies no universal threshold. The desk’s assessment is that this is honest scoping of the interface layer, but it transfers meaningful implementation and policy risk to individual protocol teams, each of whom must build the decision logic that ERC-8392 deliberately omits.

Scope, testing and next steps

The proposal is designed to sit alongside existing token standards, composing with ERC-8056, which covers split multipliers, and ERC-7943/3643, which cover compliance and transfer control, without touching those functions.

Paper testing covers HKEX lunch breaks, mainland price-limit locks, Xetra volatility interruptions, LSE periodic-auction securities, Gulf trading weeks, and NAV-cutoff funds. Corporate-action economics are out of scope. Econoar wrote that the spec had been stress-tested against those non-US structures “on paper,” while warning that “paper isn’t production.” This is the first dated ERC-8392 proposal in the supplied record; no prior comparable ERC-8392 event is available against which to measure production readiness. A reference implementation and Foundry test suite are in progress; the source material does not indicate whether any production deployment exists. No completion date appears in the proposal. What exists at publication is an interface proposal — protocols and risk systems that could consume a common status surface stand to benefit most, but users of tokenized-stock collateral remain exposed to issuer implementation choices and whatever policy consumers eventually build on top.

The FCA and Bank of England have separately appointed members to a Transaction and Post-trade Reporting Harmonisation Taskforce, with three working groups covering Policy, Strategy and Architecture, tasked with harmonizing reporting requirements across UK MiFIR, UK EMIR and UK SFTR. That taskforce addresses a distinct set of reporting obligations and is not part of the ERC-8392 process, though both efforts reflect a shared recognition that treating reporting architecture as a dedicated design problem — separate from the underlying transaction or transfer mechanism — has practical value.