# sDOLA-long2 Repayment Funds Source Proposal

**URL:** <http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069>\
**Category:** Proposals\
**Created:** [May 4, 2026, 2:45pm UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069 "2026-05-04T14:45:57Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![LlamaRisk](http://gov.curve.finance/user_avatar/gov.curve.finance/llamarisk/32/2332_2.png) [@LlamaRisk](http://gov.curve.finance/u/LlamaRisk)\
**Post date:** [May 4, 2026, 2:45pm UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069/1 "2026-05-04T14:45:57Z")

</div>

## Summary

This proposal outlines a potential strategy to reimburse the 27 borrowers who lost equity in the March 2, 2026 sDOLA/crvUSD LlamaLend exploit. The total loss was **~822,475 crvUSD** (7.0% of total collateral value). The focus of this proposal is on the funding source and storage; the reimbursement plan will be addressed at a later stage, after alignment on terms between Inverse and Curve stakeholders.

The proposed funding source is uncollected AMM fees: \>$1M in fees that have accumulated across Curve’s L2 deployments and are not yet flowing to either veCRV holders or the DAO Treasury. This avoids redirecting existing revenue streams and can be executed with a limited number of governance actions. The proposed recipient is the DAO Treasury on mainnet.

## Background

On March 2, 2026, an oracle manipulation exploit caused 27 borrowers in the sDOLA/crvUSD LlamaLend market to be hard-liquidated. The root cause stemmed from a unique and unlikely combination of factors: the oracle’s interaction with sDOLA’s pricing mechanism, the soft-liquidation health calculation math, and the high concentration of token supply in the LlamaLend market. These combined allowed an attacker to inflate the sDOLA rate, temporarily depress the oracle price, and trigger hard liquidations at distorted values. Borrowers collectively lost ~822,475 crvUSD in equity as a consequence of the exploit.

Full incident analysis: [LlamaLend sDOLA Post-Mortem](https://llamarisk.com/research/llamalend-sdola-long2-post-mortem)

## Proposed Recovery Mechanism

### Funding Source: Uncollected L2 AMM Fees

Approximately $1.14M in AMM admin fees has accumulated across Curve’s L1/L2 deployments. These fees have not been burned, bridged, or distributed because the necessary burning infrastructure has not been fully deployed on most chains yet.

As of April 23, 2026, the total uncollected fees breakdown by chain:

| Chain | Fee Receiver | Value (USD) |
| --- | --- | --- |
| Arbitrum | `0xd4F94D0aaa640BBb72b5EEc2D85F6D114D81a88E` | $483,639 |
| Polygon | `0x774D1Dba98cfBD1F2Bc3A1F59c494125e07C48F9` | $158,393 |
| Base | `0xe8269B33E47761f552E1a3070119560d5fa8bBD6` | $138,663 |
| Optimism | `0xbF7E49483881C76487b0989CD7d9A8239B20CA41` | $92,410 |
| Ethereum | `0xa2Bcd1a4Efbd04B63cd03f5aFf2561106ebCCE00` / `0xeCb456EA5365865EbAb8a2661B0c503410e9B347` | $92,227 |
| Fraxtal | `0x8b3EFBEfa6eD222077455d6f0DCdA3bF4f3F57A6` | $49,698 |
| Hyperliquid | `0xf3A431008396df8A8b2DF492C913706BDB0874ef` | $29,572 |
| Avalanche | `0x06534b0BF7Ff378F162d4F348390BDA53b15fA35` | $18,685 |
| Plasma | `0x193110Ce1542d7371e1515BD6A2E470fDefc310D` | $16,737 |
| Monad | `0x193110Ce1542d7371e1515BD6A2E470fDefc310D` | $11,535 |
| Sonic | `0x3c0a405E914337139992625D5100Ea141a9C4d11` | $10,988 |
| Etherlink | `0x193110Ce1542d7371e1515BD6A2E470fDefc310D` | $10,611 |
| Other (8 chains) | Various | $32,248 |
| **Total** | | **$1,137,406** |

_Source:_ [_Holy Curve Fee Dashboard_](https://holy-curve-production.up.railway.app/#fees)_, April 23 2026_

### **Minimum Viable Subset**

The recovery target is 822,475 crvUSD. To cover this, we propose to target Arbitrum + Polygon + Base + Optimism ($873,105 gross)

Two caveats apply:

1. **None of these four chains are single-call redirects.** Each requires either new bridger infrastructure or a DAO arbitrary call (see Step 2). New bridger deployment or arbitrary-call tooling is therefore a hard prerequisite for the baseline recovery path.
2. **Token composition at each receiver is not yet broken down.** Much of the gross value may be illiquid LP positions or long-tail tokens, where swap and bridge slippage meaningfully reduces realized proceeds. A per-token breakdown for the four targeted chains should inform the gross-to-net haircut assumption and may push the target set wider.
3. **The gross-to-net haircut can be severe.** Per Curve core devs, the existing fee-burning contracts hardcode `min_amount_out = 500 crvUSD` regardless of input value, so a $100K bag can legitimately settle for as little as $20K (or worse) under thin liquidity or solver-competition failure. Until that is fixed, the DAO should approve a **gross funding ceiling** (e.g., all four chains’ gross balances) rather than a fixed net target, and accept a partial-payout fallback if net realized \< 822,475 crvUSD.

### Procedure

The operational procedure to secure and redirect these fees involves the following steps:

**Step 1: Ensure DAO ownership of Fee Receiver contracts**

All four target Fee Receivers are currently administered by an EOA, not the DAO. Handing control to the DAO requires off-chain cooperation from the current admin on each chain; it cannot be forced by a DAO vote.

| **Chain** | **Fee Receiver** | **Admin** | **Controlled By** |
| --- | --- | --- | --- |
| Arbitrum | `0xd4F94D0aaa640BBb72b5EEc2D85F6D114D81a88E` | `0xbABe61887f1de2713c6f97E567623453d3C79f67` | EOA (“Curve: Deployer 2”) |
| Polygon | `0x774D1Dba98cfBD1F2Bc3A1F59c494125e07C48F9` | `0xB055EbbAcc8Eefc166c169e9Ce2886D0406aB49b` (ProxyAdmin) → `0xE6DA683076b7eD6ce7eC972f21Eb8F91e9137a17` | EOA |
| Base | `0xe8269B33E47761f552E1a3070119560d5fa8bBD6` | `0xbABe61887f1de2713c6f97E567623453d3C79f67` | EOA (“Curve: Deployer 2”) |
| Optimism | `0xbF7E49483881C76487b0989CD7d9A8239B20CA41` | `0xB055EbbAcc8Eefc166c169e9Ce2886D0406aB49b` (ProxyAdmin) → `0xE6DA683076b7eD6ce7eC972f21Eb8F91e9137a17` | EOA |

Migration uses one of two patterns, depending on whether a ProxyAdmin sits in front of the Fee Receiver. Both patterns rely on the Fee Receiver’s built-in two-step admin transfer (`commit_new_admin` / `accept_new_admin`); they differ in who sends the first call.

**Option 1: Direct (Arbitrum, Base).** The Fee Receiver’s admin is an EOA.

1. Current EOA admin calls `commit_new_admin(<L2 Ownership Agent>)` on the Fee Receiver.
2. DAO vote → L2 Ownership Agent calls `accept_new_admin()` on the Fee Receiver.

Arbitrum L2 Ownership Agent: `0x452030a5D962d37D97A9D65487663cD5fd9C2B32`

Base L2 Ownership Agent: `0x2c163fe0f079d138b9c04f780d735289344C8B80`

**Option 2: Via ProxyAdmin (Polygon, Optimism).** The OP FeeReceiver’s admin is the ProxyAdmin `0xB055EbbAcc8Eefc166c169e9Ce2886D0406aB49b`; its own admins are (EOA) and `babe.eth`. The recommended path re-points the Fee Receiver directly, without changing the ProxyAdmin itself:

1. Either ProxyAdmin admin (EOA or `babe.eth`, only one signature needed) calls `ProxyAdmin.execute(<fee_receiver>, <calldata for commit_new_admin(<L2 Ownership Agent>)>)`.
2. DAO vote → L2 Ownership Agent calls `accept_new_admin()` on the Fee Receiver.

Polygon L2 Ownership Agent: `0x8cB05bFEd65b522a7cF98d590F1711A9Db43af71`.

Optimism L2 Ownership Agent: `0x28c4A1Fa47EEE9226F8dE7D6AF0a41C62Ca98267`.

After step 2, `admin()` on each Fee Receiver equals the L2 Ownership Agent and the DAO can execute Step 2 of the procedure.

**Step 2: Redirect fee receivers to DAO mainnet treasury**

Pre-condition: the burner pipeline that will actually move the tokens (Step 3) must exist and be verified for each targeted chain _before_ redirection. Otherwise, we redirect into a sink that cannot be drained. The intended sequence is therefore: (1) validate burner availability and per-token routes on each target chain, (2) ownership migration (Step 1), (3) redirect (this step), (4) burn (Step 3).

After ownership migration, the DAO redirects the destination of bridged fees on each targeted L2 to the mainnet DAO Treasury (`0x6508eF65b0Bd57eaBD0f1D52685A70433B2d290B`). The Treasury acts as the intermediate sink so that any over- or undershoot from the gross-to-net conversion is absorbed there rather than at the reimbursement contract; a separate, follow-on vote then transfers the exact 822,475 crvUSD from Treasury to the reimbursement contract (see Step 4).

The exact call to redirect depends on whether the receiver has a compatible bridger wired in:

- **L2** ` **PoolProxySidechain** ` **with a compatible bridger:** DAO calls `PoolProxySidechain.set_bridge_root_receiver(<DAO Treasury>)`, which internally invokes `Bridger.set_root_receiver(<DAO Treasury>)`. A follow-up `PoolProxySidechain.bridge(<token>)` pushes the accumulated balance through the bridger to the Treasury on L1. After collection, a second vote reverts the receiver to the canonical L1 sink `0xeCb456EA5365865EbAb8a2661B0c503410e9B347`.
- **Chains with no compatible or unwired bridger (e.g., Polygon’s** ` **PolygonBridger.vy** ` **has no** ` **set_root_receiver** ` **; Optimism has** ` **bridging_contract = 0x0** `**; Base sits behind a ProxyAdmin):** either deploy a new per-chain bridger that targets the Treasury and wire it via `PoolProxySidechain.set_bridging_contract`, or have the DAO execute an arbitrary call through the L2 Ownership Agent once it owns the Fee Receiver. Each of the top-four chains falls into this category at time of writing, so new bridger deployment or arbitrary-call tooling is a hard prerequisite for the baseline recovery path

**Step 3: Token conversion**

The accumulated fees consist of stablecoins, spot tokens, and a meaningful share of LP / underlying-LP tokens. Conversion paths differ materially by token class:

- **Stables and spot tokens** (USDC, crvUSD, DAI, USDai, USDe, WETH, ARB, …): can route through CowSwap-based burners on chains where they are deployed (mainnet today; Arbitrum and Gnosis in progress per Swiss Stake). Each route should be validated by fetching swap quotes for the actual notional from the solver and confirming the route makes sense before triggering the burn.

- **LP / underlying-LP tokens** (e.g., tricrypto, cbeth-f on Base; 3c-crvUSD, crvUSDARBCRV, sUSDai on Arbitrum): these are the largest single line items at both Base and Arbitrum receivers and have **no clean automated path today**. Options under discussion with core devs:

**Burner risks and pre-conditions**

The current fee-burning contracts submit CowSwap orders with a hardcoded `min_amount_out = 500 crvUSD` regardless of input size. Under thin pool liquidity or insufficient solver competition on L2, a $100K balance can legitimately settle for $20K or worse, and the DAO has no on-chain safeguard. A proper fix requires a mainnet redeploy and multiple DAO votes (outside the scope of this proposal). Mitigations applicable here:

- **Phased burn.** Begin with low-fee, high-liquidity tokens to validate routes and observe solver behavior before escalating to the larger USDC/crvUSD/LP balances.
- **Per-pool quote check.** Pre-fetch swap quotes from the solver for the full intended notional and abort if the route is unreasonable.
- **Avoid the 7-day burner-config window.** Configuring a new burner + route via governance takes 7 days, during which liquidity could be removed before execution. Prefer pre-existing burners; if a new one is needed, plan execution timing to minimize the exposed window.

**Step 4: Execute a reimbursement plan**

The main focus of this proposal is to align on the funding source and storage method for funds earmarked for reimbursement. Final details of the actual reimbursement plan are subject to pending agreements between Inverse and Curve stakeholders.

- Inverse is working on an analysis that may reduce the headline loss figure, accounting for gains made from the sDOLA share price inflation. Pending their analysis, the total reimbursement may be lowered.
- Inverse may agree to an incentive agreement, whereby Inverse commits to a USD value of incentives equal to the reimbursement amount from Curve. The incentives would go toward supporting an sDOLA lend market on LlamaLend v2. Incentives would be spread over a 12-24 month period, and may be structured as either direct incentives or vote incentives to veCRV.
- Pending an agreement with Inverse, Curve may consider a commensurate payment plan that repays affected users over some time span. The funds held in the treasury may be approved for allocation toward stable yield-generating purposes until the time of payment.
- A donation gauge may be deployed and approved by Curve governance that allows Curve stakeholders to assign gauge weight and accrue CRV emissions toward repayment purposes. The cap may be set to 1M CRV. This strategy may further reduce the total fee revenue needed for reimbursement.

### Timeline Considerations

- The CowSwap burning infrastructure is actively being developed by Swiss Stake and is expected to be deployed on Arbitrum and Gnosis in the near term
- Burner deployment and per-token route hardening on each L2 is the actual blocker on token conversion (Step 3), not the redirect step (Step 2). Step 2 should not execute on a chain whose burner pipeline is not yet validated.
- A test burn on a low-fee, high-liquidity pool is recommended before scaling to six-figure balances, to observe solver competition and confirm the `min_amount_out` constraint is not exposing the DAO to outsized loss in practice.
- The ownership transfer from the current EOA admin to the respective L2 Ownership Agent is a blocking prerequisite on each chain and requires cooperation from that EOA; it cannot be forced by a DAO vote.
- Chains without a compatible bridger (Polygon, Optimism, Base, and most long-tail L2s) will require either new bridger deployments or per-chain DAO arbitrary-call execution before their balances can be redirected. This work is out of scope for this proposal and would need to be scoped separately.

## Appendix A: Affected Borrowers

27 addresses were hard-liquidated. Total equity lost: **~822,475 crvUSD**.

| Borrower | Collateral (sDOLA) | Debt (crvUSD) | Collateral Value (crvUSD) | Loss (crvUSD) |
| --- | --- | --- | --- | --- |
| `0x80c67fe70d7d6cc488782439fad381d8646640c4` | 1,809,065 | 1,862,484 | 2,151,056 | 288,572 |
| `0xb152fc7e9ddf01a942685e390a74009cd2b9ca52` | 3,172,023 | 3,572,521 | 3,771,671 | 199,150 |
| `0x6db248100cf4908429ab671f33d105311ed7fef8` | 2,269,436 | 2,528,047 | 2,698,456 | 170,409 |
| `0xcbcc2b2ecd195ebef03fcb7c7564e4e906485a14` | 748,854 | 853,124 | 890,420 | 37,296 |
| `0xc8801ffaaa9dfcce7299e7b4eb616741ea01f5de` | 523,742 | 587,312 | 622,752 | 35,440 |
| `0x8fc5777d607171b42a61fed4c74242e54677903f` | 371,141 | 420,605 | 441,303 | 20,697 |
| `0x57f845829140d9d9d8e357fa0d9f943483a12fc5` | 352,469 | 400,103 | 419,100 | 18,997 |
| `0xc6c77b16a85c3946e0bdfc71fdb7efd3d89359d0` | 222,232 | 250,689 | 264,243 | 13,554 |
| `0xc8233a46f57add754f32cf9e25a85aae8a7d5f29` | 38,408 | 35,046 | 45,669 | 10,623 |
| `0xadbafae28c3041ecb74456cd7fb9097bd1287308` | 76,345 | 80,543 | 90,778 | 10,235 |
| `0xba5aa2a3dbbbb4c7c3a8950fc6251bb8020cf844` | 117,078 | 132,280 | 139,211 | 6,931 |
| `0x6ce50491faa9fac1dc883a2769ab129e75eb0a75` | 36,508 | 40,042 | 43,409 | 3,367 |
| `0x3e258aae11d7ea394b2eb1176ccd54d9eb83861b` | 29,369 | 32,230 | 34,921 | 2,691 |
| `0x8467241838bc761d9ef4f8ae6790ede292fba2f9` | 48,240 | 55,503 | 57,359 | 1,857 |
| `0x2d57740ee18594bcbfa845703fad49882e1567d9` | 31,242 | 35,910 | 37,148 | 1,238 |
| `0x2b083a0aa6b808a31e9ac749772a285f5cd34fbe` | 1,671 | 1,639 | 1,987 | 348 |
| `0x6ef36f7130d00addf40ce9b040da0bc02491d2e1` | 4,563 | 5,099 | 5,426 | 327 |
| `0xc69f65d2720df32c244163e0f608284415aaef4b` | 3,877 | 4,409 | 4,609 | 200 |
| `0x21ab0875611da0235bc5b6405b8a08268d859700` | 1,762 | 1,910 | 2,095 | 185 |
| `0x5b860e2d38f723d5370cf21f82d6adad31ef0b7d` | 3,543 | 4,054 | 4,213 | 159 |
| `0xe9c0df9bd4607850d410c957fec11ec209de5ef6` | 2,128 | 2,409 | 2,531 | 122 |
| `0x9bf8af305152faddd81c70f8599148e9fc6efa20` | 85 | 80 | 101 | 20 |
| `0x145e305a6e8979cbefcb75993f7ae5270856c1d2` | 192 | 206 | 228 | 22 |
| `0xe170ed9d77792397271d564c7161351d69fe9300` | 157 | 171 | 187 | 16 |
| `0xf60de76791c2f09995df52aa1c6e2e7dcf1e75d7` | 222 | 252 | 264 | 13 |
| `0xd4ffcd8b6b7ec90f4eac001125f4a7b21dc0f781` | 90 | 101 | 107 | 6 |
| `0x8db98764ada29b55a23f7a8cb07be6f74f0d0e75` | 0.008 | 0.009 | 0.010 | 0.0004 |

**Total loss: ~822,475 crvUSD** (7.0% of total collateral value)

Collateral values calculated using sDOLA exchange rate of 1.189042662706965487.

Source: [LlamaLend sDOLA Post-Mortem — Appendix: Liquidated Addresses](https://llamarisk.com/research/llamalend-sdola-long2-post-mortem#appendix-liquidated-addresses)

## Appendix B: DAO Fund Balances

For context, the DAO’s existing funds are insufficient to cover the full reimbursement without a significant impact on operations:

- **DAO Treasury** (`0x6508eF65b0Bd57eaBD0f1D52685A70433B2d290B`): ~14,278 crvUSD (depleted after Proposal #1381). Income: ~14.2K crvUSD/week. At full allocation, it would take ~58 weeks to fund the recovery, without accounting for the Treasury’s own operational needs.
- **Community Fund** (`0xe3997288987E6297Ad550A69B31439504F513267`): ~845K CRV, 0 crvUSD. Disbursements require annual linear vests via DAO vote; not suitable for a one-time reimbursement.
- **Grants Multisig** (`0xc420C9d507D0E038BD76383AaADCAd576ed0073c`): ~10.4M CRV, ~15K scrvUSD. Earmarked for grants, not discretionary spending.

---

<div class="post-metadata">

**Author:** ![Hubert](http://gov.curve.finance/letter_avatar_proxy/v4/letter/h/9d8465/32.png) [@Hubert](http://gov.curve.finance/u/Hubert)\
**Post date:** [May 4, 2026, 2:58pm UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069/2 "2026-05-04T14:58:10Z")

</div>

Is there any liability falling on the risk service provider regarding this failure?

---

<div class="post-metadata">

**Author:** ![strky](http://gov.curve.finance/letter_avatar_proxy/v4/letter/s/c6cbf5/32.png) [@strky](http://gov.curve.finance/u/strky)\
**Post date:** [May 6, 2026, 10:28am UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069/3 "2026-05-06T10:28:53Z")

</div>

Some facts that should be on the table before this proposal moves to vote.

The CRV-long LlamaLend market has been distressed since October 2025. As of today, that is roughly **seven months** of bad debt sitting on a Curve-operated lending market with no funding source attached to its recovery. [Vote #1400](https://www.curve.finance/dao/ethereum/proposals/1400-ownership) deployed a permissionless recovery pool on 2026-04-30 to handle the exit. The pool currently sits at around $63K TVL against ~$754K of bad debt. Recovery for affected depositors depends on arbitrageurs and external LPs choosing to seed it, on no defined timeline.

The sDOLA-long2 incident happened on 2026-03-02, **two months ago**. This proposal was posted two days ago. It allocates ~$1.14M of stranded L2 admin fees — which by design are DAO-revenue that would otherwise reach veCRV holders or the Treasury — to fully reimburse the 27 affected sDOLA-long2 borrowers ($822K target, $873K gross from the four largest chains).

Two months from incident to a fully-funded resolution proposal for one LlamaLend market. Seven months and counting on a parallel LlamaLend market on the same protocol, with a deployed recovery infrastructure that has no funding.

Two direct questions before this proposal moves to vote.

**First:** why does this post not mention the CRV-long LlamaLend market or [Vote #1400](https://www.curve.finance/dao/ethereum/proposals/1400-ownership) anywhere in its text? Both are documented, on-chain, and currently under-resolved. The recovery pool thread is at [gov.curve.finance/t/…/11062](https://gov.curve.finance/t/crv-long-llamalend-market-recovery/11062). This proposal allocates ~$1.14M of common DAO-revenue without acknowledging that another LlamaLend market on the same protocol has comparable USD-scale loss and an existing recovery vehicle that lacks only seed funding.

**Second:** why does a market with an incident from two months ago receive a fully-scoped funding proposal from the same source, while a market that has been distressed for over half a year receives no allocation? If the answer is “the CRV-long pool is a separate workstream,” then this proposal should at minimum acknowledge that workstream exists and explain why the same source is not being shared. If the answer is “no one wrote a proposal for CRV-long,” then the question for the DAO is whether allocating $1.14M of common revenue to a single-market remediation is appropriate when a known parallel case is unfunded on the same protocol.

The argument that these cases differ in kind because one is an oracle exploit and the other is market drawdown does not hold up against precedent. Curve and Curve-adjacent compensation history is empirical:

- The [Vyper compiler hack of December 2023](https://gov.curve.finance/t/proposal-to-recompensate-lps-affected-by-curve-pool-exploit/9825) compensated affected LPs (depositors providing pool liquidity) with a 71.77M CRV vested grant.
- The Inverse Mills [#57](https://www.inverse.finance/governance/proposals/mills/57) / [#305](https://www.inverse.finance/governance/proposals/mills/305) / [#345](https://www.inverse.finance/governance/proposals/mills/345) series compensated anToken depositors after the Frontier oracle exploits.
- The [June 2024 crvUSD-depeg vote](https://gov.curve.finance/t/curve-grant-compensation-for-affected-users-of-the-june-12th-crvusd-de-peg-incident/10182) compensated sUSDe LlamaLend borrowers — at $31K, the smallest case in the set.

Three of the four meaningful precedents went to capital providers, not borrowers. What they share is that the loss occurred through something the protocol shipped or a parameter the DAO set, not the actor class of the affected party. The CRV-long case fits this pattern. Soft-liq band parameters, the bad-debt resolution path, and the absence of automatic recovery infrastructure for distressed lending markets are all protocol-design choices made by the DAO. The “depositors took market risk knowingly” framing is post-hoc rationalization that does not map to how Curve has actually handled compensation when losses materialized on its own markets.

The infrastructure question is also already solved. [Vote #1400](https://www.curve.finance/dao/ethereum/proposals/1400-ownership) deployed the pool template seven months into the CRV-long incident. The mechanism is operational. What it lacks is exactly what this proposal is now solving for sDOLA-long2: a funded source that closes the gap between a recovery vehicle and capital actually flowing through it.

Two paths forward, before this proposal goes to vote.

**Either** amend the scope to include a parallel reimbursement contract for the CRV-long market, funded from the same source, that issues claim-receipts on future LP-shares of the existing recovery pool to affected depositors pro-rata to realized loss and routes a portion of the same fees into the pool as ongoing seed liquidity. The pool design from Vote #1400 stays exactly as built — direct payout is not a viable form for fungible-share holders anyway. But the pool gets a predictable funding source, and affected depositors get a bounded, pro-rata claim rather than an indefinite wait.

**Or** rescope this proposal as the first half of a two-part allocation, with an explicit commitment from @LlamaRisk or another DAO actor to put forward the parallel proposal for CRV-long on the same source, on a defined timeline, before either is voted on individually.

Treating one LlamaLend market with a fully-funded path while a parallel market with a longer-running, comparable-size loss has no source attached is not a position the DAO can credibly take if it wants depositor confidence on any future risk-collateral lending market.

Particularly interested in @LlamaRisk’s view on the scope question, and on how the framework principle — when Curve compensates affected parties on its own markets, and on what basis — should be addressed as a standing matter rather than per case.

---

<div class="post-metadata">

**Author:** ![0xSEM](http://gov.curve.finance/letter_avatar_proxy/v4/letter/0/9de053/32.png) [@0xSEM](http://gov.curve.finance/u/0xSEM)\
**Post date:** [May 6, 2026, 12:52pm UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069/4 "2026-05-06T12:52:49Z")

</div>

I just want to clarify one point regarding the claim that users affected by the previous crvUSD depeg incident were compensated.

A compensation proposal was indeed put forward for the June 12, 2024 crvUSD depeg incident, and an on-chain vote was later created. However, that vote was rejected and the compensation was not executed.

As I understand it, a major reason for the rejection was concern around setting a precedent for using protocol or grants funds to reimburse user losses from LlamaLend incidents.

In my view, both cases should be treated consistently. If the DAO previously decided not to compensate affected users in the June 12 incident in order to avoid setting such a precedent, then the same standard should also apply here. Alternatively, if the DAO now believes compensation is appropriate in this case, then it should also explain why this situation is materially different from the previous one, or reconsider the treatment of the earlier affected users as well.

For reference:

- [CRV Hub vote #845”](https://crvhub.com/governance/ownership/845)
- [Curve governance discussion: “Curve Grant compensation for affected users of the June 12th crvUSD de-peg incident](https://gov.curve.finance/t/curve-grant-compensation-for-affected-users-of-the-june-12th-crvusd-de-peg-incident/10182)

---

<div class="post-metadata">

**Author:** ![midinio](http://gov.curve.finance/letter_avatar_proxy/v4/letter/m/5f9b8f/32.png) [@midinio](http://gov.curve.finance/u/midinio)\
**Post date:** [May 8, 2026, 10:04am UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069/5 "2026-05-08T10:04:21Z")

</div>

There was an exploit (design error in protocol) in the sDOLA-long2 market.

The CRV-long LlamaLend market mainly occured due to market mechanics (no exploiter).

I would support this proposal.

---

<div class="post-metadata">

**Author:** ![Cri](http://gov.curve.finance/letter_avatar_proxy/v4/letter/c/ea5d25/32.png) [@Cri](http://gov.curve.finance/u/Cri)\
**Post date:** [May 8, 2026, 11:48pm UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069/6 "2026-05-08T23:48:59Z")

</div>

In case of sDola-long2 market borrowers lost money due to oracle expoit. There was no depeg event (neither sDola nor the other crvUSD), so I think 2024 crvUSD depeg vote didn’t create a precedent that we could follow here.

Moreover, Curve already has a precedent for compensating users who lost money due to an exploit, recovery for victims of the LP hack in 2023. You can find that DAO vote here: [Curve.finance](https://www.curve.finance/dao/ethereum/proposals/521-ownership)

---

<div class="post-metadata">

**Author:** ![Cri](http://gov.curve.finance/letter_avatar_proxy/v4/letter/c/ea5d25/32.png) [@Cri](http://gov.curve.finance/u/Cri)\
**Post date:** [May 13, 2026, 11:04am UTC](http://gov.curve.finance/t/sdola-long2-repayment-funds-source-proposal/11069/7 "2026-05-13T11:04:50Z")

</div>

I am not affiliated with LlamaRisk, and this is my personal perspective.

In my view, the key issue regarding the recovery of these two different markets (CRV-long and sDola-long2) lies in whether or not recovery can be achieved through market mechanisms.

By market mechanisms, I mean the absence of direct compensation from the protocol’s funds. As you mentioned in your post, a permissionless recovery pool was created to recover CRV-long.

At the time of writing, it already has a TVL of $375,475 and continues to scale, making lenders’ funds liquid. Once certain market conditions are met, CRV-long will be fully restored.

Unfortunately, **this mechanism cannot be applied to the sDola-long2 pool.** This pool was subject to oracle manipulation, not affected by bad debt. Regardless of market conditions, it cannot be restored without direct compensation from the DAO.
