# Overview 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 currently operates as a private market maker integrated with 1inch and UniswapX, with additional aggregator and centralized exchange integrations planned. # Dual Delegation
YODL’s dual-delegation architecture cleanly separates execution liquidity from delegated $YODL (protocol-held collateral).\ Restaked vaults supply the capital Operators deploy in strategies, while delegated $YODL assigned to Operators determines their execution-credit capacity and serves as part of the protocol’s bounded deficit-restoration buffer. #### 1. Asset Delegation (Restaked Vaults) Restaked vaults contribute single-asset capital (e.g., ETH, WBTC, USDC) as execution liquidity, which Operators use to fill trades under protocol-governed constraints. Execution liquidity is mobilized in two modes: * Pre-Slashing Mode — Vaults are pre-slashed to make inventory instantly available for low-latency venues such as 1inch. * Instant Slashing Mode — Vaults are slashed and trades are settled atomically within the same transaction whenever an opportunity is executed. All vault capital remains non-custodial, revocable, and fully governed by protocol-level safeguards. #### 2. Delegated $YODL (Restoration Stake & Credit Sizing) Participants may delegate $YODL to an Operator. The delegated amount helps determine how much vault liquidity the Operator can access safely. A[ Stability Fee](/capital-access-and-protection/stability-fee), applied each epoch on the delegated amount, strengthens system solvency and provides continuous protection against unrealized or residual deficits. # Stability Fee The Stability Fee is a governance-defined cost applied each epoch to participants who delegate $YODL to Operators.\ It compensates for time-based exposure created by operator execution credit usage and helps maintain protocol solvency by providing continuous protection against unrealized deficits. Base Rate: Fixed by governance (e.g., 12% per annum). Application: Charged upfront on delegated $YODL at the start of each epoch. Scope: Applies only to participants who delegate $YODL, not Operators. **Formula:** $$ SFepoch=PcreditLine×Rbase×365Depoch $$ Where: * SFₑₚₒcₕ = Stability Fee charged for the epoch * P₍creditLine₎ = Total execution credit enabled * R₍base₎ = Governance-defined yearly Stability Fee rate * D₍epoch₎ = Epoch duration in days Example For a $10,000 execution credit line, 12% Stability Fee, and a 30-day epoch: $$ SFepoch=10,000×0.12×30/365=$98.63 $$ Result The Stability Fee is deducted once per epoch, preventing deficit carryover and ensuring Curator capital remains fully restored across execution cycles. # Risk Mitigation YODL’s architecture is designed to make capital safety autonomous — meaning curator vault assets remain protected at all times without any manual action.\ The protocol continuously monitors every vault–operator pair for solvency and automatically applies the right protection measure at the right stage. These measures operate in a predictable sequence: 1. [***Health Factor (HF)***](/capital-access-and-protection/risk-mitigation#health-factor-hf) — early-warning system that tracks vault solvency in real time. 2. [***Position Rollovers*** ](/capital-access-and-protection/risk-mitigation/position-rollovers)— voluntary operator-initiated stabilization when risk thresholds are approached. 3. [***Bounded Liquidations***](https://yodl.gitbook.io/yodl-operator-guide/risk-management-and-solvency/bounded-liquidation) — automatic, scope-limited restoration that brings the vault back to full balance. 4. [***Restoration Framework*** ](/capital-access-and-protection/risk-mitigation/restoration-framework)— the final layer that ensures every curator vault remains whole, even under systemic stress. Together, these layers form YODL’s Restoration Stack — a closed, verifiable system that detects imbalance, stabilizes exposure, and deterministically restores curator principal. # Health Factor (HF) The Health Factor (HF) is the protocol’s built-in safeguard that continuously measures the solvency of every Operator within each vault.\ It ensures that Curator vault capital remains protected at all times by determining when an Operator may self-stabilize through a [Position Rollover](/capital-access-and-protection/risk-mitigation/position-rollovers) and when the protocol must restore the vault through a [Bounded Liquidation](/capital-access-and-protection/risk-mitigation/bounded-liquidations).
$$HealthFactor(HF)=Σ(V i ​ ×(1−h i ​ ))/L$$ Where: * **Vᵢ** = USD value of each risk-buffer component (unutilized vault asset, delegated YODL, taker tokens held) * **hᵢ** = haircut applied to each component * **L** = curator principal currently utilized for execution Haircut Schedule | Asset Type | Typical Haircut | Rationale | | ----------------------------- | --------------- | --------------------------------- | | Stablecoins (USDT / USDC) | 0–1% | Low volatility / high liquidity | | ETH / WBTC / blue-chip assets | 5–10% | Moderate volatility | | Delegated YODL | 15–20% | Governance-controlled risk buffer | HF represents the relationship between the Operator’s total backing assets and the Curator capital they have deployed: * HF > 1.0 — The vault is fully solvent; the Operator’s backing assets comfortably cover all liabilities. * HF = 1.0 — The vault is at its minimum safety threshold; rollovers may be used by the Operator to rebalance exposure. * HF < 1.0 — The vault has entered the restoration zone; a bounded liquidation restores vault principal in full. Curators don’t need to monitor HF or take any action.\ The system tracks it on-chain in real time, ensuring that: * Curator principal remains intact, even if an Operator’s position weakens. * Restoration mechanisms are applied automatically within each affected vault. * Transparency is maintained — HF values can be viewed anytime through the vault dashboard. # Position Rollovers
Position Rollovers allow operators to maintain operational continuity without triggering bounded liquidation. They provide a controlled method to refinance temporary deficits by using unused credit lines or re-allocating backing assets — which can improve the Health Factor (HF), maintaining the stability of delegated YODL. ### Mechanism #### Deficit Detection The HF is viewable on the operator dashboard, and as it approaches 1.0, it indicates a potential deficit based on mark-to-market asset values and applied haircuts. The operator may elect to perform a rollover before liquidation triggers. #### Credit Re-allocation The operator rolls over exposure from one [Orchestrator](/technical-components/smart-contracts#orchestrator-per-execution-vault-per-operator) (per-vault) to another (e.g., WETH → USDT) by activating their unused credit capacity (unutilized balances) of the other asset. Rollovers can also be performed within the same asset across Orchestrators for repayments. #### Market Execution The rollover transaction is executed atomically through the Orchestrator using whitelisted AMMs. The Operator incurs standard slippage and taker fees. #### Accounting Update Managing exposure via rollovers may improve HF. #### Repayment Obligation All rollover-borrowed credit must be repaid before the epoch ends; otherwise, it is treated as outstanding exposure requiring restoration through delegated $YODL being slashed under the protocol’s restoration process, which also impacts operator reputation. # Bounded Liquidations
When HF ≤ 1.0, the system initiates a bounded liquidation — a controlled restoration event triggered when an Operator’s total backing assets (including delegated YODL, unutilized vault assets, and taker tokens) fall below the Health Factor threshold. Unlike conventional liquidations that forcibly unwind positions and risk contagion, bounded liquidations are deterministic and scope-limited, converting only the shortfall needed to fully restore the Curator’s principal while preserving protocol solvency. ### Bounded Liquidation Process #### 1. Detection Automated liquidation bots trigger when an Operator’s Health Factor ≤ 1.0, indicating that the combined value of taker tokens, unutilized vault assets, and delegated $YODL has dropped below the vault’s liability. #### 2. Conversion Operator-held taker tokens are swapped into the vault’s base asset via whitelisted AMMs to begin principal restoration. #### 3. Slashing After detection and conversion, delegated $YODL is slashed and swapped via whitelisted AMMs into the vault’s base asset to cover the remaining deficit. #### 4. Restoration Framework Activation If a residual shortfall persists after $YODL conversion, the Restoration Framework automatically tops up the remaining balance from the protocol-managed reserve to fully restore the Curator’s principal. ### Post-Liquidation Impact #### Delegator Impact Delegated $YODL is reduced by the USD value of the remaining deficit (including slippage, volatility, and DEX fees). #### Operator Impact Reputation score decreases; repeated events reduce delegation priority and lower the available execution credit ceiling. #### Curator Impact None - vault principal is fully restored. #### Protocol Impact Temporary sell pressure on $YODL due to $YODL-to-asset conversions performed during bounded restoration. # Restoration Framework
The Restoration Framework guarantees deterministic principal protection for Vault Curators by restoring their vault balance 1:1 to its pre-trade state — even in adverse market or operator failure scenarios.\ It operates through a tiered system that prioritizes restoration over penalty, ensuring vault solvency at all times. ### Restoration Reserve Protocol-managed pool that serves as the final restoration layer. Funded by: * Stability Fee applied each epoch on delegated YODL * 33% of YODL Total Supply pre-allocated at genesis * 10% of all operator slashing events automatically routed here This reserve ensures deterministic, full principal restoration even in multi-layer or systemic drawdowns. ### Optional Third-Party Protection Institutional curators can opt in for external protection through partners such as [Catalysis](https://catalysis.network/) or similar providers. These reserves can support specific market pairs or institutional vaults with programmable on-chain settlement. This layer extends protection but is not required for full restoration. Restoration Activation Restoration is triggered automatically during bounded liquidation when a vault’s Health Factor (HF ≤ 1.0) signals a shortfall. # Reputation Framework YODL uses a dual Reputation Framework to evaluate Operators and Vault Curators.\ Reputation is updated each epoch based on objective performance and participation metrics and directly influences capital routing and execution-credit allocation. * [**Operator Reputation**](/capital-access-and-protection/reputation-framework/operator-reputation) **(RM):** Measures execution quality, solvency discipline, and restoration behavior. RM affects an Operator’s execution-credit ceiling and delegation priority. * [**Curator Reputation**](/capital-access-and-protection/reputation-framework/vault-curator-reputation) **(RMC):** Measures consistency, pre-commitment behavior, and participation across epochs. Reputation is operational, fully on-chain, and ensures that capital flows toward the most reliable participants. # Operator Reputation #### **Overview** Every Operator begins with a Reputation Multiplier (RM) of **1.00** upon whitelisting. This value is stored on-chain and updated automatically after each epoch based on verifiable performance metrics.\ The RM acts as a dynamic trust coefficient, scaling the Operator’s **execution-credit ceiling.** Governance defines a global RM range of **0.50 ≤ RM ≤ 1.50**, ensuring no Operator can gain or lose influence excessively within a single epoch. #### **Epoch Update Logic** Positive behavior increases RM toward the upper bound; failures or restoration events decrease it proportionally. #### Positive Reputation Factors | **No Liquidation or Slashing Events** | Maintains solvency throughout epoch | +0.1 | | ------------------------------------- | ----------------------------------------------------- | ----- | | **Exceptional Execution Efficiency** | Generated surplus ≥ 5 bps on YODL Delegated USD Value | +0.01 | Maximum positive adjustment per epoch: +0.11. #### Negative Reputation Factors | **Bounded Liquidation Event** | Triggered when HF ≤ 1.0 | −0.05 | | --------------------------------- | -------------------------------------------------------- | ------------------------------ | | **Non-Repayment of Vault Assets** | Fails to restore by epoch end | −0.10 and temporary suspension | | Restoration Reserve Usage | Slashing sourced from the protocol’s restoration reserve | −0.20 | Maximum negative adjustment per epoch: −0.35. #### **Blacklisting & Recovery** * **Auto-Blacklist:** * `RM = 0.50` * **Re-Whitelisting:** * Requires governance approval and audit of prior epoch data (off-chain). * Upon reinstatement, RM resets to 0.90 (probationary). #### On-Chain Enforcement • Update Frequency: Each time a relevant event occurs (liquidation, repayment, surplus).\ • Data Sources: Aggregated Orchestrator data.\ • Transparency: All RM adjustments and reasons are emitted on-chain for verifiability. #### Governance Controls Governance may:\ • Define minimum and maximum RM bounds\ • Tune per-event reputation adjustments\ • Pause RM updates during system-wide incidents # Vault Curator Reputation Curator reputation reflects consistency, scale, and commitment of capital participation.\ It rewards predictable behavior (pre-commitment, steady capital allocation) and penalizes early withdrawals or inactive epochs. Every Curator begins with **RMC = 1.00** upon registration.\ This value evolves automatically after each epoch based on off-chain computation of on-chain actions recorded through the Approver, VaultRouter, and FeeManager contracts. Governance defines a global range of **0.50 ≤ RMC ≤ 1.50**, ensuring stability and avoiding volatility in capital-routing logic. #### Reputation Drivers | Parameter | Description | Measurement Basis | Weight / Impact | | ---------------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------ | | Pre-Commitment Ratio | Share of total capital the Curator locks in advance via the Pre-Commitment Vault. | (Pre-Committed Value ÷ Total Curator Deposits) | ↑ increases RMC up to +0.10 | | Allocation Depth | Amount of allocated capital across active Operators relative to vault balance. | (Allocated Value ÷ Vault Balance) | ↑ increases RMC up to +0.08 | | Allocation Persistence | Continuous capital participation across epochs without withdrawal interruptions. | Active Epochs ÷ Total Epochs | ↑ increases RMC up to +0.05 | | Early Unallocation (Penalty) | Removing allocated capital before epoch end or cool-off completion. | Count per epoch | ↓ decreases RMC −0.20 per event | | Zero-Participation Epochs | Epochs with no active capital allocation. | Epoch count | ↓ decreases RMC −0.05 per idle epoch | ### Governance Controls #### Governance may: * Adjust global RMC bounds and per-event weights. * Approve or replace the off-chain Reputation Engine. * Pause or override RMC updates during system-wide incidents. * Integrate cross-protocol metrics (e.g., Symbiotic vault metadata). # Types of Strategies YODL supports multiple execution strategy types, enabling Operators to participate in listed, verified strategies or run their own proprietary logic while remaining fully integrated with YODL’s infrastructure. *** #### **1. Listed Strategies** Listed Strategies are officially approved by the YODL DAO and appear in the Strategy Marketplace (coming soon).\ Operators can subscribe to these strategies and execute them through their Operator Binary without modifying core logic. **Subscription Model:** Listed strategies operate on a one-year subscription basis. **Strategy Publishers:** Strategy Publishers are independent developers or institutions that design, test, and propose strategies for DAO approval.\ \ Once listed, they earn subscription fees paid by Operators who opt into their strategy. {% hint style="info" %} To ensure plug-in uptime, they provide a performance bond in $YODL, which may be partially reduced if the strategy becomes unavailable or violates publishing requirements. {% endhint %} **Operator Relationship:** The relationship between a Strategy Publisher and an Operator is independent and self-managed. If an Operator identifies unfair conduct or a breach of good faith, they may propose to blacklist a Strategy Publisher. The DAO will evaluate the proposal and may reduce the Publisher’s standing or revoke listing privileges if the claim is validated. **Integration:** Listed strategies plug directly into the Operator Binary through API connections, sharing off-chain parameters such as price levels, token pairs, and liquidity amounts. Strategies do not need to be open source; Operators may independently verify their logic and performance. *** #### **2. Unlisted (Private) Strategies** Unlisted strategies are proprietary and developed solely by Operators.\ They are not subject to DAO approval, subscriptions, or external revenue sharing. Operators may build custom execution logic within their Operator Binary using languages such as Go or JavaScript and integrate the[ Settlement Relayer ](/technical-components/settlement-relayer)API endpoint to transmit price and liquidity data.\ All ownership, performance, and intellectual property rights remain with the Operator. {% hint style="info" %} Listed Strategies can be used by any whitelisted Operator through subscriptions.\ Unlisted Strategies remain exclusively owned and operated by the Operator who develops them. {% endhint %} # CoW Construction Strategy The Coincidence-of-Wants (CoW) construction strategy is YODL’s first listed strategy, allowing Operators to earn **fee-backed revenue** without taking any directional exposure. In this strategy, cycle pairs offset trades into a self-contained CoW loop. The strategy operates in two stages: **Pre-Trade:**\ The Operator quotes the same price for both buying and selling a token pair across connected order-flow venues, maintaining neutrality and avoiding speculative pricing. **Post-Trade:**\ The algorithm identifies the optimal path to close the CoW loop based on the evolving state of fills, dynamically adjusting pairs and amounts in future quotes to neutralize exposure. (For a detailed explanation, see the [CoW Research Paper](https://arxiv.org/pdf/2507.10149).) YODL hosts the [CoW construction logic](https://arxiv.org/pdf/2507.10149) and delivers proprietary identification and construction signals (pair, side, size, quote, expiry, batchId) to Operators. No models or code are provided. *** **Execution Flow** 1. **Pre-Slash (if required)** * Pre-slash vault inventory into the [Orchestrator](/technical-components/smart-contracts#orchestrator-per-execution-vault-per-operator) to make liquidity instantly available for low-latency venues such as 1inch. 2. **Quote Submission** * The Settlement Relayer receives the Operator’s quote and relays it to the connected order-flow venue. 3. **Accounting Transaction** * When a trade request is received, the [Operator Binary](/technical-components/operator-binary) sends a signed accounting transaction authorizing execution. 4. **Finalization Transaction** * After taker tokens arrive in the Operator’s Orchestrator, a finalization transaction segregates the fees earned on that trade. * Finalizations can be batched per taker token but must occur before repayment. 5. **Repayment Transaction** * Repay each Curator Vault to restore the vault’s balance and close the execution cycle. *** **Price Discovery** By default, quotes use oracle-based price discovery through YODL-approved oracles. Operators may select from the governance-maintained list. Operators may integrate custom or proprietary strategies alongside the CoW construction module. *** **Quick Reference Table** | Transaction | Trigger Event | Constraint | Purpose | | -------------------- | ------------------------- | ------------------- | --------------------------------- | | Accounting (txn-s) | Quote accepted by OFV | Immediate (≤ 500ms) | Authorize trade execution | | Finalization (txn-f) | Taker tokens received | Before repayment | Segregate operator / curator fees | | Repayment | Epoch end / vault closure | Before epoch end | Restore the vault’s balance | # Execution Lifecycle
When Curator vaults allocate capital and participants delegate $YODL, the Operator receives a USD-denominated execution-credit ceiling that defines how much liquidity can be mobilized. **Activation:** Execution-credit ceiling = (delegated YODL × credit multiplier × RM). **Utilization:** Strict on-chain checks prevent overspending or unauthorized access. **Repayment:** All utilized Curator capital must be restored before epoch end. **Liquidation:** If HF ≤ 1.0, a Bounded Liquidation restores the vault’s balance. **Renewal:** Restored capital immediately frees up execution credit, which is reusable within the same epoch. # Fee & Revenue Model
At the start of each epoch, every Operator defines **two fixed per-trade allocation percentages** — one assigned to **Curators** and one assigned to **$YODL Delegators**. * Both are expressed as a percentage of the notional trade value (e.g., 0.1% for Curators, 0.2% for $YODL Delegators). * Governance sets a **minimum threshold** for these allocations to ensure consistency for capital participants. * These fixed allocations remain constant throughout the epoch and apply to every verified fill. Whatever remains from the Operator’s quoted fee (after Curator and $YODL delegators) accrues to the **Operator** as **variable execution retention**, covering gas, infrastructure, and operation costs. {% hint style="info" %} Operators cannot set fee parameters below governance minima; quotes that do not meet thresholds are rejected by the Orchestrator. {% endhint %} Fee Parameter Range: 0.05% – 1.00% of notional fill value. #### **Surplus Share (%)** Each Operator also defines a **Surplus Share (%)**, representing the percentage of **Net Surplus** they retain from efficient executions. Participants who delegate $YODL may view each Operator’s surplus-share settings and fixed-allocation configuration. The Surplus Share applies **only** when an Operator generates positive Net Surplus.\ If a **liquidation** occurs during the epoch, any deficit adjustments applied to delegated YODL are reflected before applying the Operator’s surplus share. This model ensures: * A predictable fee structure for Curators and $YODL Delegators * Performance-driven upside for Operators (via conditional surplus) * Protocol solvency maintained through the Stability Fee, without diluting participant fees {% hint style="info" %} The protocol does not retain any share of execution fees; it is sustained independently via the Stability Fee applied to Delegators, separate from trading revenue. {% endhint %} #### Economic Summary | Participant | Operational Costs | Compensation Source | Risk | Compensation Profile | | ---------------- | ------------------------------------------------- | --------------------------------------------------------- | --------------------------------- | -------------------------- | | Vault Curator | Near-zero gas overhead | Fixed Curator Fee | None | Stable fee-share per trade | | $YODL Delegator | Near-zero gas overhead | Fixed Delegator Fee + surplus generated by their Operator | Bounded liquidation exposure | Variable fee-share | | Network Operator | Infrastructure + transaction gas cost | Maker Fee + conditional surplus | Slashing risk for non-performance | Execution profit | | YODL Protocol | Stability Fee processing + restoration management | Stability Fee | Protocol solvency | System-level balance | # Tech Stack Overview
The YODL architecture is organized into modular layers that together enable trustless strategy execution, deterministic settlement, and full Curator capital protection.\ Each layer - from strategy plug-ins at the top to Symbiotic vaults at the base - plays a defined role in connecting off-chain execution with verifiable on-chain settlement. #### **1. Strategy Plug-ins** This top layer defines how trading logic is generated and consumed by Operators. * **Listed Strategies** — DAO-approved strategies published in the Strategy Marketplace (e.g., CoW Construction Strategy).\ These strategies follow standardized policy formats and fee-parameter models. * **Unlisted Strategies** — Privately developed execution logic created by Operators.\ These integrate directly with the Operator Binary and remain fully proprietary. Listed and Unlisted strategies operate on equal footing within the execution framework. #### **2. Off-Chain Components** Execution flow is orchestrated through operator-managed systems: * **Operator Binary** — The local execution engine responsible for quoting, signing accounting instructions, maintaining exposure neutrality, and interacting with strategy plug-ins. * **Settlement Relayer** — A policy-enforcing relay layer that standardizes RFQs, applies risk and policy checks, and relays signed transactions to connected orderflow venues. Together, these components ensure operators execute trades within their permitted permissions and credit limits. #### **3. External Protocols** Integrations YODL interfaces with external ecosystems to enable accurate pricing, deterministic settlement, and restoration when needed: * **Price Oracles** — Supply verified pricing for quoting logic and Health Factor calculations. * **AMMs** — Enable conversions (e.g., taker tokens → vault asset) during finalization and restoration. * **Orderflow Venues** — Integrations such as 1inch and UniswapX, where Operators supply maker liquidity and receive fee-based compensation. * **Third-Party Coverage** — Opt-in protection provided by independent partners for institutions requiring additional safeguards. #### **4. On-Chain Contracts** (Control Layer) This layer enforces credit limits, verifies operator permissions, and performs deterministic settlement. * **Approver** — Validates operator eligibility, signature scope, metadata correctness, and enforces execution-credit ceilings. * **Orchestrator** — Per-operator/per-vault smart contract responsible for pre-slashing (if applicable), settlement intake, finalization, and repayment logic. * **Fee Manager & Rewards Distributor** — Aggregates settlement data and routes fee-shares to Curators, Delegators, and Operators according to protocol-set parameters.\ The contract does not issue rewards; it deterministically allocates fee-shares from verified fills. * **Operator Accountability Stake** — Tracks operator-specific stake and enforces slashing for non-performance, solvency failures, or restoration shortfalls. #### **5. Symbiotic Vaults** The foundation layer where all real capital and all Delegator credit-allocation is recorded: * **Execution Vaults (Curator-Owned)** — Single-asset vaults that supply the capital used for execution.\ Each vault is protected by deterministic restoration — all utilized capital must be restored within the epoch. * **YODL Stake Vault** — Tracks the YODL delegated to each Operator.\ This delegation determines the Operator’s execution-credit ceiling and provides bounded deficit if restoration is required.\ Delegated YODL never becomes execution capital; it determines scale and provides restoration. # Operator Binary
The Operator Binary serves as the execution engine linking Operators with YODL’s Settlement Relayer and on-chain contracts. It is responsible for quoting, accounting, and settlement operations, ensuring that all executions occur within verified parameters and remain fully traceable. All communication between the Operator Binary and the Settlement Relayer is authenticated and policy-bound, enabling secure, deterministic execution across orderflow venues. #### **Setup Overview** 1. **Install the Operator Binary** (provided after whitelisting). 2. **Configure environment variables** — RPC endpoints, private key path, API key, and monitored token pairs. 3. Connect to the Settlement Relayer API for real-time RFQ flow and settlement coordination. Configure the Operator Binary in the same region as the Settlement Relayer for low-latency performance. 4. Maintain continuous uptime and monitor logs, latency, and the Health Factor of active vaults. #### **Operator Binary Configuration Knobs** | Configuration Knob | Purpose | Notes / Requirements | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | | RPC & Node | Reads on-chain data from the Orchestrator to track vault balances and available vault liquidity (Curator capital). | Use reliable RPC endpoints (HTTPS/WebSocket). Latency impacts quoting performance. | | Strategy Plugin Endpoint | Connects to the active strategy plug-in to fetch pair, price, and minimum trade size data. | May point to the default CoW Construction Strategy or any approved custom strategy endpoint. | | Oracle Link (Mandatory for CoW Strategy) | Provides access to governance-whitelisted price oracles for quoting within the default strategy. | Required for operators opting into the default CoW strategy. | | Environment Variable: Private Key | Authenticates Operator actions and signs outbound requests to the Settlement Relayer. | Must be stored securely. Never share or hardcode this key. | # Settlement Relayer
The Settlement Relayer (SR) serves as YODL’s coordination layer between Operators and on-chain infrastructure.\ It standardizes RFQs, enforces protocol policy, and issues the witnessed Permit2 signature bundle (sigBlob) that each Operator’s Orchestrator verifies through `isValidSignature`. *** #### **What YODL Manages** * **RFQ Construction & Policy:** Builds quotes and enforces fee bands, taker whitelists, exposure limits, cooldowns, and rate caps. * **Witnessed Signing:** Generates the `Permit2 + RFQ` witness package used by orderflow venues and verified by the Operator’s Orchestrator. * **Sequencing & Capacity Control:** Queues or rejects RFQs when allocation or cooldown thresholds are hit, ensuring no reuse of allocated vault liquidity. * **Finalize & Repay Coordination:** Tracks fills, manages finalize windows, and pauses execution if vault solvency or policy checks fail. * **Aggregator Integration:** Hosts `/rfq` and `/order` endpoints — Operators interact via authenticated APIs, with no manual setup required. *** #### **What Operators Manage** * **Binary Connectivity:** Configure and maintain the Operator Binary’s connection to the Settlement Relayer’s authenticated API endpoint. * **Quote Transmission:** Sign and relay accounting transactions and quotes to the SR within the specified latency window (≤ 500 ms). * **Transaction Lifecycle:** Trigger accounting → finalization → repayment flows through the SR to ensure vaults are restored on schedule. * **System Uptime:** Maintain 99.5%+ runtime for the Operator Binary; downtime impacts Operator Reputation and may trigger Operator slashing. # Smart Contracts YODL’s on-chain architecture is modular and deterministic, ensuring transparent accounting for Operators and seamless integration with external vault systems such as Symbiotic.\ Each contract functions as a discrete, policy-enforced module within the execution, settlement, and restoration lifecycle. *** #### **Approver (with Registry & Policy)** Acts as the central gatekeeper of the protocol.\ It binds the Curator Vault → Orchestrator → Operator relationship, enforces eligibility and top-up thresholds, and maintains allowlists for routers, oracles, and whitelisted taker tokens.\ All actions — quote execution, vault access, and policy enforcement — pass through the Approver to ensure compliance and risk isolation. *** #### **Orchestrator (per Execution Vault per Operator)** Dedicated to each Vault–Operator pair, the Orchestrator manages execution and accounting.\ It holds pre-slashed vault inventory, validates RFQ + Permit2 witness signatures, records accounting transactions (`txn-s`), finalizes fees and converts taker proceeds into replenished vault inventory (`txn-f`), and enforces full epoch-end repayment.\ Because every Orchestrator is isolated, no cross-vault exposure exists — Operators never custody Curator capital, and all swaps occur atomically on-chain. *** #### **FeeManager (UUPS Upgradeable)** Aggregates settlement data and routes fee-shares to Curators, Operators, and Delegators.\ It enforces fee-policy parameters (minimum Curator %, maximum gross %, venue-specific basis points), tracks fixed fee parameters, and allows all participants to claim their allocated fee-shares after settlement. *** #### **Delegation (Slashing & Restoration Utility)** Handles slashing flows and deficit restoration during repayment or bounded liquidation.\ It converts slashed or held assets into the vault’s maker token via guarded, oracle-verified swaps, while maintaining cumulative deficit counters.\ This contract powers YODL’s bounded liquidation process and enforces full principal restoration for Curator vaults. *** #### **RewardsDistributor (Protocol Component)** Routes surplus fee-shares allocated to Delegators for a given Operator.\ Upon notification from the FeeManager, it credits surplus allocations by operator and token, operating outside the fee-accounting path to keep the routing logic modular and auditable. *** #### **Execution Vault (External – Symbiotic)** Represents the Curator’s single-asset vault allocated to an Operator.\ The vault’s base asset is the maker token that must be fully restored by the Operator each epoch.\ All interactions remain non-custodial and verifiable through YODL’s on-chain contracts, preserving solvency and neutrality at all times. ### YODL.sol — Token Contract Implements the YODL ERC-20 token with a fixed supply cap, governance voting, and entity-based mint limits.\ Supports pausing, burning, and rescue of non-core tokens. ### Configuration Knobs | Parameter | Description | Changes Applicable | Contract | Notes | | ----------------- | ------------------------------------------------------------------ | --------------------- | ------------------------------ | ------------------------------------------------------------- | | Fee Splits | Operator defines fixed fee parameters for Curators and Delegators. | Next delegation epoch | FeeManager, RewardsDistributor | Must stay within DAO bounds; aggregator fee is independent. | | Surplus Share | Operator sets surplus percentage allocated to Delegators. | Next delegation epoch | RewardsDistributor | Applies only if surplus is positive after deficit adjustment. | | Accounting Inputs | Include quoted gross fee at each txn-s; must pass policy bounds. | Per transaction | Orchestrator, FeeManager | Enforced fully on-chain. | # FAQs
Q1. Can Operators withdraw execution capital? No. All execution occurs within whitelisted smart contracts, ensuring on-chain accounting, and deterministic restoration of vault balances.
Q2. How do I earn yield as a Vault Curator? Curators earn **real, fee-backed yield** from verified trades executed using their delegated vault liquidity. * **Fee Accrual:** Each trade credits a **fixed Curator Fee** (defined per epoch) to the FeeManager contract in the taker token — typically ETH, WBTC, or stablecoins. * **Claiming:** These accrued fees are not automatically distributed; Curators can **claim them anytime on-chain** through the FeeManager interface.
Q3. How is curator principal protected? YODL enforces **deterministic principal protection** through a multi-layer restoration stack: 1. **YODL Staker Collateral**. 2. **Restoration Reserve** — the final backstop funded by the Funding Rate and protocol allocations.\ This structure ensures that vault balances are always restored 1:1 to their pre-trade state, even during adverse events.
Q4. Can Curators recall their delegated funds anytime? Yes — Curators have **recall rights** over their vault capital at all times.
Q5. Can Operators re-enter after blacklist? Yes — requires DAO approval post evaluation.
# Glossary
Credit Line USD-denominated execution limit, determined by delegated YODL and Operator reputation.
Curator Vault Single-asset vault on Symbiotic delegating capital to Operators.
Delegator Retail participant staking YODL to support Operator execution limits through protocol-managed collateralization.
Stability Fees Periodic stability fee applied to delegated YODL, set by governance each epoch.
Health Factor Collateral / Liabilities ratio governing operational continuity and liquidation.
Settlement Relayer Off-chain component that relays operator's quotes to orderflow venues.
Operator Institution executing approved strategies via delegated capital.
Orchestrator Core contract validating signatures and executing fills atomically.
Position Rollover Refinancing a temporary deficit using available credit.
Restoration Reserve Protocol-level fund covering residual shortfalls.