Frequently Asked Questions

General Questions

General Questions#

What is Ava Protocol?#

Ava Protocol is an event-driven EigenLayer AVS that enables seamless autonomous transactions for Ethereum and beyond. It empowers developers to improve crypto transactions with intelligent automation, enhanced privacy, effortless composability, and significant cost savings.

How does Ava Protocol help DeFi developers?#

Ava Protocol automates key aspects of DeFi development, such as on-chain interest rate updates, liquidity management, and liquidation processes. This reduces the need for manual monitoring, lowers operational costs, and improves platform reliability.

How does Ava Protocol enhance DeFi platforms?#

Ava Protocol improves platform reliability by automating functions and optimizing processes. This saves developers time, reducing inefficiencies and allowing them to focus on innovation. Ava Protocol ensures timely updates, precise liquidations, and streamlined operations.

Can Ava Protocol integrate with existing DeFi platforms?#

Ava Protocol supports both Ethereum and Polkadot, providing broad compatibility with existing applications and services. Developers can seamlessly integrate automation and advanced transaction functionalities across EVM-compatible and Substrate-based chains.

How does Ava Protocol ensure transaction privacy and security?#

Ava Protocol enhances transaction privacy and security through advanced MEV (Maximal Extractable Value) protection mechanisms. This approach prevents external entities from intercepting or manipulating transactions, ensuring that transactions are confidential and shielded from front-running and other malicious activities.

Who can benefit from Ava Protocol?#

Ava Protocol's enhanced automation benefits developers, DeFi traders, gaming projects, NFT artists, real-world asset applications, and users of practically any web3 vertical. By empowering seamless automation through super-transactions, Ava Protocol opens up new possibilities and use cases across the web3 ecosystem.

How can I get started with Ava Protocol?#

You can start by trying our testnet. Visit Ava Protocol Testnet to begin exploring the features and capabilities of Ava Protocol.

Technical Questions#

How can the ERC-6900 wallet schedule any task without storing private keys? Does something need permission on the wallet?#

Ava Protocol’s wallet introduces a controller that works in tandem with the EOA so that users don’t need to directly manage their private keys. The controller has the ability to execute future actions based on the user’s preferences without direct input. This dual-control structure allows the protocol to execute autonomous transactions on the user’s behalf without requiring direct access to their private key, streamlining wallet automation while maintaining security.

The Ava Protocol smart wallet simplifies automated transactions while keeping the user’s assets secure. The wallet automatically generates and packs multiple transactions into a User Operation, as defined by ERC-6900, combining the steps into a single process.

Is it the Task Payload stored in EigenLayer's Aggregator, and is it sponsoring the transaction via a manager?#

Yes, the UserOps (or task payload) is generated by the AVS Aggregator because the action details of the user’s task are stored in it.

There are a few ways to pay for automated transactions:

1. Paid by User’s Smart Wallet: The gas fee for smart wallet transactions is covered by the user’s smart wallet, which is funded by the user’s EOA (Externally Owned Account).
2. Paymaster Sponsorship: It can also be sponsored by a Paymaster associated with the ERC-4337 smart wallet factory. We offer a discounted program to pay gas fees directly for our users.
3. Developer Subsidization: Additionally, we plan to open the paymaster option to developers building on top of Ava Protocol AVS, enabling them to subsidize user gas fees for a streamlined onboarding process.

Does something need permission on the wallet?#

The transaction authorization process functions similarly to OAuth. The authentication can be achieved by a variety of methods:

1. The user signs a message to prove EOA wallet ownership, and submits that signed message to the AVS Aggregator.
2. The user logs in with their Coinbase account to request a session token.
3. The user logs in with their Google account to request a session token.

This session token then provides controlled, time-limited access to the user’s smart wallet. While there are other ways to allow controlled access, option #1 is the most familiar for web3 users, while options #2 and #3 cater to those familiar with web2 experiences.

For example, if a user wants to set a limit order with a three-week expiration, they could simply authorize via Google, requesting a session token that’s valid for the three-week period.

Note: OAuth (Open Authorization) is a widely used web2 protocol that allows applications to access resources on behalf of a user without exposing their credentials (like passwords). It works by granting third-party applications secure, limited access to user accounts on other platforms through tokens rather than sharing sensitive information directly.

With respect to permissions:

Much like the concept of “scopes” in Google OAuth, Ava Protocol attaches specific permissions, or “scopes”, to the session token during authentication. For instance, when a user logs in via Google and creates a smart wallet, the protocol first asks which permissions they want to enable for this wallet. If a scope is defined to permit only ETH and USDC transfers with a monthly limit of $500, then any attempts to transfer other ERC20 tokens or exceed this limit will be rejected by the AVS Aggregator, which manages the creation of task payloads and enforces these permissions.

