Things You Can Build Now with HyperOracle zkOracles - msfew

For our latest offering, check out our litepaper.

TL;DR

With the upcoming release of the next version of Hyper Oracle, we are proposing more use cases for zkOracles and zkGraphs, besides the ones we have already shared.
Focusing on trustless historical data access via a zkOracle, we propose 10+ related use cases.
By analyzing some of the innovative ideas, we can implement some of the otherwise impossible ideas with zkOracles and zkGraphs.
For the emerging ecosystem of Uniswap Hooks, we list some use cases where you can use a zkOracle to power Uniswap Hooks, or build a zkDApp powered by both a zkOracle and Uniswap Hooks.
More information and updates from the Hyper Oracle ecosystem and new ideas can be found at awesome-hyper-oracle.

0. Introduction

Hyper Oracle is a programmable zkOracle protocol. We aim to unlock historical data access and complex compute for smart contracts in a trustless and secure way.

A zkOracle provides expansive compute for smart contracts. Any DApp that uses zkOracle in their architecture is a zkDApp that has more potential than a traditional DApp.

To program a zkOracle, you can write code in a zkGraph (a piece of code for custom logic) to define your own “API”. Also, we provide zkGraph Standards, including zkAutomation, so you can use it as a template to power your smart contract to achieve the ability of end-to-end trustless automation.

In our last post, we talked about some zkDApps (DApp with a zkOracle) you can build with Hyper Oracle.

In this post, we'll look at some more potential use cases, including some new ones based on historical state / storage data, some that others imagined but can't be achieved without a zkOracle, and some of the newest ones that incorporate Uniswap Hooks.

1. zkDApps with Historical Data

Smart contracts have access to the latest blockchain data, while access to historical data requires other means. In order to guarantee the integrity of the data (“Etherscan misses nearly 15% of what are called ‘appearances’ ”), as well as the reliability of the service, we need a trustless protocol to guarantee the access of verifiable data.

Hyper Oracle unlocks historical state / storage data access in addition to historical receipt (event) data access. This means that with a zkOracle, developers can trustlessly give smart contracts access to all core data of Ethereum.

Why do we need historical data? There are many scenarios in which historical data is necessary:

The most recent data is hidden: In the case of Safe’s "shadow" owners, for example, the only way to get the data you want is to go back in time, and just using a smart contract won’t get you there.
The most recent data has been changed (or, your application is based on data at a specific time): For example, an NFT has changed its owner several times, and you need to prove that you used to own it.

We've come up with a number of ideas for you that can be built using trustless historical data. We'll list them in the Proof of X form (since all data access and compute in a zkOracle generates a ZKP!), and describe the scenarios in which they can be used.

Here’s a table summarizing the following contents:

a) On Fungible Token: Proof of Voting Power / Whale / Approved / Vesting

For a fungible token such as an ERC-20, we can use historical data to make the applications based on it more data-rich.

Using $UNI as an example, we could implement:

Proof of Voting Power: Determine the voting power of an address by obtaining specific historical data from UNI's checkpoints.
Proof of Whale: By accessing historical data from UNI's balances, we can spot past whale at any given time, even if the address has already dumped all holdings.
Proof of Approved: By accessing historical data from UNI's allowances, we can gain even deeper insights with Total Value Approved and its changes, just like what we have in Total Value Locked.
Proof of Vesting: Just like vc-vest, we can, in a trustless way, query historical data of a token’s vesting status, and determine if the vesting schedule is performed in a correct way.

With other tokens such as $USDC, you can even build Proof of Blacklist with USDC’s blacklisted to achieve compliance needs.

b) On NFT: Proof of Ownership / Mint

In addition to hosting digital collectibles, NFTs are often used as unique identifiers in scenarios such as membership verification and token-gated communities.

Taking Azuki as an example, we could implement:

Proof of Ownership: By accessing historical data from Azuki’s ownerships, we can retrieve all owner histories to see who has owned Azuki in the past.
Proof of Mint: In addition to ownerships address access, we can access the startTimestamp of Azuki NFT ownership to check if this NFT is minted by an address through a zkGraph computation. This identifies the true long-term NFT community member.

Typical applications for this scenario are NFT-related applications and various NFT membership or NFT ticketing applications that bring mass adoption.

c) On Trading: Proof of Credit / Degen

The first step before starting a transaction is to check the user's risk tolerance and credit rating. In many cases, this is done through centralized solutions, but with a zkOracle, we can implement trustless and onchain verifiable versions.

Proof of Credit: We implemented a system to examine an account’s bad debt in Marine. By obtaining more data from an account within a DeFi protocol and performing complex calculations in a zkGraph, it is possible to realize an onchain verifiable credit report.
Proof of Degen: Similar to DegenScore, We can build an onchain verifiable degen score by getting historical data to determine if an account has enough risk tolerance ability. We can get the account's transaction history for a memecoin via historical event, and the account's current holdings via ERC-20’s balances.

Applications for this would be DeFi protocols, as well as other trading-related applications such as exchanges.

