Skip to main content

What to Build on 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.

info

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

Confidential Computation​

These use cases leverage more of the confidential features of builder solidity contracts on SUAVE. They tend to focus more on programmable privacy.

  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. 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, 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.

Credible Computation​

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 is an important idea that we feel has wide applicability.

The Flashbots research team suggests thinking about anti-mechanisms 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.

Social​

  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.
    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.

Gaming​

  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.

Advertising​

  1. Learn what header bidding is first. 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.

  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.”

    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.

    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.

    Just like the gaming example, autobidders could run into serious credibility/vertical-integration concerns if they start getting traction.

Other​

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.

  1. SUAVE Router. Browse through this presentation 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 on SUAVE. Do something intense with it.

  4. Copy and improve upon any ideas the Oasis and Phala 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.”

    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:

    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.
info

Only Flashbots crew and mates will be able to access these links. They'll be removed before public launch

  1. SUAVE core team ideas.
  2. Our research team suggests that interoperability with web2 services may be one key 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.
  4. Ad auctions.