Differences from Gondi v3

Detailed comparison and improvements made from Gondi Protocol v3

Architecture Migration

Diamond Standard (EIP-2535) Implementation

Problem: The original MultiSourceLoan contract equal Ethereum's 24KB contract size limit, preventing further development and optimization.

Solution: Complete migration to Diamond proxy pattern with modular facet architecture:

Original Monolithic Structure:
├── MultiSourceLoan.sol (~24KB)
└── BaseLoan.sol (Base functionality)

New Diamond Architecture:
├── Diamond.sol (Main proxy)
└── Facets/
    ├── AccessControl.sol (Permissions)
    ├── Loan/LoanFacet.sol (Core loan operations)
    ├── RefinanceLoan/RefinanceLoanFacet.sol (Loan refinancing)
    ├── LoanExtension/LoanExtensionFacet.sol (Extensions & modifications)
    ├── Control/ControlFacet.sol (Administrative functions)
    ├── View/ViewFacet.sol (Read-only operations)
    ├── Initializer/DiamondInit.sol (Initialization)
    └── Liquidation/LiquidationFacet.sol (Liquidation management)

Technical Benefits:

• Overcame contract size limitations

• Enabled Solidity optimizer usage

• Modular upgradeable architecture

• Gas efficiency improvements

Storage Architecture Redesign

New Storage Libraries:

• AccessControlStorage.sol - Role-based access control state

• BaseStorage.sol - Core protocol configuration and parameters

• LoanStorage.sol - Loan-specific state management

Diamond Storage Pattern: Implemented using LibDiamond for conflict-free storage slots across facets.

Smart Contract Enhancements

1. Upgradeable Infrastructure

Migration: From immutable contracts to upgradeable proxy patterns

• FeeDiscountManagerUpgradeable.sol - Implements OpenZeppelin's upgradeable pattern

• AddressManager.sol -> AddressManagerUpgradeable.sol - Implements OpenZeppelin's upgradeable pattern

• AuctionWithBuyoutLoanLiquidator.sol -> AuctionWithBuyoutLoanLiquidatorUpgradeable.sol - Implements OpenZeppelin's upgradeable pattern

• AddressManager.sol -> AddressManagerUpgradeable.sol - Implements OpenZeppelin's upgradeable pattern

• Diamond facets support hot-swapping for bug fixes and feature updates

2. Dependency Modernization

Removed Dependencies:

• Solmate library (deprecated)

• Legacy OpenZeppelin versions

• Outdated utility contracts

Added Dependencies:

• @openzeppelin-contracts v5.3.0

• @openzeppelin-contracts-upgradeable v5.3.0

• delegate-registry v2.0

3. Solidity Version Upgrade

Migration: Solidity ^0.8.x → =0.8.28

• Enhanced compiler optimizations

• Latest language features and security improvements

• Better gas efficiency

New Feature Implementations

1. Bidirectional Offer System

Unlike traditional NFT lending platforms where only lenders can create loan offers, BAE introduces true bidirectional markets where borrowers can actively create loan requests that lenders can accept.

Technical Implementation: The system works by allowing borrowers to create offers with the lender address set as address(0) (zero address), which acts as a placeholder. When a lender decides to accept the borrower's offer, the system automatically assigns the lender's address and processes the loan.

Example:

• Scenario: Alice owns a Bored Ape NFT and needs 50 ETH quickly for a business opportunity

• Gondi Way: Alice must wait for a lender to create an offer for her specific collection

• BAE Way: Alice creates a borrower offer: "I'll pay 10% APR for 50 ETH loan against my BAYC #1234 for 30 days"

• Result: Any lender can instantly accept Alice's terms and fund the loan

2. Multi-Collection Offer Support

Allowing lenders to create offers that accept multiple NFT collections as collateral, rather than being limited to single-collection offers and need to create offer for every collection but in finaly for accept only one

Technical Implementation: The system uses a specialized validator contract (ListNftAddressesValidator.sol) that maintains and validates lists of approved NFT collections. When creating an offer, lenders can specify multiple collections they're willing to accept, and the specific collection is determined only when a borrower accepts the offer.

Example:

• Scenario: Bob is a lender with 100 ETH to deploy across blue-chip NFT collections

• Gondi Way: Bob must create separate offers for BAYC, CryptoPunks, Azuki, etc

• BAE Way: Bob creates one offer: "50 ETH at 8% APR for 60 days, accepting any of: [BAYC, CryptoPunks, Azuki, Doodles]

• Result: Any borrower with NFTs from these collections can instantly accept Bob's terms

3. Dynamic Fee Discount System

New Contract: FeeDiscountManagerUpgradeable.sol

Technical Features:

• NFT holding-based fee calculations

• Keeper signature validation for discounts

• Upgradeable discount logic

• Integration with loan origination flow

Library Enhancements

Hash Library Improvements (LibHash.sol)

Changes:

• Fixed obsolete signature hashes for execution data