ERC-8392: Asset Status Interface for Tokenized Assets

ERCs
1

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.

2 Likes
2

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.

3

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.

4

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.

5

Could the configuration reference suggested above also identify the valuation update schedule?

Suppose a fund’s NAV update is due at 18:00 but never arrives. The issuer then moves the deadline to the next day. Could the status change from DELAYED to EXPECTED_NO_UPDATE even though no new valuation has been published?

The source and methodology could remain unchanged throughout. A fresh statusAsOf would tell me when the status was affirmed but not whether the reporting deadline had been moved.

Would an optional schedule version or commitment let consumers distinguish a planned reporting change from a missed deadline being pushed back? That seems particularly useful for RWA lending integrations.

6

I don’t think a schedule version separates them on its own, since a planned change and a missed deadline being pushed back both bump it. What separates them is whether the old deadline had already passed, with nothing published, at the moment it was rewritten:

pushed_back = rewrittenAt > previousExpectedUpdate && valueAsOf < previousExpectedUpdate

Neither input survives in the current struct. The rewrite overwrites nextExpectedUpdate, and statusAsOf can’t stand in for rewrittenAt because it moves on every re-affirmation, so a deadline moved a day early and then re-pushed after the old date looks exactly like a slip. The Events section rules out reading it from logs too, since consumers MUST NOT rely on events.

So the view would have to carry it. Two optional fields in ValuationStatus, the prior deadline and the time it was replaced, set whenever nextExpectedUpdate is rewritten, would let a consumer check that in one call at settlement. It only keeps one step of history, which is enough for the question you asked. For RWA lending I’d want it in the view, because whoever is liquidating usually isn’t whoever took the earlier reading.

1 Like
7

@econoar interesting proposal. Separating current operational status from provenance and history feels like a clean architectural boundary. Building on @thamerdridi 's ERC-8320 point, that standard can provide the signed, versioned and role-governed claims behind an asset’s valuation, terms, risk profile, reporting schedule and business lifecycle. This proposal can expose the current operational projection of those claims through synchronous views at the token address.

Our ERC-8325–8330 family offers several additional composition points:

  • ERC-8325 establishes the durable token-to-asset binding. Anchor activity and token-program lifecycle should remain distinct: an anchor can expire while a program remains operational, and a program can be suspended while its asset binding remains valid.
  • ERC-8326 can commit the documents and configuration defining the designated market, valuation source, reporting schedule, and issuance or redemption policy.
  • ERC-8330 is an append-only NAV snapshot oracle that separates valuation time from publication time and preserves provider attribution, corrections and invalidation.
  • ERC-8328 records attributed compliance actions such as freezes, regulatory holds and enforcement actions.

For an ERC-8330-backed implementation, valueAsOf could map to valuationTimestamp, while source identifies the oracle and sourceId binds the subject, currency, NAV basis and provider or aggregation policy. The EXPECTED_NO_UPDATE versus DELAYED distinction remains additive because ERC-8330’s staleness flags alone do not establish whether an update was actually due under a reporting calendar.

An optional supporting-claim or configuration commitment could bind a status response to the governing ERC-8320 claim or ERC-8326 bundle without making either a dependency. Because ERC-8320 permits multiple active claims for a claim type, the adapter would need a deterministic rule identifying which registry, schema, author and version control the reported state.

On @zexoverz ’s history point, ERC-8330 and ERC-8328 preserve relevant valuation and compliance history, but they do not provide a complete series of market sessions, interruptions, valuation-condition transitions or primary-window states. That gap would still require polling, issuer-defined events, or an optional standardized history mechanism for transaction-driven status changes.
It may therefore be useful to add ERC-8320 and ERC-8330 to Prior Art or Composition, include a non-normative adapter mapping, clarify the ERC-8325 lifecycle boundary, and consider an optional configuration digest while keeping the core views minimal.
Architecture thread—feedback welcome: Proposing a family of candidate ERC interfaces for titled asset infrastructure

1 Like
8

@Musyimi97, good point overall. One correction on the ERC-8320 part: there is no open-ended selection problem here. ERC-8320 is role-governed, not permissionless, so arbitrary parties cannot publish competing claims and leave the consumer to decide which one is authoritative. VALUATION, for example, is only the broad claim family. The actual semantics are defined by the claim envelope and its referenced schema, which identifies the concrete claim variant within that family. The same applies to the other claim types. Multiple active claims are therefore intentional and can represent distinct governed claim variants, rather than competing candidates from which an adapter must choose a canonical one.

2 Likes
9

@thamerdridi Thanks for the correction—agreed. My wording conflated claim plurality with authority ambiguity. ERC-8320’s role governance determines who can author, validate and activate claims, while the envelope’s schema and claimVariant distinguish the concrete semantics within a broad family such as VALUATION. Multiple active claims can therefore represent separate governed variants rather than competing assertions requiring the adapter to choose an authoritative winner.

The composition question I intended is narrower: where an ERC-8392 status is derived from ERC-8320, how can a consumer verify which governed claim, schema and variant support the returned status tuple? An optional claim reference or digest could provide that provenance binding without imposing a single canonical claim or changing ERC-8320’s multi-claim model.

3 Likes