# What is Collection.xyz? Automatically buy, sell and earn yield on your NFTs. Live on Ethereum Mainnet. Collection.xyz is an NFT decentralized exchange (DEX) protocol with innovative automated market maker (AMM) features. \ \ With Collection.xyz, users can create liquidity pools with NFTs and ETH to automate buying and selling of NFTs without intermediaries. Anyone can buy and sell NFTs instantly from the pools on a simple app interface. 1. **Choice:** Users can create trade pools that **only accept specific token IDs** within an NFT collection. Under the hood, the protocol uses Merkle proofs to specify and target specific NFTs by token IDs, allowing users to target individual tokens, user-defined groups, or the whole collection. These NFTs can be grouped based on what users desire such as traits, rarity, or even whether they are banned on Opensea.

2. **Composability**: Liquidity pool positions are represented by LP ownership tokens, **composable with other protocols**. 3. **Fees & Royalties:** Collection **charges 0% protocol fees.** Liquidity pool owners determine the pool fees and royalty % for the pools they create. We encourage liquidity pool creators to honor royalties, and vault creators can incentivize liquidity providers to do so. 4. **Reward:** Anyone can reward liquidity providers with ERC-20 or ERC-721 tokens based on desired criteria through a draw system. This allows for the **easy creation of custom NFT liquidity mining programs**. (Coming Soon) The protocol has been successfully audited by [ABDK Consulting](https://www.abdk.consulting), which counts Uniswap, GMX, ZKSpace, CitaDAO and Sudoswap as some of its clients.
Collection.xyz will have the following features at launch: * Buy and sell NFTs instantly on the platform. * Create pools and provide liquidity for any collection. * No protocol fees. * Tokenized ownership of pools (LP Token); users can collateralize and transfer the LP token to any address of choice. * Integration with various NFT marketplace aggregators to enable users to trade through their apps. * Customize the royalties to creators when liquidity providers set up pools; Collection.xyz's app defaults to honoring full royalties. * Support for these ERC20 tokens: Ethereum (ETH), Wrapped Ethereum (WETH), Dai (DAI), USD Coin (USDC), Tether (USDT), ApeCoin (APE). * Create incentive vaults with Collection Draw to reward liquidity providers with NFT or token rewards. Creators can launch new collections based on the liquidity provided to NFT collections. ERC-20 tokens can also be distributed as an incentive and used as a form of token issuance.


Review User Guides	User Guides	pexels-isaque-pereira-394377.jpg
Read Whitepaper	The Collection Whitepaper	pexels-eva-bronzini-7965804.jpg
Explore Technical References	Technical Reference	pexels-pixabay-270348.jpg

# Liquidity Pool A liquidity pool is created when assets are locked in a smart contract for the purpose of providing liquidity. It uses Automated Market Makers (AMMs) / smart contracts to match buyers and sellers with set-price. It is essential to have a continuous flow of liquidity — demand and supply of NFT — so that trades can happen continuously and efficiently, and liquidity providers are incentivized (with trading fees or profiting from bid-ask spread) by providing assets. There are various kinds of liquidity pools to choose from on Collection.xyz, depending on the inventory and objective of the liquidity provider:


Advanced Pool	Liquidity providers can now specify the group of NFTs they want to trade against. Liquidity providers can set up pools for specific attributes, token IDs, rarity, hotlists and more!		Advanced Pool
Basic Pool	Liquidity providers can set up pools that trade against the entire collection.		Basic Pool

# Advanced Pool Liquidity providers can now specify the group of NFTs they want to trade against — the pool filter. * User will interact with filtering functions (by traits, or other attributes) on Collection’s interface. * The list of corresponding NFT tokenIDs will be hashed using our opensource library into a Merkle Root filter. (*This list of NFTs (the allowedSet) is different from the NFTs put into the pool (the actualSet). The actualSet is a subset of the allowedSet.)* * After depositing their assets, they can proceed to set parameters such as fees, bonding curve, delta and royalty. * Traders who want to trade against the liquidity in the pool will need to provide a proof (again from our opensource library, which we automatically calculate in our frontend) to buy or sell against the pool. The proofs guarantee only NFTs meeting the specific sub-criteria can enter the pool through the buy or sell functions. {% hint style="info" %} *For example, Alex decides to create an Advanced Pool for Golden Azuki. Using Collection.xyz, he filters all Golden Azukis for the pool he wants to trade against. He then proceeds to deposit his own Golden Azuki into the pool and set the parameters accordingly.* *The pool is now live, and other traders can buy the Azuki at the set-price. For traders who own a Azukis, only Golden Azukis can be sold into the pool (based on requirements created when setting up the pool)*. {% endhint %} The example above is used specifically for 2-sided Advanced Pool. It is pivotal to understand the concept that the group of NFTs you select in the UI at the point of pool creation, and hence trading against, is not the same as the NFTs you have to deposit into the pool. After customizing the pool, you have to choose which NFTs to deposit. *Note: Currently the DApp interface will help you add the tokenIDs into the pool filter if you happen to choose any tokenIDs from your wallet that you did not add into the filter earlier in the customization process.*

# Basic Pool Basic Pool provides liquidity for a collection without specifying any Merkle root filter. Anyone can buy or sell if there is enough stuff in the pool to buy/sell against. However, since there is no Merkle root filter, it will not make sense to deposit NFTs much more valuable than the floor price, since they will be valued exactly the same as floor price NFTs. Liquidity providers should skip the filtering interface, if they hold NFTs that they consider valued at floor price and are willing to trade against the whole collection.

# Bonding Curve and Delta A bonding curve is a mathematical formula that defines the relationship between the price and the supply of a given asset in a pool (or between the assets in a pool). The curve is the core functionality that adjusts the price of the assets accordingly to the supply, and present it to users who are interested to buy and / or sell against the pool. There are 2 types of bonding curves: 1. **Linear Curve** The **linear curve** performs an additive operation to update the price. If the pool sells an NFT by giving out an NFT and receiving tokens, the next price it quotes to sell NFTs at will increase by a flat amount (known as **delta**). * As an item is bought from the pool, the price will increase by a fixed amount. The reverse happens when an item is sold into the pool. * For example, the start price is `1.0Ξ` and the delta is `0.2Ξ`. \ After someone buys 1 NFT from the pool, the price will be `1.2Ξ`. If someone sells an NFT into the pool, the price will be `0.8Ξ`. 2. **Exponential Curve** The **exponential curve** performs a multiplicative operation where the delta acts as a multiplier function. If the pool has just sold an NFT by giving out an NFT and receiving tokens, the next price it will quote to sell NFTs at will increase by a percentage amount (known as **delta**). * The price of the NFT increased by a percentage each time an item is bought from the pool. The reverse happens when an item is sold into the pool. * `delta` is a percentage and assumes that the starting price 100%. If input the `delta` as 20% it means we want the price to increase/decrease by 20% after each trade. For example, initial price is `1Ξ`, after someone buys 1 NFT from the pool, the next price will increase by the delta to `1.2Ξ`, conversely, if someone sells 1 NFT tot he pool, the next price will decease by a multiple of the delta to `0.8333Ξ` # Fee Collection adopts a **carry fee model** by design for `TRADE` pools, where the protocol takes a percentage of the trading fee. Unlike a flat fee model, carry fee model presents a fairer and more sustainable distribution across the traders, liquidity provider and the protocol. However, as a carry fee model assumes an ongoing concern (a valid assumption for `TRADE` pools which will continue to trade within a band), it may not be as valid for LIMIT-type pools which can only trade a limited number of times (`TOKEN` or `NFT` pools). For those types of pools, for simplicity of understanding, we maintain a flat fee. The protocol fee for both types of pools will be 0% at launch, and governance 👀 can decide the percentage in the future. **Royalty** Collection seeks to provide a platform that helps to balance royalty asks from traders and creators. It is therefore **recommended by default** when liquidity provider is creating the pool. While creating an incentive program for the vault, NFT Project Owners / vault creators have the option only to incentivize pools that honor royalties. # Buy / Sell Collection.xyz enables the instant buying and selling of NFTs without having to wait for takers. NFT buyers can purchase NFTs that are deposited by liquidity providers; and sellers can trade their NFTs with the best bid price available from pools on Collection. One of the goals of Collection is to help buyers and sellers obtain the best price for the NFT by encouraging liquidity providers to supply liquidity based on customized filters so that more valuable NFTs get priced appropriately. Refer to the [guide](/guides/user-guides/buy-and-sell-nfts-instantly) on how you can execute a trade. # APR Annual Percentage Rate (APR) calculation on Collection.xyz 1. Determine the **number of periods per year** based on the given duration\ We are using 1d duration, so there will be 365 periods per year
2. Calculate the **total value locked (TVL)** by multiplying the market cap of ETH by the percentage of the market cap that is actively providing liquidity:\ TVL = MarketCapEth\* pctOfMarketCapThatlsActively ProvidingLiquidity\ \ \*Assumption used:\ pctOfMarketCapThatlsActivelyProvidingLiquidity = 0.05
3. Calculate the **accrual per period** by multiplying the volume in ETH by the collection XYZ share and the fee on trade volume: accrualPerPeriod = VolumeEth \* collectionXYZShare \* feeOnTradeVolume \ \ \*Assumption used: \ collectionXYZShare = 0.2 \ feeOnTradeVolume = 0.05
4. Calculate the **accrual per year** by multiplying the accrual per period by the number of periods per year\ accrualPerYear = accrualPerPeriod \* amountOfPeriodsPerYear
5. Finally, calculate the **APR** by dividing the accrual per year by the TVL\ APR = accrual PerYear / TVL # The Collection Whitepaper We believe NFTs will blossom into the standard for wrapping *all* non-fungible assets in the world: Art, brands, IP, synthetic assets, membership, real estate, and more. NFTs are more than just "jpegs on the blockchain." They wrap data on-chain that could not previously be represented in this way, including avatars, art, collectibles, music, game items, IP, domain names, membership, tickets, identity, synthetic assets, and real estate. #### **NFTs are anti-fragile** NFTs are one of the most anti-fragile parts of the crypto industry as they represent a highly general protocol that expands the possibilities of what we can do with tokens. ERC-20 tokens successfully captured a variety of use cases during the DeFi boom of 2020-2021, and as society gains comfort and familiarity with crypto protocols, we will see an array of fundamental use cases emerge using NFTs, ERC-20, and other decentralized protocols. This on-chain activity will subsume a plethora of previously off-chain-only economic activity. This use-case expansion is why crypto protocols as a whole are anti-fragile from cycle to cycle. #### **NFTs subsume art, music, real estate, and other unique asset classes** Protocols are developed to bridge the gap, and to allow for trusted representation of real-world assets on-chain. Art, music, and real estate are traded on-chain, where the ledger is immutable, and where the markets are always open with deep liquidity. #### **The emergence of NFT Finance as a category** Decentralized finance (DeFi) demonstrated what we could do with ERC-20 fungible tokens, with the protocols in the ecosystem expanding to over $54B in total value locked (TVL) by November 2022. Total value locked is an essential and popularized metric to measure since it represents what the committed value on these protocols are. DeFi enables the permissionless transfer of value with fungible tokens, while NFT finance (NFTFi) does so with non-fungible tokens. However, given the fast-growing development trajectory and innovation speed of NFTFi projects, NFTFi is well-positioned to capture a meaningful share of the $54B DeFi TVL from its current $175M TVL. By solving the key problems with NFTFi, we will make NFTs fully generalizable and applicable to many use cases, bringing forth the next 100X in TVL. Part of the excitement and promise of NFTFi is the fact that many possibilities — of automated market making, vaulting, trading, and deep liquid markets — happen when the building blocks of DeFi are thoughtfully layered on NFTs. Liquidity begets liquidity within a more flexible market structure. #### Recent events show we **need DeFi** The collapse of FTX, 3AC, and worries of insolvency on other centralized exchanges is weighing deeply on the crypto industry. It is clear to us that the future of crypto will be one where decentralized finance (DeFi) takes center stage. In this regard, NFTs, as compared to the rest of crypto, have a head start — the existing popular places to trade NFTs are already smart-contract settled (Opensea, X2Y2, Blur). A more specialized subset is motivated by DeFi market protocols (BendDAO, Sudoswap) and is not just using the blockchain as a settlement layer. We believe that NFTs will prevail. To enable it to blossom even further, we’ve built a next-generation decentralized NFT trading protocol to create systematically-important liquidity for the whole spectrum of NFTs. [Collection.xyz](https://app.collection.xyz/) solves the following issues elegantly: 1. **Deeper liquidity for *****all***** NFTs in the collection** 2. **Enhancing composability with any NFT Finance protocol** 3. **Adequate incentives for liquidity providers to reward their commitment** ### Issue 1: Deeper liquidity **for *****all***** NFTs in the collection** Deeper liquidity of assets in a market drives greater confidence, enabling users to instantly buy and sell NFTs at the best price. Collection.xyz introduces **advanced pooling for NFTs,** which enables users to create submarkets on subsets of a collection by token IDs, traits, rarity, or other variables. We believe advanced pooling will deepen liquidity for all ranges of NFTs in any given collection. #### Individual orderbooks per NFT hamper liquidity Existing NFT marketplaces (Opensea, Looksrare, X2Y2) have prioritized focusing their solution and marketplace on individual orderbook for every unique NFT. *Opensea has the following ways to transact an NFT:* 1. *Sell now for a fixed price (suggestions (A) the floor price, (B) the top trait price, or (C) the current best collection bid)* 2. *Timed auction, sell with declining price (Dutch auction)* 3. *Timed auction, sell to highest bidder (English auction)* The first option is based on an individual orderbook. The individual orderbook is the idea that every NFT is completely unique, and there should be a list of bids and asks maintained for each item (SKU in retail parlance). As an alternative to the other two options, Opensea layers on a set of auction price discovery mechanisms. Imagine having to wait for an auction to complete to purchase every single NFT you’re interested in buying. It’s not ideal for the impatient buyer. These marketplaces tend to use the blockchain mainly as a settlement layer. The bid side liquidity is generally poor on these marketplaces. Additionally, there is a large operational overhead as bids and asks needs to be actively managed on each item, and NFT traders on each collection need significant infrastructure investment to manage orders across multiple orderbooks. For example, The Bored Ape Collection has 10,000 items, and if it became fast-moving, that is 10,000 orderbooks that need to be individually managed. Part of the reason liquidity is unnecessarily hampered in NFT markets compared to DeFi is that 1. There is a large bid/ask spread, exacerbated by exchange fees. 2. The infrastructure to manage so many individual orderbooks is a necessary evil for professional traders today. Costs and maintaining these is a full-time role that’s only accessible to a few. 3. For the regular user, managing multiple NFTs across collections is not possible. Liquidity provisioning is impossible. To take an example down DeFi history lane: Ethlend gained little traction as a p2p loan matching service. Upon pivoting and rebranding to Aave with a set of centralized pools, their business grew exponentially. NFT markets will always be plagued by liquidity challenges by a focus on individual orderbook per token ID. It is simply not scalable nor desirable for all assets to have an individual orderbook by default. We need to find common touchpoints between collections and token IDs. An individual orderbook might work well for the rarest and most valuable of NFTs — but for the mid-range, it breaks. For the mid-range, it’s far more efficient to get it from a market that sells it as part of a class. Let’s dive into some specific examples of the approach of market-making on the basis of class commonalities. **Floor-based valuation per Collection ignores the majority of the collection** To move away from individual orderbook per token ID, the next natural idea is to group assets by the entire collection. This is the approach that current NFTFi protocols take. Whether a Bored Ape or an Azuki, they are identified by their contract addresses for the whole collection. **But how would you value collateral from a single collection?** Most fledgling NFT Finance protocols group these collections, and value them on the “floor”, which is the lowest ask price across all token IDs. We think this solution is incomplete because for most collections, *80-90% of collections are not at, or even near, the floor*. For example, with Bored Apes, as of November 23, 141/771 = 18.2% of BAYC were listed in the 60-75 ETH range with the floor being 60ETH. So, if we define the “floor region” as floor + 25%, then more than 80% of NFTs are not at or near the floor. There are few economic incentives for 80% of the NFT collection’s owners to participate in DeFi protocols where their tokens are valued at a haircut. **Practically speaking, there is currently no effective price discovery for specific classes of NFT collections other than the floor.**

BAYC floor depth of listed tokens - NFTGo, 23 Nov 2022 GMT 1300. The low end forms about 20% of the collection, and the high end (more than 8x the floor) forms about 10% of the collection. ~70% of the collection is in the middle.

We find this distribution replicated across other collections such as CryptoPunks (pictured), MAYC, etc.

We see this 20-70-10 distribution often, where 20% of tokens are at the floor region of \[floor, floor \* 1.2] and 10% tokens are ≥ 8x the floor, with 70% in the middle #### Floor-based valuation is the worst way to value NFTs The data reveals that a floor-based valuation method does NOT serve the majority of NFT collectors — many users are discerning and have no reason to participate at the floor price. > *Alice is an art collector who doesn’t buy NFTs at the floor. The NFTs she buys are handpicked — ones with traits she thinks are rare or appealing. She’s heard about DeFi, BendDAO and Sudoswap, and wants to try out these new protocols. But alas, BendDAO values her NFT collateral at the floor. And if she wants to try out an automated market maker (AMM), she can use Sudoswap, but she can only set a limit sell order, since Sudoswap as-is doesn’t allow her to place bids on non-floor NFTs effectively. Alice chooses to not do anything since the tools do not enable her to.* If you’ve spent time thinking about the pros and cons of this Azuki vs that Azuki, and you’re willing to take the risk to experiment with Decentralized Finance (DeFi), you will want to try NFT Finance (NFTFi) protocols like Sudoswap. But despite the initial enthusiasm, there is simply no easy way to bridge the gap between art collectors’ needs and DeFi — because existing NFTFi protocols are built solely around **floor NFTs**. There’s little reason to participate with your non-floor NFTs in the current world of NFT finance. Valuing an entire NFT collection based on the floor price, multiplied by the total quantity in the collection, impedes the value capture of NFTs as a rich and effective protocol to subsume art and other domains. **No major market is valued based on its least valuable constituent** — e.g. the S\&P 500 is not valued by the 500th company’s market cap, nor real estate indices by the cheapest property in the portfolio. The identification of NFT protocols with 10k PFP projects (which may be more forgiving of a floor price-based valuation strategy) may blind NFT-protocol builders to the inappropriateness of using floor price valuation for other potential NFT markets, such as real estate, insurance, or art. **Let’s smash the *****floor***** and shake things up.** Different markets have already laboriously built ad hoc solutions to create meaningful subgroups of token IDs. For ENS domains, which is the largest NFT collection on Ethereum, we find specialty markets like ENS Vision which have come up with meaningful tracked submarkets — albeit still on the level of aggregating individual orderbooks for those subgroups.

For many NFT protocol use cases, we can find many meaningful subgroups at a glance. In domain names: 3 digit ENS names, country names, etc.; in 10k PFP projects, particularly valuable traits such as M2 Mutants for MAYC, Solid Gold Fur for BAYC, etc. But until now, there is no systematic solution that respects traits and is able to go beyond the individual order-book model for each individual item if it is a non-floor (or valuable part of the collection). #### **Can an appraisal system be a part of the solution?** We believe that it isn’t good enough to rely on having an individual order book for each asset. Some NFT projects, such as Spicyest, have tried to build appraisal systems, but this cannot be a long-term solution to building thick liquidity if the rails are inefficient. Liquidity needs to be instantly available on both the bid and ask sides. Appraisals mean little if there is no committed capital or NFT to buy or sell close to price X due to technical and operational friction.

An appraisal from Spicyest for BAYC #3485

We want a system where valuations are prices committed by both buyers and sellers - **liquid valuations.** We also believe that automated market makers (AMMs) are the best current NFTFi primitive to bring liquidity on-chain. AMMs automate the distribution of yield and fees to the user via smart contracts. Anyone could commit two assets in a pair to create a pool that anyone else can trade against. It enables a much wider range of users to become liquidity providers without necessarily needing to set up complex infrastructure. It’s crucial that the AMM enables anyone to create pools without the need to apply for permissions. Greater access brings about more participants and liquidity. This is similar to how Uniswap brought in a much wider range of liquidity providers that allowed it to provide more liquidity, leapfrogging a more centralized model in Kyber Network. #### Advanced pooling: Solving the “missing middle” of NFTs for NFTFi We believe there is a need to bring the missing middle of NFTs on NFTFi. Why the middle? Again, to recap, the floor is about 20% of the collection, the top end about 10% of the collection, with 70% of token IDs being in the middle. We think the vast majority of NFTs are simply not being served by the NFTFi paradigm yet. We see this distribution replicated again and again through each collection. The current NFTFi model of serving the floor may work only when the distribution is heavily towards the floor (and even then, it is a big if), but this is not how collections are empirically distributed. To solve for this, we have built **advanced pooling for NFTs;** a primitive that efficiently encodes groups of token IDs onto the pools, using a Merkle root encoding (in the most gas-efficient way). With this, you can create DeFi submarkets on subsets of a collection. * NFTs may be grouped by trait number, male or female, or their look, to create deep two-sided markets on any subset of the collection. Each NFT-ETH or NFT-ERC20 will have a Merkle root associated with it that corresponds with the token IDs belonging to a trait. * With greater expressivity and the ability to make a market on any conceivable subset of the market, liquidity can be sourced from all around the curve. Just as Picassos have their own sub-markets — (blue period, rose period, cubist), NFTs collections will be able to have DeFi-native two-sided markets for any part of their collection.

The core implementation problem such a protocol has to solve is resolving the traits data (which is a heterogenous mix of on-chain and off-chain data) **AND** making it such that we don’t make off-chain indexers a single point of failure (the token IDs must be able to be checked/verified). #### **Resolving traits data** For the former, recall that traits are often stuffed into the tokenURI field of the ERC721 standard. In the course of indexing NFTs, a sampling of the diverse trait storage formats we’ve encountered include base64 encoding directly on chain, IPFS representation, web2 URLs hosted on a server somewhere, etc. The difficulty of parsing these traits and image data results in heavy reliance on APIs to resolve these NFT assets (resolve = fetch media data and metadata in a performant way). Moxie Marlinspike (founder of Signal) blogged about his experience creating an NFT in early 2022, which highlighted the industry’s (then) reliance on the Opensea API to resolve NFTs (). A year on, there remains no standardized format for traits metadata. And perhaps there should not be — given that rich metadata storage does not appear to us to be a native concern of core Ethereum protocol development, we also find the near-term prospect of trait standardization unlikely. #### **Ensuring indexers are not a single point of failure** The token IDs that make up the pool’s Merkle hash can be easily and transparently compared between multiple providers. This ensures that there are no single points of failure. As well, you have the final say over the token IDs and Merkle hash committed to each pool. When trading, you can also transparently see the set of token IDs allowed into a pool. We propose the following workflow to create and trade advanced trait pools. **How it works:** 1. Choose a trait (e.g. Bored Ape → Fur → Solid Gold). 2. Use a backend service to get the list of token IDs corresponding to this population (note: we don’t have to trust one third-party provider as the token IDs can be compared with another provider). 3. Hash these token IDs into a Merkle root. 4. The pool uses this Merkle root only to allow these token IDs to be traded into this pool. 5. Now it is possible to trade the vastly more valuable Gold Fur Apes as their own token set, without getting stuffed with Floor Apes (as any protocol relying only on a token contract filter will do). Traits acquire an on-chain representation — and the Merkle encoding of the set of token IDs that represent it. Token IDs are emitted in an encoded format so that developers indexing the smart contract can verify that the token ids are indeed represented with the correct Merkle root. 6. We will have an open-source JS library to help generate these proofs. Given a list of token IDs, it should generate the same Merkle proof. This will be a lightweight library — usable both on the frontend and backend. Our design principle for this ensures that everyone should be able to use this JS library to verify membership quickly. There are two interactions with the contract where you need to know the Merkle encoding, which is available in the open-source library. * Pair creation. E.g. Bored Ape, Golden Fur <> ETH * Making a trade on a pair E.g. Selling into the pair The Merkle tree approach we feel is the most gas-efficient and composable way is to create pairs. We picked this direction as opposed to two other alternatives we considered: Oracles (expensive to make external function calls), and bitmap packing (efficient up to a point, but doesn’t scale well beyond a few thousand; bitmap packing also makes things less composable as there still needs to be a hash to compare for further downstream aggregation and comparison). We’ve open-sourced our Javascript proof generation off-chain library and on-chain contracts for verification and inspection of our methodology. We are excited to see how the community interacts with advanced pooling. ### Issue 2: **Enhancing composability with any NFT Finance protocol** We believe strongly in the DeFi principles of composability — allowing multiple protocols to be used in tandem with the hypothecation of valuable economic activity. A sophisticated financial system — like DeFi, which aims to financialize an ever-increasing amount of the world’s assets — must be able to apportion risk correctly, or have the ability to apportion the risk in the first place. Productive economic activity (such as AMMs) should be itself subject to market forces. All DeFi primitives need to be built with composability in mind — and allow value capture by different protocols. This is a core design principle in non-NFT DeFi, and Collection brings it to NFT DeFi with our LP token. Previous generations of AMMs, such as Sudoswap, lacked this LP token and the ensuing composability. #### The NFTFi Lego brick - Collection.xyz

Collection.xyz is a Lego plate - which is a solid building block in any NFT ecosystem. NFT DeFi without an LP token are Lego tiles - terminal and cannot be built upon. As Collection.xyz builds out its vision of an NFT value chain, it will more and more resemble a brick!

Let’s use an analogy from Lego, since DeFi often promulgates a self-image of money-Legos. In Lego, tiles are often used to smooth out the studded appearance of many models but are seen as a terminal piece that cannot be built upon (for obvious reasons - namely, it lacks studs on top). It can cap building activity but is used only as the last part of the model-making. Collection.xyz is a plate that allows others to build on, as it has stud connectors above and stud connectors below. The workhorses of the Lego buildings are bricks and plates because they build on top of things, and in turn things can be built on top of them. They are bidirectional and can redirect productive building activity — just as Collection.xyz connects the world of liquidity provision and yield. We also prefer the ERC-721 over the ERC-20 implementation of LP tokens as ERC-20 complicates retrieval/redemption of the original liquidity provided. ERC-721 tokens don’t have fractionalization issues, and one can have full control over a given pool of liquidity — i.e. with any trade, one can understand how one’s LP collateral evolves, and withdrawal is uncomplicated. The much more important benefit of tokenization is hypothecation over fractionalization. #### **What does composability mean to the Collection team?** We know that “composability” is a term that is used fast and loose in DeFi. To us, **composability** is a set of design principles. It should: 1. Be a set of independent and self-contained services that performs a specific function related to money. 2. Have use outside of the original team’s protocol (which can be achieved through functions that can be built on, or representation as a standard protocol). Previous iterations of NFTFi have not conformed to this standard. Sudoswap’s pool ownership representing AMM activities for instance: It lacked an LP representation or any smart contract functionality that could be extended, and thus was difficult to represent to an external protocol. Composability is important to us because we believe economically useful protocols should have the maximum surface to build off of. Standardized interfaces like ERC721 help keep the mental model simple, making it easy to extend smart contract functions allows for creativity and extension of the core protocol once deployed. Thus, the Collection AMM focuses on having the ability to represent productive AMM activity through the LP token representation. All pools in Collection have ownership represented as an ERC721 LP token, which can be used as proof of ownership or further used in other DeFi protocols. LP tokens represent a claim on the base economically productive activity — fees from trading. ### Issue 3: **Adequate incentives for liquidity providers to reward their commitment** NFTFi and DeFi protocols live and die by the liquidity they can attract from users. For most NFT communities and collections, they need additional tools and infrastructure to attract more liquidity providers for their collection. NFT creators can issue additional NFT collections or ERC-20 tokens that perform various utilities. Collection.xyz enable them to reward liquidity providers through these NFT and fungible tokens. #### How to ensure deep liquidity even in times of crisis? For liquidity providers, vaults with incentives and compensation mechanisms to make up for losing optionality. The risks can also be explained as non-mean-reversion (a.k.a. impermanent loss / negative gamma for the quantitative finance-savvy). Market makers (of which AMMs are a specific case) are short optionality. A market-maker of asset A vs. asset B makes money based on these factors: * The volatility of the price ratio A/B (A/B = price of A denominated as multiples of the price of B; the volatility is the degree of change of this ratio) * The amount of time the market maker is taking on the risk * The distance of the end number A/B at t1 vs the initial number A/B at t0 (the drift) What is an AMM? An AMM is a protocol that makes a market through a series of formulae/algorithms around a certain price. The popular term “impermanent loss”, is misleading because “impermanent” is based on assumption that prices mean-revert to wherever it is you first contributed liquidity. Losses are real if the price has drifted to a new ratio of A/B. The benefits to a retail user are that an AMM imposes a lot less cognitive overhead. It’s easy to understand and utilize. Anyone can be a market-maker. AMMs are compensated by the fees and/or the bid/ask spread that is received by the pool. However, in a market that participants believe is not mean reverting, and the more widespread this belief is, the less liquidity will be available to the market. NFTFi generally works within a range, like Uniswap v3. Unlike in XYK curves in wider defi, given the step-change function (e.g. you buy Azuki #1 for 8 ETH, and then Azuki #2 for 9 ETH) and low amount of liquidity of NFT pairs (i.e., you have 1-50 Azukis on one side, and a limited amount of ETH to buy Azukis; not a highly divisible ERC20 balance unlike previous DeFi), you only have the liquidity to make within a range \[p0, p1] where p0 and p1 are prices of the NFT in its pair in ETH or ERC20 token. Optionality is time-based leverage. If you are long optionality/gamma, you have a chance of an outsize payoff, but pay a fee every day in option decay to achieve it. If you are short optionality, you receive fees but must hope for mean-reversion in order to turn a profit. To read more on gamma: **Intuition:** For traditional market makers, the market price of risk is approximated by the time premium of selling an at-the-money strangle (strikes = bid/ask). You are short gamma, believing in mean-reversion within the range. In traditional markets such as S\&P options, the option premium is the fair market price for the volatility or expected scalps within that period. A gamma ladder example: * Centre spot price at $100 * Buy at $80, 85, 90, 95, Sell at $105, 110, 115, 120 * When you are fulfilled on an order, put a new order in the opposite direction above (e.g. you buy at $95, you put a sell order at $100, and your new center spot price is $95) * As long as you return back to $100, if you roundtrip many times (e.g. $95-$100, 95-100), you will make $2.50 per trade. * This is the profit that the option premium (up to time t) tries to approximate. * Losses get large if prices drift far out of the range of the gamma ladder’s orders

If a protocol is designed where a large fraction of liquidity is provided by AMMs, we believe that there need to be alternative channels other than just the fee+bid-ask-scalping to compensate and reward systemically important liquidity. A smart market maker would simply withdraw liquidity whenever he/she believes it no longer suits to make a market, or that it will no longer be mean-reverting. But this would mean that the underlying trading protocol will undergo reflexive fragmentation, the belief of future directional moves damages liquidity sufficiently such that any volume may move the market. To some extent, this is the reflexive nature of all financial markets. #### Building counter-cyclical shock absorbers As market designers, there are counter-cyclical shock absorbers that can be built to be robust against such reflexivity. Collection’s vaults make it possible to express the view that liquidity is desirable — more than can be compensated by fees — and to reduce the correlation between the liquidity for trading and the incentives for AMM. Currently, the DeFi protocols for NFTFi (for those that allow for individual liquidity over communal liquidity) do not have ways to compensate providers of liquidity beyond fees. * Part of the problem is due to the lack of LP tokens representing the LP activity. * Another part of the problem is discoverability — because the AMMs tend to be on an individual curve basis (in order not to deal with problems of redemption of a communal pool), the trading experience across pools relies on backend indexing for discoverability of pools, and there is no on-chain aggregation. Therefore we’ve built the plumbing to enable yields to be linked to liquidity provided to an individual pool, while preserving individual liquidity share. The primitive for liquidity incentives is the **Vault**, which makes it possible to incentivize AMMs above and beyond their trading fees for a period of time. * Rewards can be in any ERC-20 token or ERC-721 (think USDC, WETH, 100 Azuki Beans or 1 rare Azuki). * This provides a route to compensate the market makers for providing systemically important liquidity at times of their choosing. We’ve observed that many collection creators do not have the capacity to incentivize liquidity with ERC-20 tokens; as such, enabling a draw reward vault with ERC-721 tokens creates the possibility of creating derivative NFT collections to reward liquidity on the primary NFT liquidity. For vaults that are ERC-20 tokens, users get a fractional reward based on the contribution of liquidity to the overall pool. For ERC-721 tokens, the liquidity provided by users entitles them to tickets to participate in the draw of the ERC-721 NFTs. Using a VRF from the Chainlink oracle, it’s proven to be a fair draw. Parameters are set by the vault creator, thus they can incentivize various factors such as honoring royalties, a certain tight bid-ask delta, fees, and specific classes of NFTs. Different styles of vaults can arise with different compensation strategies and apportioning mechanisms (two-sided, single-sided, etc), because the Collection AMM is composable with any Collection Vault or protocol utilizing the LP token. ### Two more technical design choices we made in line with our design principles and commitment to NFTFi #### You control your curve: Personal curves over communal curves **Why we chose not to go down the Uniswap route of a global unified liquidity pool.** Uniswap’s model requires you to cede control of the prices you buy at; you join a global liquidity pool that buys and sells at certain points. Additionally, common pools are fungible, but NFTs are non-fungible. * **Collection.xyz** * Have control over where you want to buy/sell * Clear demarcation of ownership of NFTs. One-to-one — you own your liquidity — if there are no trades, you definitely own your own liquidity * Need help to determine at-the-money liquidity * **Uniswap** * The native notion of at-the money liquidity / effective liquidity because you know which tick you are near * Communal pooling needs to solve the problem of withdrawing from a common pool. Users are not indifferent to what is withdrawn from the pool, barring any commercial activity, they would like the same NFT to be given to them. #### 0% protocol fee. Royalties and fees set by liquidity providers We’re launching with 0% protocol fees, and governance can decide to adopt carry fees. Liquidity pool owners determine the pool fees and royalty % for the pools they create. We encourage liquidity pool creators to honor royalties, and vault creators can incentivize liquidity providers to do so. DeFi protocols now have zero or near-zero fees and are run as public goods. Flat protocol fees are poor design. NFTs with a tight width (e.g. 2-5%) between bid/ask are charged exactly the same as NFTs with a loose width (5-15%). What is fairer is that the protocol take should be parameterized by the amount of the actual fees. A more transparent, carry model, on the percent of the fees, **itself a percent of the actual transaction value.** Carry can be between 0-X%. We don’t want to take a flat protocol fee. We believe in the carry model: We make money when you make money. #### LFG, NFTFi We know it’s the crypto ice age — but hey, our ancestral mammals also banded together for the journey to spring, right? We look forward to building together with the broader NFT community. [Collection.xyz](https://app.collection.xyz/) aims to be the decentralized exchange protocol for NFTs that forms the building bricks for the movement of NFT Finance in the foreseeable future. The core team has been building through various market cycles with companies such as Coinbase, CoinMarketCap, and Chainlink. We welcome any developer or team to join us in the mission to make NFTs more liquid and accessible to everyone. ### Try [Collection.xyz](https://app.collection.xyz/) as we launch the AMM on Ethereum Mainnet on April 4, 2023. # Collection 1.00: Patch Notes Written like a patch note for gamers, just for you, anon. #### New subclass system: Collection AMM now allows you to create/ trade submarkets of NFTs. * Prior to patch 1.00, it was impossible to create submarkets of a collection you wanted to trade on. In the following, we’ll take 3 examples, Solid Gold Fur Bored Apes, M2 Mutants, and male Azukis. You could either participate in a bidding process for individual items or on the level of a collection, but not in a two-sided way for any subgroup.

	Bid side for a Golden Fur Trait	Ask side for a Golden Fur Trait
Opensea	Put a collection offer with a trait filter	For the Golden Fur Apes you own, you have to put them up for sale individually
X2Y2	Not possible - trait filters don’t exist	For the Golden Fur Apes you own, you have to put them up for sale individually
Sudoswap	Not possible - trait filters don’t exist	You can put a limit sell for a Golden Fur Ape, but it cannot be put in a 2-sided AMM trading pool because the bid is the BAYC floor which is far away.
Blur	? - Couldn’t find a filtered collection offer

* Possible participation of non-floor NFTs in current DeFi protocols is sporadic because they either value your NFT as a floor NFT of the Collection (Benddao, Sudoswap), or are p2p loans (e.g. NFTfi) which don’t scale.

	Type of Protocol	Can it attribute a premium to non-floor NFTs?
NFTfi (the protocol)	Borrow/Lend	Yes because it is a 1-1 loan origination platform
Benddao	Borrow/Lend	No
Sudoswap	AMM	No

* How it’s done: Advanced trading is open when a Collection pool creator creates a pool with a Merkle root corresponding to the set of Token IDs. * e.g., \[73, 197, 232, 528, 544, 793, 811, 830, 1726, 1734, 1837, 2089, 2177, 2489, 2646, 3072, 3105, 3439, 3749, 3863, 3928, 4400, 4580, 4614, 4873, 4959, 4980, 5233, 5383, 5742, 5809, 5953, 6388, 6473, 7090, 7398, 7527, 7940, 8552, 8650, 8664, 8817, 8824, 8861, 9186, 9572] for the Fur - Solid Gold trait for Bored Ape Yacht Club. This can be done on any UI, including the Collection UI. * Collection backend indexes events whenever the pool Merkle hash is created or modified and associates each token ID with a pool. * Whenever one trades with the pool, a Merkle proof is provided, which allows you to buy or sell into the pool. This can be created client-side (frontend and/or backend) by a Javascript open-source library we provide. * Merkle root trading pools (one-sided or two-sided) also allow you to bring your submarket to endgame quest content such as the RewardVaults (see below). #### New items: LP tokens now represent ownership of your pool * Creating any Collection AMM Pair now gives you an LP token for each pool. Ownership of a pool is now 1:1, represented as an LP token * Prior versions of NFTFi have no such representation * This can be staked into further protocols (Collection provides the RewardVault endgame content), which form a strong ecosystem * This allows secondary market transactions for pool ownership * Balance changes: * LP tokens, in keeping with the rest of DeFi, now represent a claim on pool fees - economic activity generated by the pool #### New endgame quest: LP tokens now allow you to instance your liquidity into the endgame RewardVaults - choose from 3 gauntlets: RewardVault, RewardVaultDraw, and SingleSidedRewardVaults * Collection vaults allow for liquidity to be incentivized in all-weather conditions. * The liquidity of the market hence can be increased by the endgame content of RewardVaults. By providing a route to compensate the market makers for providing systemically important liquidity at particular points. * NFT Collections can create their own endgame vaults to reward players for providing liquidity. * The endgame quest is as follows: the player must collect LP tokens for the Collection AMM pair they’ve created. These can be obtained by creating these pairs or purchasing them on the secondary market. Once the player has LP tokens, they can instance their liquidity into the endgame gauntlet of their choice. * You as an NFT Collection: * You are able to create instances of these endgame vault types: * In the RewardVault gauntlet, you can set ERC20 rewards for a collection or any subset thereof, boosting market liquidity for these collections * In the RewardVaultDraw gauntlet, you can set any combination of ERC20 and ERC721 rewards as a draw for the collections, boosting market liquidity for these conditions * In the SingleSidedRewardVault, you can set ERC20 rewards for both the bid side (ETH or ERC20) and the ask side (NFTs) * You as a player: * In the RewardVault gauntlet, the player can earn rewards by providing liquidity to the market. The more two-sided liquidity the player provides, the more rewards they can earn. * In the RewardVaultDraw gauntlet, the player can earn rewards by providing two-sided liquidity and stand to win prize draws. The more tickets the player has, the more likely they are to win. * Explore the vaults that have been created, participate in richer endgame content #### New spells: New curves such as sigmoid * Curves such as sigmoid have been added to the mix to enable more expressiveness * Sigmoid allows you to specify an effective price floor and ceiling to the items you buy, and determine the steepness of the middle part #### Nerf: Protocol fee has been nerfed to 0%, and a carry model if it is increased. * Protocol fees are set as 0%. Individual pool creators can set the royalty and pool fee % they so desire. * A flat protocol fee of 0.5% is out of keeping with the rest of DeFi, Collection believes the protocol should be making money only when your underlying users make money. Therefore the default method of determining protocol fees will only be as a percentage of user fees (that they make from their AMM activity) #### Developer notes: All of the above will be open-sourced under the AGPL-3.0 license after Ethereum mainnet launch * Collectionswap contracts: * Javascript library: #### Open beta: Goerli * Private beta on Goerli: December 2022 (completed) * Open beta on Goerli: We will run an open beta on Goerli in Jan (live) * Try out our protocol: and please give us feedback at our Discord # Create a Trade Pool Create a trade pool with tokens, NFTs, or both NFTs & tokens 1\. To create a trade pool, click "Create Pool".

Buy and Sell NFTs with ERC-20 tokens, NFT, or both

2\. Click "Buy and Sell NFTs" to market make automatically. 3\. Select the NFT collection for which you are creating a trading pool. 4\. Decide whether you want your trading pool to accept only ***certain** NFTs* of the collection \[Advanced Pool] or ***all** NFTs* of the collection \[Basic Pool]. * Select the “Yes, accept only certain NFTs of the collection” option to start customizing the NFTs you are going to trade against. Proceed to step 5. * Select the "No, accept all NFTs of the collection" option if you do not wish to customize the NFTs you are going to trade against. Proceed to step 6.

5\. You may customize your NFT Pool on this page. You may filter the selected NFTs you would like to trade with based on tokenIDs, traits, and rarity.

6\. Next, set the parameters for the pool and deposit your assets. * Set a **start price**: Your start price is effectively the mid-price in trading terms, which will determine the buy and sell price of your NFTs. {% hint style="info" %} \#Tip: To optimize your trades, if your NFTs contain traits that are rare, we recommend setting your start price above the current floor price of the collection. {% endhint %} * Set the **amount of tokens** and **number of NFT** to deposit. * Set the number of NFTs your pool can buy up to and you will need to deposit the corresponding ETH amount to support future buys. * Set the number of NFTs your pool can sell up to by selecting the NFTs from your wallet and click “Confirm selection”. * Set a **trading** **fee percentage** you would like to earn whenever a trade happens. * Select a **bonding curve** type, and input the **delta value.** * At present, Collection.xyz supports 2 types of bonding curves i.e.[ linear](/guides/collection-concepts/bonding-curve-and-delta) and [exponential](/guides/collection-concepts/bonding-curve-and-delta). Both curves are parameterized by the delta. After a user trades with a pool, the pool consults its bonding curve to determine how the price of an NFT should change given the delta value. * The[ linear](/guides/collection-concepts/bonding-curve-and-delta) curve performs an additive operation to update the price. If the pool sells an NFT by giving out an NFT and receiving tokens, the next price it quotes to sell NFTs will increase by a flat amount (known as delta). * The [exponential](/guides/collection-concepts/bonding-curve-and-delta) curve performs a multiplicative operation where the delta acts as a multiplier function. If the pool has just sold an NFT by giving out an NFT and receiving tokens, the next price it will quote to sell NFTs at will increase by a percentage amount (known as delta). * Set the **royalty** fee, and fee recipient’s wallet address. The setting of royalties is optional. * If you would like to exclude NFTs that are marked as suspicious by Opensea, toggle on "Exclude Marked NFTs". 7\. Review your pool settings and parameters. 8\. Finally, click "approve and create pool" to initiate pool creation, and confirm the transaction in your wallet. # Create a Buy Pool Limit buy NFTs ## **Use Case #1: Collection Bid** 1\. Enter the NFT Explorer page

2\. Click on "Collection Bid"

3\. Set the parameters for the pool and deposit your ERC-20 tokens. * Set a **start price**: Your start price is effectively the mid-price in trading terms, which will determine the buy and sell price of your NFTs. {% hint style="info" %} \#Tip: To optimize your trades, if your NFTs contain traits that are rare, we recommend setting your start price above the current floor price of the collection. {% endhint %} * Select a **bonding curve**[ type](/guides/collection-concepts/bonding-curve-and-delta), and input the **delta value.** * Set a **trading** **fee percentage** you would like to earn whenever a trade happens. * Set the **royalty** fee, and fee recipient’s wallet address. The setting of royalties is optional. * Set the **amount of ERC-20** to deposit. * If you would like to exclude NFTs that are marked as suspicious by Opensea, toggle on "Exclude Marked NFTs". 4\. Review your pool settings and parameters. 5\. Finally, click "approve and create pool" to initiate pool creation, and confirm the transaction in your wallet. ## **Use Case #2: General (Create Pool)** 1\. To create a buying pool, click "Create pool" and then "Buy NFTs".

2\. Select the NFT collection from which you are buying NFT. 3\. Decide whether you want your buy pool to accept only ***certain** NFTs* of the collection \[Advanced Pool] or ***all** NFTs* of the collection \[Basic Pool]. * Select the “Yes, accept only certain NFTs of the collection” option to start customizing the NFTs you are going to trade against. Proceed to step 5. * Select the "No, accept all NFTs of the collection" option if you do not wish to customize the NFTs you are going to trade against. Proceed to step 6.

4\. You may customize your NFT Pool on this page, by filtering based on tokenIDs, traits, and rarity.

5\. Set the parameters for the pool and deposit your NFTs. * Set a **start price** * Select a **bonding curve** [type](/guides/collection-concepts/bonding-curve-and-delta), and input the **delta value.** * Set a **trading** **fee percentage** you would like to earn whenever a trade happens. * Set the **royalty** fee, and fee recipient’s wallet address. The setting of royalties is optional. * Set the **number of NFT** to deposit. * If you would like to exclude NFTs that are marked as suspicious by Opensea, toggle on "Exclude Marked NFTs". 4\. Review your pool settings and parameters. 5\. Finally, click "approve and create pool" to initiate pool creation, and confirm the transaction in your wallet. # Create a Sell Pool Limit sell your NFTs ## **Use Case #1: From Portfolio** 1\. Click "Portfolio". 2\. Select the NFTs you want to sell, and click "List X items".

3\. Next, set the parameters for the pool. * Set a **start price**: Your start price is effectively the mid-price in trading terms, which will determine the buy and sell price of your NFTs. {% hint style="info" %} \#Tip: To optimize your trades, if your NFTs contain traits that are rare, we recommend setting your start price above the current floor price of the collection. {% endhint %} * Select a **bonding curve** type, and input the **delta value.** * At present, Collection.xyz supports 2 types of bonding curves i.e. [linear](/guides/collection-concepts/bonding-curve-and-delta) and [exponential](/guides/collection-concepts/bonding-curve-and-delta). Both curves are parameterized by the delta. After a user trades with a pool, the pool consults its bonding curve to determine how the price of an NFT should change given the delta value. * The [linear](/guides/collection-concepts/bonding-curve-and-delta) curve performs an additive operation to update the price. If the pool sells an NFT by giving out an NFT and receiving tokens, the next price it quotes to sell NFTs at will increase by a flat amount (known as delta). * The [exponential](/guides/collection-concepts/bonding-curve-and-delta) curve performs a multiplicative operation where the delta acts as a multiplier function. If the pool has just sold an NFT by giving out an NFT and receiving tokens, the next price it will quote to sell NFTs at will increase by a percentage amount (known as delta). * Set the **royalty** fee, and fee recipient’s wallet address. The setting of royalties is optional. * If you would like to exclude NFTs that are marked as suspicious by Opensea, toggle on "Exclude Marked NFTs". 4\. Review your pool settings and parameters. 5\. Finally, click "Next" to initiate pool creation, and confirm the transaction in your wallet. ## **Use Case #2: General** 1\. To create a sell pool, click "Create pool" and "Sell NFTs".

2\. Select the NFT collection from which you want to sell your NFTs.

3\. Set the parameters for the pool and deposit your NFTs. * Set a **start price**: Your start price is effectively the mid-price in trading terms, which will determine the buy and sell price of your NFTs. {% hint style="info" %} \#Tip: To optimize your trades, if your NFTs contain traits that are rare, we recommend setting your start price above the current floor price of the collection. {% endhint %} * Select a **bonding curve**[ type](/guides/collection-concepts/bonding-curve-and-delta), and input the **delta value.** * Set a **trading** **fee percentage** you would like to earn whenever a trade happens. * Set the **royalty** fee, and fee recipient’s wallet address. The setting of royalties is optional. * Set the **number of NFT** to deposit. * If you would like to exclude NFTs that are marked as suspicious by Opensea, toggle on "Exclude Marked NFTs". 4\. Review your pool settings and parameters. 5\. Finally, click "approve and create pool" to initiate pool creation, and confirm the transaction in your wallet. # Buy & Sell NFTs instantly Buy and Sell NFTs If you are looking to Buy or Sell NFTs from Collection.xyz, here’s how you can do it - ## Buy NFTs

1\. After entering the Collection dApp, click on a collection you want to buy the NFT from 2\. Browse through the NFTs available for sale 3\. Hover over the NFT you would like to purchase, and click "Buy Now" * If you want to buy multiple NFTs, click on the "+" button 4\. Confirm the transaction in your wallet to finalize the transaction ## Sell NFTs

1\. After entering the Collection dApp, click on "Portfolio" 2\. Hover over the specific NFT you would like to sell and click it should direct you to its individual NFT page 3\. Click “Sell Now” button to initiate the sale 4\. Confirm the transaction in your wallet to finalize the transaction # LP Strategy Guide To begin thinking about your liquidity provision strategy, select a NFT collection and answer this question: > **Do I want to buy / sell / earn yield?** #### 🦀 T**o earn yield on your NFTs via bid/ask spreads & trading fees** 1. Create a **Buy & Sell NFTs** Pool on [Collection.xyz](http://Collection.xyz) 2. Select the NFTs attributes you want to sell (e.g. Golden Azukis) 3. Customise your pool strategy & parameters 1. Set **Start Price** as the price 2. Set **Delta** to **5%** (i.e. with every trade that your pool executes, it’ll buy/sell the next NFT at a 5% cheaper/higher price) 3. Set **Trading Fee** to **1%** (i.e. with every trade that your pool executes, you will receive 1% of the NFT price) 4. Set **Royalties** to your desired amount 4. Deposit NFTs & ETH that you are LP-ing 1. Have a buy bias? Deposit more ETH 2. Have a sell bias? Deposit more NFTs 3. Don’t have a buy/sell bias? Deposit equal amounts of ETH & NFTs 5. Approve & Create Pool {% hint style="info" %} If you have many NFTs in 1 collection with different rarity / price premiums, you are recommended to create multiple pools for each rarity/price tier, so that you extract the most value out of your strategies {% endhint %}

🐂 To buy NFTs only (without selling after the purchase)

1. Create a **Buy NFTs** Pool on [Collection.xyz](http://Collection.xyz) 2. Select the NFTs attributes you want to buy (e.g. Golden Azukis) 3. Customise your pool strategy & parameters * Set **Start Price** to how much you want to buy the NFT for * Set **Delta** to **5%** (i.e. with every buy that your pool executes, it’ll buy the next NFT at a 5% cheaper price) * Set **Trading Fee** to **1%** (i.e. with every buy that your pool executes, you will receive 1% of the NFT price) * Set **Royalties** to your desired amount 4. Deposit ETH that you want to buy NFTs with 5. Approve & Create Pool

🐻 To sell NFTs only (without buying after the sale)

1. Create a **Sell NFTs** Pool on [Collection.xyz](http://Collection.xyz) 2. Select the NFTs attributes you want to sell (e.g. Golden Azukis) 3. Customise your pool strategy & parameters 1. Set **Start Price** to how much you want to sell the NFT for 2. Set **Delta** to **5%** (i.e. with every buy that your pool executes, it’ll sell the next NFT at a 5% higher price) 3. Set **Trading Fee** to **1%** (i.e. with every buy that your pool executes, you will receive 1% of the NFT price) 4. Set **Royalties** to your desired amount 4. Deposit NFTs you want to sell 5. Approve & Create Pool

* # NFT AMM # What Is A CollectionPool? A CollectionPool is a liquidity pool that represents a set of automatic buy and/or sell orders for an NFT denoted in its base currency. A CollectionPool’s owner is an Ethereum address `ownerAddress` if and only if the `ownerAddress` is the `ownerOf()` the LPToken (short for Liquidity Pool Token) `tokenId` corresponding to the CollectionPool address. Each LPToken is represented by an ERC721 token. CollectionPools are deployed from a factory contract called `CollectionPoolFactory` which also the ERC721 contract. In order to check the correspondence of an LPToken `tokenId` with a pool address, one can use the `poolAddressOf()` function. Given that we identify CollectionPool ownership entirely with ownership of the LPToken, ownership of the AMM activity and liquidity can be easily composed with other functions and traded. LPTokens accrue the fees from trading activities for a particular pool, which are separately accounted for. For [Collection.xyz](http://collection.xyz/) v2, we support ERC721 (for NFTs, ERC1155 coming in a future version) and ETH/ERC20 on the other side. For convention’s sake, for a TOKEN-NFT pair, we consider the TOKEN pair the bid side, and the NFT the ask side. # Differences Between Individual And Communal Liquidity Pool Model There are at least two different major variants and implementations of Liquidity Pools, `communal` and `individual`. An example of a communal Liquidity Pool protocol is Uniswap - individual users cede control of the prices they buy or sell at (which are defined by `Ticks`, and join a common liquidity pool, though they may be able to specify the amount of liquidity they wish to contribute at each `Tick.`There is also a more complex problem for communal pooling to solve - namely, that while depositing non-fungible tokens into a pool may be unproblematic, deciding which of a set of non-fungible tokens to withdraw when the original owner wants it is non-trivial. There is nothing tying the original depositor to the original NFTs that they deposited - but this we feel is a poor experience. Users are not indifferent to what is withdrawn from the pool, barring any commercial activity, they would like the same NFT to be given to them. The notion of Liquidity Pool Collection subscribes to is not a `communal` pool, but an `individual` one. Here, users create a contract per Liquidity Pool that they fully control. Since there is no communal pooling of assets, withdrawal corresponds to whatever is deposited (barring any commercial activity). Individual pools can be thought of as price-ladders where users put buy or sell orders. But how then is liquidity aggregated across markets? The work of price discovery is deferred to backend indexing processes which can surface the best price at any given moment. This is a standard paradigm for NFT smart contract marketplaces that give up a global best bid/ask liquidity view in order to better capture the spirit of non-fungible finance (namely, granular access controls and apportioning of ownership, and individual control of price setting by token owners)

	Individual (Collection.xyz)	Communal (Uniswap style)
Withdrawal of NFTs	Straightforward - every pool is controlled by owner so you withdraw either what you put in, or whatever NFT was sold into the pool	Have to resolve communal ownership of a group of NFTs
Control of Prices	Total	Cannot specify actual levels to buy or sell, only liquidity levels at each pre-defined price level - Levels are pre-defined by communal pool owner
How to get best bids/asks for tokens	Rely on indexing of on-chain events	Can be gotten directly from smart contract
Fees	Rely on indexing of on-chain events	Fees are spread amongst all liquidity providers

# How do I determine if a pool has sufficient liquidity to fulfil an order? To determine if a pool has enough liquidity to fulfill an order, you can use the convenience function `balanceToFulfillSellNFT`. This function returns the minimum pool balance (in Ethereum) required to complete a trade where a user sells an NFT to the pool, after accounting for fees and royalties. If the pool's Ethereum balance is equal to or greater than the value returned by this function, the pool has sufficient liquidity to fulfill the order. # Fee Structure # Overview of the Fee Structure in NFT AMMs There are three parties that can receive fees when a trade is made. * First, the pool creator. * Second, the protocol itself (Collection.xyz). * Third, any collection that implements royalties through ERC2981 would be able to collect on that. Pool fees can further be split into a flat fee (e.g. 0.5% of the value of the trade), or a carry fee (e.g. protocol fee 20% of the fee that a user charges). Here is a breakdown of Collection’s fee structure - We prefer carry fees over flat fees generally for true two-sided AMM activity (TRADE pools). DeFi protocols now have zero or near-zero fees and are run as public goods, and we feel that in two-sided AMM activity, flat protocol fees are poor design. NFTs with a tight width (e.g. 2-5%) between bid/ask are charged exactly the same as NFTs with a loose width (5-15%). What is fairer is that the protocol take should be proportional to the amount of the actual fees the user charges. A more transparent carry model, on the percent of the fees, itself a percent of the actual transaction value. [Collection.xyz](http://collection.xyz/) will start with 0% protocol fees, but ultimately we want to make money when the user makes money\ \ However, we maintain a flat fee for NFT/TOKEN pools since that is one-time liquidity (e.g., a TOKEN pool may have a bid for an NFT, but after it buys the NFT, it does not sell it again unlike two-sided TRADE pools). Since the pool is not a going concern once the trades are fulfilled, it is conceptually cleaner to have flat fees for these sorts of pools.

	Collection.xyz	Other AMMs	Beneficial party
Flat fee (as percentage of trade)	NFT/TOKEN pools - only limit pools that have one-time liquidity	On ALL pools	Collection.xyz
Carry fee (as a percentage of user set trade fee, which is itself as percentage of trade)	TRADE pools - these pools can trade infinitely, so we charge a percentage on any buy/sell activities. At inception, this is set to zero, though this can be changed through governance	no notion of carry	Collection.xyz
User-defined fee	This is set by the owner of each pool, and determines the carry fee above.	This is set by the owner of each pool, and determines the carry fee above.	The user
Royalty	RoyaltyFee - set as RoyaltyNumerator. Set by default through Collection.xyz app to be equal the amount specified by ERC2981. This number is an override RoyaltyRecipient - set by default to be the recipient by ERC2981. Note that this cannot be overridden by the user if it is set in ERC2981 (to prevent royalty siphoning). It is thus a fallback and not an override if they royalty recipient is not set by the Collection.	no notion of royalty	The NFT collection

# Calculation and Collection of Fees * Flat fee = percentage of final traded price * User-defined fee = user defined percentage of final traded price * Carry fee = percentage of user-defined fee * Royalty = set by `royaltyNumerator` where 100% is 1e18. # Royalties # How are royalties implemented? The main on-chain implementation of royalties is ERC2981. ERC2981 is a standard that advises on a particular amount `royaltyAmount` and royalty receiver address `receiver` given a `tokenId` and overall `salePrice`. () For example, to say that royalties are 1% would be to input `10000` in `salePrice` and get `100` as the `royaltyAmount` Other royalties numbers can be off-chain by collection owners on third party websites such as Opensea or Looksrare, but can only be gotten periodically and thus done on a error-prone best effort basis. The advisory nature of ERC2981 makes it an incomplete solution. As the most widely adopted royalty standard at the moment, we integrate with it in a nuanced way: We use the derived royalty percentage as an override, while in order to prevent pool creators from siphoning off royalties from NFT collections maliciously, we allow royaltyRecipient to be set as a fallback, a place to be sent if the `receiver` is not set to any value, as per ERC2981 # Relation between Royalties and Fees in the AMMs Ultimately, they are distinguished by the beneficial party. Please refer to this destination chart
| | Beneficial party | | ----------------------------------------------------------------------------------------- | ------------------------------------------------- | | User-defined fee | The user | | Royalty | The NFT collection (addressed defined by the user | | Flat fee (as percentage of trade) | Collection.xyz | | Carry fee (as a percentage of user set trade fee, which is itself as percentage of trade) | Collection.xyz | # All Possible Royalty Scenarios As royalties are done on a best effort basis, there are a couple of special cases we have to handle

royaltyNumerator is set	ERC2981 is set	receiver is set in ERC2981	royaltyRecipientFallback is set	What happens to Royalties
Non-zero	Yes	Yes	N/A	Sent to ERC2981 Receiver
Non-zero	No	N/A	Yes	Sent to the royaltyRecipientFallback
Non-zero	Yes	No	Yes	Sent to the royaltyRecipientFallback
Non-zero	Yes	No	No	Sent to the pool
Non-zero	No	N/A	No	We don’t allow this configuration
Zero	N/A	N/A	N/A	No royalties

# Airdrop Compatibility # Can Collection.xyz handle airdrops? Yes, [Collection.xyz](https://app.collection.xyz/) can handle airdrops. So long as the airdops are sent to the smart contract, users will be able to withdraw the airdrops at a later date. We have specific ERC20, ERC721, and ERC1155 rescue functions for the owner of each CollectionPool’s LP token. With these functions, you can rescue arbitrary ERC20, 721 and 1155 tokens from these pools. However, in the case where non-tokenized perks (e.g. whitelists) are given to the NFT holder, the liquidity pool smart contract will be the recipient. In these cases, projects will need to work with [collection.xyz](https://app.collection.xyz/) to specifically pass these benefits to the ultimate owner of the NFTs. This is possible through either (A) querying `ownerOf()` on the LPToken, or if you have the `poolAddress` (B) calling the `tokenId` function if you want to tie it to ownership at a particular blockheight, or (C) the `owner()` function to directly get the current tokenID owner, or , and passing on the benefits to that address instead. If you are a project developer and need help working with us on this, please reach out on our **discord**. # Pool Types # Definition of Pool Types In NFT AMMs Collection.xyz has three types of pools, **TOKEN**, **NFT** and **TRADE** pools. TOKEN/NFT are what we call limit-type pools. Once they trade one way, they do not trade the other way. For example, a TOKEN pool may have a bid for an NFT, but after it buys the NFT, it does not sell it again. This is unlike the two-sided TRADE pool, which will buy and sell within the pool’s liquidity range. You can think of them as price ladders, with the prices parameterized by pool’s bonding curve and liquidity. The difference between TOKEN and NFT pools are mainly the type of liquidity in the pool. If we think of TOKEN-NFT pair as TOKENs being the bid liquidity, and NFTs as ask liquidity, then TOKEN pools have bid liquidity and NFT pools have ask liquidity # Comparison of Different Pool Types | Type of pool | TRADE | TOKEN | NFT | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Unlimited number of trades? | Yes | No, limited by number of trades | No, limited by number of trades | | Fee structure | Carry fee structure (percentage of user-defined fee; user-fee is percentage of trade value) | Flat fee structure (percentage of trade value) | Flat fee structure (percentage of trade value) | | Asset Recipient \[as result of trade] | The liquidity pool itself | Either the liquidity pool itself, or a specified asset recipient (user can specify) | Either the liquidity pool itself, or a specified asset recipient (user can specify) | | Assets that can be deposited by owner |

Fungible monetary tokens: ETH or ERC20 (one is prespecified)
NFTs

| Fungible monetary tokens only: ETH or ERC20 (one is prespecified) | NFTs only | | How it behaves | Two-sided liquidity within a certain price band \[as determined by liquidity in the pool] | One-sided liquidity with bid liquidity for NFTs (buy orders for NFTs) | One-sided liquidity with ask liquidity for NFTs (sell orders for NFTs) | | Ownership representation | Owner = holder of LP token | Owner = holder of LP token | Owner = holder of LP token | | Compatible with advanced/filter pools? | Yes | Yes | Yes | | Use this if you… | Want to LP (i.e. make a market) on the NFT-TOKEN pair within a certain price range to capture trading revenue. Note that your profitability is highly correlated with (a) the price staying within/near the band (b) there being significant trading volatility in the pair | Want to set buy orders for an NFT with ETH/ERC20s (set and forget) | Want to set sell orders for an NFT you own (set and forget) | | Delta | Can use any valid delta configuration | Can use any valid delta configuration | Can use any valid delta configuration | # Bonding Curves Bonding curves are on-chain methods to generate price ladders, a series of levels, to place bids and asks. # Parameters of the bonding curves We maintain four parameters for the bonding curve.

Delta

Delta is a static variable until changed used to determine the speed of price increase\ \ Delta can be **functionally flat** as well, if you don’t want prices to change from trade to trade. * The number indicating **functionally flat** delta differs from each curve. For `Linear` curves, input a delta of `0`. For `Exponential` curves, input a delta of `1e18` (representing 100% i.e. no multiplicative change). You can also do that with `Sigmoid` curves by setting `P_min` = `P_max`. However, since these are all functionally equivalent, we recommend just sticking with the simple `Linear` representation if you wish to create a **functionally flat** pricing curve.

SpotPrice

SpotPrice is a stateful variable that is used to store a rough price level to help calculate bid/asks

Props

We foresee the need for an arbitrarily large set of static variable beyond just delta (e.g. for the sigmoid curve, we require explicit min/max levels)

State

We foresee the need for an arbitrarily large set of stateful variables. State is a bytes variable for an arbitrarily large set of stateful variables.

{% hint style="info" %} Do note that the difference between props and state is just a convention for the curves that we have, and is not enforced for custom curves - someone could easily make props the stateful variable and state the static variable. {% endhint %}

Variables	Intent of variable usage	DataType	Limited Data Storage?
Delta	Static - Changed by user only when you want to change the hyperparameters of pricing function	uint128	Limited
SpotPrice	Stateful - Changed by the pool automatically on each trade	uint128	Limited
Props	Static - Changed by user only when you want to change the hyperparameters of pricing function	bytes	Unlimited
State	Stateful - Changed by the pool automatically on each trade	bytes	Unlimited

# Type of bonding curves # Linear Curve A linear bonding curve has a straight-line or additive relationship between successive trades and price. As an NFT is bought(sold), the next price it quotes to sell NFTs at will increase(decrease) by a flat amount (known as **delta**). 1. As an item is bought from the pool, the price will increase by a fixed amount. The reverse happens when an item is sold into the pool. 2. For example, if the delta is `0.2`, and the initial price is `1.0`. After someone buys 1 NFT from the pool, the price will be `1.2`. If someone sells an NFT into the pool, the price will be `0.8`. # Exponential Curve A exponential curve performs a multiplicative operation where the delta acts as a multiplier function. If the pool has just sold an NFT by giving out an NFT and receiving tokens, the next price it will quote to sell NFTs at will increase by a percentage amount (known as **delta**). 1. The price of the NFT increased by a percentage each time an item is bought from the pool. The reverse happens when an item is sold into the pool. 2. `delta` is a percentage and assumes that the starting price is 100%. If input the `delta` as 20% it means we want the price to increase/decrease by 20% after each trade. For example, initial price is `1Ξ`, after someone buys 1 NFT from the pool, the next price will increase by the delta to `1.2Ξ`, conversely, if someone sells 1 NFT tot he pool, the next price will decrease by a multiple of the delta to `0.8333Ξ` 3. The delta is a percentage, and assumes that 100% (meaning no change to price after a buy/sell operation) is `1e18`. If we want the price to increase/decrease by 20% on each buy/sell, we should input `1.2e18` to represent `120% = (100% + 20%)`. The initial price is `1.0`. After someone buys 1 NFT from the pool, the price will be `1.2 = 1.0 * 120%`. If someone sells an NFT into the pool, the price will be `0.8333 = 1.0 / 120%`. # Sigmoid Curve Coming Soon on Collection.xyz A Sigmoid function is a S-shaped function `P(deltaN)` that returns a value between minimum price `P_min` and maximum price `P_max`, with the midpoint of the two being the centre of the curve. A traditional sigmoid curve looks like the above. A sigmoid curve is most useful when we want to ensure liquidity is concentrated between two price levels, with `delta` being the slope of the curve as the midpoint (how fast it approaches the price floor or ceiling, a low `delta` value approaches `P_min` and `P_max` slowly, a high delta value quickly converges to `P_min` and `P_max`). We’ve adapted the sigmoid function, which is given as `P(deltaN) = P_min + (P_max - P_min) / (1 + 2 ** (k * deltaN))`.While a traditional sigmoid uses e as the exponent base, this is equivalent to modifying the value of k so a value of 2 is used for convenience. `delta` here represents `k * 2**10 as a uint128` As this curve requires a degree of memory of statefulness of where we are in the curve (it is meaningless if we assign the slope at the centre at every buy or sell order, that would not lead to a S-shaped curve), we use the `state` parameter to record how far we are from the original centre.

# How are the parameters used in each of the bonding curves?

	Linear	Exponential	Sigmoid
Delta (uint128)	The additive amount that the next price will increase/decrease by No constraints	The multiplicative amount that the next price will increase or decrease by 1e18 represents 100%. If it increases by 20%, we need to put 1.2e18 as delta Constrained to be ≥ 1e18	Represents the speed which `P_min` and `P_max` are attained. Low = slow, high = fast `delta` must be `k * 2**10` as a uint128. The value of k is normalized because most useful curves have k between 0 and 8, with small changes to k (e.g. 1/128) producing significant changes to the curve
SpotPrice (uint128)	Ex-fees and royalties, Bid \| Ask ~= spotPrice \| spotPrice + delta	Ex-fees and royalties, Bid \| Ask ~= spotPrice \| (spotPrice * delta/ 1e18)	Not used
Props (bytes)	Not used	Not used	Represents an encoding of upper and lower bounds P_max and P_min `abi.encode(uint256(P_min), uint256(P_max - P_min))`
State (bytes)	Not used	Not used	Represents where we are from the curve initialization point to calculate the right gradient `abi.encode(int128(n - n0))`

# Customizable spread curves The Spread Inflator Curve is an innovative bonding curve implementation designed to give users full control over the bid-ask spread, allowing liquidity providers to capture more value from buy and sell transactions. This is particularly useful for NFT projects with deep liquidity provision, as it enables a more attractive return on investment. By default, the spread inflator is percent-based, and a round trip trade will yield a 2% return on the trade price. The Spread Inflator Curve allows for the capturing of a positive bid-ask spread by ensuring that the t0-ask minus the t-1 bid (without any fees) is always greater than zero. It enables the capturing of the bid-ask spread through either a percentage inflator or a flat amount inflator, giving pool creators more control over the bid-ask spread and its effect on liquidity provision. The flat amount inflator is likely to be more intuitive for most users. For example, with a flat amount of X, every buy-sell trade pair will increase the collateral by X. The Spread Inflator Curve is particularly useful for pools with low APRs and deep liquidity provision range. By utilizing the spread inflator, pool creators can achieve APRs that are multiples of the base value. ### Benefits of the Spread Inflator Curve 1. **Customizable bid-ask spread**: The spread inflator curve allows you to set an additional spread between the buying and selling price for each pool, enabling liquidity providers to control the compensation they get from the trade through the spread they get from each trade. 2. **Flexible spread settings**: You can customize the spread inflator using either a flat amount or a percentage, giving you full control over the spread 3. **Increased returns**: With the spread inflator curve, liquidity providers can potentially achieve higher returns, making it more appealing for NFT projects looking to incentivize their community to provide liquidity. 4. **Adaptable for various NFT projects**: The spread inflator curve can be customized to each NFT project, allowing project creators to maximize their returns and provide more value to their communities. ### How the Spread Inflator Curve works The Spread Inflator Curve uses two additional parameters, a boolean `bidAskInflatorIsFlatAmount` and a `uint248 inflator`. These parameters can be set during pool creation or edited later, giving you full control over the spread inflation. The `bidAskInflatorIsFlatAmount` parameter is a boolean that determines whether the inflator is flat amount or percent-based. The `inflator` parameter is a `uint248` that specifies the amount or percentage of the spread inflation. The spread captured is separate from the fees and will be contributed back to the pool's collateral. This allows the spread captured during the trade to be auto-compounded into the pool. This is opposed to fees which are accounted for separately and is not auto-compounded back into the pool. The linear and exponential spread inflator curves have been deployed at the following addresses: * LinearCurveWithSpreadInflator: [0x44e5c01baff15059254bf4b797fcfaed70d84942](https://etherscan.io/address/0x44e5c01baff15059254bf4b797fcfaed70d84942#code) * ExponentialCurveWithSpreadInflator: [0x82f518ef627a992a7b38678b1358cd94cec35bb0](https://etherscan.io/address/0x82f518ef627a992a7b38678b1358cd94cec35bb0#code) # Github Repos & Addresses ### Github Repository All source code is open-source on Github under the AGPL-3.0 license * Github Link: ### Ethereum Contract Deployment Addresses ``` { "contracts": { "CollectionPoolEnumerableETH": "0x176607d4ae51289221A76FB1df82125Bb44546Ba", "CollectionPoolMissingEnumerableETH": "0xc56d693F7A5F0019D37ac665ccF4211ddbe5d995", "CollectionPoolEnumerableERC20": "0xebCC009CE93aBE26936834d9d204571aB6Dd83cD", "CollectionPoolMissingEnumerableERC20": "0x00c2880Da9278f7A207F7775499b95f6f1F80922", "LinearCurve": "0xa675709085ebC5d4A2B5Ccb70Ce4b7bcD7B95B1c", "ExponentialCurve": "0x02b1C4670E522A4259Aa07f3BE9071F14715D6fe", "XykCurve": "0x7fB3758Ff7b4296580c40bE1A87405dC728D0702", "SigmoidCurve": "0x6458FEB0e837c6Fd49404a244AEEcc1F41355d98", "CollectionPoolFactory": "0x03b51826a4868780DB375eE27E5b0AdaaC5274EE", "CollectionRouter": "0x9d8A2424700Dfe6CD8c44917D899042F44ed2fc0" }, "deployer": "0x0E41F7bA26349b0c427d28177BfF678D914DB9a2", "safe": "0x8C4e0af3829De1E5cf9a29554efd6548028Fcd6E", "commit": "fd8b016391df8bdc0e488f4220b9abdd32805062" } ``` ### Goerli Contract Deployment Addresses ``` { "contracts": { "CollectionPoolEnumerableETH": "0x862Bd769D11503EC1413B6258bcC4EC404B3340a", "CollectionPoolMissingEnumerableETH": "0x86EeBB3fbfAD7250354D435DdEf806e4da6aC6D8", "CollectionPoolEnumerableERC20": "0xef9F304D35cc6CE379C4c0cDD71C2b0401C0d29F", "CollectionPoolMissingEnumerableERC20": "0xc14Ec5CC6429b1385A7F0430d50E54523bD66574", "LinearCurve": "0xed0b81E4bd20Ede0fb7901E9650101fD9A8fa92b", "ExponentialCurve": "0x1130D1DfeBEb1Ad7F196df62A5cff2146A380de2", "XykCurve": "0x6f9f01C0500aa6dE43D29D2487De53cD0Ef2390d", "SigmoidCurve": "0x213E6bC3bfd3F9da3F61a26441692A963F19fdc7", "CollectionPoolFactory": "0x6e3E4E843e1Ed2269b30f13E9057269253A279f8", "CollectionRouter": "0x4998A748F6E21a73Ba423E9fFA192b91b969c6E5" }, "deployer": "0x0cF19a07d0C2C1F16f1a6403A6A4f9c08394B66A", "safe": "0x0dB0c25CF55b0eF9FA8Ff56dA406F1f104bce7d5", "commit": "fdcb7767494cbb701849d6a4d57666907e5386cc" } ``` # Audit Reports ABDK At Collection.xyz, security is our top priority. We collaborate with top auditors in the space to ensure that the protocol is safe and reliable to use. As of April 2023, our smart contracts have been audited by [ABDK Consulting](https://www.abdk.consulting/), a smart contract auditor that counts Uniswap, Tornado Cash & Sudoswap as its clients. [
]() {% embed url="" %} # Technical User Flows ### Creating a Trading Pool To create a trading pool, you need to provide the following parameters: * `nft`: The NFT contract of the collection the pool trades. * `bondingCurve`: The bonding curve for the pool to price NFTs; it must be whitelisted. * `assetRecipient`: The address that receives the assets traders give during trades. If set to `address(0)`, assets will be sent to the pool address. Not available for TRADE pools. * `receiver`: The address that receives the LP token generated to represent ownership of the pool. * `poolType`: TOKEN, NFT, or TRADE. * `delta`: The delta value used by the bonding curve. The meaning of delta depends on the specific curve. * `fee`: The fee taken by the LP in each trade. Can only be non-zero if `_poolType` is TRADE. * `spotPrice`: The initial selling spot price. * `props`: A bytes variable for static variables, used by the bonding curve. * `state`: A bytes variable for stateful variables, used by the bonding curve. * `royaltyNumerator`: All trades result in `royaltyNumerator` \* `` / 1e6 being sent to the account to which the traded NFT's royalties are awardable. Must be 0 if `_nft` is not IERC2981 and no recipient fallback is set. * `royaltyRecipientFallback`: An address that receives all royalties if not `address(0)` and ERC2981 is not supported or ERC2981 recipient is not set. * `initialNFTIDs`: The list of IDs of NFTs to transfer from the sender to the pool. To define filter parameters, use the `NFTFilterParams` struct: * `merkleRoot`: The root of the Merkle tree of the allowed set of token IDs. Filters should accept at least one token ID. A pool that accepts no tokens is a dead pool. * `encodedTokenIDs`: The encoding of the token IDs, an efficient hexadecimal packing of the token IDs to minimize gas spent on emitting the event. * `initialProof`: The Merkle multiproof for initial NFT IDs. Together with `initialProofFlags`, it forms the Merkle proof for the initial set of NFT tokens put into the pool. Flags are used to indicate which proof is used for which token ID. * `initialProofFlags`: The Merkle multiproof flags for initial NFT IDs. Together with `initialProof`, it forms the Merkle proof for the initial set of NFT tokens put into the pool. Flags are used to indicate which proof is used for which token ID. * `externalFilter`: The address implementing `IExternalFilter` for external filtering. Note on `initialNFTIDs`: The initial NFT IDs of the NFTs you wish to put into the pool. You must be the owner of these NFT IDs. Note that initial NFT IDs must be sorted using the `filter_code` library. This ensures consistency with `initialProof` and `initialProofFlags`. If it's not sorted, a "not accepted" error will be thrown. The sorted list of IDs is the `leaves` field of any Merkle proof you generate. To generate filter parameters from the library: 1. Call `.root()` for the Merkle root. 2. Call `.encode()` for encoded Token IDs. ```javascript javascriptCopy code// tokenIDFilter is the main object of the library // Example: accept [1, 2, 3, 4, 5] // Pool starts with [1, 2, 3] let tokenIDFilter = new tokenIDs([1n, 2n, 3n, 4n, 5n]); // Merkle multiproof is order sensitive. Always pass proof.leaves to tokenId fields // Required by the smart contract if a Merkle proof is needed const unsortedIDs = [1n, 2n, 3n]; const initialNFTIDs = tokenIDFilter.sort([1n, 2n, 3n]); const root = tokenIDFilter.root(); const encodedTokenIDs = tokenIDFilter.encode(); const {proof: initialProof, proofFlags: initialProofFlags, leaves: initialNFTIDs } = tokenIDFilter.proofOf(initialNFTIDs); ```
# Technical Architecture

# Create Pool

# Swapping and Trading: User Buying NFT

# Swapping and Trading: User Selling NFT

# Bonding Curves and Pricing