Lava Network - Decentralized Public RPC for Axelar

  • Date: 7/24/23
  • Address: axelar1vyg0gc7kh28ajvq2a4w3sdn33rc2txmkazks2v

→ Project Description:

Lava Protocol decentralizes RPC by pairing applications with an open network of node runners on any chain. While validators are excellent technical contributors to every web3 ecosystem, the problem we identified is the lack of incentives for RPC node runners to join, decentralize and amplify Axelar.

We thus propose “Decentralized Public RPC” (dpRPC). By using an incentive pool, Lava will attract node runners to power a decentralized RPC endpoint that will serve as a community-led, resilient to downtime, public good for any developer to use. This initiative will attract technical community members to not only run RPC nodes, but who will also amplify Axelar across Twitter, Github and contribute in many other ways to the ecosystem. We are seeking funding to sponsor the incentive pool, with the vast majority (80%) of it being distributed to node runners, while Lava will only take 20% to subsidize administrative and maintenance costs.

Just like how Validators are the most vocal voices across Web3, we believe RPC node runners, properly incentivized, have the technical expertise and motivation to become deep advocates of Axelar. A decentralized public RPC endpoint will be community-first and give node runners the initial entrypoint to help grow the Axelar ecosystem.

→ Funding Request:

We are requesting a $15000 in AXL Grant for integrating the Axelar RPC spec into the Lava protocol, maintaining the public endpoint and incentivizing the first cohort of node runners to join the decentralized RPC pool. The vast majority (80%) of the grant will be distributed by Axelar to node runners as rewards for bootstrapping the RPC pool, while Lava will only take 20% to subsidize administrative and maintenance costs. Axelar will be in a position to fund future campaigns to attract node runners.

Value to Axelar Community


We already have 100+ node runners who are ready to support this initiative, with the incentive pool we also aim to attract active members from the Axelar community, which will effectively strengthen Axelar’s ecosystem growth. By bringing together the community to create a Decentralized Public RPC endpoint, we will drive developer engagement on Axelar, attracting many more node runners to the ecosystem, the creation of new wallets to claim rewards and increased activity on Github and Twitter. We already see the high involvement of validators in every web3 ecosystem, and Decentralized Public RPC will encourage RPC node runners to be similarly vocal in and outside of the community. Upon success, the key benefits to Axelar are:

  1. The upcoming Axelar Virtual Machine will require robust and reliable RPC support to maintain good relayers and connections to Axelar, as well as other dApps deployed on it.
  2. Decentralized Public RPC access to Axelar;
  3. Lava RPC infrastructure will not just improve developer experience on Axelar but will also introduce better redundancy and high availability, performance optimization, censorship resistance, load balancing, greater scalability and privacy.
  4. Increased incentives for boosting Axelar node runner engagement
  5. Increase amplification of Axelar across Github and socials

→ Deliverables, Milestones, & Timeline:

We will maintain this project for at least six months.

  • Milestone 1 - Integration & Set Up
  • Define and launch onboarding flow for community node runners to join Lava
  • Mutually define product features, monitoring skills, priorities for Axelar etc. for lightweight involvement by foundation resources going forward
  • Milestone 2 – RPC live on Axelar Mainnet powered by Lava
  • Create specs for Axelar mainnet JSON-RPC over Lava
  • Adding Axelar support on Lava Gateway
  • Deploy Public RPC endpoint as “axelar-mainnet.public.lavanet.xyz” working with Lava protocol, no registration needed.
  • Enable support for Axelar on Lava SDK
  • Deploy and announce RPCs with node runners
  • Review and tune of performance, adoption and more with Axelar
  • Milestone 3 – Maintenance and growth
  • Monthly review and tune of performance, adoption and more with Axelar
  • Provide access to existing Axelar node runners to join Lava as providers
  • Create a dashboard to monitor all Axelar drRPC providers from this initiative
  • Run co-marketing campaigns to attract node runners to join the dpRPC
  • Review and tune of performance, adoption and more with Axelar

→ Bio & Past Work:

Gil is a distinguished expert in cybersecurity. After serving in the top cyber-warfare unit of the Israeli military, Gil founded Nautilus Intelligence (zero-day cybersecurity) acquired after just 3 years for which he raised capital, recruited and led top-tier engineering talent from Israel, Europe, and Asia. Gil came to understand the unique strengths and weaknesses of various blockchains by building high return MEV bots.

Yair is an accomplished serial entrepreneur having started his first company at age 21. Prior to focusing on crypto and co-founding Lava, he spent 6 years as the solo founder and CEO of [Supersmart]—the world’s first cashierless supermarket checkout technology. Supersmart processes $1.5B a year for top retailers in more than 9 countries. Other startups he’s co-founded include Ogmenti (Augmented Reality) and [Octopai] (Business Intelligence) for which he raised more than $50M, hired hundreds of employees and had 2 exits… Yair holds a B.Sc. in Computer Engineering from the Technion in Haifa, Israel.

Omer is an accomplished professional who currently serves as our Chief Architect Officer, demonstrating his expertise in RPC, consensus building, Layer 1 protocols, software design, and development. With a strong background in security research and zero-day cybersecurity, he has successfully led R&D teams, managed resources, and implemented various systems in the communications and digital signal processing domains. Omer holds an MBA from Tel Aviv University and a BE from the Technion in Haifa, Israel.

