The notion of "put everything onchain" has always felt like a weird hill to die on for me. There was no reason to put a lot of things onchain because outside of permanent storage, there wasn't much you could do with this data. While The Graph and similar protocols enable the querying of onchain data for front-end integration, complete with features like full-text search and filtering via GraphQL, these operations occur at the client level. This means you couldn't actually use any of this data at the smart contract level to write out logic based on this data. This limitation has led to web3 applications feeling flat and one-dimensional- the only data they can leverage at the smart contract level is a limited subset of real-time data relating to the user interacting with the contract. We can now access things like the account balance, current block number, etc.

Traditional applications have thrived by leveraging user online activity to curate personalized and immersive experiences. Unfortunately, web3 experiences have not been able to nail this, significantly contributing to the prevailing perception that web3 struggles to deliver meaningful applications that resonate with users.

Prominent applications that have shaped the digital landscape—Instagram, TikTok, Spotify, YouTube—excel in presenting users' past activities within their user interfaces and utilizing this data to formulate recommendation algorithms, deliver personalized advertisements, and connect users with creators that match their preferences. This dynamic design space is noticeably absent within web3.

We haven’t been able to do this in web3 because we haven't had the tools to access onchain data at the smart contract level trustlessly. Although it may be surprising, smart contracts don't have a way to read data from an archive node— information such as historical NFT ownership or account balances at specific block heights—and employ this data to drive conditional logic within their operations. There is a spectrum of options that allow this type of data to be accessed in smart contracts with varying tradeoffs in security and cost:

• Developers running the app put data on-chain in a fully trusted manner via EOA or multisig

• Chainlink supports the specific data type you want

• You cache the data in your contract (paying for additional contract storage)

In recent months, the emergence of several high-performance ZK teams has heralded a new era of possibilities for the Ethereum ecosystem. Among these is Axiom, a zk project poised to address the challenge of lackluster web3 applications arising from the lack of trustless data access & compute. Axiom is the first coprocessor scaling data-rich applications, and an alpha version is live on Ethereum mainnet today.

Developers can submit queries to Axiom to trustlessly access any block header, account, or storage value from the entire history of Ethereum using storage proofs. Axiom uses zk to generate validity proofs for all query results and verifies them onchain, meaning that for the first time any smart contract can directly operate on these results with no additional trust assumptions.

Axiom abstracts away much of the zk-specific, moon-math-ish knowledge that has historically been required to work with zk. The most exciting thing about Axiom is that it allows developers to write their smart contracts in Solidity, and they get verified proofs onchain by making a query to Axiom's contract then developers verify the response they got back and use this data in their own smart contract.

Axiom provides developers with TS SDK and their AxiomV1Query smart contract, letting developers create and submit queries onchain and then use the verified response in their smart contracts.

This is what the interaction looks like:

1. Send an on-chain query: a query using the Axiom SDK and submit it on-chain to the AxiomV1Query smart contract.

2. Wait for query fulfillment: An off-chain prover will index the query, produce the query result, and prove its validity in ZK. The proof is verified on-chain, and the result is written to AxiomV1Query contract storage in a Merkle-ized form.

3. Read query results: Once a result has been verified on-chain, use the SDK to fetch query results from contract storage and use them trustlessly in your smart contract application.

In my mental model, there are two main components to use Axiom:

1. Building and sending the query to the Axiom smart contract.

2. Reading and verifying the response from the Axiom smart contract in your own smart contract.

The first step is to send a query to Axiom's contract from a Node/Nextjs project using the TS SDK:

Developers can create and send their query using four methods:

• newQueryBuilder - Creates a new instance of a query

• append - Pass in the address, storage slot, and/or block number that you want to prove

• build - Obtain the keccakQueryResponse and serialized query

• sendQuery - Sends the query onchain to the AxiomV1Query contract

Reading and verifying response

Once the Prover generates the ZK proof, it will write that the `keccakQueryResponse` for that query has been fulfilled, and an event `QueryFulfilled` will be emitted. Developers read the response from Axiom's contract storage and verify the results onchain using these SDK methods:

- getValidationWitness - Allows a user to prove that their claimed data is actually committed to in keccakQueryResponse

- areResponsesValid - checks the data you provided against that hash stored onchain.

Once you've validated that the responses are valid, you can pass this response as an argument to any smart contract function that will restrict actions to accounts that go through this process and pass in a valid and verified proof to the function call.

Not only can you now generate storage proofs and use them to write the logic in your smart contract to gate actions based on historical onchain activity, but for the first time, you can use this historical data to create rich experiences akin to those in web2.

As more users, activity, and data start to come onchain, tools like Axiom will be key for creating rich user experiences without compromising security.

Some project inspo, taken from an Axiom blog post:

• Autonomous airdrops to reward protocol users for on-chain activity via smart contracts without a centralized authority.

• On-chain loyalty systems based on trustless engagement scores.

• Solver-based DeFi protocols which use provable off-chain solvers to settle markets.

• NFT transacted floor price oracles to power underwriting for NFT lending and derivatives.

• A randomness oracle leveraging consensus-level randomness from the beacon chain.

• A trustless volatility oracle used to adjust fees in an AMM or LTVs in a lending protocol.

• Generative NFTs proven in ZK to be generated from the claimed algorithm.

