[SIP5.14] Multi-Chain Raft Address Update

1. Overview:

This SIP proposes replacing the RAFT contract on each supported network (Base, Arbitrum, Ethereum and Sonic). The upgraded RAFT contract introduces functionality to allow governance to socialize losses within a vault, likely useful once Guardians are introduced who can pause Vaults.


2. Motivation:

This SIP is in response to [RFC] Arbitrum USDC Vault next steps (Dealing with USDX bad debt) and ensuring there is and can be a clear process and clear audit trail onchain.

This upgrade is necessary to enable clear and easy ways for governance to be able to socialize losses within a vault for a particular market, when combined with enabled guardians who can freeze the market while Governance takes action.

It also adds additional protections to sweepable markets, ensuring governance can add certain tokens to a blacklist too.


3. Specification:

Newly deployed raft contracts:

  • base: 0x7839d904D05d3D6B5F1D87eb93e1dcD5746AbC6E
  • arbitrum: 0x60A81C58F37527FdEcc968FC8B834Ed00b65926d
  • mainnet: 0xEcCd16aA1ae0B32b231a3B5FFE8567aBf68616E2
  • sonic: 0x2a828B0E5cB549eE568923E815D9A781b6f4F018

Actions

  1. On base:
  • Set raft address on base to 0x7839d904D05d3D6B5F1D87eb93e1dcD5746AbC6E
  1. Send cross-chain proposal to arbitrum to:
    -Set raft address on arbitrum to
    0x60A81C58F37527FdEcc968FC8B834Ed00b65926d

  2. Send cross-chain proposal to mainnet to:

  • Set raft address on mainnet to 0xEcCd16aA1ae0B32b231a3B5FFE8567aBf68616E2
  1. Send cross-chain proposal to sonic to:
  • Set raft address on sonic to 0x2a828B0E5cB549eE568923E815D9A781b6f4F018

Technical Details

The raft contract is used to handle reward token auctions. It updates the Raft contract to handle tokens with self transfer functionality blocked.


4. Risk Assessment:

This SIP introduces no additional risks, but relies on governance to decide how to handle receipt tokens once collected into the treasury after socialized losses and been executed.


5. Voting:

A YES vote for this SIP will replace the existing RAFT contract addresses with the newly deployed RAFT contracts and will be used moving forward.
A NO vote would leave the existing RAFT contracts as they are, making no changes to the protocol.

2 Likes

Thanks @chrisb for another clear write-up. I am fully supportive of this proposal as I believe this upgrade makes sense as a foundational improvement to protocol governance tooling, since it will enable onchain socialization of losses and adding safeguards (blacklist + guardian freeze flow). I see this as a necessary next step given the recent Arbitrum incident.

Hey guys! I’m new to the forum, but have been using Summer.fi and Oasis.app for years. Can you guys help me understand the socialization question here? I assumed (apparently incorrectly) that since the assets deposited into these contracts was automatically spread across multiple other DeFi protocols, that both the yield was aggregated AND the risk was dispersed. So I assumed that if we were all earning yield together from multiple DeFi protocols, if things went sour in one of them, the entire pool would absorb that equally just like the entire pool benefitted from the yield equally. At this point, I feel very fortunate to not have had assets in the pool that was affected at the time of the Silo pool getting wrecked, but I would be devastated if I had had assets in there and was left holding the bag while other depositors got 100% of their money back. I could be misunderstanding how it works, so I wanted to first come and ask if I’m even understanding the mechanics correctly. If there is a better place to have this discussion, please let me know. Thanks in advance!

1 Like

Hello @jderias and welcome to the Lazy Summer DAO forum! :slight_smile:

You’re right that vaults spread deposits across multiple strategies, but risk is not socialized across different vaults. Each vault is isolated so that an incident in one strategy (like the Silo USDx market) doesn’t impact users in unrelated vaults.

Regarding your comment, and specifically:

Since, the DAO at the time of this exposure did not have set up a guardian role the vault was not frozen - which would lead to socializing losses across the vault - dispersing the available liquidity to depositors. This was not done at the time, therefore available liquidity was addressed on the first-come-first served basis, and quickly dried out.

This is far from ideal, but a big learning. I believe there was already a small poll around possible setup of the guardian role, that could in the future prevent the infliction only on the “last-ones out” - so I am keen on continuing that discussion further.

1 Like

Thanks for the feedback. I may not have been totally clear in my initial question. I wouldn’t really expect risk to be spread from one vault to another. It seems logical that the higher risk USDC vault on Main net wouldn’t share risk with the lower risk USDC vault on Base - those are totally different animals and it seems like they would share their own risk internally, but not from one to another. I think I was unclear by using the word “pool” where I meant a lazy summer “vault.”

I do stand behind the idea that any losses within a vault should be socialized within that vault. To be honest, I will probably pull all of my deposits until (and if) that happens because there is a real possibility (as has been shown) to have a total loss in a “lower risk” stable coin vault, which is a totally asymmetric risk - I can’t justify the possibility of losing 100% of deposits in exchange for the possibility of an extra few percentage points in yield. In the meantime, I would love to continue to participate in the discussion and be helpful where I can, and would love feedback on the best way that I can do that.

1 Like

That is totally understandable @jderias, at the same time - the events around Silo sUSDx/USDC ARK has ben unpredictable (due to Balancer hack). With a new assessment and risk exposure from @BlockAnalitica (find more information here), the strategies with set caps at the moment are very conservative and I would prompt you to have a look at those, and verify that information.

Therefore, even though I understand your concerns, I personally do not see any “risk-on” strategies across the vaults of Lazy Summer Protocol.