Proposal: Integrating Pocket RPC in Aave

Integrate Pocket RPC in Aave

What is Pocket Network:

Pocket is a decentralized RPC protocol with a permissionless network of over 45.000 incentivized nodes. This gives us the best resilience in the market with latency comparable to leading centralized providers, while being decentralized. Dapps that use Pocket Network’s RPC get to own their service and the more they use it, the cheaper it gets. As opposed to other providers, rather than paying a monthly fee that is a recurring cost, Dapps using Pocket get allocated RPC service based on a POKT stake, which allows them to own their infra in a liquid way. By using Pocket, Aave will be actively incentivizing decentralization as the more traffic is served by the network, more rewards are generated, causing more nodes to be spun up for the chains in question.

Rationale:

We have learned that Aave currently uses a basket of public RPCs for servicing the end user relays. Team members have expressed the desire to improve this solution as it is not very stable and there are recurring problems in service from these different public RPCs. This is especially problematic for mainnet ETH & Polygon for which POKT provides dedicated RPCs.

By providing Pocket Endpoints to Aave’s user facing RPC we can improve the RPC service level (both latency and % uptime) and contribute to Aave’s decentralization by providing it with the most decentralized infrastructure in the market, making it more resilient and censorship resistant, while allowing Aave to own their service through its stake.

We have developed a contract and method based permissioning method that will be implemented for AAVE’s endpoint, so that it can only be used to interact with AAVE protocol.

Proposal:

We believe a good start is to provide this service with an app stake that’s good for 25M relays (won’t get rate limited if exceeded) and later ramp up depending on performance, user feedback and how much the DAO is willing to invest.

Pocket Network would stake 118,815 POKT on behalf of AAVE DAO. This would be funded as follows:

Budget:

25M Relays:

$POKT 118,815

$POKT price at time of posting: 0.171

Total: $20,317.365

Goals:

  • Improve stability in Aave’s public facing Web3 infrastructure.

  • Decentralization of Aave’s front end RPC.

  • Give Aave ownership of its RPC service via owning the POKT token.

  • Further promote decentralization in the Aave and crypto communities.

  • Raise awareness of Pocket’s service and mission to decentralize web3 infra.

  • Encourage other projects to decentralize their infra with Pocket Network.

Milestones:

  • Integration: Integration of Aave with Pocket via inclusion of a simple URL addition
  • Onboarding/Testing: Testing of the Pocket Network endpoint. Tech support provided by Pocket engineers
  • Ramp up: Allocation of a certain % (equivalent to 25M Relays) of Aave traffic to Pocket Network
    • Increase of % and Pokt stake if service is performing as desired;

Proposal content in short

We propose an addition of Aave’s frontend RPCs to Pocket Network, in order to solve stability problems currently experienced in the use of public RPC’s (especially on mainnet), as expressed by the community.

We are offering an endpoint with a stake for 25M relays that won’t get rate limited and to be ramped up in a phased manner.

To fund this we are asking the AAVE community the funds to buy 118,815 $POKT which will represent their service stake, allowing for AAVE to send up to 25M Relays per day.

4 Likes

I think this proposal is very reasonable and deserves a fair shot as it resolves/helps with multiple issues the aave ecosystem is facing today.

Aave interface
The decentralized aave user interface relies on multiple public rpcs which are used within a FallbackProvider (as e.g. the cloudflare provider doesn’t support the full rpc instruction set, so some calls will fail and be requested via flashbots leading to a slow ui/ux). This is currently especially problematic on mainnet, harmony and optimism, as there the public rpcs aren’t super reliable. Pokt already supports mainnet and harmony and has optimism on the short term roadmap.

Hackathons/ OS-projects
Currently there are quite some community projects/hackathon projects that require a rpc, but don’t have an immediate monetization to justify paying for one. While people can use free tiers of existing rpc providers, it would be nice if there was a public rpc with less strict rate limits from & for the aave protocol.

POKT team
The few people of the pokt team I had contact with were super helpful/responsive. I suggested to add contract address allow-listing as I think only with this feature it’s reasonable for the aave protocol to pay for a rpc (otherwise anyone could use the rpc for anything) while still being able to use it accross all the ipfs gateways.
The feature was available ~1week later.

