USDT/USDT0 DeFi Vaults

A reference basket of USDT and USDT0 DeFi lending vaults across Philidor's Prime and Core risk tiers. USDT0 is Tether's OFT (LayerZero omnichain) variant, and the two tokens are treated as one asset family, so a vault accepting USDT on Ethereum and a vault accepting USDT0 on Base or Arbitrum is eligible. The basket admits vaults at both Prime (risk_score ≥ 8) and Core (5 ≤ risk_score < 8) tiers, with score-weighted allocation pivoting at 5.0 so Prime vaults dominate by weight while Core names remain represented. Diversity rules seat at least 2 protocols and cap any single protocol at sixty percent of the 10 available slots.

Summary

Constituent Type

Vault (each constituent is a DeFi vault holding a qualifying terminal-underlying asset)

Minimum constituents are 3.

Eligibility Rule

A vault is eligible when its Philidor risk tier is Prime or Core, its asset_components array is a subset of ['USDT', 'USDT0'], is_stablecoin = TRUE, vaults.tvl_usd is above the basket TVL floor, the vault has been live at least 30 days, and the underlying protocol has been live at least 180 days. Both USDT (native) and USDT0 (Tether OFT on Optimism, Arbitrum, Base) vaults are admitted and treated as one asset family. Vaults that drop below Core tier or fall under any floor are removed at the next rebalance.

Structured form

The rebalancer reads this exact shape.

{
  "asset_category": [],
  "review_status": ["reviewed"],
  "terminal_underlying_category": [],
  "terminal_underlying_min_backing_offchain_pct": null,
  "tier": ["Prime", "Core"]
}

Weighting Rule

Each constituent receives a raw weight proportional to its risk score above 5.0 (the Core tier floor), normalised so the basket sums to the full allocation. The pivot is set at the Core floor so every eligible vault contributes positive raw weight. Prime vaults naturally dominate because their scores sit 3 to 4 points above the pivot versus 0 to 3 points for Core names.

Formula

w_i ∝ max(0, risk_score_i − 5.0); normalize so Σ w_i = 1.0

Worked Example

Constituent	Risk Score	Raw Weight (score - pivot)	Normalised Weight
Constituent A	7.00	2.00	38.10%
Constituent B	6.50	1.50	28.57%
Constituent C	6.00	1.00	19.05%
Constituent D	5.50	0.50	9.52%
Constituent E	5.25	0.25	4.76%
Sum	-	5.25	100.00%

This table shows the raw normalisation step before cap redistribution. If a constituent exceeds the single-name cap or falls below the floor, the rebalancer iteratively trims or removes it and redistributes the excess across the remaining names in proportion to their current weights, repeating until all caps and the floor are simultaneously satisfied within 50 iterations.

Caps

Cap	Value	Meaning
Single-name	30%	No constituent may exceed this share of the basket.
Issuer	50%	Cross-chain deduplicated; aggregate exposure to one issuer is bounded.
Floor	2%	Any constituent below the floor is dropped before final normalisation.

Refresh Schedule

Rebalances run on the last business day of March, June, September, and December at 16:00 UTC. They also fire when any constituent crosses a tier boundary, when a hard-fail flag triggers, when an active-incident clamp applies, when a constituent's score moves up by at least 1.0, or when a constituent's score moves down by at least 0.3. The asymmetric thresholds reflect the institutional client posture because routine upward APY drift should not churn the basket, but any meaningful downward move on a current member must trigger requalification so deteriorating exposures are removed promptly. Rating-triggered rebalances are throttled to at most one every 30 days. Calendar rebalances always fire and are not throttled.

Structured form

The rebalancer reads this exact shape.

{
  "calendar_day": "last_business_day",
  "calendar_months": [3, 6, 9, 12],
  "calendar_time_utc": "16:00",
  "rating_move_throttle_days": 30,
  "rating_move_triggers": [
    "tier_change",
    "score_delta_ge_1_0",
    "score_delta_down_ge_0_3",
    "hard_fail_flag",
    "active_incident_clamp",
    "new_eligible_entrant",
    "methodology_version_change"
  ]
}

Halt Conditions

The rebalancer enforces the following halt-closed invariants. When any of these fails the rebalance aborts and the prior published version is preserved. Alerts page the on-call.

ID	Description
I1	Every constituent must have a non-null issuer_id and risk_score and review_status = "reviewed". Otherwise the constituent is rejected.
I2	The eligible set must contain at least min_constituents names. If it falls below, the rebalance aborts and the prior published version is preserved.
I3	Eligible-set turnover versus the prior version must not exceed 50%. A higher turnover triggers a "universe shock" abort with the prior version preserved.
I4	The indexer must have a successful run within the last 6 hours. Stale ratings abort the rebalance and the prior version is preserved.
I5	Cap-redistribution must converge within 50 iterations. Otherwise the rebalance aborts; equal-weight fallback only runs with an explicit operator flag.
I6	The published weights must sum to 1.0 within 1e-6. The database CHECK constraint refuses to commit a version row that violates this.
I7	Calendar and rating-move rebalances are mutually exclusive per basket via a Postgres advisory lock; a second concurrent rebalance exits cleanly.
I8	Every published version is content-hash signed; the current_version_id pointer is moved atomically only after constituents and signature are written.
I9	Every version is reproducible from frozen inputs stored in basket_version_inputs; CI replays the latest version and asserts byte-equality of canonical JSON.
I10	The methodology doc_url must resolve with HTTP 200 before publish. A missing or 404 doc aborts the rebalance.

Version

Current methodology version 1.0.2

Methodology document URL docs page

Change Log

1.0.2 Voice-compliant human prose reconciliation.

USDT/USDT0 DeFi Vaults

On this page