ERC-8392: Asset Status Interface for Tokenized Assets

[econoar]

Tokenized stocks now transfer onchain 24/7 while NYSE is open 32.5 hours a week. 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:
Ondo has an offchain HTTP status API, Robinhood Chain tokens have a proprietary
oraclePaused(), most others have a bare paused(). Every lending market listing
these tokens hand-rolls this per listing.

Human curators can absorb that for five listings. Liquidation bots, 4337 policy
modules, and agents holding tokenized equities cannot — and they’re becoming the
dominant consumers. The first time a lending market liquidates borrowers against a
Friday-stale price during a Sunday-night gap, this stops being theoretical.

This draft proposes a small, ERC-165-discoverable set of token-level views — one
mandatory function, three optional extensions:

• IAssetStatus (mandatory): program lifecycle + operational status
• IReferenceMarketStatus: session (REGULAR/EXTENDED/AUCTION/CLOSED) × interruption
  (NONE/PRICE_CONSTRAINED/ASSET_HALTED/VENUE_HALTED), orthogonal dimensions, plus a
  marketId (ISO 10383 MIC) so claims can be cross-checked against public calendars
• IReferenceValuationStatus: distinguishes “stale because no update is due” from
  “stale because something is wrong” — the distinction a feed updatedAt can’t express
• IAssetPrimaryStatus: issuance/redemption window availability (incl. NAV cutoffs)

Design invariants: every enum has UNKNOWN = 0 (zeroed proxy storage can never decode
as a healthy state), views never revert, no msg.sender dependence, no events (session
transitions happen on wall clocks, not transactions), and every status is explicitly
advisory — the ERC standardizes the questions, not the trust.

It deliberately composes with, and does not overlap, ERC-8056 (split multipliers),
ERC-7943/3643 (compliance/transfer control), and feed-level market status products
(a valid implementation may source session state from an oracle report).

Full draft: Add ERC: Asset Status Interface for Tokenized Assets by econoar · Pull Request #1964 · ethereum/ERCs · GitHub

What I’m specifically asking for

This spec has been stress-tested against non-US market structure on paper (HKEX lunch
breaks, mainland price-limit locks, Xetra volatility interruptions, LSE periodic-
auction securities, Gulf trading weeks, NAV-cutoff funds) — but paper isn’t
production, and I’d rather find the breakage here than after Final.

1. Issuers (Robinhood, Superstate, Ondo, Backed, Securitize, Dinari and anyone
   else shipping these tokens): is this implementable as a thin adapter over state you
   already maintain? Where does it fight your architecture? Several of you have
   already built the semantics this standardizes — I’d genuinely welcome co-authors.
2. Curators and lending-market teams: would you consume this to set LTVs and
   liquidation logic? What’s missing for that to be real?
3. Market-structure review: the AUCTION mapping rules and the scope of
   PRICE_CONSTRAINED (limit-locks, special quotes, partial constraints like
   program-trading sidecars) are the two places I’m least certain the enums carve
   reality at the joints. If you know a venue whose states these can’t encode, please
   break them.
4. The marketId encoding (MIC, right-padded bytes32) — sufficient, or does
   cross-listing/OTC need more?

Two scope decisions worth flagging so they don’t surprise anyone: corporate-action
economics are deliberately excluded (ERC-8056 owns splits; mergers/spinoffs deserve
their own ERC — this spec only exposes their operational shadow), and there is
deliberately no aggregate “safe/unsafe” verdict — safety is a property of the
consumer’s use case, not the asset.

Reference implementation with a Foundry test suite (including the zeroed-proxy and
interface-ID assertions) is in progress and will accompany the PR.

[Anzus_GemWallet]

From a wallet-user perspective, this would be most useful when the status can be translated into plain language. For example: “reference market closed,” “price may be outdated,” or “redemption is currently unavailable.”

I like that the proposal avoids one broad “safe/unsafe” label. What matters is helping users understand what changed and why before they decide whether to trade, hold, or use an asset as collateral. Showing when the status was last updated would also help people judge how much confidence to place in it.

[zexoverz]

Lending side, yes, we would consume this. Reading assetStatus() and referenceMarketStatus() off the token address is strictly better than what we do today, which is per-listing curator config bound to an oracle address. Two things stand between “readable” and “consumable” for us.

First, setting an LTV is not a spot read. A haircut for a tokenized equity comes from history. How often was this asset ASSET_HALTED last year, how long did PRICE_CONSTRAINED persist on the venues we list, how many times did the source go DELAYED rather than EXPECTED_NO_UPDATE during a weekend gap. With no events the only way to get that series is polling every block against an archive node, per token. The no-events rationale covers wall-clock transitions and I agree there, nothing can be required to emit when no transaction happened. But general requirement 4 already splits statuses into ones an issuer pushes onchain and ones derived from stored data. The pushed ones arrive in a transaction, so an event costs the issuer nothing extra and gives every integrator an indexable history. Same for the calendar write when a delegated provider updates its schedule. Motivation says an issuer that reported CLOSED and EXPECTED_NO_UPDATE throughout a gap event ends up in a materially better position, and I think that is right, but with views only there is no record that they did.

Second, liquidation logic needs a status that is bindable at settlement, not just readable at check. Security Considerations 5 says risk-critical contracts should query in the same transaction as the protected action, and for an atomic liquidation that is enough. It is not enough for the two consumers the Motivation leans on. The AA note already concedes it. A 4337 policy module cannot touch this storage during validation, so it preflights offchain and re-checks in execution, and the value it preflighted against is not the value it settles against. Same for anything whose settlement leg is not in the check block, Dutch-auction liquidations that walk over several blocks, signed intents, queued redemptions. On the session axis nextScheduledTransition partly covers this, since a consumer can bound how long REGULAR is good for. The interruption axis has no equivalent, and by your own note halt lifts are unscheduled and not represented, so NONE at block N says nothing about block N+k.

The concrete ask is a way to commit to a reading and let settlement reject a mismatch. A bytes32 digest over the joint tuple plus the AsOf values would do it, and it keeps the position of supplying facts rather than verdicts, since the consumer picks what it binds and what it tolerates.

I would not reach for slippage-style bounds here, since bounding a price works because there is an independent reference to bound against, and here the issuer both writes the status and is the party whose operations it describes.

Happy to review the reference implementation when it lands, particularly the delegated-provider failure path.

[thamerdridi]

Interesting proposal @econoar . It seems complementary to ERC-8320, though I think the boundary could be made more explicit. ERC-8320 represents valuation, terms, risk, events, and business lifecycle information as signed, versioned, role-gated claims with schema and content commitments, while ERC-8392 exposes related current operational states through synchronous token-level views.

Would it make sense to mention ERC-8320 in Prior Art and clarify this distinction between live status and supporting provenance? Since these views are issuer-asserted and define no normative history, an optional reference to the supporting claim or configuration, with a digest binding where appropriate, could preserve the lightweight interface while allowing consumers to verify the authorship, validation, schema, content, and history behind the status.