feat: deploy Aave v3 fork on Sentrix as lending primitive

[satyakwok]

Stand up Aave v3-style lending pools on Sentrix mainnet. SRX + WSRX + bridged assets become collateralisable.

Why

Sentrix has the DEX layer (sentrix-dex) live but no money market. Lending is the second-largest DeFi primitive by TVL across every chain that has one. Without it, capital efficiency on Sentrix caps low.

Scope

• Fork aave-v3-core and adapt for Sentrix's chainId / RPC quirks
• Configure initial markets (WSRX, bridged USDC via Hyperlane, maybe stSRX once that ships)
• Oracle decision: Chainlink CCIP integration if/when available; Chronicle/Pyth as fallback; price-feed-from-DEX-TWAP as bootstrap
• Audit before mainnet deploy

Open questions

1. Custom audit or shared with an existing Aave-deployer audit?
2. Risk parameters (LTV, liquidation thresholds) per market — copy mainnet defaults or tighten for new-chain risk profile?
3. Governance: SentrixSafe-controlled initially, transition to onchain over time?

Acceptance

• Design doc + parameter table
• Deployment scripts + verified contracts on Sentrix mainnet
• Audit report linked from docs

[m13v]

the pattern that bites with 'SentrixSafe-controlled initially, transition to onchain over time' isn't the multisig phase, it's that the transition gets perpetually deferred because there's no forcing function. by the time someone proposes it, the multisig holders' incentives are entrenched and the vote to dilute themselves never gets scheduled. the protocols that actually make this work commit to a transition schedule in code at launch (timelock that progressively expands governor permissions on a fixed timeline) rather than treating it as a future governance vote. otherwise you ship 'transition over time' and quietly never do. risk parameters are the easier of the three open questions, btw, copy mainnet then tighten LTV by 5-10 pts for the new-chain risk premium and revisit after 90 days of liquidations data.

[satyakwok]

Good call on the governance point — that's the one that actually bites. "Transition over time" with no forcing function is how a multisig quietly stays a multisig forever: by the time anyone proposes the handoff, the holders have no incentive to schedule a vote that dilutes themselves. Baking it in at launch — a timelock that expands governor permissions on a fixed schedule — takes the discretion out, which is the whole point. I'll rewrite open question #3 around that: not "transition over time," but a concrete unlock timeline committed in the deploy.

LTV approach makes sense too — copy mainnet, tighten 5-10 pts for the new-chain premium, revisit after ~90 days of real liquidation data. I'll seed the parameter table in the design doc with that as the rule.

The audit question (#1) is the one I'm still chewing on — shared/Aave-deployer audit vs. a fresh one. You clearly know this space; if you've seen forks go either way there, curious what you'd weigh.