AYE. Thank you for a thoughtful and well-constructed bounty.

ChaosDAO would like to provide the following feedback from our community. We offer this feedback voluntarily in the spirit of OpenGov, in order to help teams improve their proposals so we can all build the network together.

1. ChaosDAO members voted AYE with no substantive discussion.

ChaosDAO votes as a collective based on the results of our anonymous internal voting procedures. Our members are not required to provide any feedback about why they have voted in a particular direction. Similarly, to respect our members' right to anonymity, we will not be sharing the names of individuals who have chosen to voluntarily provide feedback. We would like to disclose that some of our members are affiliated with this referendum, be that on the operational side or on the curator team. However, the number of affiliated members is vastly outnumbered by the number of non-affiliated members who voted AYE on this proposal. Additionally, our internal processes dictate that those with a COI for a particular referendum must recuse. Therefore we are confident that ChaosDAO's vote unequivocally does not represent a COI.

Hello from Polkadotters! As we are part of the IBP, we abstained from this vote as our vote might be taken as a conflict of interest. But surely, we support this initiative, because globally distributed infrastructure services benefit the Polkadot ecosystem at the backend.

Hey @Paradox , thanks for the feedback. We would like to address the points you raised.

First, regarding the 30k upfront payment, that payment does not remotely cover hardware costs to meet the requirements of the IBP (even before this proposal). Here is the cost example we used on AAG

This means that each member must invest their own capital into hardware, and this will only increase as members need to fulfil the requirements of their respective ranks to provide services under the umbrella of the IBP. As far as we are aware, in the other bounty, only Dwellir and Lucky Friday use their own hardware. Everyone else is using cloud or bare metal providers, which may reduce their long-term stickiness, reliability, and alignment with our ecosystem.

Second, regarding your point concerning the hobbyists: We will introduce a new plan for them with the bounty on Kusama, since the hobbyist track will not exist within the Polkadot bounty. We see a future for the hobbyist members in which they can support Parachain teams on the Paseo network.

Lastly, about funding parachain RPCs – while we see your point in theory, the last few months have made it clear that there are hurdles to building within the Polkadot ecosystem that sometimes are too high even for established teams, and multiple have pivoted away to other ecosystems. Our competition here is with other networks (that deploy capital in the hundreds of millions). Ultimately, holders can only benefit from highly talented teams that bring successful parachains and projects to the Polkadot ecosystem. In our view, we need to make it as simple as possible to build on Polkadot and to use Polkadot, both for existing teams and new entrants.

The criteria for parachains are fairly clear: Secure your chain using Polkadot and state that on your website. We scale the deployment according to usage to prevent unnecessary overdeployment. Curators will only decide on the requests by the ecosystem such as sidecar, explorers, and indexers. In that sense, the curators have a controlling function and, as all are trusted ecosystem members, act in the best interest of the ecosystem when it comes to such additional services.

Hi All,

I would like to share a few thoughts that I've expressed in other quarters with regards to the IBP and this particular proposal.

My response would be grouped into the following sections:

• Disclosures
• Thoughts on the IBP
• RPC Bounty & co-existence with the IBP
• Funding Parachain RPC
• Rationale for voting

These are all my opinions...

Disclosures

• I am a hobbyist member of the IBP and a would-be full member
• I white-papered and drove the now funded RPC Bounties on Kusama and Polkadot
• I was a curator of the Infrastructure bounty on Kusama
• I work at LuckyFriday, they're a full member of the IBP and a contender for funding under the RPC bounty. Like other providers who fall within this bracket, their IBP facilities and public RPC facilities are separate

Thoughts on the IBP

The IBP leverages on the concept of a group of tech savy community members coming together to provide technical services to the ecosystem. Funding to provide services is subsidised by the treasury with up-front allocations ($30,000) and somewhat secure monthly funding as long as the bounty remains funded. This reduces the capital risk that regular RPC providers take. The IBP also makes seperate allocations for administrative cost and tooling (Global Services) for which most other public providers include in their rate. This is fine for a community programme as we've seen similar supported initiatives such as the 1KV.

From an insider view, the team is doing a lot of good work, there is attention to detail, camaraderie and funding is spent as proposed.

If I were to critique, I would suggest that attention needs to be paid on the hobbyist tracks which is (at present) fairly stagnant. I think the members track is sticky, it almost feel like a treasury funded business, as opposed to a programme in which you may expect rotation or fair-share to those that qualify. Appreciating the technicalities, it is certainly difficult to expect short term rotation. However, I think with attention, these things can be improved.

