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. Lifecycle is 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

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.

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. Its provider IDs and contracts go into the exclusion ledger so discovery cannot reintroduce the same instrument under another name.

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.

Exclusion Fingerprints

Each delisted asset must retain every known discovery fingerprint:

• CoinGecko ID
• DefiLlama ID when present
• canonical chain and contract address pairs
• a concise reason and at least one public evidence URL

Discovery intake checks these fingerprints before candidate persistence. Matching is exact for provider IDs and case-insensitive for chain/address contract keys. CI rejects duplicate fingerprints, unknown catalog IDs, missing delisted rows, and exclusions without a durable provider or contract fingerprint.

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, listing class, and exclusion fingerprints so discovery blocking and active publication cannot disagree.

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, retain sourced price/exit evidence when it explains the decision, and add exclusion fingerprints.
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.

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