SUAVE Economic Security Models

Introduction

SUAVE’s design is still an area of open research with questions around economic security, incentive compatibility, social alignment, technical risk, and feasibility. All are important if SUAVE is to be successful. Feedback from the EF, rollups, EigenLayer, and others would be valuable. So far we know:

The rest is mostly TBD. This post will introduce some of the potential economic security models. I’ll argue that SUAVE should be a rollup or consider re-staking.

SUAVE Validators’ Responsibilities

For background, SUAVE executors output (full or partial) blocks that other domains using SUAVE may accept. For example, Ethereum validators could profit-switch between a SUAVE block, a block made by traditional centralized builders, or a locally built block.


The following is based off of this description of SUAVE.

Users can deposit funds on SUAVE and commit to unlock them if their preferences are met. They write smart contracts (called “bonds”) on SUAVE Chain that validate whether the preference was fulfilled and conditionally transfer a payment if so.

The incentives to participate are:

  • Executors - Incentivized by bonds
  • Validators - Incentivized by network transaction fees

SUAVE can be viewed as having two layers:

  • Messaging layer (i.e., mempool) - Transmits preferences to be executed
  • Settlement layer (i.e., SUAVE Chain) - Processes bonds

The chain is primarily intended to check the results of execution and settle payments after the fact. It processes transactions to:

  1. Bridge funds
  2. Initialize bond contracts
  3. Submit oracle updates about the state of another domain
  4. Claim the payment from a bond contract after a preference is fulfilled
  5. Other - SUAVE is a permissionless EVM chain, so anything could be deployed on it. Native activity outside of its “intended” use is unclear.

SUAVE block times are only relevant if you have to do one of the actions above in the process of executing a preference. Executors aren’t generally expected to need to take these actions while constructing a block, so SUAVE block times wouldn’t be a bottleneck in producing blocks for other domains. (I.e., SUAVE validators aren’t signing off on what block is the one they want to send to Ethereum, or any other chain using it).

Native Activity on SUAVE

Back to that “other” stuff. “The chain is being built specifically for sequencing/block building/MEV and [Flashbots has] 0 intention of rivaling ETH/other smart contract chains. [Flashbots] will put 0 resources to that.” However, “SUAVE Chain is permissionless and anyone can deploy whatever contracts and make whatever transaction.” It’s anyone’s guess what actually ends up going on there in addition to the “intended” use cases.

Let’s be real, degens gonna degen. SUAVE will have a bunch of the smartest searchers/builders/DeFi degens/etc. working around it. I’d be shocked if none of them natively deploy on SUAVE some creative leveraged trading uncollateralized NFT yield farming ponzis, because why not.

Interestingly, this native MEV could increase SUAVE validators’ desire for some kind of solution to build their blocks for them too. This would ensure that SUAVE validators have equitable access to MEV, avoiding centralization. They could actually have SUAVE executors building blocks for SUAVE Chain too, in much the same way that these executors would create blocks for other domains like Ethereum.

And that’s all fine. “Un-intended” native use just has to be acknowledged as a possibility and properly addressed. Additionally, there are always the “unknown unknowns.” Does it make sense to have some other important activities we haven’t even thought of to be done natively on this coordination chain? Seems very possible to me. All the more reason it needs to have a resilient security model.

SUAVE L1 Without a Subsidy

The simplest economic model here in isolation is insufficient - SUAVE as a standalone L1 with bridged ETH securing the chain. You could also of course secure SUAVE Chain with a hypothetical “secondary” token if you wanted to remove bridged asset risk in consensus (and could still just use ETH for gas, etc.). But this is just rehashing every L1 EVM-fork we’ve seen in the past, so I won’t bother going any further on why that’s problematic.

The economics would look like this (I assume SUAVE Chain would use an EIP-1559-like fee mechanism here):


To win blocks, SUAVE will be competing against centralized builders on other domains. These builder margins are already thin - they bid almost all of the value back to Ethereum validators today. If additional SUAVE fees meaningfully cut into margins, it will likely not be competitive in winning blocks. Since these fees are the stated incentive for SUAVE validators, they would receive negligible revenue (at least early on). I also note that SUAVE Chain validators could receive MEV from activity on SUAVE Chain itself as discussed earlier.

However, the opportunity cost of ETH staked on SUAVE = rewards from ETH staked on Ethereum L1. Assuming staked ETH is to reach equilibrium at equivalent yields on SUAVE and Ethereum L1:


