Bitcoin holders have always wanted the same thing: access to liquidity without being forced to sell the asset they want to keep.

That demand is not new. What has been missing is a borrowing product that feels mature enough for real capital.

Most onchain credit today still depends on floating-rate debt, which turns borrowing into an actively managed position. That works for traders and market makers, but it creates extra operational costs for borrowers who simply want predictable capital access against their Bitcoin. For treasury teams, institutions, or long-term BTC holders, the problem is not only rate volatility. It is the ongoing need to monitor, refinance, and manage a debt position that should be simple, fixed, and predictable.

This is why fixed-rate borrowing matters.

Babylon’s Trustless Bitcoin Vaults and Aave V4 make non-custodial Bitcoin-backed borrowing possible without launching a new chain, wrapping BTC, or rebuilding lending from scratch.

Babylon provides the Bitcoin-native collateral layer. Aave V4 provides the liquidity, accounting, and risk engine. Aegis adds the rate structuring layer, turning variable-rate borrowing into a fixed-rate user experience.

From the borrower’s perspective, the product is simple: deposit BTC through Babylon, borrow on Aave V4, and lock the borrowing cost through Aegis.

The infrastructure is complex under the hood, but the user experience is clear: Bitcoin-backed borrowing with fixed-rate certainty.

There is no shortage of demand for Bitcoin-backed liquidity. The shortage is in product quality.

If a user wants to borrow against BTC today, they can usually find a way to do it. But the tradeoffs are often unattractive:

• sell the BTC and lose the upside

• use a centralized lender and accept custody risk

• bridge or wrap the collateral into a weaker trust model

• borrow at floating rates and actively manage the risk yourself

Each of these approaches solves one problem by creating another.

For sophisticated users, floating-rate debt can be tolerated. For a broader borrower base, it is often a reason not to borrow at all. A treasurer, founder, fund, or long-term holder may be willing to accept BTC mark-to-market volatility because that is native to the asset. They may be far less willing to accept open-ended uncertainty in interest cost on top of that.

The goal is not merely to help BTC holders borrow. It is to make Bitcoin-backed borrowing feel more predictable, more legible, and more aligned with how serious borrowers think about liabilities.

Layer 1 — The collateral: Trustless Bitcoin Vaults

To understand why this product is interesting, it helps to start with the collateral layer.

Babylon's Trustless Bitcoin Vaults architecture is not just "BTC on Ethereum." It is a system for using Bitcoin as collateral while preserving a trust-minimized relationship to the underlying asset.

At the base layer, a depositor locks BTC into a Taproot script on Bitcoin, creating a BTC vault. That vault is not a generic ERC-20 asset and it is not a freely fungible unit. It is an indivisible, non-fungible collateral object tied to actual Bitcoin UTXOs on the Bitcoin network.

From there, the vault is onboarded through the BTC Vault Manager on Ethereum. That contract coordinates the onboarding process, verifies the relevant Bitcoin transaction data, tracks approved application integrations, and ultimately oversees the redemption flow when the vault is ready to be claimed.

This process is not purely onchain. It depends on a system of vault keepers, which are critical to the trust and redemption model.

There are three main keeper roles:

• Vault provider — chosen per vault; can claim on the depositor's behalf and challenge malicious claims.

• Universal challengers — defined at the protocol level as a fallback challenge set.

• Application-elected vault keepers — chosen per application; in the Aave V4 context these include the actors that support liquidation and redemption routing

Before a vault becomes active, the relevant parties complete an offchain ceremony. They prepare the transaction graph, pre-sign the required redemption paths, and generate the cryptographic material required for the challenge mechanism. Once the Bitcoin transaction is confirmed and the required inclusion proof is submitted, the vault becomes active and passes into the integrated application layer.

That matters because the system is not pretending Bitcoin suddenly became a native Ethereum asset. Instead, it builds a controlled bridge between Bitcoin-native collateral and Ethereum-based application logic.

This is the first important feature of the stack: the collateral model is designed around real Bitcoin constraints rather than hand-waving them away.

Layer 2 — The translation: making Aave V4 understand BTC vaults

Once a BTC vault becomes active, it can be handed to an integrated application. In this case, that application is Aave V4.

Aave V4 is a natural liquidity layer for this use case. It brings deep reserves, a modern hub-and-spoke architecture, and a risk engine designed for lending markets at scale. But Aave does not natively understand indivisible Bitcoin vaults as collateral.

That mismatch creates the core design challenge.

Aave expects ERC-20 collateral that can be accounted for, transferred, and partially liquidated. BTC vaults are none of those things. They are indivisible units tied to Bitcoin UTXOs. They cannot be split, merged, or treated like standard fungible collateral.

The Aave V4 integration solves that by minting vaultBTC, a synthetic ERC-20 representation of each onboarded BTC vault, on a one-to-one basis. vaultBTC acts as a translation layer between the Bitcoin vault system and Aave's lending engine.

This is an elegant design, but it comes with strict constraints.

