Brevis's collaboration with Uniswap is a great example of understanding zkVM. The Uniswap Foundation has allocated $9 million to promote an integration subsidy program for a Uni V4 hook pool. The design of Uni V4 hooks is very different from traditional AMM pools because it is highly customizable, offering developers significant flexibility. However, the downside is that upstream aggregators face considerable difficulty integrating them. If V2 and V3 pools were considered standard, then V4 hooks are non-standard, with each pool having different logic. This means every pool might need to be integrated individually. The solution to this is to use subsidies/incentives to drive the process. Specifically, when a trade is routed by an aggregator to a pool, the trade volume and gas consumption are tracked. Based on this data, subsidies are provided to the aggregator. This is the purpose of the $9 million fund. But who collects, calculates, and ensures the authenticity and verifiability of this data? That’s where Brevis comes in. Here’s how the process works: 1. A user places an order, and the aggregator routes the order to a specific Uniswap V4 Hook Pool, where the trade is executed as usual. 2. Next comes the reward logic. The router extracts the actual transaction records (e.g., a batch of transaction data, gas usage, etc.) for the trades it routed to the V4 Hook Pool over a certain period. But here’s the challenge: how do you prove that these transactions were indeed routed by the aggregator and not falsely reported to claim subsidies? The traditional approach involves centralized bookkeeping and reconciliation, but that’s clearly not crypto-native. Brevis’s role is to handle the computation and verification in this step. Brevis takes the raw on-chain data, gas consumption, and routing target pools, processes all this data off-chain, and generates a zero-knowledge proof to ensure the data’s authenticity and verifiability. Finally, the aggregator uses this “cryptographic reimbursement receipt” to claim the subsidy.