[RFC] Arbitrum USDC Vault (OLD) User Reimbursement

[jensei]

1. Summary:

Following the Silo sUSDX/USDC (127) bad debt event impacting the Arbitrum USDC Lower Risk vault, this RFC proposes a one-time, exceptional reimbursement framework in SUMR for affected depositors.

This RFC is intentionally narrow in scope and focuses only on:

1. Reimbursement baseline (84% vs 100%)
2. Vesting structure of such reimbursement (if approved)

It builds directly on the prior umbrella RFC and incorporates the sentiment expressed through forum discussion and informal polling (accounting for the @Recognized_Delegates and the community votes), with the goal of converging on a clear, executable direction that can be promoted to a SIP once agreed.

Previously posted umbrella RFC: [RFC] Arbitrum User Reimbursement, Insurance Fund, and Other Improvements

---

2. Context & Motivation:

As explored in the prior RFC, the Arbitrum USDC LR Vault experienced a loss stemming from exposure to the Silo sUSDX/USDC (127) market following the failure of Stables Labs’ USDX and Silo’s collateral/liquidation mechanics.

Across the discussion, a consistent theme emerged:

Had Guardian module existed, losses would have been limited at the vault level (depending on the reaction time of the guardian set execution of pausing the market). Moreover, had Silo reported the market backing onchain truthfully, the Lazy Summer Protocol would automatically exercise socialization of losses, resulting in an ~84% recovery for all depositors rather than a 0% / 100% split.

At the same time, there is a broad recognition that:

• The DAO treasury cannot sustainably reimburse losses in USDC, and
• unconditional bailouts introduce moral hazard.

As such, SUMR-denominated reimbursement has been proposed as a mechanism to:

• restore trust,
• align affected users with the long-term protocol,
• avoid draining liquid treasury assets ahead of the Token Transferability Event.

This RFC exists to formally converge on the reimbursement principle, while deferring exact mechanics to post-TTE market data.

