The problem ZendFi 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.

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.