Stablecoin Listing Policy

This document defines which assets Pharos admits, how admitted assets are classified, and how assets leave the active universe. It is the public policy contract for catalog curation. Runtime price construction remains in Pricing Pipeline.

Sources Of Truth

Listing governance is checked in and deterministic:

listing-decisions.json is intentionally compact. It contains only schemaVersion, policyVersion, and an exhaustive listingClassById map. Every catalog ID has one row. When a formerly tracked asset is removed to the cemetery, its row remains as excluded so the historical scope decision is not silently erased; the stablecoin-data guard accepts such extra rows only when the ID exists in shared/data/dead-stablecoins.json. Lifecycle is otherwise catalog metadata, not duplicated in the class ledger. priceBasis and exitMechanism are authored only on sourced delisted records to preserve the evidence for their removal; Pharos does not infer or store those fields for active assets.

Provider membership is discovery evidence, not an admission decision. A CoinGecko category, DefiLlama row, symbol, name, or nominal price never proves that an asset belongs in Pharos.

Listing Classes

The listing class separates the research catalog from the core monetary aggregate.

Class precedence is deterministic: excluded, then stablecoin-variant, then stable-value-investment, then cash-equivalent, then the residual core-stablecoin class. npm run check:stablecoin-data enforces exact catalog coverage and this precedence.

Instrument Eligibility

An in-scope asset must make a stable-value claim that users can test through an ordinary transfer, trade, redemption, or modeled NAV path. It must also have a distinct, verifiable identity and enough public evidence to explain the issuer, backing, peg mechanism, and holder exit.

Active additions and pre-launch promotions must pass the existing runtime price and market-cap gate documented in Adding a Stablecoin. The research packet must identify an accepted price path and a positive circulating-supply or market-cap path. The static catalog check also verifies that active metadata identifies a supported cache-admission path. These checks are process and code invariants; there is no separate admission-receipt registry.

The following are out of scope:

• non-withdrawable exchange account balances, reward balances, points, or internal credits
• permissioned, deal-specific notes or receivables whose displayed unit value is contractual accounting par rather than a transferable monetary price
• instruments whose only holder exit is issuer discretion or a private bilateral process
• ordinary equity, credit, commodity, or fund interests with no modeled stable monetary or cash-equivalent reference
• duplicate wrappers or provider aliases that do not represent a distinct holder instrument
• assets admitted only because an aggregator categorized them as a stablecoin
• assets that require an open-ended manual supply patch or fabricated par price

Small supply is a review signal, not an automatic exclusion. A missing live price caused by a known pricing-pipeline gap does not by itself remove an otherwise valid asset, and a genuine depeg must remain monitored rather than being hidden through lifecycle state. Persistent absence of any positive circulating-supply or market-cap path is a quarantine condition because the asset cannot participate honestly in market-size and coverage calculations.

Price And Exit Evidence

When a reviewed delisting depends on price or exit semantics, its catalog row records the sourced evidence:

A positive number is not sufficient when its semantics are wrong. Contractual par must not be published as a live market price. A symbol-level DEX search, unmatched contract quote, stale provider cache, or unrelated same-symbol asset also fails the identity and price tests.

Lifecycle Policy

Only active rows enter live producers and score recomputation. Quarantined and delisted records keep static detail pages but are excluded from the screener, compare, aggregates, alerts, and new provider refreshes.

Quarantine is operational, not punitive. A quarantine review records changedAt, a concrete reason, and reviewBy. The review date creates an explicit manual follow-up; extensions require another dated review. Reactivation requires a positive supply or market-cap path, the normal active-admission checks, and a new lifecycle review. Missing price coverage alone is worked as a pricing issue while the asset remains active.

A missing live price does not by itself move an active asset to quarantine or delist, and it is never papered over with a substitute quote. When every admissible price lane is empty and the asset's lifecycle is otherwise sound, the gap may instead carry a reviewed price-gap acknowledgement (STABLECOIN_PRICE_GAP_REVIEWS in worker/src/lib/stablecoin-publication-coverage.ts): a dated registry entry naming an owner, a concrete reason, at least one public https source, and an expiry no more than roughly 30 days after the review. An acknowledged gap stays published as missing — missing counts, affected market-cap exposure, and per-asset rejection detail are unchanged — but it stops producing public health warnings and admin warning causes. Renewal requires a fresh review with new evidence; expiry is automatic, so the gap alerts again until the asset is re-sourced, frozen, or delisted. Acknowledgement never applies to a depeg, never applies to an asset that already has a price, and never substitutes for the lifecycle disposition, which keeps its own dated review.

