DataQuery-only Version

This is a separate version of the Autonomous Airdrop demo that does not use AxiomREPL.

Introduction

We have a second version of the Autonomous Airdrop demo that sidesteps utilizing AxiomREPL in favor of using only Data Queries. This is in the event that your web stack does not support web workers, which we use in the Compute Query (AxiomREPL) version.

Using the DataQuery-only version is not the recommended flow, but is available for people who know what they are doing and want to use it.

Github Repo

https://github.com/axiom-crypto/autonomous-airdrop-dataquery-example

Differences from version that uses AxiomREPL

There are a few main differences between this version and the version that uses AxiomREPL in the code that should be brought to your attention:

• The web app will call a new claimAirdrop function on the AutonomousAirdrop.sol contract (instead of sending the Query directly to AxiomV2Query)

• The AutonomousAirdrop.sol contract calls a _validateDataQuery function which validates the Data Query before passing it to AxiomV2Query

• The contract emits ClaimAirdropError on error instead of reverting in order to reset the querySubmitted mapping so that a user can try again if there is an error

• The callback's callerAddr is verified to be the AutonomousAirdrop contract itself instead of the user's address (since the user submits the transaction to AutonomousAirdrop.claimAirdrop instead of directly to AxiomV2Query)

Forwarding the calldata to AxiomV2Query

The data that is received in the call comes from the SDK's .build() function that is run on the Query. The payment value is also calculated by the SDK, and the payment amount must be forwarded from the claimAirdrop to AxiomV2Query. Once this is done, the data arrives at Axiom's Prover and a ZK proof is generated, which may take some time. When the proof generation is complete, the Prover calls axiomV2Callback.

Validating the Receipt Subqueries all come from the same transaction

We want to validate that all of the Receipt Subqueries come from the same transaction and that we are just proving different parts of the same Receipt because we want to ensure that a malicious user cannot submit different data. This check may be different depending on what data you want to validate, but the main premise is that you will want to do this validation before the Query is submitted to Axiom.

There is a decoder in the repository that adheres to the encoding as described in Axiom Query Format.

Barebones Scripts

The /scripts folder contains all of the barebones scripts that you will need in order to build and send the transaction to the contract. In order to find the Swap event data that we want, we utilize Covalent's Transaction API (which has stopped indexing Goerli after block 9800000) to allow us to quickly find the relevant data, parse it, and supply it to the Axiom SDK. If you would like to run this specific example, you'll need a free API key from Covalent. The two main files in this /scripts folders are located in /scripts/src.

The first file, parseRecentTx.ts does the heavy lifting of finding a Swap transaction after Goerli block 9000000.

The other important file, index.ts, utilizes the Axiom SDK to append the 3 different Receipt Subqueries for the different data to query. It also appends a the 4th Transaction Subquery to get the to field of the transaction itself.

We go through the steps that are similar to the ones in the Quickstart section, where we create a new Query instance from an Axiom instance, append the Data Subqueries to the Query, validate, build, and calculate the payment amount. After that, we submit the Query to the Autonomous Airdrop contract which runs checks and calls AxiomV2Query with the payload to have it fulfilled by the Axiom Prover.