# NFT Treasury and Liquidity Concept (NTLC) by [indigo](https://twitter.com/_ndigo) and [fullyallocated](https://twitter.com/fullyallocated/) ## Introduction This document outlines the design and functionality of an NFT Treasury and Liquidity protocol, currently dubbed NTLC, that allows Non-Fungible Tokens (NFTs) to be redeemed against accumulated treasury assets. This document explains how the system works, its architecture, and the underlying mechanisms that support it. ## Motivation NFTs are usually wrought with issues of illiquidity and price volatility, with little assurances of how a collection may perform over time. In this paper, we introduce a system that acts as an automated dealer for the collection, ensuring floor liquidity and taking on liquidity risks that normal holders would not take, in order to provide a service for all holders of the collection. This design is inspired by Olympus Protocol, which with its Range-Bound Stability system, acts as a baseline market maker and buyer of last resort for OHM holders. ## Terminology - Collection: A set of NFTs that share a common traits. - Item: An individual NFT from a collection. - Holders: Users holding an item of a collection. - Backing: The number of reserve assets per circulating item in the collection. - Floor Price: Minimum price an item in the collection is being sold for on the secondary market. - Reserves: Total fungible assets owned by the protocol used for backing. - Float: Items in the collection NOT owned by the protocol. Used for calculating backing. ## System Overview The NTLC is designed to provide sticky, reliable liquidity and capital efficiency for NFT holders, with the goal of reducing liquidity risk using an entity similar to a bank. The system enables users to redeem their items against their backing, similar to stablecoin redemptions. Additionally, the system allows users to borrow the backing against a deposited item. Conversly, the protocol also allows borrowing of treasury-owned NFTs for reserve deposits, potentially allowing novel use cases and the ability to tap into utilities offered by the collection. The treasury accumulates reserves via minting fees, royalty fees, LP fees (through liquidity pools on AMMs), market spreads from listings, yield farming of reserves, and interest accrued on lending operations. The accumulated assets are used to support a growing, redeemable backing per NFT. This system's architecture ensures that the accumulated assets are always available to back the NFTs, providing a true floor price for the market and liquidity to the collection holders. ```mermaid flowchart TD Minted[Mint Fees] --> treasury{Treasury} royalties[Royalties] --> treasury lp[Market and LP Revenue] --> treasury farming[Yield Farming] --> treasury anon[Anon] --Redeem item--> treasury treasury --Receive backing--> anon[Holder] treasury --List item at backing + premium--> market[Marketplace] treasury --Lend backing--> backing_borrower[Borrower] backing_borrower --Pay interest--> treasury treasury --Rent item--> renter[Renter] renter --Pay interest--> treasury ``` ## System Design The NTLC is a protocol designed around a treasury with the goal of increasing liquidity and capital efficiency for all holders. There are four main features that provide these benefits: - Direct redemption of an item in exchange for backing with the treasury minus a fee - Relisting of redeemed items at a premium to backing price - Lending of backing in exchange for a item deposit plus interest - Rentals of item in exchange for a deposit equal to backing plus interest ### Treasury The treasury is used to store all backing assets and items controlled by the protocol, and will be the recipient of all fees generated through activity from protocol-owned items. The treasury is also where redemptions and lending of reserves originate from. All profit operations of the treasury, like mint fees, royalties, liquidity providing fees, and lending interest, all accumulate to the treasury. ### Backing and Redemption Each item in the collection is backed by some amount of reserves held in the treasury, defined by the equation: $$ backing = reserves / float $$ The idea of this backing is simple: Provide a minimum price guarantee for collection holders. If a holder prefers to hold the backing asset over the NFT, there is always liquidity available to redeem against. Backing is designed to always increase from any market or redemption operation by the treasury: - A fee is charged on redemption, increasing the backing of all remaining holders. - A premium to backing is added on any market listing. - Royalties or LP fees accumulate to treasury reserves. - Lending of backing or treasury-owned items generate revenue by charging interest. If implemented correctly, the treasury can ensure that any market operation satisfies the inequality $$ delta\_reserves > backing\_initial * delta\_float $$ which results in an increasing backing for each item. Conceptually, each unit of reserve that accumulates to backing effectively acts as a revenue share with the collection. In addition, the last holder of the NFT will be able to withdraw the most backing, as all pro rata fees from treasury operations would effectively have accumulated to the last holder. #### Backing and Market Floor Price With regards to the floor price of NFTs, which is minimum price that an NFT collection can be sold on secondary markets, we expect that the market will set the floor price at or close to the backing of the NFT, as any price below backing will be arbitraged. #### Miscellaneous Considerations In the case that an entire treasury's reserves have been redeemed, the treasure has effectively done a complete buyback of the supply, and the project could either wind down, or leave up listings for potential future buyers. ### Market Operations NFTs owned by the treasury can be relisted on the market for a premium to backing. Since holders often want instant liquidity during volatile times, the treasury is always willing to give liquidity at backing via a redemption. Conversely, the treasury will also relist redeemed NFTs at a premium to the backing. Any successful bids on these listings continues to accumulate backing for remaining holders. One issue with the relistings could be that the premium to backing does not grow fast enough to catch up to the true market price of the item, putting the treasury at risk of adverse selection. An expansion of the protocol could deploy auctions for treasuIry-owned items instead of the listings. This would also help prevent adverse selection in the case where a non-floor item is redeemed. These auctions would allow the treasury to sell items at a price closer to market price with minimal information about the market itself. ### Backing Loans Since each item has the rights to its backing, a holder of a specific item has the ability to deposit an item and borrow their backing for some rate of interest chosen by the protocol. By allowing users to borrow their backing, they retain ownership of their chosen item while being able to tap into extra capital, which can be used for things like staking, yield farming, or other productive purposes. The implementation of this lending subsystem would ideally handle defaults without liquidations, since the NTLC has no oracles for the outside markets to facilitate liquidations. Instead, since the loan is collateralized with an item, a borrower may default on the loan with no loss to the protocol. The loan could be structured as a fixed rate, fixed duration loan, which would count the borrower as defaulted if the full loan has not been repaid by the end of the duration. ### Item Rentals Items owned by the protocol can also be lent in exchange for a deposit equal to backing plus interest. Like lending backing, this lets anyone rent an item for any purpose. Although this is more nascent, some potential uses may be arbitraging interest rates on other lending markets, or using some utility offered by the specific collection. Loan structure and implementation can match what was described for lending of backing. ### Governance Initially there will be no governance over the system, instead using a governance-minimized approach with a focus on automation. However, governance systems can be added on top of this, with the option to manage the protocol and treasury operations. ## Risks Although the system is intended to derisk a collection, there are a few risks to using this protocol. - Smart contract risk - This is everpresent in any on-chain protocol. - Backing assets far below market floor - In a case where backing is significantly below the market's floor price, there would be minimal incentive for any users to redeem, undermining the primary utility of the system. Holders would have to wait until backing and floor price are close before this function would be of use again. Luckily, the treasury can still offer utility in the form of loans of backing and items. ## Implementation ### Architecture An initial version of the system will be designed using the [Default](https://github.com/fullyallocated/Default) framework with a single main module for the treasury, and separate policies to handle redemptions and market operations. This design allows us to expand the capabilities and new features as needed without relying on upgradeable contracts. These may be optimized and combined into one contract in the future, but is out of scope of this current iteration. The system will be built around OpenZeppelin's contracts, opting for standardization. Optimizations like ERC721A and others can be implemented in the future. ### Components The system will consist of 3 components, each a separate contract. - Treasury | module - Dealer | policy - Minter | policy #### Treasury The Treasury module is meant to be the recipient and storage for all backing assets and fees generated by the protocol or the collection. This includes royalties via ERC2981 royalties, LP fees, interest or profits from market making. The treasury will also facilitate redemptions for backing through the Dealer contract. #### Minter The Minter policy will deploy new ERC721 collections for any new projects intending to use the NTLC. #### Dealer The Dealer policy is the component used to interact with the outside market, and manage backing and protocol-owned items. The dealer will also facilitate item redemptions for the treasury. To facilitate redemptions, the Dealer will take an ERC721 item as input and return its equivalent backing, according to the backing from the treasury minus a small fee set by the protocol.