It’s clear that total revenue to Ethereum stakers > total revenue to SUAVE stakers by a huge margin.


Additionally, SUAVE validators should demand a higher yield than Ethereum L1 staking. It’s riskier (new chain, bridge risk, etc) and requires more resources to operate. In the absence of any additional incentive mechanism, an incredibly small amount of ETH should rationally be bridged to SUAVE for staking.

There’s a reasonable argument that long-run sustainable value capture is possible. However, it will certainly be negligible for at least a while. It will have limited functionality/adoption to start, and it will need to be cost-competitive.

Looking at the numbers, there’s ~16mm ETH staked on Ethereum earning a yield of ~7.5%. You can play around with the assumptions below:

SUAVE L1 - Parasitic to Ethereum Security

If this SUAVE L1 is eventually highly profitable (and attracts a large volume of bridged ETH), it is then somewhat parasitic to Ethereum L1’s economic security. Validators are forced to choose between validating either Ethereum or SUAVE as contemplated here. If SUAVE manages to offer higher and higher rewards, then rational actors will progressively unstake from Ethereum L1, bridge to SUAVE, and stake there.

This is analogous to the classic problem we’ve seen in DeFi - when lending rates are above the staking rate, participants are incentivized to unstake and use their collateral in DeFi. This has largely been addressed by liquid-staking derivatives (LSDs) or superfluid staking. These enable base layers to keep a reasonable inflation rate while maintaining sufficient collateral staked.

Alternative Economic Models

  1. Rollup - Make SUAVE a rollup
  2. EigenLayer - Use EigenLayer, attracting ETH re-stakers to secure SUAVE chain
  3. SuaveLayer - Fork EigenLayer, implement a new Ethereum re-staking protocol just for SUAVE, attracting ETH re-stakers to secure SUAVE chain
  4. L1 + Bridged LSDs - Allow LSDs to be bridged and staked (e.g., you could stake stETH on SUAVE)
  5. L1 + Decentralized Subsidy - Inflationary SUAVE token issuance
  6. L1 + Centralized Subsidy - Flashbots directly pays you to stake

Each would alleviate the economic opportunity cost issue to varying extents. Note that these options are not mutually exclusive. For example, some form of “subsidy” is potentially applicable in all cases. All scenarios contemplated include some meaningful smart contract and/or proof implementation risks:

1. Rollup

This is the most preferable option in my view. You get full Ethereum security. You can still capture value for your rollup as desired (rollups will pay a very small margin to Ethereum). You can actually safely capture more value, because it’s now reasonable to use the “secondary” token for sequencer leader selection (or local consensus if desired). It wins out on all fronts I can think of, except arguably complexity (which also = risk). Something like the OP Stack should sufficiently address this concern for me. It would greatly ease initial deployment and allow upgrade flexibility overtime.

Additionally, safeguards can be implemented as we see with most “rollups” today. There are some tradeoffs (e.g., centralized sequencers, smart contract upgrade keys, etc.), but this is acceptable short-term to mitigate risk. The smart contract bridge risk is also greatly reduced compared to an L1 option - the bridged asset is no longer required for consensus.

Staked ETH (or a “secondary” token) could be used though for decentralized rollup sequencer leader election. It could also be used for a local consensus giving stronger pre-confirmations if desired (but it’s unnecessary). For example, StarkNet plans to do something like this. This SUAVE rollup would presumably be an optimistic rollup, with the ability to transition to ZK over time as it makes sense (or maybe a 2FA SGX rollup while you’re at it).

It’s also cool that a rollup built on top of Ethereum could be building blocks for Ethereum, and those blocks would be securing the rollup built on top of it that’s building those blocks.


For a deeper analysis of rollup considerations (particularly economics), I recommend:

2. EigenLayer

Also appealing, and reasonable to implement in the relatively short-term. Ethereum staking revenue is no longer an opportunity cost for SUAVE re-stakers. They can just stack the yield from securing SUAVE Chain on top of their initial revenue. This makes it far easier to bootstrap security from a subset of Ethereum’s validators.


Re-staking smart contract risk is preferable over the bridged ETH risk in my opinion (in the case where bridged ETH is actually used to secure SUAVE, as would be the case if SUAVE were to be its own L1). There are concerns around accidental slashing using re-staking. However, this could be mitigated with safeguards such as a trusted committee with the right to veto. This option is also potentially easier to implement than building a new rollup, and alleviates many of its associated risks (proof system, bridge risk, etc.).

