Simple Summary
This ARFC seeks approval for the deployment of a new Aave V4 Isolated Hub and Spoke to onboard institutionally custodied collateral as collateral for stablecoin borrowing on Aave.
An institutional borrower deposits collateral with Anchorage and keeps it in custody for the life of the loan. The custodied balance is represented onchain as a non-transferable receipt token, the Custodied Collateral Token (CoCT), which is minted and burned by a Chainlink-designed CustodySync solution. The borrower posts CoCT on the Spoke and draws stablecoins supplied to the Isolated Hub. The full loan lifecycle, including liquidation, stays synchronised between the custodian and Aave through Chainlink infrastructure, so both sides can independently verify the position at all times.
The scope of this proposal is a single Isolated Hub and a single Spoke, both governed by the Aave DAO. No changes to existing Hubs, Spokes, or reserves are proposed.
Background
Custodied Collateral Lending
Institutional borrowers increasingly want to use assets held with a regulated custodian as collateral for onchain borrowing. The obstacle is that institutional custody and onchain lending are independent systems that were not built to communicate. Custodians hold assets offchain and manage the loan lifecycle through their own collateral management systems. Lending protocols operate entirely onchain and have no visibility into custody arrangements.
The integration proposed here resolves that gap without requiring the borrower to move assets out of custody.
Anchorage
Anchorage acts as the custodian. It holds the underlying collateral throughout the loan lifecycle, operates the collateral management system (CMS) that is the source of truth for collateral balances and loan lifecycle events, and is the counterparty to the borrower under an Account Control Agreement.
The underlying collateral never moves onchain and is never held by Chainlink, the CustodySync, or Aave.
Chainlink CustodySync
Chainlink is the orchestration layer between the two systems. Chainlink has built the solution, operates the Chainlink Runtime Environment (CRE) workflows that reconcile custody state to onchain state, maintains the onchain Proof of Reserve record of the custodied balance, and synchronizes onchain protocol state with the custodian CMS so that the two systems reflect same position data.
Chainlink does not hold assets at any point in the workflow. The CustodySync holds no asset of commercial value at any point; collateral remains within custodian and borrowed stablecoins are routed atomically from the protocol to the borrower in a single transaction.
Aave V4
Aave V4’s Hub-and-Spoke architecture allows this integration to be deployed in a fully isolated environment. A dedicated Isolated Hub and Spoke means custodied collateral is listed and borrowed against without any exposure path to assets or reserves on other Hubs, while the DAO retains complete control over every parameter and cap on both contracts.
V4 also supports the integration natively at the position level. Spoke reserves are keyed by the pair of Hub address and asset, positions on a Spoke are cross-margined across the reserves they hold, and a Hub only checks whether a whitelisted Spoke is within its draw cap. This gives the DAO a clean permission surface for onboarding borrowers and a natural upgrade path as the product matures, with no redeployment of the Spoke and no change to the borrower integration.
Motivation
The integration onboards a class of collateral that is currently unreachable for Aave: assets held with a regulated custodian by institutional borrowers who cannot or will not self-custody. It does so while preserving the properties Aave depends on. Liquidation remains enforceable, collateral valuation remains oracle-driven from Chainlink data, and the DAO controls listing, caps, and risk parameters.
For Aave this adds institutional stablecoin borrowing demand against collateral that does not compete with existing reserves, in a venue that is isolated by construction. For borrowers it removes the custody transfer that has kept regulated institutions out of onchain credit markets. The CoCT and CustodySync design is a reusable standard, so each additional borrower is an incremental listing rather than a new integration.
Specification
This ARFC is scoped to the integration architecture and the deployment of the Isolated Hub and Spoke. Risk parameters, oracle configuration, caps, and interest rate strategy are addressed in the section below and will be finalised with the DAO’s risk service providers prior to the AIP.
The integration deploys one new Hub, one new Spoke, and one bridge stack per onboarded borrower. It introduces no change to existing Aave deployments.
1. Custodied Collateral Isolated Hub
A new Aave V4 Hub, governed by the Aave DAO. It lists the stablecoin loan assets for the program and every CoCT issued by the integration.
Stablecoin liquidity enters the Hub through a separate lender-facing Spoke, which is what makes the Isolated Hub a functioning market rather than a pass-through. Each stablecoin is listed once on the Hub and shared by every borrower that draws it.
2. Custodied Collateral Spoke
A new Spoke using Aave V4’s standard open-source Spoke implementation. It lists each CoCT instance as a collateral reserve and stablecoins as loan reserves, and draws liquidity from the Isolated Hub.
The Spoke is the only venue through which CoCT is used as collateral. All borrower interaction is mediated by the CustodySync; borrowers do not interact with the Spoke directly.
3. Custodied Collateral Token (CoCT)
CoCT is an internal accounting unit required to interface with Aave V4’s ERC-20 collateral interface. It is not a tradable or transferable representation of the custodied asset and carries no direct claim on it; legal recourse runs through the collateral Account Control Agreement.
-
Transfer-restricted ERC-20, with destinations limited to a fixed allowlist covering the Aave V4 Hub, the Spoke, and the CustodySync.
-
Mint and burn authority held exclusively by the CustodySync. No other mint or burn path exists.
-
One CoCT contract per borrower position, authorising exactly one CustodySync instance.
-
Total supply tracks the custodied balance reported for an individual borrow position, adjusted for any open liquidation commitment during a settlement window.
4. CustodySync and Chainlink Infrastructure
The CustodySync is the central execution contract. All collateral updates, borrows, repayments, and liquidation settlements route through it, and it is the only contract authorised to interact with Aave on behalf of the borrower position. It is developed by Chainlink and deployed and administered under DAO control, with per-function permissions granted to the Chainlink CRE address, the custodian wallet, and the borrower address.
Supporting Chainlink components are the onchain Price Feed for the collateral asset, consumed directly by the protocol and mirrored offchain to the custodian CMS through Data Streams; the Proof of Reserve contract recording the custodied balance; and an optional synthetic price oracle used during liquidation settlement windows.
Collateral state is reconciled rather than replayed. On each cycle, Chainlink CRE reads the custodied balance and the set of open liquidation commitments from the CMS and calls the bridge, which computes a target CoCT supply and mints or burns the difference. Missed or late events are self-healing, because the next sync targets the correct state. Withdrawals remain subject to Aave’s native health check, which rejects any burn that would leave an active position undercollateralised.
5. Loan Lifecycle
The borrower calls the CustodySync bridge to borrow, and stablecoins are routed from the Spoke to the borrower’s address in the same atomic transaction. Repayment is initiated by the borrower or the custodian wallet and reduces protocol debt without releasing collateral. Interest accrual is read from the protocol on a fixed cadence and written back to the custodian CMS so that both sides price the same exposure. Collateral additions and margin returns flow through the same reconciliation path described above.
6. Liquidation
Liquidation is executed by the custodian as an OTC sale of the underlying collateral, with the proceeds used to settle the onchain position. When a liquidation is triggered, the custodian registers a liquidation commitment. Each commitment carries a unique liquidation ID, and partial liquidations are supported natively. During the settlement window, the committed proceeds are recorded onchain and reflected in the CoCT price so that the position is not liquidated out from under the custodian’s controlled process. Settlement is a single atomic transaction that repays the debt, withdraws the CoCT, burns it, and clears the commitment; it reverts entirely if any step fails.
Because CoCT transfers are permissioned, receiveSharesEnabled must be set to true on the CoCT reserve. With receive shares disabled, a liquidation would attempt to send CoCT to an arbitrary liquidator address, which fails against the transfer allowlist and would leave the position uncurable.
7. Listing Policy and Risk Parameters
The following are proposed as structural listing policy for the Isolated Hub and Spoke, independent of risk calibration:
-
CoCT draw cap set to zero for every Spoke on the Isolated Hub, permanently. There is no Hub-level concept of a non-borrowable asset, so a permanent zero draw cap is what guarantees tokens representing custodied collateral cannot be drawn out of the Hub.
-
CoCT reserves marked non-borrowable on the Spoke, with receiveSharesEnabled set to true.
-
CoCT add cap sized to the individual borrower’s custody position.
-
Onboarding a borrower requires four permissioned actions on DAO-controlled contracts: adding the CoCT as a Hub asset, adding the Spoke to that asset with an add cap, adding the collateral reserve on the Spoke, and setting the reserve price source. This ARFC proposes to initially list a single CoCT instance representing BTC pledged as collateral held within Anchorage custody.
In its current design, a governance proposal is required to new CoCT instances as collatgeral. A future proposal could designate a role scoped to onboard CoCT instances according to DAO-approved terms to reduce governance burden of onboarding individual borrowers.
Collateral factor, liquidation bonus and fee, target health factor, supply and borrow caps, interest rate strategy, and oracle configuration will be recommended by the DAO’s risk service providers and included in the AIP.
Disclaimer
This proposal has been prepared to facilitate community discussion. The authors have not been compensated by any third party to publish it.
Next Steps
-
ARFC: Gather community and service provider feedback on the deployment of the Custodied Collateral Isolated Hub and Spoke, the listing of CoCT as a collateral asset, the delegated onboarding permissions, and the risk parameters to be applied.
-
Snapshot: If sentiment is positive, submit this ARFC to Snapshot for a vote.
-
AIP: If the ARFC Snapshot passes, submit the proposal as an AIP with final parameters for onchain governance approval and execution.
Copyright
Copyright and related rights waived via CC0.
