Borrowing

Borrow Flow Overview

Two-Phase Execution

Phase 1: Synchronous (Atomic)

All state changes happen atomically:

1. Verify signature
2. Increment nonce (replay protection)
3. Sync pool indices
4. Check liquidity
5. Mint debt shares
6. Check health factor - if too low, rollback and return error
7. Schedule async withdrawal

Phase 2: Asynchronous (WAL-backed)

The borrowed assets are sent to the user via the Write-Ahead Log, which handles retries on failure.

Health Factor Validation

Before approving a borrow, the protocol validates the position will remain healthy:

Example Calculation:

• User has: 1 BTC @ $50,000 =$50,000 collateral (LT = 80%)
• Current debt: $20,000 USDC
• Current HF: (50000 × 0.80) / 20000 = 2.0 ✓

User wants to borrow $15,000 more:

• New debt: $35,000
• New HF: (50000 × 0.80) / 35000 = 1.14 ✓ Approved

If user tried to borrow $25,000:

• New debt: $45,000
• New HF: (50000 × 0.80) / 45000 = 0.89 ✗ Rejected

Debt Share Minting

Debt is tracked using shares, similar to deposits:

shares = borrow_amount / borrow_index

Example: User borrows 1000 USDT at borrow_index = 1.10 → 909.09 shares minted. After 1 year, index = 1.15: Debt = 909.09 × 1.15 = 1045.45 USDT (45.45 USDT interest owed)

Cross-Chain Borrowing

Users can borrow assets on a different chain than their collateral:

Key points:

• Collateral stays in BTC Pool
• Debt tracked in USDT Pool
• Health factor considers both positions
• User receives native USDT on Ethereum

Borrow Caps

Each pool has a maximum borrow cap to limit protocol risk exposure to any single asset. If the total debt plus the new borrow exceeds the cap, the request is rejected.

Same-Asset Borrowing

Some pools may restrict borrowing the same asset you've supplied. This prevents circular positions that could game the interest rate model.

Interest Accrual

Debt automatically accrues interest through the borrow index:

No action required from borrowers - interest compounds automatically.

Signature Requirements

Borrow requests must be signed with the user's wallet:

Nonce Protection

Each account has an incrementing nonce to prevent replay attacks. The provided nonce must match the expected value, and is incremented after each successful request.

Error Scenarios