How OnFinality helps Yodl Scales Principal-Protected Trading Infrastructure

Yodl  is an execution coordination layer that routes idle restaking collateral into market‑making strategies, while keeping the vaults that supply execution capital principal protected.

To run high-frequency execution, on-chain verification, and deterministic restoration logic, Yodl required blockchain infrastructure that is fast, reliable, and observable at scale.

Yodl chose OnFinality as its core API provider for Ethereum execution and analytics.

Table of content

1. What is Yodl and how does it work?
2. What is needed for Yodl to work at scale?
3. Why OnFinality: Infrastructure Built for Execution-Critical Protocols
4. About OnFinality

What is Yodl and how does it work?

Yodl is a meta-strategy layer that transforms restaked single-asset vaults into coordinated trading and market-making strategies executed by whitelisted Operators.

Vault capital always remains fully principal-protected, Operators access it as execution credit, which is scaled by Yodl stake delegated by retail participants.

Every executed trade produces verifiable on-chain fees, and Yodl’s multi-tier restoration framework guarantees deterministic restoration of principal, ensuring solvency, transparency, and uninterrupted yield generation.

Yodl Architecture can be divided into 6 parts

1. Participants and Roles
   1. Vault Curators supply single‑asset capital (e.g., ETH, WBTC, USDC) into restaked vaults.
   2. $Yodl Delegators stake or delegate $Yodl to Operators, which determines how much execution credit an operator can access.
   3. Operators execute strategies and trades under strict protocol constraints.
   4. Yodl Protocol enforces solvency rules, fee rules, and restoration mechanisms.
2. Dual‑Delegation Model (Collaretal + Credit): Yodl separates execution liquidity from delegated protocol collateral:
   1. Asset delegation: Vaults provide execution liquidity in two modes:
      1. Pre‑Slashing Mode for low‑latency venues (inventory is pre‑slashed for instant fills).
      2. Instant Slashing Mode for atomic execution and settlement in a single transaction.
   2. $Yodl delegation: Delegated $Yodl determines an operator’s execution‑credit ceiling and provides a restoration buffer.
3. Execution Lifecycle (How Trades Happen):
   1. Activation: Execution credit is set by delegated $Yodl × credit multiplier × RM (Operator Reputation Multiplier).
   2. Utilization: On‑chain checks enforce credit limits and authorized access.
   3. Repayment: Operators must restore all used curator capital by the end of the epoch.
   4. Liquidation: If Health Factor (HF) drops to ≤ 1.0, bounded liquidation restores the vault.
   5. Renewal: Once restored, execution credit is freed and reusable within the same epoch.
4. Fee and Revenue Model: At the start of each epoch, operators set fixed per‑trade allocations:
   1. Curator fee (fixed % of notional per fill)
   2. Delegator fee (fixed % of notional per fill) Governance enforces minimum fee thresholds. Any remaining quoted fee becomes operator retention to cover execution costs.

Operators also define a Surplus Share (%) that applies only when executions generate positive net surplus. The Surplus is shared between the operator who generated it and the $Yodl delegator who backed the operator. The protocol itself does not share any surplus or execution fee generated.

1. Risk Mitigation and Principal Protection: Yodl’s protection stack is designed for deterministic principal restoration:
   1. Health Factor (HF) monitors vault solvency.
   2. Position Rollovers allow operators to stabilize exposure when risk rises.
   3. Bounded Liquidations restore vault balance in a controlled way.
   4. Restoration Framework guarantees vault balance is restored 1:1 to pre‑trade state.
      The Restoration Reserve is funded by:
      1. The Stability Fee on delegated $Yodl each epoch
      2. A genesis allocation to the reserve
      3. A portion of operator slashing events

Optional third‑party coverage (e.g., Catalysis) can be added for institutional or specialized vaults.

1. Integrations and Execution Venues: Yodl integrates with multiple orderflow venues such as 1inch and UniswapX, with additional integrations in progress.

You can read more about them in their docs.

What is needed for Yodl to work at scale?

Yodl’s application have following requirements to work:

• High-frequency Ethereum reads during execution windowsFrequent Ethereum state reads are required during execution windows. Operators read vault state, health factors, and restoration thresholds before and after each trade to ensure deterministic restoration.
• Atomic execution with aggregatorsYodl supports execution across venues including 1inch and UniswapX, requiring accurate execution timing and transaction simulation to ensure correct routing and execution credit accounting.
• Deterministic restoration guaranteesThe restoration framework requires accurate on-chain state verification to ensure principal-protected execution.
• Continuous on-chain fee verificationEvery executed trade produces verifiable on-chain fees that must be accounted for across vaults, operators, and delegators. This requires reliable, low-error access to Ethereum execution and historical state.
• Zero tolerance for RPC instabilityYodl’s execution relies on consistent RPC availability to support continuous operation across execution windows.

Yodl needed infrastructure that behaves deterministically under sustained execution load, not just infrastructure that works “most of the time.”

Why Onfinality: Infrastructure Built for Execution-Critical Protocolse

Yodl selected OnFinality because its architecture aligns with execution-heavy, operator-driven protocols, not simple read-only dApps.

OnFinality provides Yodl with:

Dedicated Ethereum RPC for Execution-Critical Workloads

Yodl runs all execution-path Ethereum calls through OnFinality, ensuring:

• Consistent low-latency eth_call performance during live trading
• No shared public RPC congestion during high-volume execution periods
• Predictable behavior required for restoration and solvency checks

Yodl relies on OnFinality as its primary Ethereum RPC provider for live execution, on-chain verification, and restoration checks. The following metrics reflect actual production usage from Yodl’s OnFinality dashboard.

Key Infrastructure Metrics (24-hour window):

• 125,311+ Ethereum RPC responses served via OnFinality
• 131,007 execution-heavy eth_call requests, driven by continuous strategy execution
• 1.57 ms median (P50) response time, ensuring fast on-chain state reads
• 2.87 ms 95th percentile latency, indicating low tail-latency variance under load
• 0.00% error rate, critical for deterministic restoration and principal protection
• 5,000–6,000 requests per hour during sustained execution periods
• Primary traffic from the United States, aligned with operator and aggregator infrastructure

These metrics demonstrate that OnFinality supports Yodl’s execution-critical workload with stable low latency, zero observed errors, and consistent throughput, even during continuous trading and market-making activity.

As Yodl expands:

• More Operators
• Higher execution frequency
• Additional aggregator and CEX integrations

OnFinality provides infrastructure that scales without introducing new operational complexity or forcing protocol level compromises.

About OnFinality

OnFinality is a blockchain infrastructure platform that serves hundreds of billions of API requests monthly across more than 130 networks, including Avalanche, BNB Chain, Cosmos, Polkadot, Ethereum, and Polygon. It provides scalable APIs, RPC endpoints, node hosting, and indexing tools to help developers launch and grow blockchain networks efficiently. OnFinality’s mission is to make Web3 infrastructure effortless so developers can focus on building the future of decentralised applications.

App | Website | Twitter | Telegram | LinkedIn | YouTube