Skip to main content

Design Goals

We draw on the theoretical goals outlined in "Strategyproof Computing":

1. Incentives-first
2. Utility-based
3. Simple
4. Open
5. Decentralized

and the practical ones which led to the implementation of Serenity:

1. Simplicity
2. Long-term stability
3. Sufficiency
4. Defense in depth
5. Full light-client verifiability

I.

Permissionless

It should be possible for anyone to deploy a smart contract for handling orderflow or building blocks. This is inspired by the "open" principle from Strategyproof computing, which states: "Our belief is that an open marketplace will naturally lead to mechanisms with the 'right scope' and 'right complexity'."

We cannot preempt every kind of MEV that will exist, or the range of methods which can be concocted to extract it. Therefore, we aim to enable anyone, anywhere to create and deploy novel contracts in response to unpredictable needs as and when they arise.

II.

Private

The operation of mechanisms for ordering information and distributing value must be public and verifiable. The data which passes through those mechanisms need not be. Privacy is a human right and, in the context of MEV, it actually enables us to create systems that are more resilient to economic centralization over time, and to malicious manipulation in any given moment.

We must provide people with the ability to keep their data hidden and only reveal it to those whom they trust or wish to interact with.

III.

Sufficient

This is inspired by the Serenity design rationale, which states that it should be "possible to build as many classes of applications as possible on top of the protocol".

We strive for the same generality with SUAVE: it should be possible to use SUAVE to create any kind of application to do with order flow, block building, commitments, instantaneous privacy, any composition of the above, and any other MEV application we have yet to imagine.

IV.

Simple

This is taken from both sources above. Strategyproof computing argues that we ought to "simplify the decisions facing participants in distributed multi-agent systems", and Vitalik points out that simplicity matters "because it (i) minimizes development costs, (ii) reduces risk of unforeseen security issues, and (iii) allows protocol designers to more easily convince users that parameter choices are legitimate".

We value simplicity because it enhances flexibility with respect to our dependencies, such that we can readily upgrade SUAVE nodes from SGX to MPC, or deploy better cryptographic solutions like FHE, or introduce some maximally robust and sufficiently decentralized combination of the above.

V.

Decentralized

It is hard to find the optimal means of allocating resources without centralizing power. Therefore, it is worth doing. We aim for systems that are robust and scalable, beyond the limitations imposed by trusted third parties.

In our ordering here, decentralization is also related to "Defense in depth", though we apply this specifically to the boundary between developing the ideal mechanisms for MEV extraction, and crafting the most powerful means for users to express commitments and privacy preferences. That is, SUAVE should work as well as possible under a variety of security assumptions which sit at the intersection of information theory, computer science, economics, and sociopolitics.

VI.

Fair

This is inspired by Strategyproof computing, which states that, "the self-interest of participants in distributed systems should be explicitly addressed by system designers, much as we currently address issues of fault-tolerance and security."

It should be possible to quantify who benefits, and how much they benefit relative to the average.

We do not mean "who" in the personal sense, but rather in terms of the type of actors involved. Specifically, users should enjoy the majority of the value they create, with the rest of that value cascading down to those doing the most relevant work.