BGD. stataToken v3


TL;DR

We present an EIP-4626 compatible generic aToken vault/wrapper for all Aave V3 pools with their current/future listed tokens https://github.com/bgd-labs/static-a-token-v3.


Context

Aave aToken’s growing balance was a big innovation in the space, one of the first uses of the so-called “rebasing” assets, directly improving the experience of end users: you deposit assets on Aave → you receive the same amount of aToken which grows over time on your wallet.

Moreover, certain models like Curve’s liquidity pools also integrate quite nicely with the growing balance nature of aTokens.

But for some other technical integrations (e.g. Balancer’s bb-pools), the growing balance on aTokens usually comes with an implementation overhead and unnecessary headaches.

During the last months supporting technical teams contributing to Aave, we have realized the need for an “official” Aave wrapper/vault contract, simple enough for anybody else to re-use or extend, without re-implementing it from scratch every time.


stataToken vault/wrapper

The idea of stataTokens (static aToken) is simple: a user with an asset listed on Aave like USDC can interact with the stataUSDC contract both with USDC and aUSDC to wrap it into its stataUSDC version, which represents exactly the same deposit on Aave, just not increasing in balance, but in value over time.

For example, let’s say a user deposits 100 USDC on Aave v3 Ethereum, and over time will have 102 aUSDC in his wallet. By interacting first with the stataUSDC, he would receive something like 99 stataUSDC, which will stay as 99 over time, but whose growth in value will allow him to withdraw the same 102 USDC as by holding its “plain” aToken version.

From an end-user perspective, the main use case is to have full control over the balance’s growth of token changes in his wallet. For example, user A maybe just wants to deposit 200 DAI into Aave but doesn’t want his balance to increase anyhow during the following year.

From a technical perspective, as previously mentioned, the goal of this development is to serve as both a usable smart contract from day 0, together with a base layer on which anybody else can build on top, by interacting with the deployed instances, or even by inheriting and modifying the codebase.
Everything with the assurances of being an “official” development for the Aave DAO.

The main technical features are the following:

  • Full EIP 4626 compatibility.
  • Accounting for any potential liquidity mining rewards. Let’s say some team of the Aave ecosystem (or the Aave community itself) decides to incentivize deposits of USDC on Aave v3 Ethereum. By holding stataUSDC, the user will still be eligible for those incentives.
    It is important to highlight that currently the wrapper only supports 1 reward token by design (e.g. AAVE incentivizing aUSDC), but this is something that can be added in the future without breaking changes.
  • Meta-transactions support. To enable interfaces to offer gasless transactions to deposit/withdraw on the wrapper/Aave protocol (also supported on Aave v3). Including permit() for transfers of the stataAToken itself.
  • Upgradable by the Aave governance. Similar to other contracts of the Aave ecosystem, the Level 1 executor (short executor) will be able to add new features to the deployed instances of the stataTokens.
  • Powered by a stataToken Factory. Whenever a token will be listed on Aave v3, anybody will be able to call the stataToken Factory to deploy an instance for the new asset, permissionless, but still assuring the code used and permissions are properly configured without any extra headache.
    Additionally, this Factory also acts as a token registry that can be used to query all the instances of stataTokens in the network.

Security procedures

For this project, the security procedures applied/being finished are:

  • The test suite of the codebase itself.
  • Certora audit/property checking for all the dynamics of the stataToken, including respecting all the specs of 4626.

IMPORTANT. We will share deployed addresses once the security procedures are finished, don’t use the wrapper in production before!


Next steps

Once the security procedures are finished, we will deploy stataTokens for all Aave v3 instances and share with the community the final documentation on how to interact and integrate them.

In parallel, we are already working with partners of the ecosystem like Balancer for their integrations.

21 Likes

thanks @bgdlabs for this proposal, it’s quite the game changer for Aave.

  • easier integration and will solidify Aave as the base layer of yield for DeFi.
  • allow new synergies with ecosystem actors (especially stableswaps)
  • some accountants will love stataTokens as it makes their life easier and for some jurisdictions change completely how yield should be considered (we don’t do financial & tax advice so if you read this talk to someone with a degree)

Full ACI support

6 Likes

Do i understand this correct?
This basically means Aave will be using a standard tokenized vault instead of aToken in future. And if others are following there is no need for aToken, sdToken,yToken and so on?

Basically a layer everybody could (and should) use in the future and making integrations therefor extremely easy?

Hi @EzR3aL .
Not exactly. This vault is oriented to simplify the deposit side into Aave, so the quite common use case of certain users/platforms of depositing in Aave (e.g. stablecoins), but not really borrowing against, just holding aTokens.

This doesn’t really replace the balance-growing aTokens; the Aave protocol operates and will keep operating with balance-growing aTokens, because they are extremely useful for a certain type of users. But as for others having a “static” balance is preferable, the stataToken allows to cover both approaches in a non-invasive way, which usually is known as “build on top”.

So yes, as you point out, just an additional optional layer than anybody can use in the future if needed.

2 Likes

I’ve been wanting one of these for some new products we have in mind. :hugs:

Thank you for releasing BGD! :pray:

2 Likes

Amazing, thank @bgdlabs!

In full support.

1 Like

Nice work!

Over at Buttonwood we have our own implementation of this concept, along with a wrapper that does the inverse - transforms a non-rebasing token into a rebasing one. It’s always good to see convergent evolution of designs, helps confirm they’re on the right track.

Glancing over the repo it looks like you’ve got everything covered, but if there’s any insight we can offer we’re happy to help.

5 Likes

After full completion of the security procedures with Certora, we can announce to the community that the stataToken Factories are deployed on all active networks with Aave instances, together with stataTokens for all assets listed on Aave on those.

As additional information and references:

  • We have included STATIC_A_TOKEN_FACTORY into aave-address-book, for all network where is deployed. For example HERE regarding Aave v3 Ethereum.
  • Given that the factory also acts as a registry, it is possible to query a stataToken address from its underlying by calling getStaticAToken(underlyingAddress) (e.g. HERE), together with a list of all stataTokens deployed from that factory via getStaticATokens() (e.g. HERE).
  • All proxy contracts are owned by the corresponding ProxyAdmin controlled by the Aave governance (Level 1/short executor) on each network.
  • As mentioned, we have gone through an extensive review/formal verification process with Certora, resulting on a set of properties implemented. A report is available HERE.
2 Likes

@bgdlabs So sorry to be a nuisance, but I would really like to test these out in a test net environment before deploying anything to mainnet, but I noticed that STATIC_A_TOKENS don’t appear to be deployed on any testnets? Is there any possibility that this might be a mistake and that they are deployed somewhere?

Hello @vor0220 you can find the new version deployed on sepolia here: feat: add static a token factory by sakulstra · Pull Request #294 · bgd-labs/aave-address-book · GitHub

Please let us know, if you need it on a different testnet.

Thanks so much for the fast response! I was actually hoping I could get this on Mumbai.

you can find mumbai in the same pr: feat: add static a token factory by sakulstra · Pull Request #294 · bgd-labs/aave-address-book · GitHub