Protocol - Lending


Zharta’s core offering (peer-to-pool NFT-backed loans) includes its protocol, which comprises the smart contracts that govern the logic for the lending pools (LPs), the loans, and the liquidations.

There are two components of Zharta’s core offering that are not on-chain:

  1. NFT appraisal engine (NAE)

  2. Risk management engine (RME)

These off-chain components provide input for the on-chain protocol as admin functionalities.


VersionLanguageReference implementation


Vyper 0.3.7

Zharta V1 is a binary smart contract system comprised of many smart contracts. Each domain is comprised of two smart contracts, the Core and the Periphery.

The Core contracts define the data structures and the necessary storage for the domain. They are less flexible contracts and can be viewed as the database of the domain. Within each domain, the Core contract methods can only be called by their corresponding Periphery contract.

The Periphery contracts define the protocol logic and are the gateway to interact with the domain. Each Periphery contract can interact with several other Periphery contracts. They provide fundamental safety guarantees for parties interacting with Zharta and provide permissionless publicly-callable methods for each specific domain.

The Periphery contracts are more easily changed since they hold no storage variables, they only hold protocol logic. Since the domain storage exists in the domain-specific Core contract, it is easier to deploy a new domain-specific Periphery contract and point it to the Core contract and vice-versa.

This architecture is mentioned as data separation in Ethereum Docs. It has the purpose of easing the smart contracts upgrades, allowing fot faster bug fixing (including security issues) and business logic iterations. Even if the long term goal is protocol immutability, it is important at this stage to allow upgradability.

Zharta V1 is divided into the following domains:





Lending Pool (LP)



Collateral Vault (CV)


CollateralVaultCore / CryptoPunksVaultCore




Liquidity Controls (LC)


General Considerations

Zharta is launching the V1 of the protocol with the following restrictions:

  1. Maturity-based loans with a maximum of 30 days

  2. One single lending pool of ETH/WETH

  3. No liquidations before a loan's maturity date

Important Note

As said above, the protocol domains are separated into logic and data contracts. This is relevant because it allows for the upgradeability of the protocol. For the next version of the protocol, our goal is to deploy an immutable protocol but for that to be done efficiently, we first need to understand what users want and need and iterate over that. Zharta is the only party with the power to upgrade the protocol and we will always listen to our community and develop Zharta's protocol openly.


As previously stated, each domain is composed of a Core and Periphery pair of contracts. This composition is represented in the diagram as a strong coupling between those contracts.

In addition, V1 is designed so that for each ERC20 token that the lenders can deposit and borrowers can borrow from the protocol, an isolated lending market (ILM) comprised of the Core and Periphery contract pairs is deployed for the Loans and LP domains. This means that for each LP contract pair (Core and Periphery), there is a specific Loans contract pair (Core and Periphery), and only the specific Loans Periphery contract can interact with the LP Periphery contract.

As for the CV, Liquidations and Liquidity Controls domains are not specific to each ERC20 token and serve all the deployed ILMs.

Loan creation flow - a mix between on-chain and off-chain processes

The loan creation flow has two steps:

  1. Zharta's API pre-validation

    • the borrower should call Zharta's APIs beforehand to get the conditions for the loan given the NFTs chosen to be used as collateral

    • Zharta's API also validates the loan request and signs an ERC712 message

    • Zharta's portal simplifies this for now

  2. The loan is created on-chain by the borrower, using the signed message which is validated by the loan's smart contract

Protocol Diagrams

In the diagrams below, the coloured boxes (i.e. boxes that don’t have a white background) represent smart contracts.

Loan Creation

Loan Payment

Loan Default

The loans can only be defaulted if and only if the borrower didn't repay the loan by the end of the maturity date.

Although this may change in the future, as of the first iteration of the protocol, the loan defaults can only be triggered by Zharta.

Collateral Liquidation

Liquidation Periods

The liquidation periods are periods where only certain actors can take part in the liquidation of the collateral:

  • Grace period: only for the borrower

  • Buy Now period: only for the lenders

When the Liquidation Periods End

LP Deposit

LP Withdrawals

Deployment Diagram

Last updated