ZendFi

Demo

About

The problem it solves ## Escaping the DeFi Debt Trap Decentralized lending protocols like Aave and Compound have democratized access to capital, representing a significant leap forward for finance. However, their current models, primarily based on Collateralized Debt Positions (CDPs), introduce significant risks and inefficiencies for borrowers: 1. **The Ever-Present Threat of Liquidation:** * Borrowers are tethered to their screens, constantly monitoring collateralization ratios. * Volatile crypto markets mean even brief, sharp price dips can trigger forced liquidations, leading to the **permanent loss of assets**. * These liquidations often occur at unfavorable prices due to liquidation penalties and market slippage, compounding the borrower's financial loss and stress. This isn't just a financial risk; it's a significant mental burden. 2. **Capital Inefficiency through Over-Collateralization:** * To buffer against liquidation risk, users are forced to **heavily over-collateralize** their loans, often by 150-200% or more. * This practice locks up substantial capital that could otherwise be productively deployed elsewhere in the DeFi ecosystem or for other financial needs, hindering overall capital efficiency. 3. **Rigid Structures & Lack of Borrower Agency:** * Traditional DeFi loans impose strict repayment schedules and unforgiving liquidation mechanisms, regardless of the borrower's intent or broader market context. * Borrowers face a binary choice: repay precisely on time (or top-up collateral) or risk losing their assets. There's little to no **optionality** or flexibility tailored to individual circumstances or market outlooks. --- ## The Zend.fi Solution: Lending Reimagined with Borrower Empowerment Zend.fi fundamentally reimagines DeFi lending by structuring loans as **physically-settled call options** rather than traditional CDPs. This innovative approach directly tackles the aforementioned pain points, offering a significantly more flexible, secure, and borrower-centric experience: 1. **Zero Liquidation Risk. Period.** * With Zend.fi, your loan is essentially a call option you hold on your own collateral. * If the market value of your collateral drops below your repayment amount, **there are no margin calls and no forced liquidations.** You simply have the choice to let the option expire worthless if it's not economical to repay. Your downside is capped at the collateral you initially posted. 2. **Enhanced Capital Efficiency & Tighter Spreads:** * The elimination of liquidation risk means borrowers can confidently engage with loans that have strike prices (repayment amounts) closer to the current market value of their collateral. * This translates to **lower effective over-collateralization requirements** compared to traditional platforms, freeing up capital for other uses. 3. **True Borrower Optionality & Control:** * The power shifts to the borrower. At the loan's maturity, you are in control and can choose the most financially sensible path: * **Repay & Reclaim:** If your collateral's value is favorable, exercise your call option by repaying the loan (the strike price) and retrieve your original assets. * **Walk Away & Keep the Loaned Funds:** If repaying isn't economical (e.g., collateral price has fallen significantly), you can choose not to exercise the option. You keep the funds you borrowed, and the lender receives the collateral. No penalties, no further losses beyond the initial collateral. 4. **Marketplace-Driven Rates for Optimal Terms:** * Zend.fi leverages a competitive Request-for-Quote (RFQ) system. * Lenders (market makers) compete to fund your loan (i.e., sell you the call option on your collateral), ensuring that you receive loan terms (derived from the option premium) that reflect true market supply and demand, rather than relying on static pool parameters.

How it's made