Applications leveraging EigenLayer (e.g., SUAVE) could flexibly impose limits on the validators opting in. For example, “you’re only allowed to re-stake on SUAVE if you aren’t re-staking for other applications.” This reduces the “leverage” placed on economic security if that is desired.

The reduced leverage also comes at some cost - it’s more difficult to have higher stake securing the chain. It’s easier on the margin to attract re-stakers if they’re allowed to stack yield by securing other EigenLayer applications. It’s more capital efficient. So allowing for higher leverage increases the barrier to collude, but it also increases the incentive to do so. It’s a tradeoff.

There’s also an underlying centralization risk to Etherum itself. One concern regarding re-staking is that it can incentivize validators to be more sophisticated. For example, let’s say:

  • Average Joe validator - can get 7.5% yield (just vanilla Ethereum staking)
  • Sophisticated re-staker - can get 10% yield (assume SUAVE gets you an extra 2.5% for easy math)

Sophisticated stakers will compound earnings, and others are also incentivized to give their money to the sophisticated validator to stake for them. It’s quite similar to why MEV-Boost seeks to give all validators equitable access to MEV. You can think of any potential income to be earned via re-staking similarly to MEV in this context.

For the health of Ethereum’s validator set, re-staking is best suited to horizontally scalable applications which keep individual re-staker node requirements very low (e.g., EigenDA). Throwing a potentially high-resource requirement L1 with strong incentives (as SUAVE could be) on top of EigenLayer is not the best fit.

3. SuaveLayer

Similarly, SUAVE could fork EigenLayer and create their own re-staking contract. This could enable the same deleveraging if desired (i.e., don’t let SUAVE re-stakers secure anything else). This also allows for better control of their stack and associated safeguards. For example, SUAVE could choose the slashing veto committee, parameters, etc. However, this also introduces similar centralization concerns on the Ethereum validator set.

Additional benefit - SuaveLayer sounds cool.

4. L1 + Bridged LSDs

This removes the opportunity cost to secure SUAVE (net of LSD fees), allowing SUAVE validators to continue capturing Ethereum staking revenue. However, “kingmaking” certain LSDs and further entrenching LSD centralization is problematic (sorry @Hasu). You now have severe bridge risk and LSD contract risk - these bridged assets secure the chain. Bad trip.

5. L1 + Decentralized Subsidy

This would presumably be some form of secondary inflationary token that could be used to incentivize SUAVE validators. Staked ETH would still secure the chain and capture the majority of value. This could bootstrap economic security, borrowing from future expected cash flows.


This still retains the issue of being somewhat parasitic to Ethereum L1’s own economic stake. Bridge risk is again severe, as bridged ETH secures the chain.

If SUAVE were to decide any “secondary” future asset is desirable, it’s better suited to a rollup or a re-staking construct. Neither limit this ability to further decentralize, capture value, etc. (e.g., you could have dual-token staking with re-staking). A rollup/re-staking construct would just remove the aforementioned concerns around economic security, being parasitic, etc.

A SUAVE Chain makes a lot of sense. But while you’re at it, you might as well post your data and some proofs to Ethereum. What are those called again…? I’m quite surprised an L1 secured by bridged ETH would get any meaningful consideration as an option.

6. L1 + Centralized Subsidy

No. Severe bridge risk. Still parasitic to Ethereum L1’s own economic stake. Unnecessary and unsustainable. Flashbots employees get sad.

TLDR

SUAVE should strongly consider a rollup or re-staking for its eventual chain. Both alleviate the economic incentive concerns and retain flexibility for further decentralization mechanisms. My preference would be a rollup.


Disclaimer: I have no personal or professional financial stake in Flashbots (current or planned), other than hoping they make Ethereum work so that my ETH goes up. I have a small personal stake in EigenLayer. Would also appreciate it if they make ETH go up.

13 Likes

Very interesting read.
I think rollups and re-staking approaches are definitely sound approaches.
But I also wonder how the economic model will change if the consensus is achieved via DAG. There won’t be the typical PoS-like fee for authenticating transactions. Could that change some of the economic assumptions you made around the fee on SUAVE?

Hi @Jon, thanks a lot for the post! It took me a while to chew through my reading list, but I enjoyed it.

I think many of your thoughts are valid. Below I will respond to the most significant points made:

If you use unencumbered ETH as a staking token, you compete with ETH staking (and other yields)
I agree! If you do that, you get much less economic security (or whatever you’re buying) for the same cost. If you wanted to pull meaningful ETH from Ethereum, you’d have to outbid staking fees, which we neither want nor can afford. Hence, if we use some form of ETH staking, I think it will realistically use a form of staked ETH or ETH restaking, so it becomes value-additive (not parasitic) to the ecosystem.

