Suave as X

Half-baked ideas for what could be built on Suave/what Suave role Suave can play


Suave as a Continuous LOB

Users can submit bids Pay (x) to anyone who gets me at least (y) of asset A on domain B|

You can also make the bids more complex like having quantity as a function of price etc.
Also, ideally the payment of (x) happens on B and not on Suave, to simplify capital management.

See Jump’s description of this idea a while ago SLOB: Searcher Limit Order Book

1 Like

Suave as a Frequent Batch Auction:

Similar to the limit order example above except the payment predicate has additional conditions “on domain E, with all trades of type C executing at a uniform price”

[of course, there’s still lots of manipulation that could happen with only this condition such as only including orders going one direction etc. so more thought it required]

1 Like

Suave as a decentralised relay for multisigs:

Multisig sub-transactions need to be combined somehow (for a non-sc multisig).

[Just putting it out there, I assume there’s some DDOS angles etc. I haven’t taken into account - need to look into this a lot more]

1 Like

Suave as a (one-way) bridge

“Pay (x) to whoever gives me (x-\epsilon) on domain B”


Suave as M’:

If M is your original mechanism (e.g. Ethereum) and there is room for strategic action by the executor of M (e.g. validator set) that allows for larger returns, one can use M’ to restrict the actions taken by the executor of M. The question is how do you get the executor in M to obey M’ and what to do about strategic deviations by the executors of M’.

Note: @sxysun calls the inevitable strategic deviations by the executor of M’ “MEV incompleteness”

1 Like

+1 That jump writeup is great.

Anoma actually talks a lot about the LOB use case. It’s not trivial to run orderbook-based protocols on chain so people are forced to create alternatives. Typically this involves two things that are suboptimal: (1) making your own custom signature scheme for the orders and (2) storing and matching the orders off chain. Examples include opensea, dydx/limit orderbooks (though they’re now trying to do more of it on their appchain), even cowswap.

You could think of suave as a solution to both problems – we create single generic order type that you can include any format of payload in, and a decentralized layer for messaging and matching them.


Suave as a prime brokerage for global blockspace.


Suave as a labour union for users

1 Like

Suave as an air traffic controller for AGI searchers


Suave as perpetual motion machine

1 Like

Suave as a philosopher’s stone for blockspace

SUAVE as on-chain task rabbit


SUAVE as the general-purpose chain’s response to app chains

App chains run on the thesis that specific applications will need to be able to modularise the whole stack to suit their needs. SUAVE add programmability to for app designers that extends outside the EVM without having to switch to an app-chain.


I like this a lot.

Can you think of an ABCI++ analogy?

SUAVE is the interface between agents and their preferred blockchain application. This is critical to understanding why SUAVE can give agents better tools for expressing their preferences by inserting those preferences into the block building process with credible commitments.

1 Like

SUAVE as a room-temperature superconductor for blockchains.

(Little known fact: The S in SUAVE actually stands for superconductor)


Suave as Uber for X but decentralize and on-chain

suave as the hypervisor for your blockchain’s VM