aare.finance is a lending protocol designed around what crypto's last decade actually taught us: complexity is the attack surface. After Ronin, Wormhole, Multichain, and now KelpDAO, the most expensive vulnerability isn't a bug in any one contract — it's the depth of the stack we keep building on top of basic primitives.
The Aare is a Swiss alpine river — cold, clear, and predictable. It carries glacier melt out of the Bernese Oberland and through Bern at a constant temperature year-round. You can see straight to the bottom. That's the brand: a lending protocol you can read all the way through, with no opaque depth.
The Thesis
Why "back to basics" on Ethereum is a serious response — not a regression.
Look at the largest losses of the last four years. Ronin: $625M from a multisig compromise. Wormhole: $326M from a guardian signature bug. Nomad: $190M from a misconfigured initialization. Multichain: $126M from sole-key custody. KelpDAO, last week: $292M from a 1-of-1 verifier on a bridge nobody read carefully.
Each of those losses lived above the underlying chain — in a wrapper, a verifier set, a cross-chain message, a restaking layer, a liquid token of a liquid token. The base assets were fine. The bug was always in something built on top.
The industry's instinct after each incident has been to add more machinery: more wrappers, more receipt tokens, more shared-security primitives. Restake your liquid stake. Loop your liquid restake. Bridge it. Use it as collateral for borrowing more of itself. The yields on paper are remarkable. The drawdowns when something breaks are total.
aare.finance is the opposite hypothesis. If the danger compounds with each layer of abstraction, the safest place to lend is the layer closest to the chain itself. Plain Ethereum collateral. Direct on-chain prices. Code that can't be upgraded out from under you. Markets that fail one at a time, not all together.
This is not a claim that aare is the future of lending. It's a claim that some meaningful slice of users now needs a lending venue with the discipline to refuse the new risk surfaces — and that nobody is offering it without trade-offs that defeat the point. So we're building it.
Design Rules
Rules that can be broken aren't rules — they're guidelines. These four are enforced in code or by the absence of code.
Each collateral / borrow pair is its own market with its own oracle, its own LTV, its own liquidation logic. A bad asset in one market cannot drain another. Contagion stops at the market boundary.
Once deployed, the core lending contracts cannot be upgraded. No proxy admin. No migration script. No multisig that can swap the implementation tomorrow. The code you read on day one is the code that runs forever.
If an asset's solvency depends on a bridge, a verifier set, a guardian committee, or a restaking layer, it does not list. We accept ETH and the most-used Ethereum-native LSTs. Anything that requires off-chain attestation is excluded.
Lower borrow caps than peers. Multiple independent oracle sources per market with deviation bounds. Longer liquidation grace periods. The protocol prefers fewer liquidations to faster ones, and lower utilisation to higher yields.
Scope
The only honest way to communicate risk is to be specific about what's in and what's out.
Architecture comparison
A side-by-side of how aare.finance differs from monolithic-pool lending. This is not a knock on Aave or Compound — they serve different users with different risk tolerances. It's a clarification of what aare is for.
| Property | Monolithic-pool lender | aare.finance |
|---|---|---|
| Market structure | Shared pool, many collateral types | Isolated market per pair |
| Upgradability | Proxy admin, governance can upgrade | Immutable |
| Bridged collateral | Often supported | Excluded |
| LRT collateral | Supported (rsETH, eETH, etc.) | Excluded |
| Oracle design | Often single source per asset | Multi-oracle median + deviation guards |
| LTV ceilings | Aggressive, optimised for capital efficiency | Conservative, optimised for survivability |
| Cross-asset contagion risk | Possible (shared pool) | Bounded by market |
| Governance over live markets | Yes (parameters, listings, upgrades) | No — only deploys new markets |
| Yields | Higher (broader collateral, more leverage) | Lower — intentionally |
Honest disclosure
Educational principles apply to project pages too.
aare.finance is concept-stage. No mainnet contracts are deployed. No audits exist yet. No TVL, no track record, no incident history. Anyone claiming otherwise on social media is impersonating us — we'll only ever announce launch from the domain on this page.
"Safer" is a hypothesis, not a fact. The four design rules above are a reasoned response to a real problem, but until aare runs in production through a real market crisis, we can't claim it's empirically safer than any alternative. We can claim the design surface is smaller. That's different from "safe".
Lower risk means lower yield. If you're optimising for the highest possible yield, aare won't be your venue. The whole point is to refuse certain trades.
Domain hygiene. The only legitimate URL is aare.finance. Lookalike domains targeting a Swiss-river-themed lending protocol will appear — bookmark the real one.
We'll only email you twice: once when the testnet opens, once when audits and mainnet contracts go live. No marketing, no airdrop hints, no "exclusive opportunities".
By signing up you agree to receive at most two emails. We will never sell, share, or otherwise abuse your email.