Skip to content
LiveNew tools this week
Submit
AIMarketly
resilience-classify logo

resilience-classify

Add explicit resilience overrides (`chainTier`, `deploymentModel`, `collateralQuality`, `custodyModel`) where `inferResilienceDefaults()` is too optimistic. Use when adding a stablecoin or auditing report-card accuracy.

TokenBrice/stablecoin-dashboard0installs24starsDevOps & CI/CD

SKILL.md

Full skill instructions

Resilience Classify

Use this skill to identify coins whose resilience defaults are wrong and to add only the override fields that differ from inference.

Read First

  • Read shared/​lib/​report-cards.ts, especially inferResilienceDefaults().
  • Read docs/​report-cards.md for the scoring model and tier meanings.
  • This skill is only for chainTier, deploymentModel, collateralQuality, and custodyModel. Leave governanceQuality alone unless the user explicitly asked for it.

Workflow

  1. Read the stablecoin entry in shared/​data/​stablecoins/​coins/​*.json (or shared/​data/​stablecoins/​coins.generated.json). Treat the runtime stablecoin re-export as import-only.
  2. Compute or reason through the default inference from backing and governance.
  3. Flag candidate mismatches when you see:
  • non-Ethereum primary deployment
  • multichain or OFT/​CCIP/​Wormhole/​LayerZero architecture
  • off-chain or exchange custody
  • bridge-heavy collateral
  • delta-neutral or structured strategies
  • keywords like CEX, Ceffu, Copper, Fireblocks, bridged, Bitcoin L2, Solana

  1. Research official docs plus one independent source when the architecture is not obvious.

  2. Classify using these questions:

  • chainTier: where do minting logic and collateral really live?
  • deploymentModel: is the token single-chain, canonically bridged, third-party bridged, or natively issued on multiple chains?
  • collateralQuality: what is the riskiest significant backing component?
  • custodyModel: is collateral onchain, institutionally custodied, or effectively exchange/​counterparty held?

  1. Apply only fields that differ from defaults in the matching per-coin JSON file. Keep the diff minimal and regenerate shared/​data/​stablecoins/​coins.generated.json.

  2. Regenerate shared/​data/​stablecoins/​coins.generated.json and run npm run check:stablecoin-data; for full additions, follow Phase 7 in docs/​process/​adding-a-stablecoin.md.

Tiers

  • chainTier: ethereum, stage1-l2, mature-alt-l1, established-alt-l1, unproven
  • deploymentModel: single-chain, canonical-bridge, third-party-bridge, native-multichain
  • collateralQuality: native, eth-lst, rwa, alt-lst-bridged-or-mixed, exotic
  • custodyModel: onchain, institutional-top, institutional-regulated, institutional-unregulated, institutional-sanctioned, cex

Decision Rules

  • chainTier is about the core protocol and collateral location, not where bridged wrappers trade.
  • deploymentModel decision tree:
    • independent mint or redeem on more than one chain -> native-multichain
    • one home chain only -> check whether other chains use canonical or third-party bridges
  • For mixed collateral, classify by the riskiest significant component.
  • If any meaningful backing is exchange- or counterparty-held, lean toward cex.
  • When torn between two tiers, choose the riskier one and cite the evidence.

Known Pattern Examples

  • Solana-native or other alt-L1 core systems often need chainTier overrides.
  • CCIP, LayerZero, Wormhole, and similar architectures often imply third-party-bridge.
  • Delta-neutral or exchange-based collateral often pushes custodyModel to cex and collateralQuality toward exotic.