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 — 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 are both 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 60% of the 10 available slots.

Summary

Constituent Type

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

Minimum constituents: 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 ≥ $5M, the vault has been live ≥ 30 days, and the underlying protocol has been live ≥ 180 days. Both USDT (native) and USDT0 (Tether OFT on Optimism, Arbitrum, Base) vaults are admitted — they are 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 100%. The pivot is set at the Core floor so every eligible vault — Prime or Core — contributes positive raw weight; Prime vaults naturally dominate because their scores sit 3–4 points above the pivot versus 0–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	9.00	4.00	26.23%
Constituent B	8.50	3.50	22.95%
Constituent C	8.00	3.00	19.67%
Constituent D	7.50	2.50	16.39%
Constituent E	7.25	2.25	14.75%
Sum	—	15.25	100.00%

In this illustrative case every normalised weight is below the 30% single-name cap and above the 2% floor, so no cap-redistribution is needed. When a constituent exceeds a cap, the rebalancer iteratively trims it to the cap 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 — see invariant I5).

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 a calendar schedule (the last business day of March, June, September, and December at 16:00 UTC) and additionally 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 ≥ 1.0, or when a constituent's score moves DOWN by ≥ 0.3. The asymmetric thresholds reflect the institutional client posture: 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.1

Methodology document URL: https://docs.philidor.io/docs/methodology/baskets/usdt-prime-core-vaults

Change Log

1.0.1 — Initial published methodology.

USDT/USDT0 DeFi Vaults

On this page