[ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4

[SentoraHQ]

[ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4

Summary

This ARFC establishes a framework for Sentora to operate Hub and Spoke instances on Aave V4, and authorises the first instance on Ethereum.

Hub and Spoke instances deployed under this framework are externally curated instances, independently managed by Sentora, which holds curation over collateral selection, risk parameters, interest rate curves, and oracles across its markets. Curation of these instances sits outside the risk management mandate of the Aave DAO and its service providers.

The Aave DAO retains smart contract and admin role ownership through the Aave DAO Governance Short Executor, and grants Sentora revocable operational roles. Sentora executes ongoing changes through an optimistic model: risk-reducing actions execute instantly, while risk-increasing updates require a 48-hour onchain timelock, and new Hub deployments and new collateral markets require a 2-week optimistic governance process.

The stablecoin surface is restricted to RLUSD, PYUSD and OUSD, and the Aave DAO receives 50% of instance revenue. No credit lines to or from Aave DAO Hubs are authorised here, and establishing one would require a separate proposal in accordance with the Aave Risk Framework.

Motivation

Sentora currently operates curated lending market strategies across several isolated venues. That fragments liquidity, duplicates risk operations across incompatible parameter models, and requires separate monitoring and tooling for each venue. Aave V4 is the first architecture that permits consolidation without giving up curation control, because the Hub and Spoke model lets one liquidity domain serve several Spokes with distinct collateral sets and distinct risk configurations.

For the Aave DAO, the deposits involved sit on external venues today, so the instance adds to Aave liquidity and revenue potential, and establishes Aave as a primary venue for RLUSD, PYUSD, and OUSD stablecoin growth.

Market Structure

The diagram below shows the target state of the first instance, a single Liquidity Hub on Ethereum serving as the sole liquidity domain for all Sentora Spokes on that network, isolated from other Aave markets. No credit lines to or from other Aave Hubs are proposed here.

Hub assets are split into two distinct categories: borrowable liquidity and collateral-only assets.

RLUSD, PYUSD, and OUSD serve as the sole borrowable liquidity, each supplied with independent interest rate curves and drawn by the Spokes. All other registered assets function strictly as collateral, configured with a 0% interest rate and a zero draw cap across every Spoke. Consequently, all debt issued by the instance is denominated exclusively in RLUSD, PYUSD, or OUSD.

The deployment launches with three initial Spokes segmented by risk profile, with a fourth planned for later deployment. The RLUSD Yield Spoke offers RLUSD borrowing against yield-bearing collateral: initially USDe and Huma PST, with planned expansion to assets like PRIME and mWIN. The Bluechip Spoke offers RLUSD borrowing against kBTC. A third spoke, OUSD Yield, will have a similar set up to the RLUSD Yield spoke, replacing the corresponding borrowed asset. Lastly PYUSD Yield, will launch subsequently to mirror the yield-bearing model with PYUSD debt against a tailored collateral selection. Collateral sets across all Spokes are expected to expand over time, with every new asset onboarding subject to the governance veto process.

Instance Management

Sentora serves as operational manager for the instance, holding authority over risk, growth, and market configuration. Aave DAO maintains smart contract and admin role ownership via the Aave DAO Governance Short Executor to protect ecosystem security and alignment, which does not place the instance within the risk management mandate of Aave DAO service providers.

The instance’s assets, risk parameters, interest rate curves, liquidation configurations, and oracles are selected and maintained solely by Sentora. They have not been reviewed against the Aave Risk Framework and are not maintained under it. The Aave DAO’s risk service providers carry no mandate to monitor the instance, to produce parameter recommendations for it, or to perform incident response on it, and none is engaged or compensated to do so. Service providers retain the ability to raise objections and to bring matters to governance where they judge that competitive alignment or systemic risk considerations warrant it, at their own discretion and on their own initiative.

Aave V4 natively implements the OpenZeppelin AccessManager across all privileged configurator functions, enabling operational boundaries through granular, account-specific role delays rather than custodial transfers. Sentora owns none of the deployed contracts and acts exclusively through revocable roles granted to the Sentora operational address and a dedicated intermediate Risk Steward contract:

grantRole(SENTORA_RESTRICTIVE_ROLE, sentoraAddress, 0) // risk-reducing

grantRole(SENTORA_MANAGED_ROLE, sentoraAddress, 172800) // risk-increasing

grantRole(SENTORA_MANAGED_ROLE, sentoraRiskSteward, 0) // risk-reducing

Emergency risk mitigation is handled via the Restrictive Role, allowing the Sentora operational address to immediately execute functions such as pauseReserve, freezeReserve, haltAsset, haltSpoke, and resetting caps in the calling transaction.

Routine market operations sit inside the Managed Role and follow an optimistic model split into two execution paths based on risk direction:

• Risk-Reducing Actions (Zero Delay): Sentora executes these in the same block via an extended Risk Steward contract. The Steward exposes a restricted, one-way numeric entrypoint covering granular parameter cuts such as reducing collateral factors, tightening collateral risk, or lowering add and draw caps. The Steward verifies that updates move strictly in the risk-reducing direction.

• Risk-Increasing Actions (48-Hour Delay): Any parameter movement that increases risk, such as raising collateral factors or expanding caps, as well as parameters where the risk direction is ambiguous, such as interest rate models and liquidation configurations, cannot pass through the Risk Steward. These changes must be scheduled directly on the AccessManager by the Sentora operational address and await a mandatory 48-hour onchain timelock before execution. Ambiguous functions are classified as risk-increasing.

The 48-hour delay is the constraint on the risk-increasing path. It provides a fixed observation window during which any scheduled change is visible onchain before it takes effect. Increases are not bounded in magnitude and are not subject to cooldowns between updates, so a large parameter change and a small one are delayed identically. The Aave DAO does not hold a mechanism to cancel an individual scheduled operation inside the window. The recourse available to the Aave DAO is revocation of Sentora’s role grants through an onchain governance proposal, which removes Sentora’s authority over the instance going forward.

Asset listings and new Hub deployments follow an optimistic two-week governance review. Sentora submits its proposal and market analysis to the Aave governance forum, opening a two-week window for review. If any appointed Aave DAO service provider objects within this window, the action immediately pauses and moves to a binding Snapshot vote. Sentora cannot proceed with onchain scheduling or deployment while a Snapshot is pending. The window is an opportunity to object rather than a review commitment. No service provider is scoped or compensated to review these submissions, and the absence of an objection does not indicate that a review was performed.

Aave DAO Oversight

The Aave DAO Governance Short Executor retains structural ownership of the instance, holding the admin roles across all Hub and Spoke contracts, configurators, and the native AccessManager. Core protocol controls are never delegated to Sentora, including smart contract upgrades and role assignments. The Short Executor sits above all operational flows, retaining the right to revoke Sentora’s role grants through an onchain governance proposal.

For new Hub deployments or asset additions, the DAO exercises governance control through an optimistic two-week forum review. If any appointed Aave DAO service provider objects within this window, the rollout halts and escalates to a binding Snapshot vote. Sentora cannot proceed with deployment or onchain execution while a Snapshot vote is pending.

Ownership is retained so that the deployment remains inside the Aave V4 codebase and upgrade path, and so that the ability to halt a deployment or listing, or to withdraw Sentora’s authority entirely, stays with the Aave DAO and can be exercised at its discretion. Ownership is not an assertion that the Aave DAO or its service providers manage risk on the instance.

Aave DAO Alignment

To preserve alignment with core Aave DAO markets, this framework imposes structural, commercial, and operational bounds.

RLUSD, PYUSD, and OUSD serve as the exclusive borrowable stablecoins across any Sentora Hub, with USDC and USDT permanently excluded to avoid conflicting with existing Aave market liquidity. A minimum reserve factor of 20% applies to every asset on the Hub, which Sentora may raise but never lower.

All protocol revenue generated by the instance (including reserve factor earnings, protocol liquidation fees, and related fee streams) is split 50% to the Aave DAO and 50% to Sentora, settled directly onchain with zero operating costs borne by the Aave DAO.

These economic and market bounds function directly alongside the Aave DAO’s governance ownership. Because the Aave DAO retains underlying contract ownership through the Short Executor, enforces a 48-hour timelock on risk-increasing calls, and maintains veto authority over new assets and Hubs, the Aave DAO retains the ability to act where competitive alignment or systemic risk considerations require it.

Specification

Collateral & Loan Assets

The Sentora Hub proposes to connect three new spokes

Spoke	Borrowable	Collateral Only
Sentora RLUSD Yield	RLUSD	USDe, PRIME, mWIN, PST
Sentora OUSD Yield	OUSD	USDe, PRIME, mWIN, PST
Sentora Bluechip	RLUSD, PYUSD, OUSD	kBTC

Spoke Parameters

Collateral factors, risk premiums and liquidation fees are adjusted based on each asset’s specifications.

Spoke(s)	Reserve	Collateral Factor	Max Liquidation Bonus	Borrowable	Collateral Risk	Liquidation Fee
Sentora RLUSD Yield, Sentora OUSD Yield	USDe	91.5%	3.5%	No	6.25%	3.5%
Sentora RLUSD Yield, Sentora OUSD Yield	PRIME	89.5%	5.0%	No	18.75%	5.0%
Sentora RLUSD Yield, Sentora OUSD Yield	mWIN	84.6%	7.5%	No	0%	7.5%
Sentora RLUSD Yield, Sentora OUSD Yield	PST	87.5%	5.0%	No	75.0%	5.0%
Sentora Bluechip	kBTC	86.0%	4.5%	No	0%	4.5%

Add & Draw Caps

Spoke	Asset	Add Cap	Draw Cap
Sentora RLUSD Yield	RLUSD	100,000,000	90,000,000
Sentora RLUSD Yield	USDe	50,000,000	0
Sentora RLUSD Yield	PRIME	15,000,000	0
Sentora RLUSD Yield	mWIN	75	0
Sentora RLUSD Yield	PST	20,000,000	0
Sentora OUSD Yield	OUSD	10,000,000	9,000,000
Sentora OUSD Yield	USDe	5,000,000	0
Sentora OUSD Yield	PRIME	1,500,000	0
Sentora OUSD Yield	mWIN	7	0
Sentora OUSD Yield	PST	2,000,000	0
Sentora Bluechip	RLUSD	33,300,000	30,000,000
Sentora Bluechip	PYUSD	33,300,000	30,000,000
Sentora Bluechip	OUSD	5,000,000	4,500,000
Sentora Bluechip	kBTC	580	0

Interest Rate Curves

The borrowable assets use one rate curve with a kink at 90% usage. RLUSD, PYUSD and OUSD use the same curve.

Parameter	Value	Meaning
Base Drawn Rate	0.50%	Borrow rate at 0% usage
Optimal Usage Ratio	90.00%	Usage level where the slope changes
Rate Growth Before Optimal	3.50%	The borrow rate goes up from 0.50% to 4.00% between 0% and 90% usage
Rate Growth After Optimal	12.00%	The borrow rate goes up from 4.00% to 16.00% between 90% and 100% usage
Liquidity Fee	20.00%	Share of the interest that goes to the Fee Receiver

The collateral-only assets use a flat 0% rate curve. USDe, PRIME, mWIN, PST and kBTC use the same curve. The contract does not accept an Optimal Usage Ratio of 0, so the ratio is 90%. With all rate values at 0, the borrow rate is 0% at every usage level.

Parameter	Value
Base Drawn Rate	0.00%
Optimal Usage Ratio	90.00%
Rate Growth Before Optimal	0.00%
Rate Growth After Optimal	0.00%
Liquidity Fee	0.00%

Oracle Configuration

Asset	Price feed	Feed address
RLUSD	Chainlink RLUSD/USD	0x26C46B7aD0012cA71F2298ada567dC9Af14E7f2A
PYUSD	Chainlink PYUSD/USD	0x8f1dF6D7F2db73eECE86a18b4381F4707b918FB1
OUSD	Not defined	To be confirmed prior to launch
USDe	Chainlink USDe/USD	0xa569d910839Ae8865Da8F8e70FfFb0cBA869F961
PRIME	Chainlink PRIME/wYLDS exchange rate, with wYLDS at 1 USD	0xf17C0EdcAA28371e9c8012D7699bF40ECF0F58d1
mWIN	Midas mWIN/USD NAV feed	0x1725A66D810C0775f6B3B0FD85646D371dA19517
PST	Chainlink PST/USDC exchange rate x Chainlink USDC/USD	0x4BE50bE32dB1510240d542f77c5B36Ca0D0965E6, 0x8fFfFfd4AfB6115b954Bd326cbe7B4BA576818f6
kBTC	Chainlink BTC/USD, with kBTC at 1 BTC	0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c

Next Steps

1. ARFC: Gather community and service provider feedback on the adoption of Sentora Externally Curated Hub & Spoke Framework on Aave V4.

2. Snapshot: If sentiment is positive, submit this ARFC to Snapshot for a vote.

3. 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.

[CryptoInvest]

Interesting proposal Aave could expand as a credit infrastructure and not only as bank

The next Aave is Aave

(not Morpho)

[AaveLabs]

The ARFC to activate the Sentora Externally Curated Hub & Spoke Framework on Aave V4 has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here

[trevorsc]

Thanks to Sentora for putting this forward. Isolating curated risk in its own Hub is exactly what V4 was built for, and I’d like to see more of it.

Because this would be the first externally curated V4 Hub, though, its terms will likely become the default for every curator that follows. I’d suggest that Aave set the bar for a curator deployment around three questions: what the DAO earns, how that’s enforced, and how the DAO exits if it doesn’t work out. Before this moves to AIP, I’d like to understand those for this proposal.

1. Revenue base and scale. The split covers “protocol revenue” (reserve factor plus protocol liquidation fees), while Sentora sets the interest rate model (IRM), the reserve factor above the 20% floor, and listings. By my rough math, if the draw caps (about $163.5M) were fully drawn at the 4% kink rate, the DAO’s share would be about $0.65M a year, before any collateral risk premiums. Could Sentora share:

• 6 and 12-month projections for supply, draws, and DAO revenue, based on its track record in comparable markets;
• whether existing Sentora-curated liquidity (for example its PYUSD and RLUSD Morpho vaults) is expected to supply the Hub, and whether Sentora earns fees on that supply that sit outside the split;
• any issuer incentives or related-party relationships linked to the listed assets.

2. Enforcement. Which contract receives fees, who can change the fee receiver, and is the 20% reserve-factor floor enforced by role permissions? I’d suggest a DAO-owned splitter that Sentora’s roles can’t modify, monthly settlement with published transaction hashes, and the ability for the DAO or Guardian to cancel an individual queued change during the 48h timelock.

3. Asset mix. The instance uses eight assets. Three (RLUSD, PYUSD, USDe) are already listed on Aave. The other five (OUSD, PRIME, PST, mWIN, kBTC) are new to Aave or still under review elsewhere. Where Aave’s own providers have already assessed an asset, the parameters differ: LlamaRisk recommended mWIN on Horizon at 67% LTV / 72% LT with an 80 mWIN cap, while this proposal uses an 84.6% collateral factor. I’d suggest:

• launching with the assets already familiar to Aave, and bringing new collateral in on small “seasoning” caps that grow only with demonstrated liquidation depth and redemption performance;
• a limit on the share of draws backed by collateral that no Aave provider has assessed;
• published justification wherever a curator’s parameters are looser than an Aave provider’s for the same asset;
• confirmation of the exact launch collateral per spoke, the expansion pipeline with timing, and that every addition goes through the two-week review.

4. Oversight and alignment. The two-week optimistic review relies on a DAO service provider objecting, but the ARFC says none is engaged or paid to monitor the instance. Horizon, on the same 50/50 split, sits inside LlamaRisk’s paid scope. I’d ask the DAO and Sentora to consider:

• a narrow, funded oversight mandate paid from instance revenue, covering listing review, monitoring, and emergency freeze, with parameter setting staying with Sentora;
• a Sentora first-loss commitment, since as written Hub suppliers absorb any shortfall
• adding GHO as a borrowable asset. Under the Horizon terms, the DAO keeps the full interest on GHO it originates, which gives a revenue path that doesn’t depend on the split.

5. Reporting, KPIs, and exit. For the AIP:

• a monthly public report (TVL and draws by spoke, revenue and settlement, liquidations and bad debt, a parameter-change log, oracle events);
• 24/7 on-call, incident disclosure within 24h, and a post-mortem within 7 days;
• explicit removal triggers (undisclosed bad debt, missed reporting or settlement, an undisclosed conflict, a change of control) and a committed wind-down period after any revocation;
• a 6-month pilot term with a review against the projections above. Meeting the targets could earn higher caps or, later, a credit line from a DAO Hub. Missing them leads to wind-down.

[dirkdiggler871026]

On seasoning (the third point above): a curator’s parameters get compared against Aave’s own providers here — mWIN at 67% LTV / 72% LT on Horizon versus an 84.6% collateral factor in this proposal. What decides whether a liquidation actually completes is not the LTV comparison but the exit curve: what a seized position realises, at size, in the venue the liquidator is pushed into.

That is measurable, and I publish it for the Base equities venues at a pinned block — 19 rows, each carrying its size, band and termination reason (executability-report/measurements/base-depth at main · dirkdiggler1026/executability-report · GitHub). One example of why the curve, not the mark, decides: at that block two pools for the same underlying differ by roughly 600× on a $100 exit, because one of them holds almost nothing.

To be explicit: I have not measured mWIN, OUSD, PRIME, PST or kBTC. I am not proposing a parameter. The point is narrower — “demonstrated liquidation depth” needs a defined measurement (pinned block, both legs against the same state, a size ladder, a failure taxonomy), otherwise two reviewers can both be right and still disagree.

Would it help if I ran that for mWIN’s redemption path and published it — or is that already inside LlamaRisk’s scope for Horizon?

[chainza]

Following up on @trevorsc 's point 4 and the Snapshot result. With the ARFC passed, the oversight question is still open for the first instance: the framework states no service provider is scoped or paid to monitor it, and the two-week listing review only works if someone is actually watching.

Separate from any paid mandate, a public read-only monitor for this Hub is straightforward on the same event-driven approach as the V4 cap-utilization monitor we raised in the cap-round thread (post #35 in [ARFC] Aave V4 Activation on Ethereum Mainnet). It would cover live utilization and add/draw cap status per Spoke, queued AccessManager operations during the 48h window with time remaining, and role-grant changes.

@SentoraHQ, would you want that kind of external signal for the Hub? @LlamaRisk / @AaveLabs, is it useful before the AIP, or is monitoring of curated instances deliberately left out of scope? If the AIP includes funded tooling for oversight of curated instances, we’re open to scoping that.

[LlamaRisk]

The ARFC is explicit on this and we’ll confirm it: the instance is externally managed by Sentora, this sits outside the risk management mandate of the DAO’s service providers. On that design the instance falls outside LlamaRisk’s engagement with the DAO. We have not reviewed its configuration, and research we’ve published on any asset for Aave core markets shouldn’t be taken as covering its use in this instance.

That isn’t an objection. Whether to authorise an externally managed instance on these terms is the DAO’s decision.

The one thing we’d add concerns the future. The ARFC authorises no credit lines to or from Aave DAO hubs and requires a separate proposal under the Aave Risk Framework for any such line. If that path is ever taken, in either direction, the instance would come within the Aave risk perimeter and within our mandate, and we would expect it to meet the Aave risk standard in full: adherence to the Risk Framework, LlamaRisk review of the assets, parameters and market structure, delisting where required, and standard risk steward operation with LlamaRisk as a signing party. We’ve discussed this with Sentora and are open to working with them on it, as we are with any team building on Aave.

[JosueMpia]

Oh…

I’m interested to see @AaveLabs response here. The Credit Line request will definitely be needed for @SentoraHQ to bootstrap those markets. (In the short term)

In my view, the risk discussion comes down to two broad areas: quantitative risk vs. qualitative risk. Two different ways of assessing the same underlying problem.

* Quantitative risk AKA @SentoraHQ focuses on what can be measured: liquidity, volatility, correlations, concentration, price impact, stress losses, and other market data. The output is typically numerical, limits, exposure caps, thresholds, or parameter recommendations.

* Qualitative risk AKA @LlamaRisk focuses more on structure: dependencies, governance, operations, technology, counterparties, and broader failure modes that may be difficult to capture in a model.

Sentora → primary market/quantitative risk + curation
LlamaRisk → broader independent risk review and Aave Risk Framework oversight

Of course, the two will overlap many times. Qualitative risks can become quantitative very quickly, and quantitative signals can expose deeper qualitative problems.

[trevorsc]

Thanks @LlamaRisk that’s clear and I agree. As it stands, no DAO service provider is scoped to oversee externally curated hubs, and given how the hub is isolated, that seems reasonable for a first deployment.

My question is less about this hub than about the precedent. As the first externally curated hub on V4, whatever terms it launches with will become the starting point for every curator after it. As I read the ARFC, the DAO keeps admin through the Short Executor and takes 50% of revenue onchain. What’s missing is an agreed basis for using those powers. Without one, any later decision to resize or wind down a hub becomes an ad hoc vote against a live market.

I’d suggest the DAO agree a short set of standard terms for externally curated hubs before the next one is approved:

1. A named reviewer, funded from the curator’s revenue share. Today the two-week window for listings is, in the ARFC’s own words, “an opportunity to object rather than a review commitment,” and risk-increasing changes on the 48h timelock have no reviewer at all. I’d suggest designating a provider to (a) review listings during the two-week window, (b) check risk-increasing changes within the 48h timelock and flag them if needed, and (c) watch a basic dashboard of utilization, oracle deviations and bad debt.
2. Default parameters. Assets already reviewed for DAO Hubs start from the DAO-approved parameters. Curators can deviate (that’s the value they bring), but with a short written rationale posted when the change is made.
3. Reporting and review. A monthly public report from the curator, and a review at ~6 months against KPIs agreed upfront: net-new supply, DAO revenue, cap utilization and bad debt.
4. Wind-down triggers. Objective conditions, such as sustained underperformance against those KPIs, an unresolved oracle or collateral incident, or the curator stepping away, under which caps go to zero on a set timeline. That gives the curator’s depositors a predictable process

Taken together, these should make it easier for Aave to say yes to more curators through standard terms for everyone, low friction to launch, and a clean exit if a hub doesn’t work out.

And a question for @Sentora do you expect the initial RLUSD, PYUSD and OUSD supply to be net new to Aave, or partly moving over from your other curated venues? It doesn’t change my support, but it helps the DAO size the revenue case and think about overlap with its own stablecoin hubs.

[spap]

Good news on point 2: Aave V4’s AccessManager can cancel a single queued operation. The catch is who can do it inside 48 hours.

Thanks @trevorsc, your question was worth a measurement. On a fork of block 26,175,742 I gave a test account the Hub configurator role with a 48h delay, like SENTORA_MANAGED_ROLE, queued an updateFeeReceiver, and called cancel() from each seat:

cancel() from	result
Short Executor	passes
V4 Security Council Safe (5 of 8)	passes
the account that queued it	passes
Protocol Guardian, Governance Guardian, random address	reverts
Protocol Guardian, once set as the role’s guardian	passes

• The DAO holds the right, but its route is a Level 1 vote: 1 day cooldown, 3 days voting, 1 day delay, read on-chain. Longer than the window. The Security Council Safe can cancel inside it.
• The 20% floor is not in the code: the Hub accepts any liquidity fee up to 100%. A floor would come from which functions the Sentora roles reach, or from a steward check.
• This is today’s Core setup, one node; the Sentora instance is not deployed yet.

Same method on 14 other contracts, with the calls to rerun: The holder of a role is not always the one who executes it: one measured case

Curious what the team thinks: would a guardian on SENTORA_MANAGED_ROLE, so one queued change can be cancelled inside the 48h without revoking the whole grant, fit the AIP?

RealSpap