Deprecation of UiPoolDataProviders / UiIncentiveDataProviders

[sakulstra]

The two contracts UiPoolDataProviders and UiIncentiveDataProviders are inherently problematic for integrators.

Most importantly:

• they break on every upgrade, making them not very easy to use
• they are not deployed as part of the protocol, but by the maintainers of aave/interface who have their own release cadence (e.g. on aave v3.2 the version in address book was simply non functional for 10 days till it got updated). To make matters worse, some integrators now rely on a private fork of ours of the ui-pool-data-provider which we used for dash as it was deployed before avara deployed the 3.2 instances - our version isn't better and also breaks on each upgrade(just fetches a bit more data, which is even worse in every case).
• as pool upgrades never happen exactly at the same time across networks due to chain synchronisation times, even if the new providers were deployed, you need to exactly time the replacement on each network to not have a downtime on your interface
• testnets usually are not 100% in line with mainnets, so the uipooldataproviders are not actually equal

After the 3.2 upgrade we looked at a lot of integrator code and the reality is that they don't like the providers because of the issues mentioned before, but also because:

Lack of documentation

Upgrades happen randomly without announcing (e.g. 3.1 broke at some point because virtualBalance was added)
The code itself is the least documented thing on the aave-origin repo with not a single test touching it.

Over-fetching

1. Every more or less decent app knows after one call what the symbol/name/decimals and addresses(underlying a/v) of a reserve are. Most integrations we checked even store that info in some sort of backend or similar(not sure exactly how they keep in sync, we didn't see the backend implementation - i guess events or polling).
   So refetching these things on every call is wasteful and part of the reason why when benchmarking these calls are extremely slow.
2. These providers are built for aave/interface, same as the utilities. The use-case is not the same between integrations built on top and the interface. E.g. a leverage protocol built on top might only care about wstETH/WETH rates, but has zero interest in other reserves and no interest at all in things like unbacked, isolation/silo or irparameters. The only thing they might want is the rates of the two assets -> the current utils and providers force them to fetch & calculate everything though.

---

I think as long as there is no alternative to e.g. only fetch & calculate the current rate, providers need to stay part of the repository. Longer term though i think it makes sense to provide some finer grained utilities built on top of the native procoldataprovider. In case of 3.2 upgrade, there was no reason for any app to break due to stable debt removal - noone used stable rate already.

Bottom line is that the current state is not very good for users/consumers due to the reasons mentioned above.
More fine granular integration docs should be provided somewhere and rely on non breaking core components like the pdp - no custom contract that breaks on every upgrade.

[defispartan]

I think that maintaining the UiPoolDataProvider and UiIncentiveDataProvider contracts (or equivalent alternatives) in the address book is important to provide integrators with ability to integrate Aave data into applications requiring aggregated market and user data with the least amount of code. These view contracts are the best option that currently exists for developers to query Aave data in the most code-efficient manner.

Breaking Changes

The impact of breaking changes is not unique to UiPoolDataProvider or UiIncentiveDataProvider. Whether a contract is upgraded in place (like ProtocolDataProvider) or updated through separate deployments, a breaking ABI change will disrupt integrations either way.

I don't have a strong opinion on the best way to maintain Ui helpers for breaking changes moving forward. On one hand, I think that upgrading contracts in place is generally better, but I also think that managing view contracts with the complexities and edge cases of Ui helpers could cause unnecessary burden for Aave Governance.

One change that could remove some of this burden from the address book is removing Ui helpers from the Address Book ABI list. Since the ABIs are version-specific, it makes more sense to document them in that manner rather than having a universal ABI that only works on specific markets.

Documentation

The challenges with documentation are mostly a carryover from breaking changes. In terms of developer experience, Aave Labs maintains
contract documentation, aave-utilities SDK, and developer support in the Aave Discord to assist with any questions regarding the usage of helper contracts.

One area that the documentation can definitely be improved is providing references for the ABIS / Aave Utilities SDK methods that are currently supported for each market.

Overfetching

I don't think is a significant issue. The primary complaint that I see from integrators in the Aave Discord is often the opposite—that Pool and ProtocolDataProvider view methods underfetch, requiring multiple calls for the same data that the UI helpers can retrieve in one.

[sakulstra]

The impact of breaking changes is not unique to UiPoolDataProvider or UiIncentiveDataProvider. Whether a contract is upgraded in place (like ProtocolDataProvider) or updated through separate deployments, a breaking ABI change will disrupt integrations either way.

On the v3.2 upgrade we did quite excessive research on how integrators use aave, and ppl who properly used the ProtocolDataProvider had zero breaking changes. Same was true for aave v3.1.
The only cases were things broke were:

• ppl relying on ui providers
• ppl hardcoding the pdp, instead of fetching via addresses provider. The reason here is that the upgrade model of pdp is a bit different as with upgradability - the pdp get's replaced instead of upgraded.

One change that could remove some of this burden from the address book is removing Ui helpers from the

Having an address on address book that we don't actually know what it is exactly is a bit weird. To me it seems far more rational to put both the contract & the address on aave-utilities. For ux i think this would actually be a big improvement as each utilities version ships with it's compatible set of contracts & addresses.

I don't think is a significant issue. The primary complaint that I see from integrators in the Aave Discord is often the opposite—that Pool and ProtocolDataProvider view methods underfetch, requiring multiple calls for the same data that the UI helpers can retrieve in one.

Could you connect us with one of these integrators (or at least name them)? I'm a bit curious which integration would need all data for all reserves etc, as most i'm aware of are rather specialized. With 3.2 we tried to get in contact with the ones affected by liquid eModes and the feedback was in neither direction. The ones affected by the breaking changes in ui pool data provider, for the most part did not care about 95% of the data fetched and returned by provider and the aave-utilities - the only reason they are using it, is because it's the only well documented option that exists atm (so better fetch everything then inventing the utils outselfes).