Challenges we ran into Our primary goal was to **avoid re-inventing the wheel** by leveraging an existing, battle-tested RFQ protocol—specifically Thetanuts V4. This approach promised access to established infrastructure, market maker liquidity, and a degree of inherent security. However, we quickly realized the key difficulty was handling the **dual-asset nature inherent in a lending protocol**. In most lending scenarios (both CeFi and DeFi), a borrower provides, say, WETH as collateral and receives USDC as a loan. The RFQ protocol we built on, Thetanuts V4, is designed for options where the collateral for the option and the premium paid are typically in the *same asset* (e.g., WETH collateral for a WETH call option, premium paid in WETH). Its **OptionFactory** and **BaseOption** structure enforce this. **Initial Exploration & Discarded Approaches:** 1. **Forking the Protocol:** We briefly explored forking the Thetanuts *OptionFactory* and *BaseOption* contracts to directly add dual-asset logic. However, this would have rapidly blown up the scope, requiring significant modifications to core, audited components. This would have meant a much larger auditing surface for us, and more importantly, we would **lose the crucial network effects and liquidity** of the existing Thetanuts ecosystem. Market makers would need to integrate with an entirely new, unproven system, and secondary market activity for our options would be non-existent. 2. **Single Complex *BaseOption* Extension (The "Swap-in-Place" Idea):** Our next attempt was to create a single, complex *BaseOption* extension. The idea was: * The borrower (wanting USDC) would list their collateral (WETH) on the RFQ. * To fit the Thetanuts model, we'd initially frame the RFQ as if the borrower was *selling* an option *on their WETH collateral*, with the premium to be paid *in WETH*. * The market maker (lender) would bid with WETH (representing the "loan amount" minus their fees/premium for the *actual* underlying option structure). * This WETH premium would be sent to our custom *BaseOption* contract. * Our custom *BaseOption* would then have a function like *swapCollateralPremiumForStables* that the *market maker* would call. This function would take USDC from the MM, swap it for the WETH held by the option, and send the USDC to the borrower. * Finally, our custom *BaseOption* would use the original WETH collateral to create a *standard* *PhysicallySettledCallOption* (which Thetanuts MMs understand), but critically, it would then need to programmatically swap the *buyer* and *seller* roles to correctly represent the loan (borrower is buyer of the call, lender is seller). This "swap-in-place" approach *could* theoretically work, but it had significant drawbacks: * **MM Friction:** It was clunky for market makers. They'd have to "overpay" in WETH, then perform a second transaction to provide USDC and reclaim their excess WETH. This is a tough operational sell and introduces extra gas costs and complexity for them. * **Settlement Latency & Risk:** The loan wouldn't be instantly settled. The borrower would be waiting for the MM to perform the second *swapCollateralPremiumForStables* step. If the MM failed to do so or there was a delay, the borrower might end up receiving their "loan" in WETH (the initial premium), which might have fluctuated in value and wouldn't be the USDC they requested. * **Complexity within *BaseOption*:** Overloading a single *BaseOption* with all this state management and multi-step settlement felt fragile and less clean. **Our Solution: The Dual-Contract Architecture – Coordinator & Handler** Our breakthrough came when we decided to **ingeniously split the responsibilities into two distinct but interconnected smart contracts**, which elegantly wrap the existing Thetanuts *OptionFactory*: 1. ***PhysicallySettledCallOptionLoanCoordinator.sol* (The Orchestrator):** * This contract acts as the **primary user-facing entry point for borrowers.** As seen in the *requestLoan* function, the borrower deposits their actual collateral (e.g., WETH) directly into the *LoanCoordinator*. * Crucially, the *LoanCoordinator* itself then **acts as the *requester* (seller of an option) on the Thetanuts *OptionFactory***. * When calling *OptionFactory.requestForQuotation*, the *LoanCoordinator* specifies *params.settlementToken* (e.g., USDC) as the *collateral* for the RFQ and *loanHandlerImplementation* as the option *implementation*. The *collateralAmount* for this RFQ is the *desired loan amount in USDC*. * The *extraOptionData* passed to the factory in *requestLoan* encodes *address(this)* (the *LoanCoordinator*'s address) and the *nextQuotationId*. This is key for the *LoanHandler* to call back to the correct *LoanCoordinator* instance. 2. ***PhysicallySettledCallOptionLoanHandler.sol* (The Specialized Option):** * This contract is a *BaseOption* extension, making it compatible with the Thetanuts *OptionFactory*. It's the *implementation* deployed by the factory when a lender fills the RFQ created by our *LoanCoordinator*. * Its *initialize* function is where the magic happens post-RFQ settlement. It decodes *params.extraOptionData* to get the *coordinator* address and *quotationId*. * It then calls *PhysicallySettledCallOptionLoanCoordinator(coordinator).handleSettlement(quotationId, finalOption)*. * The *handleSettlement* function in the *LoanCoordinator* is critical: * It verifies that *msg.sender* is indeed the *LoanHandler* deployed by the factory for this specific *quotationId* (*require(state.optionContract == msg.sender, "Invalid handler")*). * It calculates fees and transfers the net loan amount (USDC, which was the *currentBestPriceOrReserve* from the RFQ) to the original *requester* (the borrower). * It then transfers the *original WETH collateral* (which it has been holding) from itself to the *LoanHandler* (*msg.sender*). * Back in the *LoanHandler.initialize* function, it now has the WETH collateral. * It then *clones* a *standard* *PhysicallySettledCallOption* implementation (address fetched from the *LoanCoordinator*). * Finally, it initializes this *final* *PhysicallySettledCallOption* with the correct parameters: * *collateralToken*: The original WETH. * *buyer*: The original borrower (*requester* from *handleSettlement*). * *seller*: The winning lender from the RFQ (who was *params.buyer* in the *LoanHandler*'s *initialize* context, as they "bought" the *LoanHandler* option from the *LoanCoordinator*). * *numContracts*/*collateralAmount*: The original WETH collateral amount. * The WETH collateral is approved and effectively moved into this final, standard option contract. **Why this solution is superior:** * **Clean Separation of Concerns:** The *LoanCoordinator* handles user interaction, collateral management for the loan request, and RFQ initiation. The *LoanHandler* acts as a temporary bridge, facilitating the asset swap and the creation of the final, correctly structured option. * **MM Compatibility:** Market makers interact with an RFQ where the "collateral" and "premium" (from their perspective) are in USDC (the settlement token of the loan). This is a standard interaction for them. They bid with USDC. * **Atomic Settlement (from Borrower's perspective):** Once a lender fills the RFQ, the *LoanHandler*'s initialization and the subsequent *handleSettlement* call ensure the borrower receives their USDC and the final WETH-collateralized call option is created in a single logical flow, triggered by the factory settlement. * **Reusability:** We use the *Clones* library for efficient deployment of the final *PhysicallySettledCallOption*, and the *LoanHandler* itself is also a clone. * **Non-Intrusive to Thetanuts Core:** We did not need to modify Thetanuts' core contracts. Our system plugs into their *OptionFactory* by providing a custom *BaseOption* implementation (*LoanHandler*). This dual-contract architecture allows us to bridge the gap between a user's desire for a cross-asset loan (WETH for USDC) and an RFQ system designed for same-asset option collateral/premium, all while retaining the benefits of the underlying platform. The challenge was to design the flow of funds and contract interactions in a way that was both secure and logical for all parties involved.