Fast, reliable & scalable public RPC - Powered by Lava

Public RPC is often a source of frustration for users and developers alike. It’s fragmented, unreliable and under-maintained - many times degrading the UX on wallets and dapps, creating a bad reputation for chains as being slow or hard to build on.

Lava’s Incentivized Public PRC (ipRPC) initiative offers a completely new approach to public RPC - empowering users & devs with super reliable & performant access to data, while making it easy for teams & DAOs to monitor, manage, and save on infra costs.
ipRPC will allow Archway to seamlessly consolidate top RPC providers into a single, super reliable endpoint - with optimized performance and deep insights.
Through Lava’s public endpoint, users pair with the top performing providers in their geolocation, and data is quality-controlled by Lava Protocol - meaning developers can focus less on troubleshooting infra and more on building cool apps.

We’re asking for 75,000$ to launch a new super reliable, scalable, and performant public RPC endpoint for Archway. The funding will be used to onboard and reward providers - both Lava & Archway community node runners and Lava’s industry leading partners e.g. 01node, Allnodes, Bware Labs, Nodes Guru, Lavender.Five, Stakecito, ChainLayer, Blockdaemon, Imperator, Chainstack, Liquify etc.

Providers will be incentivized with $ARCH on a monthly basis, according to the volume of requests they serve and the quality of their responses (measured in uptime, latency and sync). This means that for the first time, web3 data providers are accountable for their SLA.

We’re already helping chains like Evmos, Axelar, Starknet and NEAR improve the user & developer experience in their ecosystem - powering leading apps, wallets and dev-tools.

Technical advantages:

  1. Top performance - users are paired with the top performing providers in their geolocation, which are incentivized to serve fresh data with min latency and max high uptime
  2. Constant availability - Lava’s endpoint is powered by a large network of providers, meaning even if some go down users are not affected. Furthermore, even if Lava’s blockchain goes down users are connected directly to providers, so service goes uninterrupted
  3. Data accuracy - queries are sampled and cross-referenced to ensure that the data is accurate users are protected from bad actors
  4. High rate limits - Lava’s public endpoint offers 30req/sec, Lava’s gateway and SDK offer 50req/sec and more for free

Read more about Lava’s design & tech advantages


  1. Integration & Setup
  • Archway “Spec” integration + maintenance
  • Setup, monitoring & maintenance of RPC endpoints for Archway Mainnet & Testnet
  • Provider analytics dashboard
  1. Provider onboarding
  • Co-marketing campaign to onboard RPC providers
  1. Endpoint launch
  • A single endpoint that makes it easy for anyone to interact with Archway for free (Axelar example)
  1. Growth
  • Monitoring and optimizing performance
  • Onboarding more users
  • It is also possible to explore adding advanced APIs & indexers

This proposal, if accepted, will send 75,000$ worth of ARCH tokens from the community pool to Lava Foundation’s address - archway1v2cxu37h8d4pt9dqw909wfswfungpuv3qy7rh3
The majority (70%) of funding will be used to onboard and incentivize node runners for providing quality service through the new public RPC. 30% will be used to cover Lava Foundation’s costs for setup, maintenance, support, marketing, bookkeeping and compliance.

We’re looking forward to receiving your questions and feedback!

About Lava:
Lava is a modular infrastructure layer for blockchain data. The novel protocol is customizable to support any RPC & API for any chain. Developers no longer need to be limited by a lack of API providers and can build on 25+ chains already supported by Lava’s network of node runners. Lava introduces “Specs”: a modular data primitive that lets contributors add and scale new chains & APIs.

Discord: Lava Network


I don’t know much about pricing for this kinda stuff to analyze the ask, but love the idea of partnering and working with Lava Network, and know we’ve had some difficulties with public RPCs lately!

Great to have you guys around, thanks for joining the forum and offering the service.


We have been following the Lava project for a long time and are testnet participants and providers.

In our opinion, Lava radically changes the rules of the game!
This is an incredibly powerful and ambitious team that shows incredible success in bringing their ideas to life.

And they are a great solution for developers through the use of their RPC system

This will allow you to receive data in the quality in which it should be!


As a validator for various blockchains and in particular a validator for Archway (mainnet) and lava (testnet) I create my own RPCs which are mainly used by myself and some other validators for internal purposes. Such RPCs opened by validators are not often released to the general public. Lava’s ipRPCs are more structured and prepared to open up reliable RPCs to the general public, which is great
I am an ipRPC provider for Evmos and Axelar and I definitely support this proposal!!!