I would like to propose the continuation of the proposal brought up by @chrisb on a topic of Guardian Setup ( [RFC] Arbitrum USDC Vault next steps (Dealing with USDX bad debt) - #2 by chrisb ).

Due to misalignment on the Insurance Fund establishment (between some of the large @Recognized_Delegates), I separate this proposal - setting it up as a one-off governance proposal. I suggest continuing the Insurance Fund discussion in a separate Topic focusing on additional protections for the users of Lazy Summer Protocol, and exploration of thereof.

---

3. Proposal:

This RFC proposes the following reimbursement framework, subject to Lazy Summer DAO approval:

3.1 Scope & Eligibility

• Applies exclusively to depositors affected by the Silo sUSDX/USDC (127) exposure in the Arbitrum USDC Lower Risk vault.

• Eligibility derived from Snapshot, with a reconciliation process for addresses that may have been omitted due to indexing or UI inconsistencies.

  Spreadsheet for overview and verification can be found here.

• Reimbursement calculated based on USDC-equivalent balances, net of yield accrued after the incident.

3.2 Asset & Valuation

• Reimbursement, if approved, is denominated in liquid SUMR.
• SUMR valuation to be determined post-TTE, using the 30-day trailing average market price, to avoid distorted price discovery.

3.3 Reimbursement Baseline (see polls below)

Three options are proposed for community consideration:

1. No reimbursement
2. Retroactive, proportional loss reimbursement (84%) in SUMR.
   Reflects the outcome that would have occurred had Silo reported the backing (or lack of thereof) of the market onchain, that would automatically trigger vault-level loss socialization.
3. Retroactive, full reimbursement (100%) in SUMR
   Fully compensate affected depositors for losses incurred due to the incident.

Both of the proposed options will be subject to a 1 month delay to be able to track the 30-day average price of SUMR.

3.4 Vesting Structure (see polls below)

If reimbursement is approved, the following vesting options are proposed:

1. Immediate vesting; 1 month after TTE
   Distributed 1 month after the TTE (priced at 30-day average).
2. Monthly vesting over 6 months
   Reimbursement will be calculated using the 30-day average SUMR price post-TTE.

Longer vesting schedules are intentionally excluded from this RFC, based on the sentiment expressed by affected users regarding liquidity expectations in a USDC-denominated vault.

---

4. Open Questions:

This RFC is seeking focused feedback on the following:

1. Reimbursement Baseline

   • Should the DAO pursue retroactive proportional reimbursement (84%), or
   • retroactive full reimbursement (100%), both in SUMR?

2. Vesting Structure

   • Should reimbursement unlock 1 month after TTE, or
   • be subject to a monthly vesting schedule (6-month)?

---

5. Next Steps:

• Gather Community and @Recognized_Delegates feedback on this RFC.
• Review the Tentative Timeline written below.
• Sense-check sentiment via informal support indicators below.
• Devise ideas on technical implementation for the vesting (if relevant).
• Incorporate agreed direction into a formal SIP, to be proposed onchain 1 month after the Token Transferability Event (TTE) ~21.02.2026.

5.1 Tentative Timeline

1. RFC posted on the Forum <18th December 2025>
2. Discussions & Technical implementation preparation <19th December 2025 - 4th January 2026>
3. SIP to be posted on the Forum <5th-11th January 2026>
4. SUMR Token Transferability Vote <14th January 2026>
5. SUMR Token Transferability Event <21st January 2026>
6. 30-day average SUMR price <21st February 2026>
7. SIP edited on the Forum with detailed SUMR allocations <23rd February 2026>
8. SIP to be posted onchain <25th February 2026>
9. Vote result execution <2nd March 2026>

---

6. Informal Support Indicator

6.1 Reimbursement Baseline

Choose one:

• No reimbursement (continue discussion below)
• Retroactive, proportional loss reimbursement (84%) in SUMR
• Retroactive, full reimbursement (100%) in SUMR

If any reimbursement is approved, it will be a subject to a 1-month cliff to be able to devise the price of SUMR on a 30-day trailing average.

6.2 Vesting Structure (if reimbursement is approved)

Choose one (no-vesting = Immediate vesting; 1 month after TTE ~4m post incident):

• No vesting
• 6 months, monthly vesting

Votes are non-binding and intended solely to gauge @Recognized_Delegates, and community sentiment.

[SadMan]

Hi,

As an affected lender who supports the 84% retroactive socialization baseline (the outcome we should have had if the vault had functioned as designed), I want to comment specifically on vesting.

By the time any reimbursement happens, victims will already have been fully illiquid for several months. Because of that, long vesting periods (6–12 months) feel disproportionate and punitive, effectively extending the loss far beyond the original incident.

A short vesting period (e.g. 1 month) is the most reasonable compromise:

• it maintains alignment,

• limits immediate sell pressure,

• and acknowledges that affected users have already carried the full burden for a long time.

Long vesting does little to protect the protocol, but significantly harms the people it’s meant to compensate.

[jensei]

Replying to: [RFC] Arbitrum User Reimbursement, Insurance Fund, and Other Improvements - #26 by techsqrt

This is exactly the level of input I love to see @techsqrt! I agree on:

1. The definition of the data points should be more clear. Now with the standalone RFC specifically focusing on the user reimbursement, I think we should move these discussions here, to improve any necessary details before moving onto SIP.

2. adjusting the average to be “middle 20” numbers to drop the outliers

Thanks for this, and looking forward to @Recognized_Delegates input, as well as @BlockAnalitica thoughts on contribution/support of the reimbursement.

[Meta]

Has @Block_Analitica made any contribution to this discussion besides posting their retrospective? Is anyone the directly responsible individual pursuing that relationship for plausible contribution to this fund?

[MasterMojo]

Whatever is decided Is this framework going to be the same for any future bad debt event?

[jensei]

This is a very good question @MasterMojo, at the end of the day it is always up to the DAO. As far as my personal view on this goes → NO.

@jensei

Applies exclusively to depositors affected by the Silo sUSDX/USDC (127)

&

@jensei

2.3 Moral Hazard and Incentive Alignment

A crucial insight from the previously mentioned Euler thread is Hasu’s warning:

“If a platform compensates deposits unconditionally, curators capture upside while offloading downside to the protocol.”

Lazy Summer DAO must avoid this trap. Therefore, this RFC seeks input for the following:

1. Compensation: if-any; one-time, exceptional, and vested.

I would advice strongly against setting this precedence. For this specific case (pre-guardian control) I consider this as a one-off approach to address the problem at hand.

[MasterMojo]

Appreciate this response!

[Meta]

@MasterMojo could you expand on your reasoning for a 6 month vest?

[Ceazor]

I also voted for a 6 month vest. My reasoning is simple. Those users are stablecoin holders, and most likely would like to try to recoup USDs, They are likely not lookign to speculate on SUMR. So its predictable that the vast majority of them will be sellers of their SUMR allocation. Its best to spread this out over a vest. More volume for traders and LPs.

also, using SUMR as an “insurance” fund was not part of the init plan. I dont disagree with it, but it came about as result of the incident. so the “system” is not well designed for this. Its not like sAAVE which was always intended to act is a backstop.

Im also bias, as i did not lose any in that specific vault, i withdrew before the xUSD drop. And i hold SUMR.

[SadMan]

@Ceazor

Thanks for being transparent about your bias — that actually helps clarify the discussion.

I want to gently re-anchor this debate on one core fact that tends to get lost: if the vault had functioned as designed, affected lenders would have lost ~14–16%, not 100%.

That’s not speculation — that’s the explicit promise of a diversified, “Lower Risk” vault with loss socialization.

The 84% baseline isn’t about being generous to victims. It’s about restoring the expected outcome of the product. Everything else (SUMR mechanics, vesting, sell pressure) comes after that baseline is acknowledged.

On vesting: spreading sell pressure to protect SUMR holders is understandable, but we shouldn’t forget that affected lenders have already absorbed:

• 100% loss instead of ~16%,

• months of forced illiquidity,

• and now additional market risk via SUMR.

A long vest may help token dynamics, but it further penalizes users who already paid far more than their fair share. That’s why many of us see shorter vesting as a reasonable compromise, not an aggressive demand.

Finally, it’s true SUMR wasn’t originally designed as an insurance backstop — but neither was the Arbitrum USDC “Lower Risk” vault designed to wipe out stablecoin depositors.

We’re already in an exception scenario, and fairness should take priority over token optics.

[Ceazor]

Can you clarify why you thought lenders were only exposed to ~15% downside risk?

”if it had functioned as designed”? This part is unclear to me.

The way i understand it. i need more info indeed. but not being exposed made this research unessential.

-lvUSDC (on arb) had exposure to xUSD
-agile depositors withdrew from lvUSDC, before or during depeg, for full value.
-slower depositors are left holding the empty bags

this often happens in the space, and is why i have recommended “socialization of losses” be added to the system

-pause withdraws/deposits with emergency button (admins, devs, dao, should have this power)
-readjust price per share.

that said this does not pertain to this event, rathe future events. but it does speak to “as designed”

that said, it the table was turned, i can certainly see the side you are presenting. im in several other vaults on other projects that “present a recovery plan” that never gets executed.

I think the plan here, WILL be executed when terms are settled, which is fantastic in comparison.

[SadMan]

@Ceazor Happy to clarify — this is an important point and I think we’re actually closer than it may seem.

When I say “~14–16% downside if it had functioned as designed”, I’m referring to the expected behavior of a diversified, curated vault with loss socialization, not what actually happened in practice.

Concretely:

• The Arbitrum USDC Lower-Risk vault had ~16% exposure to the Silo sUSDX/USDC (127) position.

• In a normally functioning vault with:

  • proportional accounting,

  • loss socialization,

  • and/or an emergency pause preventing a bank run,
    the maximum loss per depositor would have been proportional to that exposure.

• Meaning: every depositor should have ended up with ~84% of their USDC, not 100% and not 0%.

What broke that expectation was not simply “crypto bank run dynamics”, but the absence of safeguards that are implicitly promised by a curated “Lower Risk / set-and-forget” product:

• no pause,

• no guardian,

• no forced socialization,

• and an oracle design that prevented the system from even recognizing the loss in time.

So when I say “as designed”, I don’t mean “as implemented on that day”, but as the product is marketed and reasonably understood by depositors:

diversified exposure → proportional downside.

You’re absolutely right that agile depositors exited and slower ones were left holding the bag.

That’s precisely the failure. In a Lower-Risk curated vault, depositors should never be competing against each other in a reflexive bank run. Otherwise, the product is functionally indistinguishable from a permissionless pool with no curation guarantees.

I fully agree with you that:

• socialization of losses,

• emergency pause,

• and price-per-share adjustment
  are the correct long-term fixes — and I support them strongly.

Where I’d like to add one clarification, in light of the current RFC framing, is this:

84% is not really a debated “option” anymore. It represents the counterfactual baseline of normal vault behavior — the outcome users reasonably expected if the system-level safeguards had worked.

The real question is whether the protocol chooses to go beyond that baseline (toward 100%), not whether the baseline itself is acceptable.

That’s why many of us view 84% not as generosity, but as restoring the result that should have occurred absent the system-level failures.

Appreciate you engaging in good faith — and I agree with you on one important thing: the fact that a recovery plan here is likely to be executed at all already puts Summer ahead of many other protocols. That’s exactly why getting this right matters so much.

[Ceazor]

i do see your point and i think we are eye to eye on the best practice of socialization of losses.

i can recall the SONNE exploit (early 2025) where one vault i was in, immediately paused and PPS adjusted and we all lost the same

and another that didn’t and i am holding an empty bag.

the question here i think is obviously was which was the expectation of Sumr vaults, regardless of code design.

AFAIK, the ~84% is already agreed, and here we’e discussing vest or not vest.

so lets return to your thoughts.

Is it fair to ask these victims to take on long term SUMR speculation?

obviously 4 years is not fair, but 3 months? 6 months? these are questionable amounts of time. and the only true answer will be found in a goverance vote.

There is also a cosideration of the liquidity depth of SUMR LP when live, and how much of a price impact would an entire reimbursement sell off have. simply, can the LGE LP take the hit.

if the losses are foreexample 1 M USDC, and the SUMR LP intended to launch with 1M USDC/ 1M SUMR (i have no idea the intended LP rn)

Then selling becomes a race here. and first sellers win over later sellers (not socialization again)

It might be better to just hand out the USDC then, and avoid the giant red candle on the SUMR chart.

[rspa_StableLab]

Voted for proportional reimbursement and six-months vesting. Reimbursement without vesting could mean reimbursing with tokens just at the TTE of $SUMR, which could lead to a rocky start.

Better to wait six months and give the token more breathing room.

[Meta]

On compensation for ~250 affected lenders, it appears both @Ceazor and @SadMan are in agreement on two things: compensation should certainly be provided, and it would be MUCH more favorable to both affected depositors and SUMR holders to be covered in USDC.

Unfortunately, the Lazy Summer DAO doesn’t have the funds to make good on these losses - which is the sole reason why depositors are willing to accept the uncomfortable compromise of taking a speculatively priced governance token in its stead.

Let’s remember SUMR is being used to cover losses of individuals’ personal savings denominated in USDC, in a vault & on a platform that promised “set and forget” functionality in theory, and guaranteed multiple layers of risk controls to mitigate or socialize any realized losses in practice. Instead, the affected lenders experienced 100% losses, WHILE acting as guarantors to first-out depositors. This meets the legal bar for misrepresentation.

TLDR 1:

1. User expectation was same-day exit in USDC at ~84% of deposit value - based on marketing, technical and risk-control guarantees plastered protocol & forum-wide
2. Protocol reality to date has been ~2 months of DAO debate with inversely-incentivized SUMR token holders to hopefully receive some compensation on some timeline, while affected depositors have lost 100% of their USDC deposits.

At the very same time: Lazy Summer DAO vaults have yet to make the technical changes that would guarantee other vaults are free of similar crises, while Summer.fi continues to claim its vaults are as hands-off and safe as ever. As you can imagine, this - plus the appearance of sandbagging the restitution process - is making lenders fairly pissed off, and I can imagine few things that would make them lend again short of a >=84% USDC comp presented ASAP.

But forget these affected lenders for a second: consider the value-proposition of the protocol in the first place, from which the inherent value of SUMR stems. If users cannot trust the very “set and forget” premise on which Lazy Summer is built, and in this CRITICAL precedent token holders shortchange depositors, the alignment between lenders and token holders split. At the worst, you may see affected lenders explore more combative means of seeking restitution, negative PR at the critical launch period of the token, and an environment in which present and future depositors no longer feel safe to add to the protocol TVL.

So what does “shortchange” mean in this scenario? Every departure from “TLDR 1: User expectation…” - and we’re already so, so far off the promises made.

Ok, so what?

6 months is not a trivial timeline for accessing one’s savings. Taking a speculatory, illiquid, multi-month SUMR position instead of an instant USDC withdrawal is not what ANY depositor has in mind when entering a Lazy Summer vault.

Because affected depositors and SUMR holders are inversely incentivized, I propose a compromise: depositors release expectations of no vest, while @Recognized_Delegates compromise from their preferred 6 mo target. Instead, we settle the question of vesting here in the forum, agreeing to a 3 month vest, starting from TTE.

TLDR 2:

Democracy in governance is not a pack of wolves and a few sheep voting on what they’ll have for dinner. Clearly SUMR-rich delegates will vote in the immediate interest of their own token holdings, at the expense of present and future depositors - hence the urgency for meeting depositor needs through discussion versus token vote.

My proposal is a “hardcoded” compromise of 3 month vest, to be reflected in the final Tally proposal.

[rspa_StableLab]

Appreciate the sentiment and can sympathize with how you feel. The issue is when too many tokens come on the market at the same time it creates something that is a net negative for everyone, including those getting reimbursed. Is 6 months too much? Maybe! Would love to hear other solutions instead of creating a massive market dump on day one.

[Meta]

Per your request, some other proposals for avoiding a day-one dump:

1. A 3 month vest, as proposed here and in the original bundled RFC.
   1. In fact, any length of vest technically accomplishes your stated goal of avoiding a day one dump - but 3 seemed to me like the happy compromise among prenegotiated options.
   2. The rollout of the reimbursement can be linear (day-by-day unlock over 3mo) or periodic (at t=30d/60d/90d), each of which staggers total tokens being freely traded. Whatever the approach, the design of vesting leaves room for mitigating dumping; the length of vesting may also prevent dumping, but simultaneously punishes affected lenders.
2. An alternative reimbursement plan that delivers whole or partial compensation in USDC, plausible over a longer timeline.
   1. V2 staking shows us Lazy Summer DAO is comfortable allocating 20% of future earnings to stakers in USDC.
   2. A similar plan could be explored for this incident specifically, or as part of an ongoing insurance fund (which would take on some or part of this affected lender liability).
3. Pre-staking SUMR allotted to affected lenders for a 1-3 month period, allow it to earn yield while waiting to be unlocked.
   1. This is primarily meant to clearly signal to affected lenders “your SUMR can work for you, you don’t have to sell it!” NOT to lengthen the ultimate implied vest timeline.
4. Without intending to sound sarcastic: continue building a great protocol that stands by its core promises, continues to generates “set and forget” returns for an ever-growing pool of depositors who have faith in the safety of their savings, gradually growing TVL, and ultimately causing SUMR price appreciation.
   1. Nothing says “HODL” like the token value going up.

I’m open to hearing further alternatives, but I think my original proposal and the ones above meet and exceed the criteria of avoiding a “massive market dump on day one”.

[SadMan]

I agree with the concern about avoiding a day-one dump, that’s a legitimate goal.

But I think Meta already laid this out well: the question is not “dump vs no dump”, it’s how to balance market stability without forcing victims of a stablecoin vault to become long-term SUMR speculators.

From an affected lender perspective, a hardcoded 3-month vest already:
• avoids a day-one sell-off,
• reduces reflexive selling dynamics,
• and still respects the fact that many of us have already been waiting months after losing access to our funds.

Anything longer starts to feel less like market protection and more like shifting protocol risk onto depositors a second time.

So yes, avoiding a dump matters.
But so does restoring trust that “set and forget” doesn’t turn into “lock up and hope”.

[Bozer76]

Agree with @SadMan. A 3mo vest sounds reasonable.

As an affected lender, I’d hope for 50% in USDC, then rest vested over above mentioned 3mo.

[jefflost]

Just found out I lost all my money in the vault, am in shock, especially considering that 16% of the TVL of the vault was affected…. Doesn’t seem fair, if anything the loss should have been socialized for the entire TVL of the protocol, not just that vault., which would have then made it like 2%? or should have/ had insurance fund which functions similarly? I specifically deposited in that vault because it said “low risk.”

Does a 3 month vest, mean tokens are released every week, every day? I think even every month would be a mistake and it needs to be more often, as the sell pressure needs to be distributed more.

However, hopefully the token is made to be more valuable, so we wouldn’t want to dump it. I think that would be good for the protocol in general, not just for affected users. $100k a year in usd token payouts (revenue share) seems a bit low for a protocol at $90m in TVL. The token should get at least 5% of all the yield for every vault.

Edit: After seeing real yields of stablecoins only average to be about 4%, 2% USDC yield to SUMR, at least relatively, is not that bad, if that ratio persists.

But the insane emissions/ inflation of SUMR, have me worrying that the token price will go down as fast as the inflation. It would be really unfair if the amount of SUMR being distributed was set on day 1, and then after 3 months, because of massive inflation, the value is half… or even worse, we are getting 20 cents on the dollar because of the tokenomics.