Aave interface: the web app behind the Aave money market

What the interface actually does

The Aave interface is described as an open source interface for the decentralized liquidity protocol Aave, and the readme lists three things it enables users to do.

Users can manage and monitor their positions on the Aave Protocol and the overall status of it. They can manage and monitor their positions on the Aave Safety module, which is the part of the protocol that liquidates positions that fall below the health factor. And they can participate in Aave Governance.

That is a complete application, not a component. It is a wallet-connected front end that talks to the protocol across many chains, reads data from an API and a subgraph, and presents it.

The homepage is app.aave.com, the primary language is TypeScript, and the package name in the manifest is aave-ui. The repository listing shows a Next.js application with a pages/ directory alongside src/, a public/ directory, a cypress/ directory for end to end tests, and a patches/ directory, which tells you the project carries local patches to third-party packages.

The configuration in .env.example shows the shape of a real production application. There is a base URL for the Aave API v2, a governance cache API endpoint, a CoinGecko key, a TokenLogic REST API key for whole-protocol figures, a mixpanel key for analytics, and a set of per-chain private RPC keys covering mainnet, Polygon, Avalanche, Arbitrum, Base, Optimism, Metis, Gnosis, BNB, Scroll, zkSync, Linea, Sonic, Celo, Monad and a generic family entry. That list is the clearest single indicator of what this codebase has to deal with.

There is also a set of on-ramp integrations, with a Transak app URL, API URL and key, a fiat on ramp toggle, and a WalletConnect project id.

Running it locally

The local setup is three commands, and the toolchain is pinned tightly enough that you should read the first paragraph before running anything.

The readme says the project requires Node, with the version in .nvmrc, and pnpm v10 or newer. The repo pins [email protected] through the packageManager field, so running corepack enable will select the correct version automatically. The package manifest also declares the node engine as 24.x, which is a tighter constraint than the .nvmrc alone suggests.

Then:

cp .env.example .env.local
pnpm install
pnpm dev

The .env copy is the first step for a reason. The example file already contains working public values for several third-party services, including an API base URL, a Transak API key, an Amplitude key and a CoinGecko key, and blank placeholders for the things you must supply yourself, such as the per-chain private RPC keys and the Tenderly credentials. Copying it means you can run the app before you have configured a wallet or a subgraph key.

The scripts in the manifest show the shape of the build. dev runs next dev, and there is a dev:special variant that sets NODE_OPTIONS with --inspect and a raised --max_old_space_size of 8000 for the cases where the default heap is not enough. build runs next build, build:analyze sets ANALYZE=true, and build:static sets STATIC_EXPORT=true for a static export. The lint scripts run next lint over src and pages, and prettier over src, pages and cypress in check mode.

There is a separate build:optimize-svgs script that runs svgo over every SVG in public with six-way parallelism, and a serve:static script that serves the exported out/ directory with npx serve. The static export exists because the IPFS deployment needs it, since IPFS serves files rather than running a Next.js server.

IPFS deployment, and why the domain is a CNAME

The IPFS deployment section explains an architectural decision that is unusual for a web application, and it is the most interesting thing in the readme.

Each commit gets deployed to IPFS automatically, and a GitHub action comments the appropriate IPFS hash embedded in the Cloudflare IPFS gateway after each commit. The DNS of app.aave.com always points to the latest main IPFS hash.

So the production site is content-addressed. There is no server serving the application, and the canonical domain resolves to whatever the newest main-branch deployment hashed to. The readme calls it a decentralized manner and explains the consequence in the troubleshooting section: if you cannot connect to app.aave.com, you can use any public or private IPFS gateway supporting origin isolation, by going to a gateway plus /ipns/app.aave.com.

Two gateways are listed as having worked at some point, the Cloudflare one at app-aave-com.ipns.cf-ipfs.com and the dweb.link one at app-aave-com.ipns.dweb.link.

The security note attached to that advice is not decoration. The readme warns to make sure the gateway supports origin isolation to avoid possible security issues, and says you should be redirected to a URL that looks like https://app-aave-com.<your gateway>. The reasoning is that without origin isolation, a gateway serves content from multiple origins under one hostname, and a page with the ability to move value cannot be allowed to share an origin with content you did not intend to trust.