Also, as an ipRPC provider, I will say that it is much more pleasant to create RPC and receive incentives for it)


As I see decentralized RPCs as the vital part of robust, stable and censorship-resistant web3 paradigma which we’re trying to build together and it’s still so eary - I’d strongly support that proposal.

1 Like

We see this as a big plus for archway ecosystem, reliable archival rpc’s are very essential for archway’s sucess. In support of this proposal

1 Like

From our side, reliable decentralized RPCs is the right way to go. And being in a long and strong connection with both Archway and Lava teams, we are sure it’s a huge step for both projects and not a penny will be wasted.

So we do support the proposal

1 Like

I totally agree with your thoughts.


I am supportive of this initiative but have two comments/questions:

  • It’d be great to set a fixed number of ARCH from the text of this spend proposal to make sure the numbers match or are clear to everyone once it goes on-chain.
  • Just wondering how services were valued for the Archway network? it seems to me that Axelar and Stargaze were asked for a lower grant. Just trying to understand how pricing was done for the Archway network.

Overall I’m supportive of this implementation.

1 Like

How long is this funding expected to last before needing another community pool grant?


Is it necessary to pursue this, given the abundance of existing providers?

The request also seems substantial relative to the costs associated with maintaining infrastructure.

As pointed out above, other community proposals were for significantly less.

1 Like

Having healthy and competitive and open market of RPC providers is definitely good for the ecosystem, and this proposal is welcome step to get the discussion going in the right direction

However IMHO this proposal in its current form is lacking clarity on various critical aspects:

  • What is the incentive/pricing model for the data providers?
  • What kind of SLA will lava foundation provide to archway community in exchange for these funds? Will there be an on-call support available for the archway community in case of incidents?
  • How competitive is the SLA/pricing model as compared to if the community wants to use one of the other API providers directly (e.g lavender five, NodesGuru , Blockdaemon etc)?
  • How long are these funds expected to last?
  • What kind of monitoring and public dashboards will be available to the archway community?
  • For reference, Archway Foundation public APIs currently provide 50 req/s rate limits for free.
  • As of this writing, there are currently 28 RPC providers published on the archway networks repository (networks/archway/chain.json at main · archway-network/networks · GitHub) which are available for the community. The incentive to do so is also part of the Archway Foundation delegations program.

Further questions:

  • Are there rate limits on websocket as well?
  • It’s a bit concerning that the lava axelar grpc endpoint does not seem to work since past few days, tested with
❯ grpcurl -d '{"proposal_id": 1}'
Error invoking method "": rpc error: code = Unknown desc = failed to query for service descriptor "": Failed to SendRelay ErrMsg: {"Error_GUID":"3878864920113280740","Error":"failed to getSupportedApi gRPC ErrMsg: api not supported {name:grpc.reflection.v1.ServerReflection/ServerReflectionInfo,connectionType:}: api not supported {name:grpc.reflection.v1.ServerReflection/ServerReflectionInfo,connectionType:}"}

While the voting period is ongoing, I believe fully understanding the details and value addition of this proposal is crucial for the collective benefit of the Archway community. Perhaps at this point it would be more beneficial to the community and the ecosystem to have a proposal with smaller grant to run a proof of concept test for a short term before moving on to a longer term commitment.


I agree with @shahbaz’s concerns regarding the request size and accountability with SLAs. It would be great if we could work together to come up with a revised proposal that includes an uptime commitment for these services. I believe this will help us ensure better performance and more clarity on the use of funds.


Hey @shahbaz, thanks for the detailed reply, appreciate the feedback.

