sDOLA-long2 Repayment Funds Source Proposal

Proposals
1

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

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, 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:

    1. Use the new Curve router with balanced withdrawal: supports balanced exits in principle, but is not battle-tested in production; not appropriate for six-figure positions without prior validation.
    2. Manual claim by a trusted EOA (e.g., Mich) followed by manual unwinds: functional, but fully trust-based.
    3. Defer LP-token conversion until L2 burner infrastructure with LP-input support exists.

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

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.
3 Likes
2

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

2 Likes
3

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 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 anywhere in its text? Both are documented, on-chain, and currently under-resolved. The recovery pool thread is at gov.curve.finance/t/…/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:

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 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.

1 Like
4

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:

1 Like
5

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.

1 Like
6

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

1 Like
7

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.

1 Like