Overall, an Aye.

RPC Bounty & IBP

I white-papered the procurement strategy for RPC funding to help alleviate a few problems with public RPC provision, in short:

• Untethered spending, the here's my invoice pay-me mentality
• To establish general standard of service
• To establish allocation of service i.e. how many providers do we need, how many connection should we service on a per-chain basis
• To reduce favouritism with who gets funded under OpenGov

The fundamentals of the approach is well established and follows traditional procurement. One would expect that this fair entry approach would attract vendors (in/outside of our ecosystem) to compete in a manner that after a few iterations and with transparency of bids, would yield a market-rate.

With this model, RPC providers are taking their own capital risk i.e. no lumpsums or subsidies. They must maintain server standards or face loss of earnings.

The providers under the RPC bounty provide service based on directive from the curators who have set service requirements based on analysis of previous usage. This (again imo) is a very efficient approach that scales with network need. In an age of significant use of light clients, we would see reduced RPC demand and as such the curators can scale down provision.

While the core service is the same, the approach is vastly different. Where financing permits, I see no reason why both bounties can't co-exist.

Overall an Aye

Funding Parachain RPC

I've shared my view on funding of RPC services for Parachains with referendum 354 issued by OnFinality. I maintain my position that for-profit parachains projects should not receive relay-chain funding or subsidy for RPC services.

Imo, if a parachain project has high RPC traffic, it is most likely "doing well" and can afford service or in the least be able to leverage of some service-in-kind. If it is not "doing well" then there would be very little RPC traffic.

The proposal is also vauge on the selection criteria, depriving me of an opportunity to further examine. Putting a logo and slogan on your website is not sufficient selection criteria. Leaving it up to the curators to be fair also doesn't work for me. Picking favorites can lead to competitive advantage.

A confident Nay

Rationale for vote

It is important for me to be consciously consistent with my votes, especially with matters that set precedence. Relay-chain treasury funding of Parachain infra is a big no-no for me. On the other side, I am also a supporter of the IBP (in principle) and can't see myself voting against.

Since, I can't with good mind vote Aye or Nay then I must Abstain.

Regards, Will | Paradox

@14iV...5p78

Just to add a little more context. Each provider in the IBP provides 2 node instances where as each provider within the RPC bounty provides signficantly more, the curators guide needs on a per network basis. For instance, we don't need the same capacity on Westend or System Parachains as we do on Polkadot. The RPC bounty allows tweaking to ensure capacity is where it is needed. The answers per network coverage is true, 12 providers has more coverage that 6.

@Amforc Thank you for your answers.

I want to give credit to the IBP for the transparent reporting on funds being spent.

@14iV...5p78 Hi DotBeliever, happy to address the topics you raised.

>Before we cast our votes on this proposal, let's discuss the bounty program for Public RPCs for Relay and System chains that was approved in December 2023.

While we believe that the time of bounty creation is irrelevant, the IBP far precedes the bounty program you mentioned and is active since December 2022.

>This program, backed by several infrastructure providers, costs only a tenth of what the IBP-Bounty does.

This is comparing apples to oranges – what the IBP offers goes way beyond that bounty you mentioned. The IBP also provides better transparency through a clear indication of expenses and member reimbursements rather than just generically allocating the funds for RPC.

We cannot find any public records of current costs, and RPC providers seem to be able to charge what they like as of now.

With the goal of offering some comparability for DOT holders voting on this proposal, we calculated monthly costs based on previous proposals for six of the seven members in that bounty (the last member never applied for treasury funding to our knowledge).

The data are from proposals between November 2022 and Q2 2023:

• Provider A Coverage: Polkadot, Asset Hub Polkadot, Kusama, Asset Hub Kusama, Westend, Asset Hub Westend, boot node = $14'790/month
• Provider B Coverage: Kusama, Asset Hub Kusama = $14'920/month
• Provider C Coverage: Polkadot, Asset Hub Polkadot, Kusama, Asset Hub Kusama, Westend, Encointer, Collectives = $43'170/month
• Provider D Coverage: Polkadot, Asset Hub Polkadot, Kusama, Asset Hub Kusama = $15'256/month
• Provider E Coverage: Polkadot = $4'827/month
• Provider F Coverage: Polkadot, Kusama, Westend, boot node = $11'288/month

In total, for these 6 providers with various coverage, monthly cost amount to $104'251. A single IBP location costs around $11'000, covering 16 different networks. This means that the IBP reduces expected costs by >50% while offering significantly higher network coverage.