To address your questions:

  1. The incentive model for providers is simple - the amount of traffic they serve each month (measured in Compute Units), adjusted for the quality of their service (uptime, latency, sync) in relation to other providers. Lava’s protocol is designed to incentivize providers to excel - if you consistently provider top service you’ll get more users & rewards. If your performance is not up to standard, you’ll get way less traffic so users aren’t affected.
  2. While we don’t have a formal SLA in place, our team is known as being very responsive and committed to providing quick and efficient support. Historically responding in less an hour, available on Slack/Telegram/Discord.
  3. Using Lava has many advantages over using each provider on their own:
    • Users optimally pair with top performing providers in their geolocation
    • Users pair with multiple providers at any given moment, so they’re not affected by specific provider downtime.
    • Lava cross-verifies data between providers, making sure users get the latest & most accurate data
  4. The initiative will run for 6 months
  5. Archway stats will be available on, our “provider explorer” - where anyone can view on-chain data about provider activities. In addition we’ll launch a dedicated dashboard for Archway, that will aggregate useful information about the state of the endpoint - total traffic, # of providers, geolocation spread etc. here’s an example for Evmos
  6. Lava offers 30req/sec on the public endpoint and 50+ req/sec via the gateway, also for free. There are many advantages to incentivizing providers through Lava, as they’re directly incentivized to maintain and improve their service, while standard public RPC is known to fail due to low maintainence.
  7. We’re currently serving 1B+ daily relays across dozens of networks, Our services are running on K8 and protected cloud services. Archway RPC will also be added to Lava SDK, which allows anyone to access providers on Lava’s network in a fully p2p manner, and without relying on services run by us.
  8. Currently websockets aren’t rate-limited on our end, but can be limited by providers.
  9. Looks like you’re trying to query an unsupported API. We can easily add it to the protocol, as we’ve just done today for CosmWasm APIs on Axelar per user request. Another major advantage of Lava is the open source nature of it - anyone can propose to add new chains & APIs, so users aren’t reliant on a single entity to maintain the protocol.

Thanks for the thoughtful prop! Excited about what Lava can potentially bring to the ecosystem. That said, I do have a few concerns that I’d like to raise here:

  1. This proposal did not follow the standard governance process. The proposer did not join any community call. There was really no discussion, and the little feedback that came through this thread was not addressed or incorporated into the prop that went on-chain.
  2. It’s my understanding that Lava is currently in its testnet phase, with plans to launch mainnet in the coming months. While the prospects of this integration are definitely promising, committing a significant portion of community resources to a protocol that is new to the Archway ecosystem and not yet live on mainnet warrants some serious consideration.
  3. There have been questions about why this proposal’s cost is significantly higher than other protocols, which have not been addressed. For example, the recent Stargaze proposal from a few weeks ago was for ~$61,000 (or 1,200,000 STARS). Why is the Archway spend so much more?

I’d love to see an integration and long-term partnership here, but feels there’s been a lack of discussion around the specific prop that went on-chain


Hey @yuvalxyz,

For transparency, we are also running a testnet validator on Lava, but we don’t run Archway Infrastrucure APIs as of now.

Let me highlight why we are supporting this initiative, from an Infrastructure point of view: We believe that this integration might be beneficial for the ecosystem, as it load balancing the existing 28 RPC providers, and in the end it’s a more eficient service, than having every API consumer to build their own loadbalance macanism in-house.

At the same time, there are some things that might need to be clarified at incentive level and how the grant will be used. From our perspective the following questions should be answered:

  • How many nodes will be onboarded on Lava, as a target?
  • How much a node costs on avarage (Hardware + maintanance)?

Based on the above, you would have more transparency on the total grant size for 6 months, and how the funds will be allocated.

Having that in mind, we will be staying on the sidelines until this is being clarified.

1 Like

6 months, afterwards we aim to establish a long-term partnership for stability & consistency. Also we’re already in the process of automating ipRPC, so that ecosystems can easily self serve and renew whenever they want.

Hey @Apradar, thanks for your comment and sorry for the late reply.

  1. The fixed ARCH amount of the prop is 350k
  2. 75k-200k$ is the standard budget our ecosystem partners invest in ipRPC - this is to offer sufficient incentives for robust support on Mainnet + Testnet + Archive, and to cover costs for Lava Foundation which also includes spotlighting Archway on Magma Points.

To follow up on @flavianBware’s point - running an Archway RPC node can cost around 150-200$/month, and usually with ipRPC we’re onboarding anywhere between 50-100 providers. However rewards are not distributed evenly, rather according to providers’ quality of service and reliability - the goal is for top performing providers to be able to profit. That way providers on the network are incentivized to constantly maintain & improve their operations for the ecosystem.

Taking into account newly appeared arguments, we decided to halt the proposal from our side as we do need more discussion on this matter and as we have a formal ‘DAO’ procedure we all have to follow it

In any case we are open to all further discussions after the procedure will be formally passed