Wildcat: Undercollateralized Credit Expansion for Fun and Profit 2.0

A huge amount of crypto's valuation is due to the extraordinary success of the decentralized finance (DeFi) industry. By leveraging the trustless and immutable nature of blockchains we have crafted different composable financial services that improve on traditional finance (TradFi) products. Today, we have stablecoins to rival global banking and foreign exchange; decentralized exchanges and automated market makers (AMMs) to rival traditional brokerage and market making; and onchain yield derivatives to rival traditional derivatives. We’ve also created a plethora of value-bearing assets that provide better ROI than traditional investment vehicles. However, we haven't been able to replicate credit systems and fractional reserve banking to a satisfiable extent. These two primitives underpin the global financial system and have played a key role in the relative success of modern-day capitalism. There's little doubt that the development of proper credit rails backed by a decentralized reputation scoring system will lead to even more growth and potentially take DeFi mainstream. We just have to do it without all the crime and bear market-inducing financial blowups this time. In this article, we present Wildcat Finance: a protocol that allows select borrowers to offer undercollateralized yield opportunities to lenders at the former's discretion. It's quite far from the dream of undercollateralized credit rails for end users, but we believe it is very much essential for select use cases. More importantly, we believe that Wildcat’s architecture and innovations are a massive leap in the journey to bringing credit markets and unsecured loans onchain. An overview of traditional credit and money markets Credit is the spine of civilization–access to un(der)secured debt has allowed individuals, businesses, industries, and nation-states to benefit from the global banking system for centuries. However, the problem facing this entire setup is well summarized in this scene from the classic Game of Thrones series, where Bronn asks what happens if he refuses to pay back a loan from Tyrion. Bronn is intuiting about the problem credit has faced from inception: debtors defaulting on their obligations. In the past this was extensively circumvented by the lender making sure they only lent when they had some “leverage” on the borrower–for example, that they were more powerful and could obtain their funds in a forceful manner if it came to that. As Tyrion explained in the scene, it wasn't unusual for lenders to possess (or have the means to purchase) armies beyond that of their ruler. If they feel their debt is at risk, they could simply pay for the throne to be seized in a rebellion. One way or another, lenders always get their gold back. In more modern times we aren't that outrightly barbaric. We've witnessed the rapid expansion of a worldwide banking standard, aided by international credit rails, and backed by all sorts of multilateral deals and pacts. To this end, consumer credit has taken on a new form with credit scores. Credit bureaus are granted access to the profile of customers of the financial sector. That data is then assessed using various models, such as the FICO model, to produce a score that represents the likelihood of an individual to repay a debt. This is all great but there are two pain points that persist due to the unreliability of the underlying architecture: Securing the financial data of consumers The offerings of the better credit bureaus and their customers being siloed to the West Let's not kid ourselves, the first is a persistent issue that carries into crypto. Until we have fully thought out cryptographic attestation models, the occurrence of leaks and oopsies are likely a matter of time in any case. The good news is that we're getting there with web proofs. But solving the second problem is the entire point of DeFi–borderless transactions and composability. In the following section we will provide an overview of how credit has fared in crypto so far. The Wild West, but it's set in a Dark Forest The entire point of decentralized finance is coordinated financial disintermediation–the elimination of middlemen and centralized parties who are usually responsible for ensuring an opaque system is functioning as intended. Users do not have to wholly place their trust in such entities when they opt into using DeFi protocols. They can simply verify it is all working as intended because every onchain action is transparent and immutable. A second benefit that comes from the settlement of DeFi on blockchains: there's virtually no limits to who can be your counterparty. This is evident in the success of payment giants such as Circle, Tether, and the more native Liquity protocol. It's a 24/7 party and everyone's invited–regardless of geographical limitations. This notion of borderless trust elimination is entirely opposite to the very essence of traditional credit and money markets, where trust is essential (and conditionally rated) at every point of interaction. To overcome this clash of ideals, DeFi protocols like Aave and Compound introduced overcollateralized, peer-to-pool loans as the default. Under this arrangement, the borrower loses a higher value of collateral if they choose to default on their loan's term. These features served as training wheels that allowed the growth of yield and yield derivatives in DeFi's conceptual era–but we can do more with better trust models. We must do more if DeFi is to become more useful to the average Joe. As we discussed in the previous section, traditional credit is heavily reliant on borrower credibility and reputation (assessed via a credit score). While onchain reputation scoring remains a formidable task due to the pseudonymity of blockchains and the ability of users to simply switch profiles, this feature has been replicated to an extent by various providers such as Accountable and Credora. These providers offer this data to applications which seek to offer undercollateralized loans to select participants. This is a great feat overall, but it still faces the challenges we previously outlined. For example, crypto users have the ability to possess multiple identities and profiles which they may wish to not coalesce. A proper reputation system has to take the entirety of a single user's identities into consideration, which makes existing onchain credit systems susceptible to failures. The difficulty of tracking creditworthiness in crypto contributed to the Alameda-FTX saga that rocked the crypto industry in 2022. No one else but Alameda and FTX had the full perspective of their financial situation, which allowed them to misrepresent their books to lenders and users. Alameda wasn’t the only casualty in the crisis that rocked crypto’s nascent unsecured lending industry. Other high-profile casualties were Celsius, Three Arrows Capital (3AC), and Orthogonal Trading to name a few. The 2021/2022 crises essentially heralded the end of crypto undercollateralized credit before it even had a chance to grow. A second, milder criticism of reputation systems in crypto is that they are essentially regressive. This is due to the fact that trust is outsourced to a single entity in the worst case, presenting a non-trivial attack vector. “What happens if a provider faces a security incident?” critics typically ask. It’s also important to note that this risk vector doesn’t disappear when trust is distributed by using data from various providers. There is still a lot of room to improve undercollateralized lending, rather than letting it morph into its traditional analog. After all, we intend for these systems to be–at the very least–viable alternatives to their traditional counterparts. The consensus is that we've barely even grazed the surface of what is possible, and Wildcat changes this. Wildcat: Trust, but verify Wildcat's novel attempt to improving onchain undercollateralized credit involves taking a see-all, non-intrusive approach to credit arrangements, while granting borrowers a considerable amount of leeway to access capital as they please. The protocol is only involved in the first stage (assessing borrower credibility). Beyond that everything else is processed based on the parameters defined by a borrower and opted into by a lender. Paraphrasing their seminal whitepaper: Wildcat permits ratified borrowers to establish fixed-rate onchain credit facilities, the collateral of which can be partially withdrawn for the borrower's purposes. Counterparty selection is entirely up to borrowers, who are expected to optimize their lender set to fit the jurisdiction in which they reside (amongst other things) without impeding too much on their obtainable credit lines. This is all also backed by Wildcat's approach to credit quagmires. The protocol is designed to integrate legal guardrails through almost every relevant aspect– a not-so-surprising fact, given Wildcat’s founder is a well-rounded law aficionado. While relying on traditional legal systems to resolve disputes may raise eyebrows, we contend that crypto is already moving beyond the infamous “code is law” and Wildcat’s approach is a sign crypto is ready to interact with the real world. In the following subsections, we will now evaluate some of Wildcat v1's notable features under the optics of the protocol, its borrowers and lenders. The Wildcat protocol at a glance The Wildcat protocol consists of the following components: The archcontroller The archcontroller is a protocol-affiliated multisig tasked with ensuring that only permitted borrowers can deploy vaults via any specified controller. The conditions of its permissibility are mostly offchain, and dependent on the ability of a borrower to pass the required checks. The sentinel The sentinel is a second protocol-affiliated multisig that is responsible for dealing with issues involving jurisdictional legalities and sanctions. It is extensively able to move a lender's entire position to an auxiliary escrow contract, such as in the case that it detects the associated address is on a list of sanctioned addresses. The sentinel contract utilizes Chainalysis’ service to periodically ensure that lenders across deployed vaults are unsanctioned. In the case that a lender is flagged, the contract calls an “excision” function within the associated vault, causing the deployment of the aforementioned auxiliary contract, and the transfer of the lender's position to this contract. The borrower is expected to immediately settle the lender's position to this contract, and the funds are held there until the lender resolves the issue under the corresponding jurisdiction. The controllers The controllers are a set of contracts responsible for handling vault access permissions for both borrowers and lenders. They are essentially a representation of the borrower and the logic they implement for their interactions with lenders. These contracts contain: The borrower's address, which is permitted by the archcontroller to deploy vaults The mechanism for the lender selection process The sanity-check logic for a vault's parameters during deployment The mechanisms for altering a vault's parameters post-deployment The factory The factory contains the logic of a template vault which is used to approve/reject the parameters proposed by a borrower during vault deployment. They are responsible for curtailing borrower excesses during the vault creation phase. The vault The vault is where most of the magic happens. Lenders deposit their assets according to parameters defined by the borrower (and subject to the controller and sentinel contracts) and are then issued interest-accruing debt tokens. The borrower The borrower is able to set up permissioned vaults using the following parameters: The asset they want to borrow, which could be any ERC20 token they desire. The reserve ratio for every vault is defined by the borrower at creation and represents the minimum amount of lenders’ deposit the vault must always hold to be considered healthy. A grace period is also specified to represent the maximum amount of time a vault can remain unhealthy (i.e., below its reserve ratio) before an annualized delinquency rate is charged to the borrower's position. The maximum capacity of a vault, i.e. its debt ceiling, is defined by the borrower based on their needs and can be arbitrarily adjusted subject to the lenders’ agreement. The interest rate for a vault is a static rate, since the arrangement takes on the form of perpetual duration loans. It is implicitly agreed upon by both parties when the lender deposits into the vault, and can be adjusted following new agreements. The withdrawal cycle, which is the term's duration, at the end of which lenders can redeem their deposit and interest prorated, depending on how much of the collateral has been returned by the lender. Borrowers are entirely responsible for vetting their counterparties. They maintain a list of eligible lender addresses per controller, which represents parties with whom they have reached an offchain agreement beforehand. This list can be altered as they please to add or remove lenders; lender addition is expected to be preceded by sufficient due diligence, and lender removal must be followed by the satisfaction of the borrower's debt obligation towards the former. Borrowers also have the ability to deprecate a vault by reducing the APR to zero and satisfying all their outstanding obligations to the vault's lenders. These obligations are specified by the lender—an important agent in the Wildcat protocol we analyze subsequently. The lender The experience for lenders remains mostly the same as in overcollateralized money markets, except that the ability to lend is a permissioned role dependent on the borrower's approval. Lenders also have the option to sign an agreement which outlines the conditions of a default and how asset retrievals are to proceed under these conditions. This feature is a failsafe to allow direct jurisdictional intervention in cases where a borrower pulls an Alameda or a 3AC (if you know, you know). To bring it all together (with a bunch of sketches): let us assume we have a borrower (Alice) and a lender (Bob). These are some of the actions they are expected to carry out while using Wildcat: 1. Alice approaches the Wildcat team to be verified as a borrower. The processes they would have to pass through depend on various factors, the most important being the residence of their business. If they pass the required checks, they can proceed to create a market using the aforementioned variables. 2. Bob can then approach Alice via a provided channel to submit a request to be allowed to deposit to the latter's market. Alice will grant them the ability to deposit if they pass the required checks, if not they are ghosted. 3. If Bob is granted access to the market, they can proceed to deposit the underlying asset. The protocol automatically mints them a corresponding quantity of market tokens which represent their position (capital + interest). 4. When Bob wishes to exit their position, either partially or fully, they submit a withdrawal request and burn the amount of market tokens they would like to receive. The protocol begins a withdrawal cycle and notifies Alice of their request. The burning (or not) of Bob's market tokens depends on the availability of sufficient reserves to handle their request. If the reserves are sufficient, all their market tokens are burned, if not only the quantity satisfiable by the reserves are burned, and the rest is marked as “expired”. The withdrawal of this expired request is then deferred to a later time when Alice has effectively recollateralized the market. 5. If a second lender (Chris) was onboarded at a previous time and now wishes to withdraw alongside Bob, their request is added to Bob's to be settled at the end of the withdrawal cycle. If the reserves cannot satisfy both of their requests fully, the available amount is distributed pro rata and their leftover requests are marked as expired to be processed at a later withdrawal cycle when Alice has returned the deposits to the market. Wildcat v2: Less trust for double the verification After almost a year on mainnet (holding steady at a TVL of $2.9 million, and with more than $30 million in processed loans), Wildcat is already undergoing some changes aimed at ease of use. The devs are doing something! A notable feature of Wildcat v2 is the addition of hooks for various purposes, enabling a more modular architecture. For the uninitiated, hooks are conditional helper contracts that constrict/expand a particular logic so that it is more granular beyond the protocol's default offering. Wildcat v2 hooks help borrowers to define what conditions the address submitted by a lender must satisfy in order to be granted the ability to deposit their assets to a market. Some of the areas which benefit from the modularization of the Wildcat protocol are: Counterparty selection Counterparty selection in Wildcat v1 was a manual process on the borrower's end: addresses would only interact with a market if the borrower had added them to a set of allowed addresses stored in the controller contract for that market. This is conditional on the lender (who provides the address) passing the checks required of them by the borrower in a manual process. This was a considerable friction point due to the logistics involved on either party's end, and we're all very busy people after all. Wildcat v2 optimizes this experience by placing the access policies for every market behind hooks, In this way, lender selection is almost entirely automated for borrowers who wish it so. A borrower could set up their market so that it can accept deposits from any address that has a certain credential, such as NFTs and/or SBTs, zero-knowledge proofs of access to certain sites, or even offchain credentials from KYC/KYB services. The protocol would then automatically grant access to any address which satisfies the condition. Term durations By default, Wildcat loans are perpetual duration loans, meaning that a lender could choose to opt out of the arrangement at any time by submitting a withdrawal request. This could disrupt the intentions and plans of the borrower, as they may not be done with the lender's capital at this time. Wildcat v2 allows borrowers to define time-restricted markets where lenders cannot place a withdrawal claim for a specified minimum period. This allows the implementation of closed/fixed term loans, after which they convert back to perpetuals. Minimum deposit requirements Most borrowers may choose to impose a minimum deposit amount on their lenders, so that they can reach their maximum capacity with less parties involved or for whatever other reason. In Wildcat v1 this could only be implemented via a backroom handshake deal, where the borrower bargains with lenders before they deposit. However, the introduction of hooks in Wildcat v2 will allow the enforcement of a minimum asset quantity at the point of deposit. Playing to Win: the risks and contingencies of undercollateralized lending Like everything else, the use of the Wildcat protocol in any instance comes with some risks, the most obvious being borrower defaults. Wildcat makes it so that undercollaterization risk is entirely dependent on the lenders’ perception of the borrower: How good is their social reputation? (To be fair, SBF has shown the risks of over indexing on social reputation. Someone being perceived as “based” isn't enough reason to hand over your capital to them). How risk-averse are their observable strategies? How well have they fared since their operation? All these and more are questions that must be considered by a lender before they try to get in contact with a borrower and give out their capital. Most of the answers can be deduced from various reputation systems and other attestation methods such as proof of reserve dashboard reports. Better systems with “verifiable compute” are possibly the next step, because verification is still very much necessary regardless of trust levels. No one wants to face a 1001 days in the life of a turkey scenario, where borrowers suddenly stop being able to satisfy their obligations due to the lack of timely insight and information asymmetry between counterparties. Until then, we must make the best of what we have. This is not a Wildcat-native issue, though– the reality of assigning trust scores is that reputation lags horribly in comparison to crypto's volatility. A single wick in the wrong direction might cause a borrower to become deficient and lead to a chain of insolvencies as we witnessed throughout 2022. The good news here is that Wildcat brings it all out to the open from the onset and allows the legal arm to do its thing. Defaults? Simply cite the MLA and sue for your settlement! Your counterparty violated a signed agreement/contract? Better call your lawyer! The simple idea is that jurisdictional bodies are very much willing to intervene in any case of a violation of agreement (it's essentially free money). So we simply leave it up to them, rather than argue to what extent code is law (it isn't arguable anyway in this case). Concerning smart contract risks: Wildcat is still part-DeFi, even if extensively permissioned, and DeFi is infamous for its contract exploits. However, Wildcat has taken a tight approach to security that includes integrations with SphereX (an onchain security solution). SphereX improves Wildcat’s robustness against breaches by performing checks to validate the logic of pre- and post-function calls made to any of the protocol's contracts. This “effectively creates an iron dome around the protocol” as the Wildcat team describes it. Additionally, Wildcat’s contracts have also undergone audits by security researchers and multiple public Code4rena reviews. We’re tempted to describe Wildcat as having a “mandate of heaven” level of security, but this is DeFi and we shouldn’t forget Euler–a formally verified lending protocol with six auditors–suffered one of the most dramatic hacks to date. Nonetheless, prospective users will appreciate the effort Wildcat has made to prevent zero-day exploits and keep funds safe. Final thoughts While Wildcat isn't the only provider of undercollateralized credit, its unique approach across the board sets it out amongst its competitors. Their collaboration with Wintermute is also not to be ignored, especially since Wintermute isn't known for not dominating whatever fields they play in. The thesis is simple: Wildcat will make undercollateralized credit cool again and usher in productive risk-taking that will ultimately define a new era for all of crypto. This is onchain banking, but better. Author’s note: A version of this article was previously published here. A huge amount of crypto's valuation is due to the extraordinary success of the decentralized finance (DeFi) industry. By leveraging the trustless and immutable nature of blockchains we have crafted different composable financial services that improve on traditional finance (TradFi) products. composable Today, we have stablecoins to rival global banking and foreign exchange; decentralized exchanges and automated market makers (AMMs) to rival traditional brokerage and market making; and onchain yield derivatives to rival traditional derivatives. We’ve also created a plethora of value-bearing assets that provide better ROI than traditional investment vehicles. However, we haven't been able to replicate credit systems and fractional reserve banking to a satisfiable extent. These two primitives underpin the global financial system and have played a key role in the relative success of modern-day capitalism. There's little doubt that the development of proper credit rails backed by a decentralized reputation scoring system will lead to even more growth and potentially take DeFi mainstream. We just have to do it without all the crime and bear market-inducing financial blowups this time. In this article, we present Wildcat Finance : a protocol that allows select borrowers to offer undercollateralized yield opportunities to lenders at the former's discretion. Wildcat Finance It's quite far from the dream of undercollateralized credit rails for end users, but we believe it is very much essential for select use cases. More importantly, we believe that Wildcat’s architecture and innovations are a massive leap in the journey to bringing credit markets and unsecured loans onchain. An overview of traditional credit and money markets Credit is the spine of civilization–access to un(der)secured debt has allowed individuals, businesses, industries, and nation-states to benefit from the global banking system for centuries. However, the problem facing this entire setup is well summarized in this scene from the classic Game of Thrones series, where Bronn asks what happens if he refuses to pay back a loan from Tyrion. this scene Bronn is intuiting about the problem credit has faced from inception: debtors defaulting on their obligations. In the past this was extensively circumvented by the lender making sure they only lent when they had some “leverage” on the borrower–for example, that they were more powerful and could obtain their funds in a forceful manner if it came to that. As Tyrion explained in the scene, it wasn't unusual for lenders to possess (or have the means to purchase) armies beyond that of their ruler. If they feel their debt is at risk, they could simply pay for the throne to be seized in a rebellion. One way or another, lenders always get their gold back. In more modern times we aren't that outrightly barbaric . We've witnessed the rapid expansion of a worldwide banking standard, aided by international credit rails, and backed by all sorts of multilateral deals and pacts. To this end, consumer credit has taken on a new form with credit scores . outrightly barbaric credit scores credit scores Credit bureaus are granted access to the profile of customers of the financial sector. That data is then assessed using various models, such as the FICO model , to produce a score that represents the likelihood of an individual to repay a debt. FICO model This is all great but there are two pain points that persist due to the unreliability of the underlying architecture: Securing the financial data of consumers The offerings of the better credit bureaus and their customers being siloed to the West Securing the financial data of consumers The offerings of the better credit bureaus and their customers being siloed to the West Let's not kid ourselves, the first is a persistent issue that carries into crypto. Until we have fully thought out cryptographic attestation models, the occurrence of leaks and oopsies are likely a matter of time in any case. The good news is that we're getting there with web proofs . web proofs But solving the second problem is the entire point of DeFi–borderless transactions and composability. In the following section we will provide an overview of how credit has fared in crypto so far. The Wild West, but it's set in a Dark Forest The entire point of decentralized finance is coordinated financial disintermediation –the elimination of middlemen and centralized parties who are usually responsible for ensuring an opaque system is functioning as intended. Users do not have to wholly place their trust in such entities when they opt into using DeFi protocols. They can simply verify it is all working as intended because every onchain action is transparent and immutable. coordinated financial disintermediation A second benefit that comes from the settlement of DeFi on blockchains: there's virtually no limits to who can be your counterparty. This is evident in the success of payment giants such as Circle, Tether, and the more native Liquity protocol . It's a 24/7 party and everyone's invited–regardless of geographical limitations. Liquity protocol This notion of borderless trust elimination is entirely opposite to the very essence of traditional credit and money markets, where trust is essential (and conditionally rated) at every point of interaction. To overcome this clash of ideals, DeFi protocols like Aave and Compound introduced overcollateralized, peer-to-pool loans as the default. Under this arrangement, the borrower loses a higher value of collateral if they choose to default on their loan's term. These features served as training wheels that allowed the growth of yield and yield derivatives in DeFi's conceptual era–but we can do more with better trust models. We must do more if DeFi is to become more useful to the average Joe. must As we discussed in the previous section, traditional credit is heavily reliant on borrower credibility and reputation (assessed via a credit score). While onchain reputation scoring remains a formidable task due to the pseudonymity of blockchains and the ability of users to simply switch profiles, this feature has been replicated to an extent by various providers such as Accountable and Credora . These providers offer this data to applications which seek to offer undercollateralized loans to select participants. Accountable Credora This is a great feat overall, but it still faces the challenges we previously outlined. For example, crypto users have the ability to possess multiple identities and profiles which they may wish to not coalesce. A proper reputation system has to take the entirety of a single user's identities into consideration, which makes existing onchain credit systems susceptible to failures. The difficulty of tracking creditworthiness in crypto contributed to the Alameda-FTX saga that rocked the crypto industry in 2022. No one else but Alameda and FTX had the full perspective of their financial situation, which allowed them to misrepresent their books to lenders and users. Alameda-FTX Alameda wasn’t the only casualty in the crisis that rocked crypto’s nascent unsecured lending industry. Other high-profile casualties were Celsius, Three Arrows Capital (3AC), and Orthogonal Trading to name a few. The 2021/2022 crises essentially heralded the end of crypto undercollateralized credit before it even had a chance to grow. A second, milder criticism of reputation systems in crypto is that they are essentially regressive. This is due to the fact that trust is outsourced to a single entity in the worst case, presenting a non-trivial attack vector. “What happens if a provider faces a security incident?” critics typically ask. It’s also important to note that this risk vector doesn’t disappear when trust is distributed by using data from various providers. There is still a lot of room to improve undercollateralized lending, rather than letting it morph into its traditional analog. After all, we intend for these systems to be–at the very least–viable alternatives to their traditional counterparts. The consensus is that we've barely even grazed the surface of what is possible, and Wildcat changes this. Wildcat Wildcat: Trust, but verify Wildcat's novel attempt to improving onchain undercollateralized credit involves taking a see-all, non-intrusive approach to credit arrangements, while granting borrowers a considerable amount of leeway to access capital as they please. The protocol is only involved in the first stage (assessing borrower credibility). Beyond that everything else is processed based on the parameters defined by a borrower and opted into by a lender. Paraphrasing their seminal whitepaper : Wildcat permits ratified borrowers to establish fixed-rate onchain credit facilities, the collateral of which can be partially withdrawn for the borrower's purposes. Counterparty selection is entirely up to borrowers, who are expected to optimize their lender set to fit the jurisdiction in which they reside (amongst other things) without impeding too much on their obtainable credit lines. seminal whitepaper ratified This is all also backed by Wildcat's approach to credit quagmires. The protocol is designed to integrate legal guardrails through almost every relevant aspect– a not-so-surprising fact, given Wildcat’s founder is a well-rounded law aficionado. While relying on traditional legal systems to resolve disputes may raise eyebrows, we contend that crypto is already moving beyond the infamous “code is law” and Wildcat’s approach is a sign crypto is ready to interact with the real world. In the following subsections, we will now evaluate some of Wildcat v1's notable features under the optics of the protocol, its borrowers and lenders. The Wildcat protocol at a glance The Wildcat protocol consists of the following components: Wildcat protocol The archcontroller The archcontroller is a protocol-affiliated multisig tasked with ensuring that only permitted borrowers can deploy vaults via any specified controller. The conditions of its permissibility are mostly offchain, and dependent on the ability of a borrower to pass the required checks. archcontroller The sentinel The sentinel is a second protocol-affiliated multisig that is responsible for dealing with issues involving jurisdictional legalities and sanctions. It is extensively able to move a lender's entire position to an auxiliary escrow contract, such as in the case that it detects the associated address is on a list of sanctioned addresses. sentinel The sentinel contract utilizes Chainalysis ’ service to periodically ensure that lenders across deployed vaults are unsanctioned. In the case that a lender is flagged, the contract calls an “excision” function within the associated vault, causing the deployment of the aforementioned auxiliary contract, and the transfer of the lender's position to this contract. The borrower is expected to immediately settle the lender's position to this contract, and the funds are held there until the lender resolves the issue under the corresponding jurisdiction. Chainalysis The controllers The controllers are a set of contracts responsible for handling vault access permissions for both borrowers and lenders. They are essentially a representation of the borrower and the logic they implement for their interactions with lenders. These contracts contain: controllers The borrower's address, which is permitted by the archcontroller to deploy vaults The mechanism for the lender selection process The sanity-check logic for a vault's parameters during deployment The mechanisms for altering a vault's parameters post-deployment The borrower's address, which is permitted by the archcontroller to deploy vaults The mechanism for the lender selection process The sanity-check logic for a vault's parameters during deployment The mechanisms for altering a vault's parameters post-deployment The factory The factory contains the logic of a template vault which is used to approve/reject the parameters proposed by a borrower during vault deployment. They are responsible for curtailing borrower excesses during the vault creation phase. factory The vault The vault is where most of the magic happens. Lenders deposit their assets according to parameters defined by the borrower (and subject to the controller and sentinel contracts) and are then issued interest-accruing debt tokens. vault The borrower The borrower is able to set up permissioned vaults using the following parameters: The asset they want to borrow, which could be any ERC20 token they desire. The reserve ratio for every vault is defined by the borrower at creation and represents the minimum amount of lenders’ deposit the vault must always hold to be considered healthy. A grace period is also specified to represent the maximum amount of time a vault can remain unhealthy (i.e., below its reserve ratio) before an annualized delinquency rate is charged to the borrower's position. The maximum capacity of a vault, i.e. its debt ceiling, is defined by the borrower based on their needs and can be arbitrarily adjusted subject to the lenders’ agreement. The interest rate for a vault is a static rate, since the arrangement takes on the form of perpetual duration loans. It is implicitly agreed upon by both parties when the lender deposits into the vault, and can be adjusted following new agreements. The withdrawal cycle, which is the term's duration, at the end of which lenders can redeem their deposit and interest prorated, depending on how much of the collateral has been returned by the lender. The asset they want to borrow, which could be any ERC20 token they desire. The reserve ratio for every vault is defined by the borrower at creation and represents the minimum amount of lenders’ deposit the vault must always hold to be considered healthy. A grace period is also specified to represent the maximum amount of time a vault can remain unhealthy (i.e., below its reserve ratio) before an annualized delinquency rate is charged to the borrower's position. The maximum capacity of a vault, i.e. its debt ceiling, is defined by the borrower based on their needs and can be arbitrarily adjusted subject to the lenders’ agreement. The interest rate for a vault is a static rate, since the arrangement takes on the form of perpetual duration loans. It is implicitly agreed upon by both parties when the lender deposits into the vault, and can be adjusted following new agreements. The withdrawal cycle, which is the term's duration, at the end of which lenders can redeem their deposit and interest prorated, depending on how much of the collateral has been returned by the lender. Borrowers are entirely responsible for vetting their counterparties. They maintain a list of eligible lender addresses per controller, which represents parties with whom they have reached an offchain agreement beforehand. This list can be altered as they please to add or remove lenders; lender addition is expected to be preceded by sufficient due diligence, and lender removal must be followed by the satisfaction of the borrower's debt obligation towards the former. Borrowers also have the ability to deprecate a vault by reducing the APR to zero and satisfying all their outstanding obligations to the vault's lenders. These obligations are specified by the lender—an important agent in the Wildcat protocol we analyze subsequently. The lender The experience for lenders remains mostly the same as in overcollateralized money markets, except that the ability to lend is a permissioned role dependent on the borrower's approval. Lenders also have the option to sign an agreement which outlines the conditions of a default and how asset retrievals are to proceed under these conditions. This feature is a failsafe to allow direct jurisdictional intervention in cases where a borrower pulls an Alameda or a 3AC (if you know, you know). To bring it all together (with a bunch of sketches): let us assume we have a borrower (Alice) and a lender (Bob). These are some of the actions they are expected to carry out while using Wildcat: 1. Alice approaches the Wildcat team to be verified as a borrower. The processes they would have to pass through depend on various factors, the most important being the residence of their business. If they pass the required checks, they can proceed to create a market using the aforementioned variables. 1. 2. Bob can then approach Alice via a provided channel to submit a request to be allowed to deposit to the latter's market. Alice will grant them the ability to deposit if they pass the required checks, if not they are ghosted. 2. 3. If Bob is granted access to the market, they can proceed to deposit the underlying asset. The protocol automatically mints them a corresponding quantity of market tokens which represent their position (capital + interest). 3. market tokens 4. When Bob wishes to exit their position, either partially or fully, they submit a withdrawal request and burn the amount of market tokens they would like to receive. The protocol begins a withdrawal cycle and notifies Alice of their request. 4. The burning (or not) of Bob's market tokens depends on the availability of sufficient reserves to handle their request. If the reserves are sufficient, all their market tokens are burned, if not only the quantity satisfiable by the reserves are burned, and the rest is marked as “expired”. The withdrawal of this expired request is then deferred to a later time when Alice has effectively recollateralized the market. 5. If a second lender (Chris) was onboarded at a previous time and now wishes to withdraw alongside Bob, their request is added to Bob's to be settled at the end of the withdrawal cycle. If the reserves cannot satisfy both of their requests fully, the available amount is distributed pro rata and their leftover requests are marked as expired to be processed at a later withdrawal cycle when Alice has returned the deposits to the market. 5. Wildcat v2: Less trust for double the verification After almost a year on mainnet (holding steady at a TVL of $2.9 million, and with more than $30 million in processed loans ), Wildcat is already undergoing some changes aimed at ease of use. The devs are doing something! TVL of $2.9 million, and with more than $30 million in processed loans A notable feature of Wildcat v2 is the addition of hooks for various purposes, enabling a more modular architecture. For the uninitiated, hooks are conditional helper contracts that constrict/expand a particular logic so that it is more granular beyond the protocol's default offering. Wildcat v2 hooks help borrowers to define what conditions the address submitted by a lender must satisfy in order to be granted the ability to deposit their assets to a market. Some of the areas which benefit from the modularization of the Wildcat protocol are: Counterparty selection Counterparty selection in Wildcat v1 was a manual process on the borrower's end: addresses would only interact with a market if the borrower had added them to a set of allowed addresses stored in the controller contract for that market. This is conditional on the lender (who provides the address) passing the checks required of them by the borrower in a manual process. This was a considerable friction point due to the logistics involved on either party's end, and we're all very busy people after all. Wildcat v2 optimizes this experience by placing the access policies for every market behind hooks, In this way, lender selection is almost entirely automated for borrowers who wish it so. A borrower could set up their market so that it can accept deposits from any address that has a certain credential, such as NFTs and/or SBTs, zero-knowledge proofs of access to certain sites, or even offchain credentials from KYC/KYB services. The protocol would then automatically grant access to any address which satisfies the condition. Term durations By default, Wildcat loans are perpetual duration loans, meaning that a lender could choose to opt out of the arrangement at any time by submitting a withdrawal request. This could disrupt the intentions and plans of the borrower, as they may not be done with the lender's capital at this time. Wildcat v2 allows borrowers to define time-restricted markets where lenders cannot place a withdrawal claim for a specified minimum period. This allows the implementation of closed/fixed term loans, after which they convert back to perpetuals. Minimum deposit requirements Most borrowers may choose to impose a minimum deposit amount on their lenders, so that they can reach their maximum capacity with less parties involved or for whatever other reason. In Wildcat v1 this could only be implemented via a backroom handshake deal, where the borrower bargains with lenders before they deposit. However, the introduction of hooks in Wildcat v2 will allow the enforcement of a minimum asset quantity at the point of deposit. Playing to Win: the risks and contingencies of undercollateralized lending Like everything else, the use of the Wildcat protocol in any instance comes with some risks, the most obvious being borrower defaults. Wildcat makes it so that undercollaterization risk is entirely dependent on the lenders’ perception of the borrower: How good is their social reputation? (To be fair, SBF has shown the risks of over indexing on social reputation. Someone being perceived as “based” isn't enough reason to hand over your capital to them). How risk-averse are their observable strategies? How well have they fared since their operation? How good is their social reputation? (To be fair, SBF has shown the risks of over indexing on social reputation. Someone being perceived as “based” isn't enough reason to hand over your capital to them). How risk-averse are their observable strategies? How well have they fared since their operation? All these and more are questions that must be considered by a lender before they try to get in contact with a borrower and give out their capital. Most of the answers can be deduced from various reputation systems and other attestation methods such as proof of reserve dashboard reports. Better systems with “ verifiable compute ” are possibly the next step, because verification is still very much necessary regardless of trust levels. No one wants to face a 1001 days in the life of a turkey scenario, where borrowers suddenly stop being able to satisfy their obligations due to the lack of timely insight and information asymmetry between counterparties. Until then, we must make the best of what we have. verifiable compute 1001 days in the life of a turkey This is not a Wildcat-native issue, though– the reality of assigning trust scores is that reputation lags horribly in comparison to crypto's volatility. A single wick in the wrong direction might cause a borrower to become deficient and lead to a chain of insolvencies as we witnessed throughout 2022. The good news here is that Wildcat brings it all out to the open from the onset and allows the legal arm to do its thing. Defaults? Simply cite the MLA and sue for your settlement! Your counterparty violated a signed agreement/contract? Better call your lawyer! The simple idea is that jurisdictional bodies are very much willing to intervene in any case of a violation of agreement (it's essentially free money). So we simply leave it up to them, rather than argue to what extent code is law (it isn't arguable anyway in this case). Concerning smart contract risks: Wildcat is still part-DeFi, even if extensively permissioned, and DeFi is infamous for its contract exploits. However, Wildcat has taken a tight approach to security that includes integrations with SphereX (an onchain security solution). SphereX SphereX improves Wildcat’s robustness against breaches by performing checks to validate the logic of pre- and post-function calls made to any of the protocol's contracts. This “effectively creates an iron dome around the protocol” as the Wildcat team describes it . describes it Additionally, Wildcat’s contracts have also undergone audits by security researchers and multiple public Code4rena reviews. We’re tempted to describe Wildcat as having a “mandate of heaven” level of security, but this is DeFi and we shouldn’t forget Euler–a formally verified lending protocol with six auditors–suffered one of the most dramatic hacks to date . Nonetheless, prospective users will appreciate the effort Wildcat has made to prevent zero-day exploits and keep funds safe. Code4rena most dramatic hacks to date Final thoughts While Wildcat isn't the only provider of undercollateralized credit, its unique approach across the board sets it out amongst its competitors. Their collaboration with Wintermute is also not to be ignored, especially since Wintermute isn't known for not dominating whatever fields they play in. with Wintermute The thesis is simple: Wildcat will make undercollateralized credit cool again and usher in productive risk-taking that will ultimately define a new era for all of crypto. This is onchain banking, but better . better Author’s note: A version of this article was previously published here. Author’s note: A version of this article was previously published here. Author’s note: A version of this article was previously published here . here