Thank you BGD Labs for the feedback. Though receiving it so close to the release is surprising, given that the proposal has been public for months, discussed widely, and advanced through TEMP CHECK and ARFC votes. Many of the points raised were addressed earlier in this thread and in the first post.
On versioning (v3.3 vs v3.5) and launch feasibility
We built Horizon on Aave v3.3 because it was the latest stable base when the technical work started. The Aave Protocol has been iterating continuously since the initial proposal was drafted. It’s basically impossible to rebase on each release, especially when custom changes are required. Moving Horizon to v3.5 now would mean repeating major engineering work, new security reviews and audits, partner integrations, and end‑to‑end testing. That would likely delay launch by months and put business development at risk. The plan is to move Horizon to 3.5 as soon as possible after release in order to bring it up to speed with the latest protocol version.
On “Operational” vs “Executive” roles
Obviously, we disagree with this interpretation of “executive” vs “operational” roles. A simple google or AI query would easily confirm how our interpretation of these roles is essentially correct. The design delegates executive decisions to centralized, accountable entities (appropriate for this asset class) and assigns onchain operations, specifically smart contract upgrades, to the DAO through ownership of the contracts. This is laid out in the proposal since the first iteration. We believe that the fact that the DAO could potentially exercise executive power, if wanted, has no meaning substantially. Especially with onchain governance, where no single entity can independently decide on whether or not to perform an action. Finally, this creates a much more robust and secure setup as there is no multisig controlling the funds, as also acknowledged by BGD labs.
This is also surprising:
We want to remind BGD Labs that Aave Labs is not “external to the DAO”, it is in fact a Service Provider and active community member. The code produced for the Horizon RWA instance has been reviewed by SPs @Certora and @LlamaRisk , while SPs @ChaosLabs and @TokenLogic were also involved in the project. The Horizon RWA Instance isn’t just a plain, “infrastructural” usage of the Aave Protocol code. It’s strongly tied to the Aave DAO and that was the intention since the beginning, as highlighted by the 50/50 involvement in incentives and revenue share and as approved by the community twice through TempCheck and ARFC.
Next steps
Extensive technical, legal and compliance work has been conducted over the last five months to ensure that the required code changes and the configuration fit the needs of asset issuers and all the parties involved. Making these changes now, either changing the control model or rebasing to a new release, would delay launch by months, compromise the business development completed to date, and put the whole Horizon project at high risk.
We will move forward as planned in the original proposal, and launching on the v3.3 base and setting a clear upgrade path post‑launch with auditors and relevant service providers. If the activation AIP is voted positively, we are open to implement any additional work the DAO may require and to plan upgrades that keep Horizon reasonably close to upstream, with appropriate risk controls and audits. As the Horizon configuration can be also technically changed pretty easily, we are open to re-discuss with the DAO another setup if it’s finally determined that the current approach doesn’t fit the DAO expectations.
We appreciate the continued collaboration from service providers and the community and look forward to delivering Horizon as already approved by the community. We are also looking forward to collaborating with every Service Provider, but we want to ultimately highlight the importance of providing feedback in a consistent and timely manner to avoid disrupting work flows.