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]
2 Likes
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”
2 Likes
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.
5 Likes
Suave as a prime brokerage for global blockspace.
2 Likes
Suave as a labour union for users
2 Likes
Suave as an air traffic controller for AGI searchers
2 Likes
Suave as perpetual motion machine
1 Like
Suave as a philosopher’s stone for blockspace
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.
5 Likes
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)
2 Likes
Suave as Uber for X but decentralize and on-chain
suave as the hypervisor for your blockchain’s VM
Suave as https://uniswap.org/whitepaper-uniswapx.pdf (this is literally what I thought this thread was about haha)
1 Like