Zumer is an open-source liquidity protocol for the NFT market. It is built on the Ethereum blockchain to offer a permissionless and trustless way to originate NFT-backed loans at scale. It could be further developed into a decentralized credit and liquidity risk management protocol for providing any creditrelated banking and investment banking services in the Metaverse. Zumer is not just a protocol but also a decentralized society allowing Zumerians to design the financial system for the Zumer Metaverse.
The trading model of most current DeFi protocols is being run in a decentralized manner—even a few are claiming they are the bank of DeFi. However, none of them runs a real-world banking model but rather a brokerage model.
The most critical element of a banking model is a mechanism to manage the credit cycle and liquidity risk. This paper outlines our proposal to transform the risk management model from traditional finance into a Web3 model by decentralizing most decision-making processes.
The banking system is not designed to assume zero default risk; rather it is designed to underwrite calculated risks. Therefore, every bank in the world adopts an allowance/provisioning model to manage risk and protect against the volatility of losses from potential defaults, i.e. non-performing loans. Different measures are implemented to ensure the banking system has enough buffer to absorb losses during a financial crisis. According to Basel III, the international regulatory framework for banks, regulated banks are required to maintain a certain level of bad loans allowances and core Tier-1 capital (aka shareholder equity) as a % of risk-weighted assets to cover the potential losses from defaulting assets. It is a precautionary method taken by all banks worldwide and banking regulatory bodies to avoid systematic risk.
A similar mechanism does not yet exist in the crypto DeFi space since all borrowings must be over-collateralized and DeFi borrowers are essentially borrowing against their own assets. Even if they technically default when they fail to maintain the required loan-to-value (or loan-to-debt) ratio, the liquidation of cryptocurrencies happens without hassle as they have adequate liquidity backing their loans.
NFTs are a very different asset class in the crypto space. First, it is not a very liquid asset, even the blue-chip projects. Second, the price of NFTs is determined by a small group of collectors. These are the main reasons why the existing DeFi protocols are not able to incorporate NFTs into their product offerings. We need a totally different model to price and handle the risks involved.
A precarious provisioning system is what we suggest applying to our DeFi protocol to handle collateralized lending of NFTs.
The real-world banking model
The following components determine borrowing costs in most cases in the traditional financial system:
Funding costs could be further broken down into the inflation rate and net funding cost. It must be noted that discussion of inflation in this context would also involve the discussion of loan duration—different durations of loans would have different funding cost requirements as the time difference should factor in inflation expectations. Therefore, the longer the duration, the higher the funding cost. In general it can be said that a funding cost is the cost paid for a financial institution to collect its funds, such as deposits. In our case, this cost equates to the opportunity cost of liquidity providers.
Credit cost is the through-the-cycle and the long-term default tendency of a particular type of asset; for example, the credit cost of credit card loans is at around 6%-10% historically, while it could shoot up to 20% during a period of crisis (reference here).
Liquidity cost is the cost incurred to satisfy the liquidity needs of the depositors. It is important as there will always be a duration mismatch between the assets (the NFT loans) and the liabilities (crypto staked in the protocol to earn yields). Anecdotal experience has told us that in most cases the duration of assets would be longer than the duration of liabilities. Therefore, we need a mechanism to encourage liquidity providers to lock up their capital for longer periods in the protocol while still being able to satisfy their short-term liquidity needs. We will discuss later how our protocol design aims to facilitate this ALM (asset-liability management) automatically through a simple mechanism without the need to hire a team of actuaries.
Underwriting spread is the net interest spread banks charge for their profits to compensate for their efforts of originating a loan and to protect its depositors. The underwriting spread charged would be re-distributed to the protocol community and its stakeholders in a trustless manner using decentralized smart contracts.
Zumer's funding cost could be determined by a voting system that comprises 2 sets of pools. The first set of pools is to determine the protocol's short-term rate (to price the 30-day loans). This set has two voting pools, initially at 5% and 15%. Stakeholders of the Zumer Protocol could choose to stake (non-revertible to increase the cost of attack) their veZUMER (the voting token) tokens to add their weight to either pool, which would determine the ultimate short-term funding rate of the protocol. This is how a weighted average funding cost is determined.
Weighted average funding cost =
where w(i) represents the weighting, p(i) represents a pool’s interest rate and w(1) + w(2) = 1
For example, if 20,000 veZumer were staked to 5% pool and 80,000 veZumer were staked to the 15% pool, the weighted average funding cost preferred by the Zumer community would be 13% (20% x 5% + 80% x 15%).
An analog to this approach is the Federal Funds Rate, determined by the central bankers at the Federal Reserve. We delegate the "central bank rate" decision to Zumer community members who hold $Zumer tokens.
Similarly, the second set of pools is the long-term rate (to price 12-month loans). Considering current inflation expectations, it would consist of 2 pools of higher rates, initially at 15% and 25%.
Visualizing how the weighted average funding cost would be displayed on the protocol:
With only 2 anchor rates being determined by the stakeholders of the Zumer Protocol, we could form a yield curve and price any duration of loans in-between by interpolation.
Figure 1 - Steep yield curve – high inflation
Figure 2 - Flat yield curve – low inflation
This system creates a dynamic and decentralized decision-making process for the formation of a yield curve unique to the Zumer Protocol. The benefit of this approach is to enable the protocol stakeholders to dynamically and proactively adjust the yield curve in response to ever-changing external factors such as new competition, worsening macroeconomic outlook, changes in liquidity, etc. With this mechanism, it therefore becomes unnecessary for a centralized organization or person (e.g. the Federal Reserve or Mr. Jerome Powell) to "reactively" decide on the benchmark rate for pricing a loan.
The ability to make real-time adjustments of the protocol's funding cost requirements to adapt to internal and external changes is a unique feature of the Zumer Protocol. Stakeholders are thus equipped with the tools to maintain Zumer Protocol's edge against its direct and adjacent competition.
To further explain the economic benefits of allowing a proactive and dynamic yield curve change, we would like to use the following example to demonstrate the value creation thereof.
Figure 3 – Equilibrium @ static status
Figure 4 – Demand shifted but price unchanged
Figure 3 is the equilibrium price (funding cost) achieved in a static competitive environment, assuming no changes in external factors. However, in reality, there are always changes in external factors. For example, there are more favorable policies that support the growth of NFTs, hence leading to a structural increase in the demand for NFTs and the need for loans to leverage up investors' positions. In this case, the demand curve should shift to the right-hand side, and the equilibrium price (funding cost) should then increase to capture the extra utility created (as reflected in the yellow area).
Without a real-time and dynamic rate resetting mechanism, the funding cost would continue to stay at the old rate until someone (e.g. a centralized admin) notices the change and adjusts the interest rate accordingly: a reactive response to external stimulus. This scenario could leave a lot of food on the table and reduce the capital efficiency of the system, not to mention that higher interest rates in certain situations are better able to encourage utilization of capital (reference here).
Another benefit of having this decentralized interest rate determination mechanism is to allow the protocol to develop a secondary bond market (aka trading the yield curve plus credit spreads) for the loan positions, e.g. securitization of staked lending positions.
This novel approach allows all Zumer token holders to be the decentralized central bankers of the protocol, deciding when to tighten and loosen liquidity and how much to tighten and loosen depending on changes of the external environment.
Credit costs could be broken down into asset-level and individual-level credit costs. The asset level credit cost usually is determined by experience, i.e. the historical default tendency of a particular asset class and a particular population of borrowers. For example, mortgage loans have a through-the-cycle default rate of 0.1%-0.3%, while unsecured SME loans usually would see a normalized default rate of 2-4%. Based on these experiences (which might vary across countries), banks would make provisions (credit cost) in advance for every new loan underwritten, known as a "specific" provisioning expense. Banks also do "general" provisioning, which is usually a fixed percentage against the outstanding loan balance, separate from the specific provisioning expense. The general provisioning could vary from 1% to 2.5%, depending on different regulatory requirements and internal policies of banks.
In addition to the risk level of a particular asset class, banks also segment their customers into different risk levels, e.g. prime, sub-prime, semi sub-prime, etc. Fintech firms also have algorithms to classify their loan applications into varying degrees of risk, resulting in different borrowing terms (credit limit, interest rate, duration, etc.).
Since we are still in the exploration stage of extending credit to metaverse natives (the NFT asset class and anonymous borrowers), we would naturally take a more conservative approach to ensure that assigning credit costs to each NFT project is designed systematically. Before adopting an experience-based approach, we suggest a step-up approach when assigning the credit cost during the early stages of protocol launch.
We suggest ranking the NFT projects in three levels of risk: high, medium, and low. The high-risk projects would be assigned a higher credit cost, for example, 15%; i.e. we would expect 15% of the high-risk NFTs (in value) to default in this scenario. To protect our lenders, we would reflect and include this credit cost of 15% in the borrowing cost on top of the funding cost for these high-risk NFT projects. This mechanism would be applied similarly to medium-risk and low-risk NFT projects.
As the protocol community gains more experience, we could delegate the ranking decision to the community stakeholders to decentralize the decision-making process in determining the risk of each NFT project.
Duration mismatch between assets and liabilities is a daily problem all financial institutions must tackle. Failure to manage the duration mismatch resulted in the collapse of a few notable financial institutions historically, e.g., Lehman Brothers. In the banking sector, the average duration of assets (loans) is longer than the average duration of liabilities (deposits) because most loans are either mortgages or corporate loans with loan tenures of 5-10 years or longer. Most banks manage their liquidity needs, for example if they don't have enough liquid cash for withdrawal from customers, by either attracting more time deposits (offering higher deposit rates) or by tapping into interbank liquidity. Therefore, there is always a hidden cost of managing the mismatch in duration.
We would like to introduce a dual-pool system for managing credit and liquidity risks related to collateralized NFT lending. Unlike the fungible collaterals in existing Defi protocols, NFT collaterals do not have access to instant liquidity during a liquidation event. Therefore, a single pool mechanism would not work for a DeFi protocol providing liquidity to NFTs.
Another reason why the current DeFi model is not suitable to manage NFT-back lending is the forced liquidation mechanism given a high utilization rate (the Compound Model). NFT owners have emotional attachment to their NFTs. According to our customer interviews, forced liquidation due to increased interest rate is totally not acceptable to NFT owners. Our new design would solve this problem.
Two liquidity pools to meet the needs of different risk-takers
Like the real-world banking model, we propose building a provision pool to manage the liquidity needs caused by default events. Our protocol or third-party liquidators would liquidate the defaulted NFTs in the protocol marketplace or on the open market, but this process takes time. When the yield farmers want to withdraw their liquidity from the protocol during this liquidation process, the provisioning pool could provide instant liquidity to the yield farmers. Then, after the NFTs are liquidated, the capital obtained would go back to the provisioning pool to replenish the previously used liquidity. As long as we price the NFT loans conservatively, we could generate arbitrary gains from liquidation events.
Furthermore, the arbitrary gains would go to the provision providers to compensate for the risk of locking up their liquidity for longer. This provision pool would also act as an "equity" buffer to absorb losses in any black swan events. The protocol would thus mint each provision provider a PP token that can be staked for them to farm the protocol's native tokens.
Within the provisioning pool, there are two components. The first component is the protocol's own reserve, similar to the Tier 1 core capital in banks. The other component is a liquidity pool from external provision providers, which is essentially the decentralized way to make a provisioning reserve for bad loans for the protocol. The amount of capital in the provisioning pool would determine how much the protocol could originate in lending loans. There are two phases we suggest going through before a full decentralization of the provisioning pool system.
First, by default, the total outstanding loan balance should be set not to exceed the total balance of the provisioning pool. In this way we could ensure the entire lending pool principal is protected. This is equivalent to a bank with a Tier 1 capital ratio of 100%. After more education and once we enter a more mature stage of the protocol, we would recommend to the community to reduce the risk buffer as more information is collected to understand borrowers' risk behavior. We could then increase the leverage the system could take by adjusting the total loan/total provisioning balance ratio to 120%, 150%, 200%, 300%, etc. In the banking system, this ratio is about 700 – 900% depending on different government regulations. Of course, the higher the ratio, the less risk would be absorbed by the provisioning pool, but the more capital efficient the provisioning mechanism would be.
The protocol would charge a one-off underwriting fee (2% of the loan amount) for each loan origination as the platform income.