MetaStreet v2, coined the "Automatic Tranche Maker", or "ATM", is a new primitive in NFT lending that enables user defined risk profiles within a pool of capital. With this design, users have complete control over the terms of their loan offers while also benefiting from the capital efficiency of pooled funds.
There are two participants in the ATM: lenders and borrowers. Lenders deposit funds into a pool, and borrowers can then borrow from that pool according to the terms set by the lenders. Each lender indicates a maximum price up to which he is willing to lend. While each lender acts independently, the pool stacks all of the lender positions to form the most competitive single offer to borrowers, who can instantly access the liquidity provided by the pool.
In this manner, lenders act collaboratively, rather than competitively, in order to provide borrowers with the best possible terms. Each lender has a unique risk profile, which allows them to collaborate - lenders with low risk tolerances can participate at a lower return profile in the same loan as high risk tolerance lenders who get a higher return profile. In essence, low risk lenders are getting insurance from high risk lenders, and high risk lenders are getting leverage from low risk lenders.
For example - assume that a CryptoPunk NFT is worth 100 ETH. There are three lenders interested in lending to CryptoPunks, but all three have different risk profiles.
  • Lender A wants to lend up to 10 ETH per punk, Lender B up to 30 ETH, and Lender C up to 45 ETH.
  • All three lenders deposit into the same CryptoPunk pool, indicating their own price tolerances.
  • When a borrower comes to the pool, they’ll see instant liquidity at 45 ETH for their CryptoPunk, and happily take the proceeds.
  • Behind the scenes, the three lenders each get their desired outcome. Lender A takes the 0-10 ETH position, Lender B takes the 10-30 ETH position, and Lender C takes the 30-45 ETH position.
While the borrower will see a single interest rate, the Lenders will split the interest disproportionality, such that Lender C gets the bulk of the return (in exchange for taking on the bulk of the risk), with the share of interest waterfalling down to each subsequent lender in the pool.
In the same way that return is split disproportionally, so too is the risk carried by each lender. If the value of the CryptoPunk declines and the borrower defaults, the loss will be borne by Lender C first, up to 100%, before each subsequent lender bears any losses.

Lender Parameters

Lenders participating in a pool will indicate the price up to which they are willing to lend, as explained above. Lenders with different prices will collaborate to offer the best possible terms to borrowers.
However, price is not the only parameter that a lender must select. Lenders will also indicate a "rate tier" and "duration" as part of their deposit decision. While price decisions drive lender collaboration, rate and duration decisions drive lender competition, and act as a ranking mechanism when two lenders have identical price decisions.
Continuing our above example, consider a scenario in which there are 3 lenders (Lender C1, C2 and C3) willing to lend up to 45 ETH per CryptoPunk. If these lenders also indicate identical rate and duration preferences, they will simply share equally in their exposure to any 45 ETH loans sourced from the pool. But, if Lender C1 wants priority in getting his deposits used for loans ahead of Lender C2 and C3, he can achieve this by offering a lower rate, or longer duration, than Lender C2 and C3 are willing to offer. In this manner, positions are not only ordered vertically (according to price), but also horizontally (according to duration and rate).


This protocol design address three major problems in NFT lending: oracle dependency, centralized permissions, and capital inefficiency.
  • oracle dependency - the ATM does not subject users to any oracle dependencies as users indicate their own maximum loan prices. This keeps the protocol anti-fragile, with zero external failure points.
  • centralized permissions - without oracle dependencies, the protocol is able to offer complete long-tail coverage without risk of harm to users. This means the ATM does not need a centralized whitelisting mechanism - any user can create a lending pool for any NFT, at any time.
  • capital inefficiency - without collaborative pool dynamics amongst lenders, this design would result in fragmented liquidity and laborious origination efforts, both of which drive costs of capital up. With capital pooling, these pitfalls are avoided, causing a virtuous flywheel (lower interest rates -> attract more borrowers -> increase earning potential of lenders -> attract more lenders -> lower interest rates).