Platform & Strategy (40%)

This vector measures the probability that protocol code or strategy design causes loss.

Formula

base_score     = (lindy_score + audit_score + strategy_score) / 3
platform_score = base_score * worst_dependency_safety_factor * count_discount

Importantly, the dependency adjustment is worst-of, not multiplicative across every dependency. A platform's score is bounded by the single weakest dependency it relies on, with a modest additional discount for fan-out.

1) Lindy Score

Continuous maturity curve from deployment age:

lindy_score = 10 * (1 - e^(-days_live / 365))

Longer proven runtime raises the score; very new deployments score lower.

2) Audit Score

Audit depth and diversity improve the score; no audit is heavily penalized.

• no audit: severe constraint
• standard audit coverage: incremental uplift
• broader independent review: stronger confidence

3) Strategy Score

Strategy complexity increases operational and technical risk.

Examples:

• simple lending / isolated lending: high strategy score
• multi-market routing / auto-compound: moderate
• yield aggregation / leveraged / derivatives: lower

4) Dependency Factors (Worst-Of, Not Multiplicative)

The platform score is bounded by its weakest dependency. The worst safety factor among all dependencies is applied — a single value, not a product across the full dependency list. A small count discount then accounts for fan-out: more dependencies means more surface area even when each individual dependency is strong.

Safety factors by dependency tier:

• Prime dependency (score 8.0+): 0.95× (5% haircut)
• Core dependency (score 5.0-7.9): 0.80× (20% haircut)
• Edge dependency (score below 5.0): 0.50× (50% haircut)

Count discount (applied on top of the worst-of safety factor):

count_discount = max(0.85, 1 - 0.03 * (n - 1))

where n is the number of dependencies. A platform with a single dependency has no count discount; additional dependencies each subtract 3 percentage points, floored at 0.85.

Worked example. A platform with three dependencies — one Core (0.80), two Prime (0.95 each) — takes the worst factor 0.80, not 0.80 × 0.95 × 0.95. The count discount is max(0.85, 1 − 0.03 × 2) = 0.94. Final dependency multiplier: 0.80 × 0.94 = 0.752.

This is deliberately more forgiving than a naive product-across-all-dependencies rule, which would double-count dependency risk when multiple strong dependencies are involved. The worst-of rule captures the "chain is only as strong as its weakest link" intuition without compounding.

5) Incident Caps

Protocol incidents impose caps that relax across discrete time windows. Caps are severity- and resolution-aware:

Minor incidents do not impose a cap on the platform score. They may still be recorded and surfaced in explainability metadata, but they do not penalize. The rationale is that minor incidents — contained bugs, brief frontend outages, resolved edge-case issues — are expected in the lifecycle of any live protocol and are not predictive of future depositor loss.

Major incidents — loss of user funds, exploits, material governance incidents, or equivalent — do impose caps that relax as the incident ages and as the protocol demonstrates resolution.

Beyond the time window shown, the incident no longer caps the platform score; it remains available in explainability metadata.