SUAVE should strongly consider a rollup
I think over the longer term (thinking 4+ years out) this option makes total sense. There are at least three factors to consider with rollups (there might be more as our understanding improves):

The pros and cons of rollups
So, rollups guarantee safety + liveness through the L1 (you can’t make invalid state transitions + you can always force a state transition).

First, SUAVE doesn’t benefit from these benefits as much as one would think. SUAVE isn’t interested in users bridging a lot of funds and storing them there. Rather, we are investigating techniques to minimize the need to bridge funds to SUAVE as a user. In a perfect world, only major searchers/builders will have to maintain a balance and only enough for working capital. That could still come out to a meaningful amount, but it’s not comparable to L2s like Optimism/Arbitrum/StarkNet, etc. who all compete on attracting & locking up as many funds as possible. Likewise, the ability to get a state transition mined through L1 is not relevant/useful to searchers.

Second, the high security of an L2 comes also at a high (DA) cost today.

Third, SUAVE needs to report state transitions from other domains back to the home chain, so that the conditional payments from bids can be unlocked to executors. As far as I understand today, rollups have the nice property that SUAVE can trustlessly read the state from Ethereum L1 and other rollups building on Ethereum.

Initially, I don’t think the economics come out rollup favored, because the security benefits from rollups don’t mean much to SUAVE and hence cannot justify the high cost. All of these three factors can change (and probably will over time) to tilt that balance in favor. For example, if DA costs go down enough, it doesn’t matter how little security you derive, it will probably be worth it.

Closing words
The main reason why there aren’t a ton of details on how the chain will be secured is that it’s simply not a priority right now.

All of the value creation from SUAVE will come from its innovative transaction types and programmable privacy framework. So we are focusing on getting these right because 1) that’s what will determine much of our future success, and 2) that’s what we’re uniquely good at.

What I particularly liked about your analysis is that, while they all have some pros&cons, there are many viable options for security. Personally, I consider it a solved problem and one where the available options get better every year. So we’re happy to “outsource” that thinking and push it to the future.

7 Likes

Appreciate the thoughtful response!

Initially, I don’t think the economics come out rollup favored, because the security benefits from rollups don’t mean much to SUAVE and hence cannot justify the high cost. All of these three factors can change (and probably will over time) to tilt that balance in favor.

Hence, if we use some form of ETH staking, I think it will realistically use a form of staked ETH or ETH restaking, so it becomes value-additive (not parasitic) to the ecosystem.

Agreed, a rollup likely wouldn’t make sense right this second while being clearly preferable a few years out imo. I.e., if it was launching today something along re-staking lines would be cleaner and sufficient. It’s largely dependent on timing expectation of if/when a potential SUAVE Chain would be launching. I.e., if launch is looking something like a couple years out or so where by then:

  • EIP-4844 parameters have been juiced up further beyond initial spec/transitioning to Danksharding etc. such that DA costs are negligible
  • Rollup is overall more complex/would need to deal with all the issues other rollups are trying to deal with even now in maturing (permissionless proofs, decentralizing sequencers, etc.),. The tech would likely need to be a bit more mature at the time to make sense pursuing it, so as not to distract from the larger priorities of building SUAVE mechanics.

Vs. if launch looks on the earlier side, waiting around for Ethereum/rollup maturation wouldn’t make much sense when something like re-staking would work quite well. Obviously defer on y’all have a much better sense of realistic timelines here.

Rather, we are investigating techniques to minimize the need to bridge funds to SUAVE as a user. In a perfect world, only major searchers/builders will have to maintain a balance and only enough for working capital.

Very interesting! Agree would certainly factor in here.

The main reason why there aren’t a ton of details on how the chain will be secured is that it’s simply not a priority right now.

All of the value creation from SUAVE will come from its innovative transaction types and programmable privacy framework. So we are focusing on getting these right because 1) that’s what will determine much of our future success, and 2) that’s what we’re uniquely good at.

Strongly agreed on priorities! Focusing on the system first then surveying available security/chain options only when feeling more developed seems right, shouldn’t be decided when so much is still in flux. This is just the fun area I can play with thinking on while I eagerly await the more technical details :grin:.

3 Likes

That’s a good summary! :slight_smile: I hope we’ll have more stuff out soon that you can engage with, because I really enjoy this level of discussion.

2 Likes