That is a real and often-missed property of IPFS hosting, and the readme treats it as the one thing a user must check.

There is also a feature toggle for testnet networks. Users enable test networks by opening the Settings menu and toggling the Testnet mode switch, after which test networks such as Sepolia and Mumbai become available in the network selection menu.

The dependency patches, and what they signal about the stack

The package.json has two blocks that say more about the project than any documentation would, the pnpm overrides and the patchedDependencies.

The overrides pin a long list of transitive dependencies: caniuse-lite at an exact version, protobufjs and qs at minimum versions, the React type packages, bignumber.js, axios, the ws package under ethers, form-data, d3-color, js-cookie, js-yaml, rollup, sharp and tmp. Some of those are security pins, since js-yaml is constrained to at least 4.0.0 and below 4.3.0 and resolved upward to 4.3.0.

The patchedDependencies block is more revealing. connectkit at 1.9.2 and @funkit/connect at 9.28.1 both carry local patch files in the patches/ directory. Both are wallet connection libraries, and the patch files are applied at install time by pnpm. When a project has to patch its own dependency, it is usually because a fix is needed that upstream has not taken, and the patch cannot be released yet.

Two details follow. The patched versions are pinned to exact numbers, so an upstream release will not be picked up silently, and a reviewer has to look at the patch files to know what changed and why.

The rest of the stack is visible in the repository listing: a .babelrc, an .eslintrc.js, a commitlint.config.js, a jest.config.js with a jest.setup.js for unit tests, a cypress.config.ts for end to end tests, svgo.config.js for the SVG pipeline, a crowdin.yml for translation, a .linguirc matching the Lingui i18n setup, and a .husky/ directory for git hooks.

There are also Sentry configurations for the client and the server, and the Tenderly keys in the environment file, so error reporting and transaction monitoring are part of the production setup rather than an afterthought.

Where the Aave interface is the wrong thing to fork

The first limitation is the licence. The readme's licence line is All Rights Reserved, copyright Aave Labs, linking to LICENSE.md, and a licence that GitHub cannot classify. The package manifest separately declares BSD-3-Clause, which is an inconsistency worth resolving before you rely on either. Whatever the outcome, the intent stated in the readme is clear: this is not permissively licensed, so the open source here is source-available for reading, contributing and running, not a base you can rebrand and ship.

The second is that it is an application, not a library. The manifest marks the package private, and there is no published API surface for reading Aave state from your own code. If you want Aave data in a dashboard or a bot, you want the protocol contracts or the API client, not this repository.

The third is the operational surface. The environment file lists private RPC keys for sixteen networks, an API key for the Aave API v2, a governance cache endpoint, a subgraph key, analytics keys, a CoinGecko key, a TokenLogic key and Tenderly credentials. Anyone wanting to run this needs a dozen external services configured before the application is fully functional, and a fork has to decide which of those keys it may share.

The fourth is the release cadence and the branch structure. The recent releases are named release-2026-10-20_13-57, release-2026-10-19_09-03 and release-2026-10-17_14-47, all titled Production release, which tells you that production deploys come from main commits on a near-daily schedule. A fork with a different release process has to reconcile that with the IPFS deployment, where every commit is published and the domain points at the newest one.

The fifth is the governance and contribution surface. Contributors with at least one merged pull request to main are eligible for a GitPOAP, and the contributing guide covers local development, deployment, configurations and feature proposals. That is a well-organised project, and it also means the expectations of a contributor are set by an existing process you would be joining or replacing.

Editorial conclusion

Aave interface fits a front-end developer who wants to work on a real DeFi application, since it is the code behind app.aave.com with the wallet connection, market data, governance and analytics all wired up, and since each commit is deployed to IPFS so the app stays reachable even if the hosting changes. It is the wrong choice if you need a library for reading Aave state from your own backend, since this is an application rather than a package, and it is the wrong choice if you want to self-host a copy under your own brand, since the licence reserves all rights to Aave Labs. Before contributing, read CONTRIBUTING.md for the local setup and deployment conventions, and note that the last push was on 2026-10-22 with production releases shipping most days.

Frequently asked questions

Official sources

1. aave/interface on GitHub
2. Issues
3. Project website
4. README
5. Releases