vaultBTC cannot behave like a freely tradable collateral token without breaking the relationship between the Aave position and the underlying redeemable BTC vault on Bitcoin. In other words, it is not meant to become just another composable token floating through DeFi. It is a tightly controlled accounting bridge that lets Aave reason about BTC-backed collateral positions without pretending the underlying collateral has the same properties as ERC-20 assets.

That design choice leads to two especially important consequences.

1. Liquidation respects indivisibility

In a standard DeFi lending market, partial liquidation can seize a precise fraction of collateral. With BTC vaults, that is not always possible, because each vault is a whole unit.

The integration handles this by allowing a borrower position to contain multiple ordered BTC vaults. During liquidation, the system walks the borrower's ordered list and seizes consecutive vaults until the required liquidation amount is covered.

That can create over-seizure. If the next vault in line is larger than the exact amount needed, the system cannot split it cleanly. Instead, the architecture includes fairness mechanics that use the excess value for additional debt repayment or return value to the borrower through a fairness payment in WBTC.

This is not a cosmetic implementation detail. It is one of the core reasons the product is credible. The system acknowledges Bitcoin's indivisible collateral structure and builds liquidation logic around it instead of pretending it does not matter.

2. Two liquidation paths, not one

Not every liquidator can redeem a seized vault directly on Bitcoin.

• In the claiming set (an application-elected keeper or arbitrageur with the right infrastructure): they take the seized vault through the Bitcoin-side redemption path after the challenge period.

• Permissionless, outside the claiming set: the integration uses a Vault Swap. The liquidator receives an immediate WBTC payout from the Aave-side liquidity layer, while the seized vault is escrowed for a qualified arbitrageur to purchase and redeem later.

This broadens who can liquidate — keeping the market permissionless — without assuming every participant can operate keeper infrastructure across both chains.

Layer 3 — The rate: where Aegis fits

Babylon and the Aave V4 integration make Bitcoin-backed borrowing possible.

Aegis is what makes it usable as a fixed-rate credit product.

Aegis inserts a fixed-rate credit layer on top. The borrower selects amount and term; Aegis returns a fixed quote; on approval of the required delegation, the position originates against the underlying Aave infrastructure while Aegis handles the rate-transformation logic and downstream protection.

What will this loan cost me?

Aegis answers that question by inserting a fixed-rate credit layer on top of the Aave borrow flow.

The borrower chooses the desired loan amount and term. Aegis returns a fixed-rate quote. Once the borrower approves the required delegation and confirms the transaction, the position is originated against the underlying Aave infrastructure while Aegis handles the rate transformation logic and downstream protection mechanics.

From the user's perspective, the experience is straightforward:

• receive a fixed quote at origination

• borrow against vaultBTC-backed collateral

• get proceeds immediately

• know the borrowing cost in advance

From the system's perspective, the work is much harder:

• source the liquidity through Aave

• manage the mismatch between floating-rate debt and fixed-rate borrower promises

• track the position through on-chain logic

• protect against adverse rate moves over the term of the loan

This is where Aegis' rate engine, position logic, and hedging infrastructure matter.

The important point is not that the product eliminates complexity. It is that it moves complexity away from the borrower and into the protocol layer, where it can be managed systematically.

That is what good credit packaging does.

The user experience here should feel much closer to a modern loan product than a DeFi strategy.

The borrower should not have to assemble the product manually by borrowing variable, thinking about duration, monitoring rates constantly, and trying to hedge the mismatch themselves.

Instead, the ideal experience is:

1. Deposit BTC through the Babylon trustless vault flow

2. Select a borrow asset, amount, and duration

3. Receive a fixed-rate quote from Aegis

4. Execute once and receive proceeds

That is a materially better product than "borrow variable and manage it yourself."

No single protocol tries to do everything. Babylon unlocks the collateral, Aave supplies the liquidity engine, and Aegis turns those primitives into a borrowing product that works outside a narrow class of active DeFi users. That's how new financial primitives become real markets — different layers becoming good enough to compose into something users actually want.

Aegis is preparing to launch fixed-rate borrowing against vaultBTC collateral on Aave V4 on 01.07.2026.

If you are interested in becoming one of the first users or clients, please reach out to

ermin@aegis.im or aurelien@aegis.im

The strongest version of this story is not "Bitcoin holders can now borrow." That is too narrow, and it undersells what is being built.

The stronger claim is this:

Bitcoin holders can access non-custodial onchain credit without selling their BTC, without relying on a simplistic bridge-and-wrap model, and without taking floating-rate uncertainty directly at the user layer. That is a meaningful product improvement.

It makes Bitcoin-backed credit more predictable, DeFi borrowing more legible and the overall stack more useful to serious borrowers.

Babylon is helping make Bitcoin usable as programmable collateral.

Aave V4 provides the lending engine that gives that collateral access to liquidity.

Aegis is building the fixed-rate layer that turns those primitives into a cleaner borrowing product.

Together, that creates something compelling:

Bitcoin-backed borrowing with fixed-rate certainty, built for the next phase of onchain credit markets.