Peer-benchmarked IR curves + loop elimination math
Hi all — first time posting here. Following up on esports4053's thread, I took a data-driven pass at Radiant's current IR curves and the economics of loop farming under the present incentive structure. Sharing methodology and numbers for community review. All data is from public sources (DefiLlama + Arbitrum RPC, snapshot 2026-04-21) and the analysis is reproducible.
**Competitive rate gap**
| Asset | Radiant borrow | Peer median | Gap |
|---|---|---|---|
| USDC | 11.18% | 3.28% | **+790 bps** |
| WETH | 8.51% | 1.58% | **+693 bps** |
| ARB | 10.51% | 5.45% | +506 bps |
| WBTC | 1.80% | 1.76% | +3 bps |
At +500 to +800 bps above market, rational borrowers self-select into peers (Aave V3, Compound V3, Morpho, Silo). The 68–75% utilization visible on USDC and WETH therefore cannot be demand-driven — it has to be reflexive supply.
jEQUg5W.png (2386×768)
**Loop economics make the incentive structure concrete**
With LTV = 0.8, a 5-round compounded loop, current USDC rates, and an approximate ε_s (supply-side emission APR) derived from on-chain `rewardsPerSecond` × RDNT TWAP × a 50% allocation assumption:
- dLP-eligible wallets: **loop APR ≈ +11.5%** (profitable)
- non-eligible wallets: **loop APR ≈ −15.5%** (unprofitable)
This matches the thread’s diagnosis: the borrow side is sustained by a closed set of locked-dLP holders recycling emissions, not by organic demand.
GTgE1Dn.png (1934×771)
**Minimum condition to eliminate loops**
Setting ε_b = 0 (as proposed), the loop becomes unprofitable when:
`r_s + ε_s < L · r_b`
For peer-matched USDC (r_b ≈ 3.3%, L = 0.8), this gives:
`ε_s < ~1.0% APR`
So the ε_b = 0 change alone is necessary but not sufficient — the supply-side emission ceiling also matters, and it comes out to roughly 1% APR on USDC for loops to be structurally unprofitable. Similar derivations per asset are in the full write-up.
**Recommended curve parameters**
Fit via weighted least-squares to the per-U median of Aave V3 and Compound V3 on Arbitrum, using their actual on-chain curve parameters:
| Asset |
U* |
r0 |
s1 |
s2 |
Rate at kink |
| USDC / USDT |
0.90 |
0.75% |
3.25% |
23% |
4.00% |
| WETH |
0.90 |
1.02% |
0.50% |
10% |
1.52% |
| ARB |
0.45 |
0.00% |
7.00% |
300% |
7.00% |
| WBTC |
0.80 |
0.50% |
4.00% |
300% |
4.50% |
Effect at current live utilization:
- USDC: 11.18% → 3.44% borrow rate (**−774 bps**)
- WETH: 8.51% → 1.40% (**−711 bps**)
- ARB: 10.51% → 5.45% (**−506 bps**)
- WBTC: 1.80% → 1.13% (already roughly competitive)
xFjMjL9.png (1332×804)
W9h7uyr.png (1332×804)
**Honest limitations**
- Radiant’s own on-chain curve parameters could not be read in this pass — the pool proxy uses a non-standard implementation slot (EIP-1967 and older patterns all returned zero). Comparison is against peer curves only.
- Per-asset allocation point (supply vs borrow split) was approximated at 50/50 rather than read from `ChefIncentivesController.poolInfo`. Worth tightening before any governance vote.
- Demand elasticity for post-change utilization shift has not been fit (Radiant’s post-hack history has too few clean rate-change events). Any forward projections should be treated as order-of-magnitude.
- Historical 90-day utilization timeseries per asset was not pulled in this pass.
None of these change the direction of the recommendation, but they cap the confidence on exact magnitudes.
**What this analysis is and isn’t**
- Independent work, no prior engagement with Radiant or any named peer protocol
- Offered for community review as input to the ongoing IR curve review
- Full section-by-section write-up (§1–§8), CSVs of all inputs, and the Python scripts that produced everything are available — happy to share the repo link in a follow-up or DM if useful
- Happy to iterate on any assumption the team would set differently (allocation split, ε_s cap target, peer-set choice, etc.)
Questions welcome.
