Skip to content

Commit 2e176d9

Browse files
authored
feat: docs on RWA Price Oracle Safeguards + Horizon marketing update (#30)
1 parent 6e2a51e commit 2e176d9

4 files changed

Lines changed: 18 additions & 12 deletions

File tree

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -95,7 +95,7 @@ In addition, Enigma Dark has adapted the Foundry-based fuzzing [invariant suite]
9595

9696
<br>
9797

98-
**-> Horizon Aave v3.3 - July 2025**
98+
**-> Aave Horizon (v3.3) - July 2025**
9999

100100
- [Certora](./audits/2025-05-30_Certora_Horizon-v3.3.0.pdf)
101101
- [StErMi](./audits/2025-06-25_StErMi_Horizon-v3.3.0.pdf)
File renamed without changes.
File renamed without changes.
Lines changed: 17 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,22 +1,22 @@
1-
# Horizon RWA Instance
1+
# Aave Horizon RWA Instance
22

33
## Context
44

5-
- Horizon is an initiative by Aave Labs focused on creating Real-World Asset (RWA) products tailored for institutions.
6-
- Horizon will launch a licensed, separate instance of the Aave Protocol (initially a fork of v3.3) to accommodate regulatory compliance requirements associated with RWA products.
7-
- Horizon will have a dual role setup with responsibilities split between Aave DAO (Operational role) and Aave Labs (Executive role).
5+
- Aave Horizon is an initiative by Aave Labs focused on creating Real-World Asset (RWA) products tailored for institutions.
6+
- Aave Horizon will launch a licensed, separate instance of the Aave Protocol (initially a fork of v3.3) to accommodate regulatory compliance requirements associated with RWA products.
7+
- Aave Horizon will have a dual role setup with responsibilities split between Aave DAO (Operational role) and Aave Labs (Executive role).
88

99
## Overview
1010

11-
The Horizon Instance will introduce permissioned (RWA) assets. The Aave Pool will remain the same, except that RWA assets can be used as collateral in order to borrow stablecoins (or other permissionless non-RWA assets). Permissioning occurs at the asset level, with each RWA Token issuer enforcing asset-specific restrictions directly into their ERC-20 token. The Aave Pool is agnostic to each specific RWA implementation and its asset-level permissioning.
11+
The Aave Horizon Instance will introduce permissioned (RWA) assets. The Aave Pool will remain the same, except that RWA assets can be used as collateral in order to borrow stablecoins (or other permissionless non-RWA assets). Permissioning occurs at the asset level, with each RWA Token issuer enforcing asset-specific restrictions directly into their ERC-20 token. The Aave Pool is agnostic to each specific RWA implementation and its asset-level permissioning.
1212

1313
From an Issuer perspective, RwaATokens are an extension of the RWA Tokens, which are securities. These RWA-specific aTokens (which are themselves not securities) will simply signify receipt of ownership of the supplied underlying RWA Token, but holders retain control over their RWA Token and can withdraw them as desired within collateralization limits.
1414

1515
However, holding an RwaAToken is purposefully more restrictive than merely holding an RWA Token. RWA Tokens subject holders to Issuer whitelisting and transfer mechanisms, but RwaATokens are fully locked and cannot be transferred by holders themselves.
1616

1717
For added security and robustness, a protocol-wide RWA aToken Transfer Admin is also added, allowing Issuers the ability to forcibly transfer RWA aTokens on behalf of end users (without needing approval). These transfers will still enforce collateralization and health factor requirements as in existing Aave peer-to-peer aToken transfers.
1818

19-
As with the standard Aave instance, an asset can be listed in Horizon through the usual configuration process. This instance is primarily aimed at onboarding stablecoins (or other non-RWA assets) to be borrowed by RWA holders.
19+
As with the standard Aave instance, an asset can be listed in Aave Horizon through the usual configuration process. This instance is primarily aimed at onboarding stablecoins (or other non-RWA assets) to be borrowed by RWA holders.
2020

2121
## Implementation
2222

@@ -101,7 +101,7 @@ Stablecoins, or other non-RWA permissionless assets, may also be configured as c
101101

102102
## Edge Cases of Note
103103

104-
Consider the following scenarios involving the example permissioned `RWA_1` token. Flashloans may be utilized from other protocols if disabled in Horizon.
104+
Consider the following scenarios involving the example permissioned `RWA_1` token. Flashloans may be utilized from other protocols if disabled in Aave Horizon.
105105

106106
### RWA Holder Loses Private Keys to Wallet
107107

@@ -134,15 +134,15 @@ At the conclusion, `RWA_1_ISSUER` will have migrated both `ALICE`'s initial debt
134134

135135
#### Limitations
136136

137-
There may not be ample liquidity in the Horizon Pool to cover via flashloan the debt position to migrate. Under those circumstances, it is the responsibility of the Issuer to provide liquidity or resolve as needed.
137+
There may not be ample liquidity in the Aave Horizon Pool to cover via flashloan the debt position to migrate. Under those circumstances, it is the responsibility of the Issuer to provide liquidity or resolve as needed.
138138

139139
### RWA Holder Becomes Sanctioned After Creating a Debt Position
140140

141141
If a user creates a debt position but then becomes sanctioned, their actions may need to be blocked until further resolution. Consider the following scenario.
142142

143143
#### Assumptions
144144

145-
- `RWA_1` has a `80% LTV` in Horizon.
145+
- `RWA_1` has a `80% LTV` in Aave Horizon.
146146

147147
#### Context
148148

@@ -176,7 +176,7 @@ This theoretically allows recipients to open stablecoin debt positions without o
176176
Assumptions:
177177

178178
- `RWA_1_ISSUER` has been granted `AUTHORIZED_TRANSFER_ROLE` in the RwaATokenManager contract for `aRWA_1`..
179-
- `ALICE` is allowlisted to hold `RWA_1` and has supplied `100 RWA_1` to Horizon, receiving `100 aRWA_1`.
179+
- `ALICE` is allowlisted to hold `RWA_1` and has supplied `100 RWA_1` to Aave Horizon, receiving `100 aRWA_1`.
180180
- `BOB` is not allowlisted to hold `RWA_1`.
181181

182182
1. `RWA_1_ISSUER` executes `authorizedTransfer` from `ALICE` to `BOB` for `100 aRWA_1`.
@@ -251,7 +251,7 @@ Assumptions:
251251

252252
- `BOB` and `ALICE` are allowlisted to hold `RWA_1`.
253253
- `ALICE` has an off-chain legal agreement with `RWA_1_ISSUER` to be able to be a liquidator.
254-
- `LTV` of `RWA_1` is `>80%` in Horizon.
254+
- `LTV` of `RWA_1` is `>80%` in Aave Horizon.
255255
- `RWA_1` and `aRWA_1` have decimals of 8.
256256

257257
Consider the following scenario:
@@ -318,6 +318,12 @@ The Issuer's Transfer Agent must properly record this officially as a transfer o
318318

319319
Exact configuration details for eMode, isolated mode, flashloan fees, and liquidity mining rewards are to be determined.
320320

321+
## RWA Price Oracle Safeguards
322+
323+
Unlike crypto-native assets priced by decentralized exchange markets, RWAs rely on a Net Asset Value (NAV) reported directly by the asset issuer. This introduces a critical risk vector: the potential for delayed, inaccurate, or malicious price reporting. A simple operational error or a malicious act could lead to an incorrect NAV being published onchain, which could trigger faulty liquidations across the market. While an emergency steward can reactively freeze the reserve, this process introduces operational delays, creating a window where whitelisted liquidators could exploit a faulty price and cause irreparable harm to borrowers.
324+
325+
Aave Horizon implements a robust, automated safeguard directly at the Oracle level to mitigate this risk. In partnership with Chainlink and LlamaRisk, pre-defined upper and lower price bounds are configured for each RWA price feed at the Decentralized Oracle Network (DON) level. When an issuer reports a new NAV, the Chainlink DON validates it against these bounds before publishing it onchain. If the reported NAV is within the bounds, the update is accepted. If it is outside the bounds, the DON rejects the update, and the oracle continues to report the last known valid price. This proactive mechanism prevents a faulty price from ever reaching the Aave Horizon protocol, eliminating the risk of erroneous liquidations. Furthermore, any breach of these price bounds is paired with a time-sensitive reaction from Aave Horizon's emergency steward to prevent new debt originations and additional exposure until the root cause analysis is performed.
326+
321327
## References
322328

323329
- https://governance.aave.com/t/arfc-horizon-s-rwa-instance/21898

0 commit comments

Comments
 (0)