rio: extract from 2026-02-21-rakka-sol-omnipair-rate-controller.md

- Source: inbox/archive/2026-02-21-rakka-sol-omnipair-rate-controller.md
- Domain: internet-finance
- Extracted by: headless extraction cron (worker 6)

Pentagon-Agent: Rio <HEADLESS>

domains/internet-finance/omnipair-uses-adaptive-target-utilization-range-not-fixed-kink-curve-for-interest-rate-control.md

@@ -0,0 +1,35 @@
+---
+type: claim
+domain: internet-finance
+description: "Omnipair's rate controller uses configurable target utilization ranges that trigger rate increases at the upper bound rather than fixed kink curves, and upgraded from 50%-85% to 30%-50% targeting due to shallow liquidity constraints"
+confidence: experimental
+source: "@rakka_sol (Omnipair founder), Twitter 2026-02-21"
+created: 2026-03-11
+---
+
+# Omnipair uses adaptive target utilization range not fixed kink curve for interest rate control
+
+Omnipair's interest rate controller differs mechanistically from standard lending protocols like Aave by using configurable target utilization ranges rather than fixed utilization-interest curves (kink models). The protocol originally targeted 50%-85% utilization but downgraded to 30%-50% after observing that shallow liquidity combined with dynamic LTV made it difficult to exceed ~55% utilization in practice.
+
+This design allows the protocol to increase borrow rates as soon as utilization hits the upper bound of the target range (50% in the new configuration), rather than waiting for a predetermined kink point. The founder explicitly frames this as enabling "no more fragmentation between lending and spot" — positioning Omnipair as unified capital infrastructure.
+
+## Evidence
+
+Rakka (Omnipair founder) stated:
+> "We don't use a fixed utilization-interest curve, but rather a target utilization range. The current markets use a 50%-85% range, and given shallow liquidity plus dynamic LTV, it's hard to go beyond ~55% utilization. We've upgraded the default config to a 30%-50% target range. This increases borrow rates as soon as utilization hits 50%."
+
+The upgrade was triggered by operational constraints: shallow liquidity and dynamic LTV preventing utilization from exceeding ~55%, indicating the protocol is responding to real market friction rather than theoretical optimization.
+
+## Limitations
+
+This is a single-source claim from the protocol founder. The mechanism's effectiveness compared to fixed-curve designs requires independent validation through:
+- Actual utilization rates achieved post-upgrade (post-2026-02-21)
+- Capital efficiency metrics across different market conditions
+- Comparison of liquidation risk profiles vs. Aave-style kink curves
+- Whether the 30%-50% range actually constrains utilization as intended or if market behavior diverges
+
+---
+
+Relevant Notes:
+- [[stablecoin-flow-velocity-is-a-better-predictor-of-defi-protocol-health-than-static-tvl-because-flows-measure-capital-utilization-while-tvl-only-measures-capital-parked.md]]
+- [[internet-finance/_map]]

entities/internet-finance/omnipair.md

@@ -52,7 +52,7 @@ Combined AMM + lending protocol on Solana — swapping and borrowing in the same
 - **~2026-03-15 (est)** — Leverage/looping feature expected (1-3 weeks from late Feb conversation). Implemented and audited in contracts, needs auxiliary peripheral program.
 - **Pending** — LP experience improvements, combined APY display (swap + interest), off-chain watchers for bad debt monitoring
 
-- **2026-02-21** — Upgraded interest rate controller from 50%-85% to 30%-50% target utilization range; founder @rakka_sol stated rates now increase as soon as utilization hits 50%, addressing shallow liquidity constraints that capped utilization at ~55%
+- **2026-02-21** — Upgraded interest rate controller from 50%-85% target utilization range to 30%-50% range after observing shallow liquidity and dynamic LTV constraints prevented utilization from exceeding ~55%. Founder positioned this as enabling "no more fragmentation between lending and spot."
 ## Competitive Position
 - **"Only game in town"** for leverage on MetaDAO ecosystem tokens currently
 - Rakka argues mathematically: same AMM + aggregator integration + borrow rate surplus = must yield more than Raydium for equivalent pools

entities/internet-finance/rakka.md

@@ -41,4 +41,4 @@ Topics:
 
 ## Timeline
 
-- **2026-02-21** — Published thread explaining Omnipair's adaptive utilization range mechanism and positioning protocol as unified capital venue to eliminate lending-spot fragmentation
+- **2026-02-21** — Published detailed explanation of Omnipair's adaptive target utilization range mechanism, distinguishing it from fixed-curve designs like Aave. Announced upgrade to 30%-50% target range based on operational data showing ~55% utilization ceiling.

inbox/archive/2026-02-21-rakka-sol-omnipair-rate-controller.md

@@ -6,12 +6,13 @@ date: 2026-02-21
 archived_by: rio
 tags: [omnipair, rate-controller, interest-rates, capital-fragmentation]
 domain: internet-finance
-status: enrichment
+status: processed
 claims_extracted: []
 processed_by: rio
 processed_date: 2026-03-11
+claims_extracted: ["omnipair-uses-adaptive-target-utilization-range-not-fixed-kink-curve-for-interest-rate-control.md"]
 extraction_model: "anthropic/claude-sonnet-4.5"
-extraction_notes: "Extracted two claims: (1) mechanism-specific claim about adaptive utilization range vs fixed kink curve, rated experimental due to single-source founder statement; (2) strategic positioning claim about capital consolidation, rated speculative due to unverified fee data and early-stage evidence. Updated entity timelines for Omnipair and Rakka. No enrichments—these are novel mechanism insights not covered by existing claims."
+extraction_notes: "Single claim extracted on Omnipair's distinctive rate controller mechanism. This is mechanistically novel compared to standard kink-curve designs but requires independent validation. Entity updates for Omnipair and Rakka capture the upgrade event and positioning. Fee comparison data preserved as fact (single source, unverified). No enrichments to existing claims — this is a new protocol-specific mechanism insight."
 ---
 
 # @rakka_sol on Omnipair interest rate controller upgrade
@@ -35,8 +36,7 @@ From @Jvke201 discussing Omnipair's fee structure -- "$1000 USDC position costs
 
 
 ## Key Facts
-- Omnipair's initial rate controller used 50%-85% target utilization range
+- Omnipair fee comparison: $1.67 over 60 days for $1000 USDC position vs $600 on competitors (per @Jvke201)
+- Original Omnipair rate controller used 50%-85% target utilization range
 - Upgraded configuration uses 30%-50% target utilization range
 - Observed utilization ceiling of ~55% due to shallow liquidity and dynamic LTV
-- Fee comparison claim: $1000 USDC position costs ~$1.67 over 60 days vs $600 on competitors (unverified)
-- Tweet engagement: 7 replies, 8 retweets, 55 likes, 9,312 views