Delist when the instrument itself fails scope, including account-only balances, private contractual-par notes, misleading provider artifacts, or assets without a meaningful transferable or redemption claim. A delisted record requires a dated reason and public source.

Freeze only a previously active stablecoin that has effectively ended or failed and whose historical market record belongs in the cemetery. Freezing a Tracked Stablecoin owns that procedure.

Ongoing Runtime Review

The active-admission gate is run for additions and promotions and can be repeated when runtime coverage is in doubt. It records the accepted path in the asset research packet:

• a verified provider or exact-contract identity
• a supported current-price path
• a positive circulating-supply or market-cap path
• the metadata needed by that path
• unresolved risks or follow-up work

An incumbent with a price-pipeline failure remains active while the failure is investigated. An incumbent with no defensible positive supply or market-cap path moves to quarantine. An asset whose instrument semantics fail scope moves to delisted. This separates repairable pricing work from catalog-quality decisions without suppressing genuine market stress.

Re-Admission

Re-admission is exceptional. It requires new evidence that the instrument changed, not merely that a provider relisted it. The same reviewed change updates the catalog lifecycle and listing class so historical scope decisions and active publication cannot disagree.

The recorded application is the 2026-09-29 sofid-sofi re-admission. The 2026-07 quarantine reason — no positive market cap on any permitted source — no longer held: CoinGecko sofiusd began publishing a positive price and market cap (0.999461 USD and ≈328.75M USD cap with ≈12.3M USD daily volume, observed 2026-09-29), DefiLlama carries the asset (llamaId = 430, ≈328.81M peggedUSD), and the tracked deployments corroborate the circulating figure (Ethereum totalSupply 100,077,224 plus Solana mint supply 228,886,850.23 = 328,964,074.23). Publication runs through CoinGecko detail admission (geckoId: sofiusd), so no curated on-chain aggregate is admitted, and the scoped protocol-par reference stays a no-trusted-quote fallback only (see Pricing Pipeline).

Change Procedure

For an addition or promotion:

1. Apply the instrument and class tests before editing the catalog.
2. Add the catalog row and its listingClassById entry.
3. Record a passing runtime price and market-cap path in the research packet.
4. Regenerate catalog projections.
5. Run npm run check:stablecoin-data and the focused tests named by the addition procedure.

For quarantine or delisting:

1. Change the catalog lifecycle with the required review metadata.
2. For delisting, classify the row as excluded and retain sourced price/exit evidence when it explains the decision.
3. Regenerate catalog projections and verify active surfaces no longer include the ID.
4. Preserve canonical URLs and legacy ID redirects for historical readability.
5. Run npm run check:stablecoin-data and focused lifecycle tests.

For a full cemetery removal authorized by the lifecycle owner, remove the catalog source and its active-universe projections, add the cemetery record, and retain the prior listing ID as excluded. This keeps the scope decision auditable even though the asset is no longer part of the tracked catalog.

A curated cemetery record in shared/data/dead-stablecoins.json follows the cemetery's owner-approved rules:

• Inclusion. A new record needs a public market and a primary public source that documents its failure or discontinuation (an issuer or protocol announcement, governance record, official docs or status page, regulator, court or registry filing, or on-chain record); reputable press may be linked only when it documents the same event, and market-data listings, provider "ended" markers, launch or fundraising articles and general wikis never qualify. There is no size floor; peak market cap is recorded when known. Records curated before 2026-10 do not all meet this bar; Cemetery and Compare describes what the page claims for the archive as a whole.
• Primary cause. Each record carries one primary cause: the root reason the coin failed or its issuance and operation ended, whether or not it lost its peg. Triggers such as runs, exploits or orders are described in the obituary.

Every new curated record carries recordedAt, the UTC YYYY-MM-DD date on which it entered Pharos (not the death date), and a mechanismArchetype describing how the coin was designed to hold its peg. Cemetery and Compare owns the full field contract.

The complete implementation procedure for new assets is Adding a Stablecoin. Catalog structure and generated artifacts are documented in Stablecoin Data Registry.