Skip to content

Commit

Permalink
Sprucen up use cases (#41)
Browse files Browse the repository at this point in the history 
* sprucen up use cases

* attned to comments

---------

Co-authored-by: andytudhope <[email protected]>
  • Loading branch information
@dmarzzz @andytudhope
dmarzzz and andytudhope authored Nov 6, 2023
1 parent db5febd commit e06b527
Showing 1 changed file with 83 additions and 47 deletions.
130 changes: 83 additions & 47 deletions docs/novel-use-cases.mdx
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: What to Build
description: An up-to-date list of ideas it might be interesting to build on SUAVE
description: An up-to-date list of ideas that might be interesting to build on SUAVE
keywords:
- key
- concepts
Expand All @@ -9,82 +9,118 @@ keywords:
- ideas
---

# What to Build on SUAVE
# 🏗️ What to Build on SUAVE

A good way to generate value is to design an app that is uniquely enabled by SUAVE.
A good way to generate value is to design an app that is **uniquely enabled by SUAVE** ✨.

Computation on SUAVE can be done in ways that are both **confidential** and **credible**. Lots of SUAPPs will leverage both of these features in different ways.
SUAVE exhibits three key differences from existing blockchains:

:::info
1. Faster block time (than Eth L1) ⏱️
2. Programmable privacy 🔒
3. Credible offchain computation 💻

The categories on this page are deliberately broad. SUAPPs can make use of any, or all, of SUAVE's unique features. Do not feel that you need to stick to our suggestions or ways of categorising use cases
## Categories

:::
In present-day Ethereum, there are many centralized services used to coordinate and mitigate the effects of MEV. Most of the categories below are based on these existing services:

## Confidential Computation
- [🔄 OFAs](#-ofa-order-flow-auctions)
- [🔍 Searchers](#-searchers)
- [🧮 Solvers](#-solvers)
- [📢 RFQ](#-rfq-request-for-quote)
- [🎯 Intents](#-intents)
- [🌊 AMMs](#-amms-automated-market-makers)
- [🖼️ Auctions](#-auctions)
- [💸 PFOF](#-pfof-payment-for-order-flow)
- [🛠️ Block Builders](#-block-builders)
- [📅 Rollup Scheduler](#-rollup-scheduler)
- [🧩 Blob Merger](#-blob-merger)

These use cases leverage more of the confidential features of builder solidity contracts on SUAVE. They tend to focus more on *programmable privacy*.
SUAVE also enables new and unique decentralized application paradigms.

1. Liquidations based on sensitive information, like ZK Collateral. Check someone’s ZK Credential of some kind (twitter account, etc.) and keep it in SUAVE [Confidential Data Storage](/technical/specs/rigil/confidential-data-store). Let other people bid on revealing it, or reveal it in case of undercollateralization.
1. Not directly related, but revealing information in the case of "bad behaviour" has wide applicability, the most interesting of which is likely [Rate Limiting Nullifiers](https://vac.dev/publications), which could be useful for the SUAVE chain design itself.
2. Escalating fee auctions. Basically, write a contract that takes orders which are partially filled, and raises the fee offered over time according to a fixed strategy. The entire curve doesn’t have to be revealed, only a short time window of the next offered price.
3. A telegram bot which keeps keys in SGX, rather than just some random escrow.
- [🌐 Social](#-social)
- [🎮 Gaming](#-gaming)


## Credible Computation
### 🔄 OFA (Order Flow Auctions)

These use cases leverage SUAVE more as a coordination layer for things happening in other domains (i.e. other chains or just elsewhere on the web). [Credible computation](https://hackmd.io/@sxysun/ccdwtf) is an important idea that we feel has wide applicability.
Order Flow Auctions (OFAs) are responsible for taking in a transaction or intent and routing it somewhere, either based on predefined logic, an auction, or by introspecting the transaction or intent.

The Flashbots research team suggests thinking about [anti-mechanisms](https://www.youtube.com/watch?v=5v_wBkrIJhs) for web2 services as a fun, productive use of DarkDAOs. That is, instead of building collusion rings to buy votes, we can build collusion rings to allow permissionless interaction with web2.
- [MEV-Share](https://github.com/flashbots/mev-share) 🔄
- [MEV-Blocker](https://mevblocker.io/) 🛑
- MEV-Share+
- Dynamic refund: currently, users set their own refund percent, but depending on the state of the mempool and blockspace auction, they may want a lower or higher refund percent. A SUAPP could simulate a user's trade, query L1 state to get pool and token information, and use this to reason about what refund % to use on that user’s bundle.
- Dynamic hint: one of the open research questions around programmable privacy is where the privacy efficiency lies. An example of this, relevant to MEV-Share, is as follows: given a Uniswap L1 trade, how much information should be revealed? A $10 trade most likely can leak the entire trade details because it would be better to batch, but a very large trade has a risk of being probabilistically front-run; therefore, it should leak less information, or at least that is one possibility.
- Batching user trades and back-runs together.
In all these cases, a SUAPP could simulate a user's trade, query L1 state to get pool and token information, and use this to reason about what refund % to use on that user’s bundle.

### Social
### 🔍 Searchers

1. Bribe Twitter accounts to post certain tweets in certain time periods. Check results and post to chain with an oracle. Hide what the content the account was bribed to say was using [Confidential Data Storage](/technical/specs/rigil/confidential-data-store).
1. In friend.tech you can promise to give out the twitter ads revenue share to your key holders (ofc this has serious legal concerns etc, but as an example it’s cool). Your twitter ads revenue is calculatable using the public API, so if we could do an oracle from twitter to on-chain, then it is possible to build a (smart) contract that queries the API ~once per day and checks if the account holder pays out to the key holders in 7 days and if not slashes some stake.
Take an existing searcher bot design, write it in Solidity, and put it on-chain! Simple strategies will be more effective with the current state of the network and can take advantage of the `sendBundle` precompile to send bundles to centralized block builders.

### Gaming
### 🧮 Solvers

1. For games like Sid Meier’s _Civilization_, build an on-chain oracle that takes game state as input, and then let players to sign contracts that enable them to negotiate with each other in expressive ways, e.g., “I want to borrow your units in this continent for X turns and in exchange I’ll commit to taking your future contracts of Y.” In this way, you can directly build mods (specifically, mods around incentives/contracts/commitments) into existing games without having to build a new game, so you don’t have a cold-start problem. Those mods tend to be the most monetizable ones anyway.
Solvers are responsible for finding mathematically optimal solutions in combinatorially large solution spaces, usually framed as finding optimal routes through multiple liquidity pools or in matching coincidences-of-wants. Solvers can be implemented in Solidity and operate on order flow and intents submitted by users to SUAVE.
- [CoWSwap Solver Example](https://github.com/cowprotocol/services/tree/main/crates/solver) 🧩

### Advertising
### 📢 RFQ (Request for Quote)

1. Learn what [header bidding is first](https://digiday.com/media/wtf-header-bidding/). Then, create a snippet/plugin that websites can integrate in their frontend so whenever a user visits the website, the data is sent to multiple auction houses/ad publishers, who then participate in an auction. In our case, the website owner would send the CCR to the auction contract, specifying some Kettle(s) and then the off-chain components do the actual auction and return the winning bid. The latency requirements are brutal (sub 1 ms level) but we discussed internally and agreed that it’s not impossible.
RFQs, or Requests for Quote, are off-chain services that take a user's ask, broadcast it to a network of market makers, and respond with the best price. A SUAPP could do this in two ways:

2. Currently 80% of google ads and 100% of microsoft ads goes through autobidders: algorithms that help to elicit and constantly express advertiser preferences like: “I want to show my ad to as many junior tech professionals in Colorado as possible for $1,000” but not indicate the value per individual.”
1. Use an HTTP post precompile to send to a list of market makers, or
2. Accept a curve of prices a market maker is willing to fill at and automatically respond on their behalf.

The market structure is similar to the block building market in Ethereum: sophisticated advertisers develop their own autobidding algorithms instead of using the auctioneer’s provided autobidders (albeit the reasoning could be just more fine-grained control over preferences rather than “private orderflow”). And that the autobidding/advertiser platform/auctions/publisher platform teams have their offices “split up by literal walls” despite them working on the same floor to prevent collusion.
The second option changes the nature of RFQs, as market makers would not need to continuously update new pricing curves.

Without privacy one cannot build an autobidder, as strategic behavior would just rekt the service (you can manipulate behavior of other people’s bidding agents/algorithms by misreporting your preferences), so we want advertisers to report their preferences to some builder solidity contract, which does aggregation and bids in the header-bidding ad auction in real-time.
### 🎯 Intents

Just like the gaming example, autobidders could run into serious credibility/vertical-integration concerns if they start getting traction.
Intents refer to “what” the desired outcome of an action on a blockchain should be as opposed to transactions which specify “how” an action should be performed. Intents and Solvers work together very closely as some solvers aggregate intents in order to maximize user welfare under various definitions. In order to support these functionalities on SUAVE, you can help deploy various intent formats!

## Other
- [ERC-7521](https://github.com/essential-contributions/EIPs/blob/master/EIPS/eip-7521.md?ref=blog.essential.builders) 🔗
- [ERC-4337: UserOps](https://github.com/eth-infinitism/account-abstraction) 🔏

These use cases either mix both of the above categories, or present another kind of idea that doesn't fit into either of the above.
### 🌊 AMMs (Automated Market Makers)

1. SUAVE Router. [Browse through this presentation](https://docs.google.com/presentation/d/19km1xqXrp6HClAOmyUwtq7lADM7BEUsPbTUE7zCwhCw/edit#slide=id.g2923336d3ff_0_569) to get an overview of the idea.
2. Deadman switch. A contract that posts a message on the L1 if it doesn’t get (stealth) heartbeats.
3. Deploy [intents](https://blog.essential.builders/introducing-erc-7521-generalized-intents/) on SUAVE. Do something intense with it.
4. Copy and improve upon any ideas the [Oasis](https://oasisprotocol.org/p4w3-hackathon) and [Phala](https://github.com/Phala-Network/amsterDOT-2022) hackathons.
5. Ticketmasters sell things like Taylor Swift concert tickets. Currently, their UX is basically “click the frontend, wait 10mins, and then find out you didn’t get the ticket.”
The ability for SUAVE to emit transactions and perform off-chain and confidential compute opens numerous doors for AMM designs.

An application for this would be similar to ad auctions, but the latency requirements are not as brutal, and can be relaxed to perhaps even a few minutes. The basic idea:
- More expressive liquidity management 🌊
- Private liquidity 🔐
- UniV4 hook integrations 🔗

1. Deploy NFT contract on ETH L1. Accepts face value of tickets in ETH.
2. Once I have sent face value of ticket to NFT contract, I send my real, confidential bid to the Bid contract on SUAVE. This is just a number.
3. Bid contract calculates set of winning bids once auction is over. Emits this as bundle (or sends it to builder via precompile).
4. NFT contract on ETH L1 receives winners, loops through them, checks they have the balance they bid. If so, send NFT. If not, skip (and keep their face value ETH as penalty). Does this over a period of blocks to avoid flash loan vulnerability.
### 🖼️ Auctions

Auctions, and mechanism design more broadly, can encompass most of the ideas on this page. But some specific interesting auction ideas include:
- Private NFT auction 🖼️
- Combinatorial Auction 🤝
- Dutch Auctions - Fee escalators could be one example that are especially interesting combined with a programmable information leakage model like MEV-Share.
- Ad Auctions - [Learn about header bidding first](ttps://digiday.com/media/wtf-header-bidding/). Then, create a snippet/plugin that websites can integrate into their frontend so whenever a user visits the website, the data is sent to multiple auction houses/ad publishers, who then participate in an auction. In our case, the website owner would send the CCR to the auction contract, specifying some Kettle(s), and then the off-chain components do the actual auction and return the winning bid.

## Flashbots Links

:::info
### 💸 PFOF (Payment for Order Flow)

Only Flashbots crew and mates will be able to access these links. They'll be removed before public launch
Design a SUAPP where wallets can forward order flow to and bulk auction off the transactions to searchers and market-makers.

:::
### 🛠️ Block Builders

There is a vast amount of builder algorithms live in the current Ethereum blockspace market; any of these can be implemented on SUAVE. Additional precompile support may be needed for more advanced functionality but can be merged relatively fast.

### 📅 Rollup Scheduler

Rollups (L2s) have the challenge of posting data batches to L1, increased posting frequency increases security and UX but increases costs, less frequent posting is cheaper, but comes at the cost of UX. A Roll up post scheduler would be a SUAPP where each roll up submits their preference for when batches are uploaded and then stream batches to scheduler whenever ready. The scheduler will find optimal posting schedule for all preferences and post to base layer on each roll ups behalf.

### 🧩 Blob Merger

In EIP 4844, each blob transaction can have a blob of a max size 128kb and blocks can have 4 blob txns. This means:

- given block with constant `BLOB_MAX_SIZE` = 128kb and `NUM_BLOBS_PER_BLOCK` = 2
- and 4 blob transactions w/ sizes: 100 kb, 100kb, 25kb, 25kb

we could never reach the optimal outcome (higher throughput) of all blobs being included. This is because the 100kb blobs will be leaving 28kb of space on the table, which the other two blobs could fit into. This is similar to the relation between the current gas limit and “regular” transactions in Ethereum, except in the data gas market case you’re only allowed two transactions and each transaction is storing temporary data, not initiating complex contract interaction. Luckily, [EIP4844 Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) use [BLS12-381](https://electriccoin.co/blog/new-snark-curve/) which can be easily aggregated. This is what a "Blob Merger" would do.

### 🌐 Social

Incentivize Twitter accounts to post certain tweets in specific time periods. Check results and post to chain with an oracle. Hide the content the account was incentivized to say using Confidential Data Storage 🐦.

### 🎮 Gaming

In games like Sid Meier’s Civilization, etc., you build an on-chain oracle that takes game state as input, and then you can allow players to sign (smart) contracts that let them negotiate with each other in a super expressive way, e.g., you can now say “I want to borrow your units on this continent for X turns and in exchange, I’ll commit to taking your future contracts of Y.” In this way, you can directly build mods (and specifically, mods around incentives/contracts/commitments) into existing games without having to build a new game, so you don’t have a cold-start problem and those mods are the most monetizable ones anyway 🎲.

1. [SUAVE core team ideas](https://www.notion.so/flashbots/Hackathon-Ideas-beed49f0eb0a46c38466b39afb40f372).
2. Our research team suggests that [interoperability with web2 services may be one key](https://www.notion.so/flashbots/Concrete-Ideas-On-Novel-SUAPPs-b6857caf58b94eaebf1852317594a219) to novel SUAPP design, given that these use cases have a big total addressable market (TAM), and no cold-start problem.
3. [Andrew's shitposts](https://flashbots.notion.site/flashbots/SuApp-shitposts-f404c62d046545c2ae256a0ea8e6f2cd).
4. [Ad auctions](https://www.notion.so/flashbots/Ad-Auctions-3e6c7ca6b93a41f484cd64510cb9619b).

0 comments on commit e06b527

Please sign in to comment.