The notion of "put everything onchain" has always felt like a weird hill to die on for me. There was no reason to put a lot of things onchain because outside of permanent storage, there wasn't much you could do with this data. While The Graph and similar protocols enable the querying of onchain data for front-end integration, complete with features like full-text search and filtering via GraphQL, these operations occur at the client level. This means you couldn't actually use any of this data at the smart contract level to write out logic based on this data. This limitation has led to web3 applications feeling flat and one-dimensional- the only data they can leverage at the smart contract level is a limited subset of real-time data relating to the user interacting with the contract. We can now access things like the account balance, current block number, etc.

Traditional applications have thrived by leveraging user online activity to curate personalized and immersive experiences. Unfortunately, web3 experiences have not been able to nail this, significantly contributing to the prevailing perception that web3 struggles to deliver meaningful applications that resonate with users.

Prominent applications that have shaped the digital landscape—Instagram, TikTok, Spotify, YouTube—excel in presenting users' past activities within their user interfaces and utilizing this data to formulate recommendation algorithms, deliver personalized advertisements, and connect users with creators that match their preferences. This dynamic design space is noticeably absent within web3.

We haven’t been able to do this in web3 because we haven't had the tools to access onchain data at the smart contract level trustlessly. Although it may be surprising, smart contracts don't have a way to read data from an archive node— information such as historical NFT ownership or account balances at specific block heights—and employ this data to drive conditional logic within their operations. There is a spectrum of options that allow this type of data to be accessed in smart contracts with varying tradeoffs in security and cost:

• Developers running the app put data on-chain in a fully trusted manner via EOA or multisig

• Chainlink supports the specific data type you want

• You cache the data in your contract (paying for additional contract storage)

In recent months, the emergence of several high-performance ZK teams has heralded a new era of possibilities for the Ethereum ecosystem. Among these is Axiom, a zk project poised to address the challenge of lackluster web3 applications arising from the lack of trustless data access & compute. Axiom is the first coprocessor scaling data-rich applications, and an alpha version is live on Ethereum mainnet today.

Developers can submit queries to Axiom to trustlessly access any block header, account, or storage value from the entire history of Ethereum using storage proofs. Axiom uses zk to generate validity proofs for all query results and verifies them onchain, meaning that for the first time any smart contract can directly operate on these results with no additional trust assumptions.

Axiom abstracts away much of the zk-specific, moon-math-ish knowledge that has historically been required to work with zk. The most exciting thing about Axiom is that it allows developers to write their smart contracts in Solidity, and they get verified proofs onchain by making a query to Axiom's contract then developers verify the response they got back and use this data in their own smart contract.

Axiom provides developers with TS SDK and their AxiomV1Query smart contract, letting developers create and submit queries onchain and then use the verified response in their smart contracts.

This is what the interaction looks like:

1. Send an on-chain query: a query using the Axiom SDK and submit it on-chain to the AxiomV1Query smart contract.

2. Wait for query fulfillment: An off-chain prover will index the query, produce the query result, and prove its validity in ZK. The proof is verified on-chain, and the result is written to AxiomV1Query contract storage in a Merkle-ized form.

3. Read query results: Once a result has been verified on-chain, use the SDK to fetch query results from contract storage and use them trustlessly in your smart contract application.

In my mental model, there are two main components to use Axiom:

1. Building and sending the query to the Axiom smart contract.

2. Reading and verifying the response from the Axiom smart contract in your own smart contract.

The first step is to send a query to Axiom's contract from a Node/Nextjs project using the TS SDK:

Developers can create and send their query using four methods:

• newQueryBuilder - Creates a new instance of a query

• append - Pass in the address, storage slot, and/or block number that you want to prove

• build - Obtain the keccakQueryResponse and serialized query

• sendQuery - Sends the query onchain to the AxiomV1Query contract

Reading and verifying response

Once the Prover generates the ZK proof, it will write that the `keccakQueryResponse` for that query has been fulfilled, and an event `QueryFulfilled` will be emitted. Developers read the response from Axiom's contract storage and verify the results onchain using these SDK methods:

- getValidationWitness - Allows a user to prove that their claimed data is actually committed to in keccakQueryResponse

- areResponsesValid - checks the data you provided against that hash stored onchain.

Once you've validated that the responses are valid, you can pass this response as an argument to any smart contract function that will restrict actions to accounts that go through this process and pass in a valid and verified proof to the function call.

Not only can you now generate storage proofs and use them to write the logic in your smart contract to gate actions based on historical onchain activity, but for the first time, you can use this historical data to create rich experiences akin to those in web2.

As more users, activity, and data start to come onchain, tools like Axiom will be key for creating rich user experiences without compromising security.

Some project inspo, taken from an Axiom blog post:

• Autonomous airdrops to reward protocol users for on-chain activity via smart contracts without a centralized authority.

• On-chain loyalty systems based on trustless engagement scores.

• Solver-based DeFi protocols which use provable off-chain solvers to settle markets.

• NFT transacted floor price oracles to power underwriting for NFT lending and derivatives.

• A randomness oracle leveraging consensus-level randomness from the beacon chain.

• A trustless volatility oracle used to adjust fees in an AMM or LTVs in a lending protocol.

• Generative NFTs proven in ZK to be generated from the claimed algorithm.