Summary
This RFC proposes upgrading the Yield Repurchase Facility (YRF) from a single-asset weekly buyback facility to a multi-asset facility (YRF v2).
Today, YRF can only track and act on yield from one reserve asset (USDS/sUSDS). It burns 100% of that yield, relies on a hardcoded $11.33 backing value, and cannot update its bond-market contracts without a full redeployment. YRF v2 removes these limitations: it draws yield from a governance-approved whitelist of ERC4626 reserve vaults, lets governance split each asset's yield between buybacks and liquid backing, reads the backing value live from an oracle rather than a constant, and standardizes the facility's lifecycle and administration.
This proposal implements the "YRF redeployment" already approved in principle under OIP-194 (multi-asset reserve support and mutable backing for buybacks) and specifies what has now been built.
Motivation
Design limitations of the current facility
- Single-asset lock-in. YRF only tracks yield from USDS/sUSDS. Reserves held in other assets (e.g. sUSDe) contribute nothing to buybacks unless they are first manually swapped into USDS.
- No yield split. The facility burns 100% of the tracked treasury yield via buybacks. There is no option to route part of the yield toward growing liquid backing instead.
- Hardcoded backing. Liquid backing is fixed at $11.33 in the contract. When YRF buys OHM off the market and burns it, it withdraws the backing value of the burned OHM to fund further buybacks but that withdrawal is sized off a stale constant rather than the protocol's actual backing.
- Immutable bond contracts. The Bond Protocol teller and auctioneer addresses are immutable, so updating them requires redeploying the whole facility.
- Non-standard lifecycle. The facility uses a bespoke
isShutdown flag instead of the newer protocol-standard enable/disable pattern, which makes its operational state harder to reason about and integrate with.
Specification
YRF v2 keeps the familiar YRF cadence — a weekly budget spent down through daily Bond Protocol SDA markets that buy OHM and burn it.
Multi-asset reserve whitelist
YRF v2 maintains a governance-managed whitelist of ERC4626 reserve vaults instead of one fixed asset. Each asset's yield is tracked independently, and each asset gets its own bond market denominated in its underlying reserve token.
For assets whose shares cannot be synchronously redeemed (e.g. sUSDe), the facility can sell the vault shares directly on the bond market instead of redeeming to the underlying first.
Role-gated functions add, remove, enable, and disable individual assets without touching the rest of the whitelist. Onboarding is constrained: one vault per reserve token, vault share decimals equal to the reserve decimals, and no more than 18 reserve decimals.
Yield split between buybacks and backing
Each asset carries a configurable buyback share: the portion of its projected yield routed to OHM buybacks. The remainder is retained by the protocol as backing. This replaces the current all-or-nothing 100% burn and lets governance tune how aggressively each asset's yield is used for supply reduction versus backing growth.
Configurable backing via an oracle
The hardcoded $11.33 constant is removed. The facility reads liquid backing live from a BackingOracle policy, and designates one whitelisted vault as the backing vault from which recovered backing is drawn and recycled into the buyback budget. The backing vault cannot be a sell-shares asset, and cannot be disabled or removed while designated.
The backing value itself is governed separately in that policy: each update is bounded to ±10% of the current value and passes through a timelock (queued by the backing_admin role, executable by anyone once the delay elapses, cancellable by Emergency), with a direct admin path retained. As a safety guard, if the OHM oracle price is unavailable or below backing, market creation is skipped for that cycle; the burn of already-purchased OHM still proceeds.
Bond-market price floor and initial discount
Every bond market is now created with a non-zero minimum price anchored to the OHM oracle price, so SDA price decay can no longer hand out an unbounded discount on protocol reserves. A configurable initial discount sets where each market's price starts relative to the oracle price, giving governance control over buyback aggressiveness while the floor protects the downside.
Clearinghouse receivables offset
A role-gated per-Clearinghouse offset can be applied to reduce the receivables value used when projecting yield, neutralizing phantom or defaulted receivables (such as those from the reported Cooler v1 liquidation vector) so they cannot inflate the YRF budget. Governance can additionally include or exclude specific Clearinghouses from the backing yield projection.
A companion function lets governance lower an already-stored yield projection before it is injected into the budget. It can only move the value down, and it reverts if a weekly reset replaced the projection after the correction was prepared.
Budget contributions
Anyone can add funds to a whitelisted asset's weekly buyback budget, in either the reserve token or the vault shares. A contribution is an irreversible donation: the funds join the facility's tracked holdings and are spent down over the remaining daily markets of the running week. This gives the DAO and third parties a way to supplement buybacks without a redeployment or a governance action.
Soft-failing operations
Each vault's weekly reset, daily cycle, share redemption, market creation, and fund return is isolated. A failure in one asset is recorded as an event and skipped, leaving the remaining assets and the heartbeat unaffected, and the skipped work is retried on the following cycle.
Mutable bond contracts
The teller and auctioneer addresses are now updatable through role-gated setters, so Bond Protocol contract changes no longer require redeploying the facility.
Standardized lifecycle (IEnablerV2)
The bespoke isShutdown flag is replaced with the protocol-standard PolicyEnabler / IEnablerV2 pattern (while preserving the legacy IEnabler surface), and the facility supports ERC-165 interface detection.
Disabling only halts operation; the funds and the week's accounting stay in place. Two paths follow from there:
reEnable resumes the interrupted week where it stopped, and is available to the operational role only within a grace window after the disable. Outside that window, enable performs a full restart. returnFundsToTreasury (emergency and admin, while disabled) burns tracked purchased OHM and returns all remaining vault, reserve, and OHM balances to the treasury across the full whitelist automatically.
At activation, a one-shot seeding function carries the outgoing facility's epoch position and unspent weekly budget into v2, preserving the running cycle instead of restarting its schedule.
Roles & Governance
YRF v2 separates administration, day-to-day operations, and emergency control, and places the most sensitive operational changes behind a dedicated timelock.
| Role | Expected Holder | Can | Cannot |
|---|
| admin | OCG timelock | Add new assets; remove disabled non-backing assets; select the backing oracle and backing vault; update bond contracts; seed migration state; set Clearinghouse offsets and inclusions; enable, disable, or unwind the facility; configure the YRF and backing-oracle timelocks; and call operational setters directly. | Bypass the asset-registration safety checks. |
| yrf_admin | DAO multisig | Queue the seven YRF operational changes; resume the facility or its timelock with reEnable during their grace windows; and sweep balances above tracked accounting to the treasury. | Add or remove assets, make structural changes, change backing, call operational setters directly, disable the whole facility, or return tracked funds to the treasury. |
| backing_admin | DAO multisig | Queue a backing-value update on the BackingOracle, subject to the timelock and ±10% bound. | Set backing immediately, alter facility configuration, or manage YRF operational parameters. |
| emergency | Emergency multisig | Disable the entire facility; return its tracked funds to the treasury while disabled; disable the timelock policies; and cancel queued YRF or backing-oracle actions. | Disable only one asset, add assets, change parameters, or re-enable the facility. |
| heart | Heart contract | Execute the periodic facility cycle. | Perform administrative, operational, or emergency actions. |
| anyone | Permissionless | Contribute reserve tokens or vault shares to an enabled asset's budget, and execute a valid queued action after its delay. | Queue, cancel, or bypass a timelocked action. |
YRF Timelock. Seven operational mutators are routed through a dedicated timelock policy: setting an asset's yield buyback share, setting the initial discount, enabling an asset, disabling an asset, excluding a Clearinghouse, increasing a Clearinghouse's receivables offset, and lowering a stored yield projection. Actions (individually or as an atomic batch) are queued by yrf_admin, become executable only after a configurable delay, may then be executed by anyone within a 3-day window, and can be cancelled by the Emergency role before execution. This gives the community visibility into, and a veto window over, changes to the facility's buyback economics.
Because every operational mutator is timelocked, pausing a single asset is also subject to the delay. Emergency intentionally has no asset-specific switch. Its immediate lever is to disable the facility as a whole while a targeted change is queued.
Launch Configuration
| Parameter | Value |
|---|
| sUSDS | Backing vault, 100% buyback share, redeemed to the reserve |
| sUSDe | Sell-shares asset, 100% buyback share, next-yield seed of 23,543 USDe |
| Initial bond discount | 3% |
| Backing | 12.04 USDS per OHM |
| YRF timelock delay / execution window | 1 day / 3 days |
| Re-enable grace window | 5 days |
| Clearinghouses | DAI v1 and v1.1 included in the backing yield |
| Receivables offsets | None set at launch |
Both assets launch at a 100% buyback share, so day-one behaviour remains a full burn of the tracked yield. The yield split is a capability the DAO can exercise later, not a change taking effect at activation.
Rationale
- Capital efficiency. Drawing yield from multiple reserve assets removes the manual swap step and lets every stablecoin reserve asset contribute to buybacks.
- Flexibility. A configurable yield split and a live, governed backing value let the DAO steer between supply reduction and backing growth as conditions change, instead of being locked into a single hardcoded policy.
- Fail-closed safety. The price floor, the buy-below-backing guard, and donation-resistant accounting close off the paths through which the current facility could over-spend protocol reserves.
- Operational resilience. Soft-failing per-asset steps and mutable bond contracts mean routine external hiccups are handled without redeployment or a stalled heartbeat.
- Standardization and oversight. Adopting the
IEnablerV2 lifecycle aligns YRF with the rest of the protocol, and the YRF timelock gives the community advance notice and a veto window on changes to buyback economics.
Next Steps
- Community discussion. Feedback on the design and on the launch configuration parameters above.
- Audit. YRF v2 to be audited before deployment.
- Execution. The YRF redeployment is already authorized under OIP-194, so no further OIP is required. Once the audit is complete, deployment and activation proceed through an OCG proposal.
