Introduction to Yield Donating Strategies

Yield Donating Strategies (YDS) are smart‑contract vaults that accept a single ERC‑20 asset and donate all profits to a configured on‑chain address. Users can deposit directly into a strategy via the standard ERC‑4626 interface; the strategy deploys funds to one external yield source (lending, staking, AMM, etc.).

When a period is profitable, the system mints new shares to the donation address. When a period realizes a loss, the system burns donation shares first to keep user price‑per‑share steady; only losses beyond that donation buffer are socialized across all holders.

Who this is for

DeFi‑native engineers who want to author strategies that fund public goods by design. We assume:

• Ethereum‑mainnet context
• ERC‑20 / ERC‑4626 familiarity
• Foundry workflow for development and testing

The model in one paragraph

A YDS strategy is an ERC‑4626 vault where profit becomes donation exposure instead of user yield. The donation address holds strategy shares that are minted on profit and burned on loss. As long as donation shares exist, user price‑per‑share (PPS) remains flat through ups and downs. If a loss exceeds the donation buffer, PPS drops for everyone (socialized loss).

💡 In multi‑strategy vault setups (see MultiStrategyVault Lifecycle), a manager can shift allocations between Yield Donating and Yield Generating strategy to control PPS or recover losses; in a standalone direct‑deposit strategy, future profits accrue to the donation address, not to PPS.

Why YDS (developer motivations)

• Codify philanthropic yield: Ship strategies whose profits are guaranteed to fund a beneficiary address on‑chain.
• Clean user promise: Depositors keep principal access; they knowingly forgo yield. Donation mechanics are transparent in events and balances.
• Simple surface: ERC‑4626 in, ERC‑4626 out. Donation/loss settlement for all depositors happens at a single trusted moment (report), which you can automate.

Key concepts (compact glossary)

• Strategy (ERC‑4626 vault): One contract per asset. Users deposit/withdraw using deposit, redeem, etc. The strategy interacts with one external yield source.
• Donation address: The beneficiary account. Receives donation shares on profit; its shares are burned first on loss.
• Donation buffer: The live balance of donation shares. It shields users from losses until exhausted.
• Price‑per‑share (PPS): In profit periods, PPS stays flat (because profit is represented as new donation shares). In loss periods, PPS stays flat while donation shares are burned; if the loss is larger than the buffer, PPS falls.
• Report (trusted step): A keeper/manager call that harvests, converts rewards to the underlying if needed, values the position, and finalizes accounting. Donation share mint/burn occurs here.
• Roles:
  • Management — config and trusted operations (including reporting cadence).
  • Keeper — automation for report calls.
  • Emergency admin — halt new deposits/mints and help unwind positions during incidents.

Lifecycles at a glance

Strategy (direct deposits)

1. Deposit → shares. User calls ERC‑4626 deposit; shares minted.
2. Deploy. Strategy moves idle funds into its single external source (keep this path simple and deterministic).
3. Accrue. Rewards/interest build up in the position; user PPS does not rise from this.
4. Report → settle profit/loss. Trusted call harvests, converts, values, and finalizes accounting:
   • Profit: mint donation shares; user PPS stays the same.
   • Loss: burn donation shares first; only excess loss lowers PPS.
5. Withdraw. Users redeem at current PPS; after a socialized loss they receive less than they deposited.

Vault (optional aggregator, context only)

A vault can hold multiple strategies (YDS and/or compounding) and shift allocations. That is a vault‑operator concern and not required to author a direct‑deposit strategy. Pages 3–4 focus on the strategy layer.

Responsibilities for strategy authors

• Accurate reporting. During the trusted report call: harvest, convert with bounded slippage, and return a truthful total assets figure (idle + deployed assets). Donation mint/burn depends on this number.
• Boring public paths. Keep deposit/withdraw/mint/redeem minimal—move only underlying to/from the external source.
• Automation. No report means no donation and no loss absorption. Configure a keeper or a runbook for cadence.
• Eventing. Emit clear, machine‑readable events for donation share mint, burn, and donation address changes so downstream analytics and UIs can display “yield donated.”

What users should expect

• No APY on shares. These shares are principal‑tracking by design. Show “Yield Donated” instead of a compounding APY.
• Losses are transparent. As long as donation shares exist, user PPS is unchanged through losses; once the buffer is gone, PPS falls.
• Withdrawals at current PPS. Users can exit at any time; redemptions reflect the latest accounting.