The AVS performs the task execution, but does the operator also verify whether a smart contract event has occurred?#

In the AVS network, operators are responsible for monitoring onchain events and signals (such as subgraphs) to determine when task conditions are met. Currently, operators function as a large group, though we plan to introduce randomized smaller groups in the future to reduce the risk of collusion. Each group of operators is assigned specific tasks to monitor and actively listen for relevant onchain events. When conditions are met at the designated time or block, the group reaches a consensus, or “verdict,” on whether to trigger the task and notifies the Aggregator.

After receiving the verdicts, the Aggregator creates the necessary task payloads and submits them onchain for execution. The Aggregator also monitors each transaction’s execution status. If a transaction fails, there are two user-configurable options for handling it: either retry on the next block (or after a defined interval), or abort the task altogether. Additionally, users can opt to receive execution status notifications through channels like email or Telegram.

How are events indexed, and does it then post proof of the task execution?#

Once submitted, the execution status is logged as onchain events that can be queried via chain RPC or future aggregation tools like Dune Analytics for reporting purposes. To effectively track these task submissions, we’ve developed an innovative task data structure that has been iteratively refined over the years. This data structure functions as a priority queue, enabling efficient grouping, filtering, and prioritization to meet Ava Protocol’s core requirements:

• Prioritization: Tasks generally follow a first-come, first-served order. However, we designed the queue with flexibility to allow users to adjust task priority based on their needs. One common way to increase priority is through higher fees. If a user sets a higher payment for a task, it will be prioritized over others under the same conditions.
• Grouping: Tasks are grouped and batched for operator monitoring. This grouping allows similar tasks to be assigned to the same group of operators, optimizing monitoring efficiency and reducing network load.
• Filtering: Not all tasks are eligible for execution, depending on the permissions users set in their smart wallets. At the execution stage, the AVS Aggregator filters out tasks lacking the necessary permissions, rejecting them before submission. Additionally, the Aggregator can cease tracking certain tasks when necessary, such as when a spam smart contract is identified and blacklisted, preventing tasks targeting that contract from executing.

Would you say that Ava Protocol essentially removes the need to build and maintain custom backend APIs for dapps and protocols?#

Absolutely! Ava Protocol acts as a Retool or Zapier for web3 by allowing developers to build and automate dapps without needing extensive backend infrastructure. Similar to how Retool eliminates the need for companies to create internal tools from scratch, Ava Protocol abstracts away much of the backend complexity for dapps. It enables developers to set up automated transactions, event-triggered smart contract interactions, and other essential dapp functions without maintaining a custom backend.

Ava Protocol brings similar benefits to web3. It aims to help developers launch dapps on time and achieve their KPIs by reducing development time from three months to a week, cutting costs by 90%, and enabling seamless MEV protection and multi-chain deployment with a single click.

Do I bring contract ABIs or my subgraph to Ava Protocol? How does Ava Protocol know about my NFT events?#

Ava Protocol’s Studio is designed to integrate seamlessly with tools web3 developers are already familiar with. Filtering NFT events falls under the Smart Contract Events category, where you could use standard Ethereum query syntax to filter specific topics within the NFT smart contract. For example, you might format queries like topic0=”<method_name>” and event_data.field1=”<input_parameter_1>” to target specific event data fields.

Here’s how you can feed your own data to Ava Protocol automation:

• Smart Contract Events: For custom events within a smart contract, we use standard chain RPC subscription methods behind the scenes to listen to onchain events. All that’s needed is the smart contract address and the ABI snippet for the specific function the automation interacts with — there’s no need to upload the entire ABI. If the contract is verified on Etherscan, simply sharing the smart contract address is sufficient, as we can fetch the ABI directly from Etherscan.
• Oracle Signals: Oracles provides a wide range of valuable signals for onchain and smart contract interactions. While price feeds of crypto markets are among the most popular queries, we are also seeing increasing demand for various real-world signals, including sports and event outcomes, interest rates, and real-world asset data. With the growth of interoperability solutions, oracles now play a role in cross-chain data sharing.
• Subgraph Queries: The Graph already handles the heavy lifting of indexing blockchain data and enables custom queries tailored to user needs. To integrate with Ava Protocol, simply provide your subgraph URL for polling, or an API key if the query isn’t public.
• Custom Web Endpoints: Ava Protocol also supports polling of custom endpoints to retrieve data, such as information from your backend server or other web services.
• Webhooks (Planned): In the future, you’ll be able to set up a webhook on the Ava Protocol AVS and call an endpoint, allowing you to trigger tasks or manually feed in data. However, due to potential DDoS risks, we plan to implement an additional protective layer over the AVS to handle these requests securely.

---

For additional questions or suggestions to improve this documentation, please create a GitHub Issue on our Repository.