>Are we aiming to create an ecosystem that relies solely on Treasury funds? The IBP-Bounty is requesting $4 million to purchase servers and offer services to parachains at no direct cost (though funded by all DOT holders through the Treasury).

These funds are not allocated to purchasing hardware. They will be used retroactively to pay for services provided. This proposal prepares for a scenario where we would have to deploy over 1'140 RPC nodes across 15 datacenters.

>In the short term, this is quite costly ($4 million!), and over the long haul, it threatens the development of a self-reliant ecosystem where diverse providers can offer services to parachains.

The $4M are allocated to retroactively pay for services provided, and shouldn’t be seen as “spent”. The proposal outlines how usage of funds will be accounted for in a model that has been working well over the past year, with full transparency to the community. The IBP is not a single provider. It is a collective of independent providers that do not rely on each other, resulting in a robust and long-term sustainable setup for the benefit of Polkadot.

>Because of the IBP's offerings, parachains might not engage with other providers, preferring services provided at no charge by the IBP. This setup makes it hard for other providers to compete, especially since they don't have $4 million to invest in hardware. What will happen next year if this bounty program is discontinued? Without a thriving market of service providers, support for parachains could come to a halt.

As outlined above, the $4M are for retroactive payments for services provided, not hardware. The goal of the Polkadot treasury is maximize the effectiveness of its spending, and providers are welcome to compete for that spending. The IBP offers a highly efficient and robust service at a competitive price, and enables projects to build on Polkadot more easily by removing the friction of negotiations with individual RPC providers.

Before we cast our votes on this proposal, let's discuss the bounty program for Public RPCs for Relay and System chains that was approved in December 2023.

This program, backed by several infrastructure providers, costs only a tenth of what the IBP-Bounty does.

Are we aiming to create an ecosystem that relies solely on Treasury funds? The IBP-Bounty is requesting $4 million to purchase servers and offer services to parachains at no direct cost (though funded by all DOT holders through the Treasury).

In the short term, this is quite costly ($4 million!), and over the long haul, it threatens the development of a self-reliant ecosystem where diverse providers can offer services to parachains.

Because of the IBP's offerings, parachains might not engage with other providers, preferring services provided at no charge by the IBP. This setup makes it hard for other providers to compete, especially since they don't have $4 million to invest in hardware. What will happen next year if this bounty program is discontinued? Without a thriving market of service providers, support for parachains could come to a halt.

[Deleted]

I truly cannot express enough how much support I have for the IBP bounty, its members, and their processes.

Having had the opportunity to engage with the Paseo Testnet, I witnessed firsthand the exceptional quality and dedication of each member. The stability provided by validators, collators, and RPC was impressive, but what really stood out was their immediate and enthusiastic willingness to offer support whenever necessary.

Furthermore, during the launch of Paseo, the IBP proved their commitment to optimizing costs by providing market prices for infrastructure that were not only competitive but also highly advantageous.

@Colorful Notion 

Thank you for your vote!

Regarding light clients, the IBP is fully aligned with the ecosystem's future goals and wants what's best for Polkadot. For example, IBP members are required to run bootnodes for free, which are (among other things) required for light clients to establish connection with the network. From the 13 entities running bootnodes on Polkadot, 11 are the currently active IBP members.

There is also a little misconception regarding light clients: As of now, light clients can only be used for fetching the current state and it is not possible to be used for historical data. While it will eventually be supported (as mentioned by a fellowship member here), even then we will still need people to run archive nodes. Currently we believe this feature could enable more participation with consumer hardware due to the nature of its design by anyone from home, which would reduce costs. Still, those people would also need to be compensated in some way for their services and the IBP would like to enable this, perhaps through its own collective with a subtreasury in the future. We will create a proper proposal once those features are reality.

We also strongly believe that the formation of an "RPC industrial complex" is not possible due to the design of the bounty and our curators selection, whose interest are those of the network and not of the IBP members.

Because this is forecast to cover parachains comprehensively, we support this bounty wholeheartedly. There is a strong track record from everyone involved, and there is almost no risk of failure.

We would not support this if it did not cover parachains comprehensively. But because it does, we feel very strongly about this working successfully especially with a bounty model.

My only concern is that people who object on the grounds that light clients + smoldot should replace RPC should be heard, and that we don't turn RPC into a DOS/QWERTY keyboard type situation when true resilience is supposed to come from that instead. Those people are correct and should be listened to sooner rather than later, with a sense of urgency. I hope we don't have a RPC / IBP industrial complex getting in the way of that future.

AYE