Therefore this proposal has my full support.

Disclaimer:
I’ve been a developer on the aave user interface till v3 release (and still contributing from the community side).
I’ve been in contact with POKT team before the proposal was created as i was deeply unhappy with the unstable rpcs used on the interface.


I’m not sure if 25M relays will be needed/sufficient, but it seems to be a reasonable starting point. Would love for POKT to post some quarterly/monthly stats in case the proposal gets accepted.

5 Likes

I support this proposal. Decentralizing Aave’s RPC relays will bring both added resilience and lower costs. Pokt has proven itself as an infrastructure provider.

I’m not experienced enough (IT wise) to give a fair opinion regarding this proposal

No doubt a decentralized RPC would be interesting but isn’t AAVE already integrating The Graph? If so, in which ways would the Pocket RPC be a more resilient/decentralized alternative?

Maybe @bgdlabs or any other devs could analyze the proposal

2 Likes

Hey @Tor_GAINS thank you for your feedback.
Pocket provides access to full-nodes for indexed or non-indexed purposes, whereas TheGraph is an indexer and provides tools for more specific uses and developers, so Pocket ends up being a more robust solution for this use case. Ideally Aave can use both providers for each intended purpose, Pocket for RPC, TheGraph for subgraphs.

Thegraph is no longer used on the aave interface for quite some time now.

Thegraph is an interesting project but not usable for apps that have complex data requirements.

Just to name a few shortcomings:
When a bug is found the polygon aave v2 graph takes around 2 months to resync, which is not a turnaround any project could live with.

There’s no reasoable way to e.g update all entries at once making the graph data for coins with rebasing simply wrong(stETH and ampl user balances are wrong on the subgraph)

Thegraph doest support all networks aave is operating on.

Even if this stuff would work on thegraph side, it always would make sense to have a fail proof fallback as thegraph could go down (it did multiple times in the past and even a 30min downtime is quite bad).

1 Like

What is the actual latency and reliability with Pokt compared to others? Aave wasn’t down during the past few infura outages when things like MetaMask were down.

Regarding reliability, having over 45000 nodes with no single point of failure and geographic spread across 16 regions we can guarantee virtually 0% downtime.
For latency comparison please find the figures from our tests here:

P(90) time here means 90% of users received response time below that, and is a configurable parameter in POKT’s “cherry picker”.

To explain that I need to elaborate in a few sentences how the aave ipfs interface works and how it is potentially different to some other defi app interfaces.

The aave interface distinguishes between representation and execution on the rpc.
For the representation (market balances, your balances, governance states …) the interface uses public rpcs.
For the actual execution (supply, borrow, …) the interface uses the rpc of the connected wallet.

So when mm is down/ infura geo-blocking users you might still be able to interact with the app to a given point as the representation is relying on these public rpcs.
You might not be able to execute a transaction via your connected wallet if it relies on an rpc that doesn’t work at a given point in time though.

For most networks the aave interface relies on multiple rpcs on the representation layer, so when one goes down/geo-blocks or rate limits the user, another one will be used (a bit more complex then that, but this is the gist).

That said, for some networks there are not a lot public rpcs and the ones that exist are not very reliable. In good cases this results in increased latency. In bad cases in downtime on the representation.

Over the past year(s) the aave interface has added a few tricks to reduce rpc calls (e.g. the governance users some quite heavy caching to function with public rpcs / do some things sequentially instead of parallel resulting in bad ux, but less rpc calls per second), but still there are cases when the rate limits bring the application to a halt.

It’s hard to provide a reproduction for actual downtime, but here’s a reproduction where you can see how bad public rpcs perform on ethereum mainnet in certain cases. This is an official ipfs aave interface deployment hash from a month ago, so the cache on governance is not quite up to date:

For me it takes more than 30s to load, if it loads at all as sometimes it doesn’t do to rate limits on the cloudflare rpc.


The POKT proposal doesn’t suggest to change any of the things i wrote above, the interface will still rely on multiple prcs. In its core it’s about adding one more to the list with less limitations than the ones used right now.

A snapshot vote was created for this proposal:
https://snapshot.org/#/aave.eth/proposal/0x61ad521a6490c94a06237bcb650ae5011cddf08bc061e445a1053cb3d14b41e5

1 Like