d) On L2: Proof of TVL / Downtime / Council

L2 Rollup contracts on Ethereum can also be taken as examples. Like the Onchain L2Beat, which we talked about in a previous post, we can extend its functionality with the help of historical state data.

Proof of TVL: The historical TVL and its changes can be obtained from a rollup’s bridge contract’s data.
Proof of Downtime / Liveness: A rollup typically keeps submitting the latest state, publishing data, and verifying proofs on the L1. In the case of Scroll, for example, we can get all the historical data and analyze which L1 blocks have no commitBatch or finalizeBatchWithProof events to know if the rollup has any downtime.
Proof of Council: Rollups usually have a council that manages the security upgrades of L1 contracts. In the case of Arbitrum, for example, we can get the historical council members by querying Arbitrum’s owners. In this way, we can find out whether the council is always operating in a reasonable manner.

Overall, with these additional features, our "onchain verifiable L2Beat" can be upgraded to a watchtower for an L2, and all computation and data is trustless.

e) On Airdrop: Proof of OG

An airdrop cannot be performed without access to historical data. A zkOracle provides access to all the relevant data.

Proof of OG: The identity of an OG can be proved in a variety of ways: as an NFT holder, as an early user of a contract, or as an early holder of a token. These can be accessed through a zkOracle.

f) On MEV: Proof of Sandwiched

For MEV a zkOracle can provide more data and more compute, as well as for related use cases.

Proof of Sandwich: Sandwiching is a very common MEV behavior. By obtaining historical event data, we can prove that a user's behavior such as Swap has been harmed by an MEV bot, and thus compensate the account, just like MEVictim Rebate, or punish the attacker.

These are just a dozen of use cases we came up with using historical data and trustless compute. I'm sure as a developer, you'll probably come up with some more interesting applications building with zkOracles!

2. zkDApps that Make the Impossible Possible

Before the advent of more data with zkOracles, and more compute with zkGraphs, there was no way for developers to implement many creative projects in a trustless manner.

In this section, we will pick some ideas from the following, and share some solutions to realize these projects that were not possible before, thus demonstrating the capabilities of zkOracles and zkGraphs. Ideas come from:

a) Vault for arbing withdrawals on L2 bridges

TLDR: Automated arbitrage through optimistic L2 bridges.

The difficulty of this project is mainly automation and security. We can use zkGraph for programmability, and zkAutomation for automation. At the same time, all operations are guaranteed to be computationally integrity by ZK.

With the programmability of zkOracles, we are able to realize this idea.

b) Very low gas DEX

TLDR: Aggregate tiny trades, for a cheaper DEX.

One of the advantages of zkOracles is that almost all of the computation overhead ends up being an O(1) verified ZKP on the L1. Therefore, zkOracles can be used to aggregate tiny trades and settle them onchain through zkAutomation, just like a zk rollup. At the same time, the cost of these processes is only the ZKP verification cost, and security is fully guaranteed by ZK.

We have built a similar project: zkAMM. It requires only a few additional components to realize a zkGraph-driven "DEX as a zk rollup" aka “very low gas DEX”.

c) L2 – L2 transfer using Proof of Burn

TLDR: User burns tokens on L2 A, and posts the proof of burn on L2 B for bridging.

zkGraph can use data from different blockchain networks as dataSource and dataDestination. The flow of this application is as follows:

user triggers a bridge operation on an L2 A contract, burn ->
zkOracle fetches the data, and calculates it in zkGraph ->
zkGraph uses zkAutomation to settle the bridge operation on the L2 B contract, and at the same time provides ZKP of Burn ->
bridge completed

This project would be a great hands-on application to familiarize yourself with the whole zkOracle, zkGraph and zkAutomation process.

d) Automated risk scoring of lending borrowing pools

TLDR: A combination of credit score of an account, and bad debt scoring of a pool.

In our liquidation keeper Marine, we have shown how to build a basic credit score for users. We can realize the full idea by upgrading the existing version within three incremental dimensions:

More Protocols: We need more records of a user's interactions with the DeFi protocol as well as a credit history, in order to realize a richer user history.
More Users: We need to take a pool as the core and analyze its associated users to determine the overall health of the pool.
More Compute: For the above two upgrades, we need to perform complex computations using zkGraph, and add various coefficients to finalize a risk score.

This project will be the cornerstone of DeFi 3.0. It will not only use more data from zkOracles; it will also use more compute from zkGraphs.

e) Better Wallets

TLDR: A multi-chain friendly wallet that can intent solvers/broadly everything apps.

The core idea of a better wallet is to make every EOA address a smart contract address. The next generation of wallets are smart contract wallets.

With the help of zkOracles, a better wallet would be a smart contract plus a zkGraph. Because a smart contract is not enough for multi-chain access, cross-chain bridging, and massive computation.

What you can programmably achieve with a zkGraph includes the following:

Use USDC to pay for gas in all chains
Fast aggregation of assets across all chains
Automatically freeze address when hacked

