Summary
Aave Labs is sharing a high level overview of the Aave V4 config engine, the tooling used to compose and execute onchain governance payloads that change protocol configuration. The config engine itself is not new: it has underpinned most Aave V2 and Aave V3 governance payloads for parameter updates, asset listings, and permission changes. Under Aave V4, it continues that role and takes on a larger surface given the protocol’s hub and spoke architecture.
Motivation
Governance proposals that change protocol configuration, for example interest rate parameters, asset caps, or role assignments, are executed through a payload contract that governance votes on and that the protocol’s executor runs once approved. Writing each payload by hand, calling low level setter functions directly against core contracts, is difficult to review line by line and leaves more room for mistakes.
The config engine addresses this by giving payload authors a standardized, typed interface for common configuration actions. Rather than each payload independently encoding calls to core contracts, a payload author expresses intent, such as a role grant or a reserve parameter update, and the engine translates that intent into the correct sequence of calls. This keeps payloads smaller and more consistent, and makes them easier for the community to review, since a function like accessManagerRoleMemberships() reads as an actual grant or revoke rather than a set of raw storage writes.
Specification
For Aave V4, the config engine is implemented as AaveV4ConfigEngine, a stateless contract invoked by delegatecall from the payload’s execution context, meaning it holds no state of its own. It acts as a facade over four sub-engines, each covering one area of protocol configuration:
- Hub actions: asset listings, asset configuration updates, halts, deactivations, cap resets, and management of which spokes are attached to which assets.
- Spoke actions: reserve listings, reserve and liquidation configuration updates, dynamic reserve configuration, and position manager updates at the spoke level.
- AccessManager actions: role memberships, role definition updates, target function role mappings, and admin delay updates.
- PositionManager actions: spoke registrations and role renouncements.
Payload authors inherit from AaveV4Payload, an abstract base contract, and override only the categories relevant to their proposal. Its execute() function runs the populated categories in a fixed order, with hooks available before and after execution for any custom logic a specific payload needs. This fixed, ordered execution is what keeps V4 payloads predictable to review regardless of author.
Aave V4’s hub and spoke architecture gives the config engine a larger surface than it had under Aave V2 or Aave V3, where a single pool contract covered most of this ground. Separating hub level actions (asset and spoke level configuration) from spoke level actions (reserve, liquidation, and position manager configuration) mirrors the protocol’s own separation of concerns, so a given payload only needs to touch the layer it is changing.
The implementation is public and available for review:
Aave Labs