3 Likes

Robust RPCs will be pretty important as the VM goes live to operate relayers across newly connected chains & support its over services. :+1:

What are the long-term incentives for the operators? Lava will have its own incentives backed into the protocol?
When we say “better redundancy and high availability”, can you quantify it? E.g., sending a request to the service will ensure that there is at least 1/N node that must be online to reply to it, where N = .

@sergey that’s a great question, thank you :slight_smile:

  1. At Mainnet, Lava will have built-in incentives for PRC Providers to provide public RPC for Axelar, in addition to our paid service. Axelar will then be able to subsidize decentralized public Archives and rich APIs.

  2. Through Lava, apps connect to multiple RPC providers instead of just one (aka decentralized RPC). This creates high redundancy of available RPC nodes where one or multiple nodes going down doesn’t affect users. We commit to 99.9% availability on our public endpoint during the initiative.

Let us know if you have any other questions.

ok cool. :+1: makes sense.

Thank you for making this useful and thought-provoking grant application. Lava Network’s aim to provide robust, decentralised RPC service for developers certainly seems to fulfill a real need in a very appropriate way.

The Axelar team could consider starting its own program incentivising validators to provide RPC services as an alternative, however it is unlikely to be anywhere near as cost efficient, due to the benefits of scale Lava should get supporting multiple networks.

Therefore, in principle we, LunaNova, see no objections to this. The idea is sound. The team behind it seem very capable.

What we’d like to explore is:

  1. Lava needs to be able to compete on service quality against large centralized RPC providers such as GetBlock, Alchemy and QuickNode. Do you have any information on expected performance metrics such as query latency?
  2. What sort of rate limits will you impose on public endpoints to prevent abuse?
  3. Would rate limits be static or fluctuate dependent on overall supply and demand?
  4. Will you support both Axelar Testnet and Mainnet?
  5. Given your statement “We will maintain this project for at least six months” how, given the obvious financial constraints of a fixed grant, could we ensure sustainment?

We look forward to hearing from you.

Hello @Mike, thank for your support! Please find the answers to your questions below:

1.Lava needs to be able to compete on service quality against large centralized RPC providers such as GetBlock, Alchemy and QuickNode. Do you have any information on expected performance metrics such as query latency?

Great question! Lava aggregates many different providers and ranks them based on quality of service, guaranteeing high quality service (or more specifically query latency).
We have community providers and bespoke provider partners that offer very high SLA.
Lava currently supports over 20+ chains and we have great performance metrics, achieving 50~100ms in many cases in EU & US.
With that in mind, we expect to deliver similar or better results for Axelar.

2.What sort of rate limits will you impose on public endpoints to prevent abuse?

The initial rate limit is set at 30 req/sec per IP on the public endpoint, we did a research and found this is slightly above average compare to other providers

3.Would rate limits be static or fluctuate dependent on overall supply and demand?

Rate limits in Lava may have static thresholds per IP to prevent abuse. Overall network-wide rate limits could fluctuate based on dynamic conditions, managing demand and ensuring service stability. This strategy balances fair access, performance, and competitiveness against other RPC providers.

4.Will you support both Axelar Testnet and Mainnet?

Yes, we will support both Testnet and Mainnet. Our initiative aims to serve the entire Axelar ecosystem while ensuring high QoS. If supporting both chains reduces QoS due to incentive distribution to both chains, we will communicate it here and may consider supporting only Mainnet. Until further notice, we will continue to support both chains

5. Given your statement “We will maintain this project for at least six months” how, given the obvious financial constraints of a fixed grant, could we ensure sustainment?

Great question. Service for public RPC is incentivized by the grant, which will be evenly distributed over six months to ensure sustainability despite financial constraints. This ensures supply/demand will control the number of node runners participating based on their cost of goods.
Users could further participate in Lava by buying subscriptions on chains for higher rate limits and access to more advanced features, this in the future will help with the sustainability for providers.

Thank you for a constructive response to our questions. Your answers about performance and management of rate limits are very helpful.

With regard to sustainment we like your intention to spread the incentives evenly over the grant term. We sincerely hope there will be the organic growth from users buying higher rate-limit subscriptions as you describe, although we expect there will be a real need for both Axelar and Lava to strongly market the decentralised service to encourage this increased participation.

We wish you well with your grant application.

This sounds like a great idea in general, having professional node runners run RPC nodes for public use is always welcome on any chain.

Will there be any required parameters in order to apply to be an incentivized node runner for the public RPC program?

How will the nodes be scored if at all? and will the score of a node reflect the reward from the pool?

Will this require running archive nodes?
If not will archive nodes be marked somehow and get priority?

Would happily support this initiative :slight_smile:

This would be nice, can we have some stats like response time , queries , distribution among nodes with the other networks lava operates. Can we expect similar stats to be shared for axelar as well if chosen.

Thanks for feedback and great questions! :raised_hands:

Anyone eligible* will be able to become a node runner in this program and potentially gain rewards.

The rewards will be distributed according to QoS and usage to assure users are getting the best service possible, which mean that professional node runners might get more rewards compare to new node runners who will have a poorer QoS. At this stage it will not require running an archive node, moving forward with this initiative and per the feedback from the community we might add archival node support which will also effect the incentives as its require greater effort.*

*Eligibility will be determined by the ecosystem, for example it can be bound to posting on twitter or contributing to the docs.