These are some of the top picks for "impossible ideas" and how to make them possible with zkOracles. You can also take a look at some of the other ideas in there, and I'm sure zkOracles will help to realize them in a trustless manner, fueling the next wave of zkDApps.

3. zkDApps with Uniswap Hooks

Uniswap Hooks is one of the hottest ecosystems in recent times. Developers have been building a lot of hook-based applications even before Uniswap v4 was deployed.

Hyper Oracle has also started the awesome-uniswap-hooks repository, which documents many of the projects in the Uniswap Hooks ecosystem as well as cutting-edge research.

There are also many opportunities for integrations and convergence between zkOracles and hooks. We've already seen a number of applications of zkOracles with hooks, for example:

Privacy preserving compliance DEX
Data-driven DEX
Rebate by hook for MEV victims

a) Two Types of zkDApps with Uniswap Hooks

There are actually two types of zkOracle integrations with Uniswap Hooks:

zkOracle powering Uniswap Hooks: a zkOracle brings more data and more compute to make Uniswap Hooks more powerful.
zkOracle and Uniswap Hooks together powering DApp: a zkOracle brings more data and more compute, together with the functionality of Uniswap Hooks, they make a DApp more powerful.

b) zkOracle-Powered Uniswap Hook

A zkOracle is able to provide Uniswap with more data with historical data access as well as more compute via its zkVM. In both cases, we can build some very innovative applications.

More Data

Historical data can extend the capabilities of various onchain oracles, giving them access to past data and allowing them to realize advantages such as stabler prices.

TWAMM: The historical data allows a TWAMM to fetch prices from more blocks without caching.
Truncated Oracle: Also more pricing data on more pools.

More data can also be used to help realize various historical data related applications.

NFT Owners Only: Use historical data to get the time of NFT ownership of an account to improve this hook.

More Compute

You can also enhance the computation of Uniswap Hooks with zkGraph. In the following examples, the Uniswap Hooks need to handle much computation or require automation.

Automated Buyback: This hook enables automated token buybacks from their treasury when the price drops below a target threshold in a Uniswap Pool. Expanding on this, you could implement an automated trading bot (someone in the Hyper Oracle ecosystem is building this). Then you might need to use more complex trading logic, rather than just buying at a specific value. For example, use the compute of zkGraph to run a quantitative trading logic, or even machine learning based trading.
New York Trading Hours: This hook allows the Uniswap Pool to trade only when the NYSE is open. Imagine if you need to extend this to more scenarios: Asian trading hours, or European trading hours, then it would require more compute. Also for special cases, such as Chinese trading hours that take into account lunar holidays and compensated day offs, you would need to automatically submit the relevant changes every year. You can do this by using zkGraph, and by using zkAutomation to automatically update the parameters.
I’m Feeling Lucky with Uniswap: First use a zkOracle to provide a verifiable random number, then use beforeSwap hook to leverage some of the user funds to purchase a small portion of a random memecoin for them.

Both

Of course, you can use both historical data and zkVM compute.

We won't give you a specific example, but a similar application could be built using the following architecture. In the beforeX hooks of your application, you can verify the proofs generated by the zkOracle, and then do the rest.

The workflow would be:

zkOracle computes and generates proof
beforeX hook verifies the zkp
Further onchain interaction happens

c) zkOracle-and-Uniswap-Hook-Powered DApps

When a DApp uses both a zkOracle and a Uniswap Hook, it means that any kind of application can already be implemented.

A zkOracle brings onchain verifiable historical data access and unlimited compute, while a Uniswap Hook brings onchain native programmability and flexibility to any token and transaction related operations.

With the zkOracle and the Uniswap Hook, your application is completely free from any limitations of your imagination. Here are some interesting use cases I can think of.

Dark Forest Rank: Using a zkOracle to get the full history and operations of a contract or account, and then analyzing it with a zkGraph to generate a ranking of all contracts and accounts (value, trade profit, MEV profit). This data can be used in other application scenarios such as trading or DAOs. A Uniswap Hook can be used to rank and categorize a population, e.g. the top 100 people in terms of value cannot trade certain tokens in order to ensure fairness and prevent the Matthew effect.

4. Outro

Whether it's a zkDApp with historical data, a zkDApp making the impossible possible, or a zkDApp with Uniswap Hooks, you can use a zkOracle to augment your smart contracts and applications:

More complex computational power that can be verified onchain
Access to more historical data or multiple data sources
The ability to perform automation for rich interactions

The newest applications we present here are just the tip of the ecosystem iceberg. Stay tuned for more interesting applications in the future.

Share your ideas and tag us on Twitter or Discord. Come build with us!

About Hyper Oracle

Hyper Oracle is a programmable zkOracle protocol that powers smart contracts with arbitrary compute and richer data sources. Hyper Oracle offers full security and decentralization for trustless automation and onchain AI/ML so builders can easily create next-gen dApps.

hyperoracle.io | x.com/hyperoracle | github.com/hyperoracle