Author: Shisi Jun, Shisi Jun

For UniSwap, which has a daily trading volume of $770 million and over 4 million users, entering the NFT market also signifies the beginning of a new round of offensive and defensive battles. Many platforms are concerned about whether their competitors will play a strong hand like SudoSwap right from the start.

However, the market data after three days of launch is quite disappointing. Despite a 5 million USDC airdrop and GAS discounts, it only captured a mere 2% of the trading share. For a time, mediocrity and ordinariness became synonymous with the Uniswap NFT market. Is it really just that? In fact, the current market and contracts launched are not the complete versions, and many functions are not yet open.

Follow Shisi Jun as this article delves into the operation of the NFT trading market and the principles of aggregators, combining Uniswap's latest protocols, Permit2 and Universal Router, to gain a deeper understanding of how the largest Dex platform is addressing the dilemmas of FT and NFT Swap!

1. Background

1.1 What is an aggregator?

Traditionally, an aggregator is primarily used for data aggregation. It collects data from various websites and presents the information categorized on a single platform to meet the needs of different users. A professional NFT aggregator needs to gather all NFT trading order information from different public chains and applications and integrate them into one platform. This provides users with a smooth trading experience and improves trading efficiency. Therefore, the focus of an aggregator is:

• Tool attributes: Providing functionalities that a single NFT market does not possess, with a greater emphasis on user experience.
• Trading experience: The following sections will outline various trading system architectures, where one can significantly feel the fragmentation of the trading process, making it impossible to complete a one-click transaction seamlessly.

So why is there a need for aggregation in NFT purchases? Let's first summarize the operational models of mainstream NFT markets.

1.2 Mainstream Trading Market Models

• The classification is based on three core aspects of the trading lifecycle: how to publish, how to bid, and where to match transactions. The different implementations of these three aspects lead to differences in traffic sources, operational costs, and market audience. A typical example is: on-chain orders:
• Vertical built-in markets: 【Contract Interpretation】CryptoPunk - The World's First Decentralized NFT Trading Market
• AMM matching markets: A Clear Explanation of the AMM Mechanism of NFT Market Newcomer SudoSwap - Innovations, Challenges, and Limitations
• Off-chain orders:
• Third-party markets: After Grabbing 100,000 NFT Orders from X2Y2, How Many Users Actually Did Not Collect Royalties?

The advantages of on-chain orders are: security, information transparency, and decentralization. However, the downsides are high costs and lack of traffic. The advantages of off-chain orders are: low costs and easy traffic aggregation, but the downsides are: centralization, trust costs, and cancellation costs. The above describes the model of a single NFT trading platform, while an aggregator is a system that calls the aforementioned single platforms and completes transactions. Currently, Uniswap has integrated the top 10 trading platforms: OpenSea, X2Y2, LooksRare, Sudoswap, Larva Labs, Foundation, NFT20, and NFTX.

Currently, the off-chain order third-party market model is mainstream (over 90%), with the greatest competitiveness lying in traffic and user habits, which are closely related to contract system design and user cognitive habits.

From the seller's perspective, they will naturally list where there are buyers, making it easier to complete transactions. Buyers will also look for platforms with more seller orders to transact quickly. However, although there are giants like OS, it is not the end of competition. OS occupies 80% of the trading volume but has long hoped to follow a web2 IPO route, which is why it has not issued tokens or shared profits with users, leading to a gradual market erosion by X2Y2 and other aggregators this year. Other platforms are also troubled by their smaller traffic and the fact that most new users prefer large platforms, resulting in mediocre growth.

1.3 How Aggregators Work

Aggregators are inherently tools that call the trading systems of other platforms rather than building their own trading protocols. Among the nine platforms integrated by Uniswap, platforms like OS and X2Y2 are open order pool systems. The purpose of this openness is to provide a programmatic implementation of order trading systems, which is mostly used by bots. For platforms, being able to execute transactions quickly is a hallmark of a good platform, and the open order pool is a mutually beneficial initiative for ecological co-construction. The on-chain order system analyzes mainstream on-chain protocols like Sudoswap and NFTX. How does aggregation replace third-party markets to complete transactions? Let's look at an example:

• An order can be initiated by either the seller or the buyer, or even the platform (including the aggregator).
• First, the seller authorizes the NFT contract (Operation 0), allowing for deductions. At this point, X2Y2: Exchange can directly transfer the seller's assets from the NFT contract at any time, which is why third-party platforms are overly centralized.
• The transaction intent is confirmed using on-chain verification, as seen in X2Y2: Exchange or OS: Seaport protocols.
• The order originates from the third-party market's web2 system, and the aggregator receives the user's signature and selling conditions (e.g., one monkey, 50 ETH to complete the transaction).

The execution process is:

1. Build the buy and sell order parameters (including signatures and amounts) on the aggregator platform.
2. The user sends the transaction to the aggregator's on-chain contract.
3. The aggregator contract replaces part 1 in the diagram below, sending it to the third-party market's on-chain contract.
4. Because it has gone through the aggregator contract, multiple purchases can be completed in one transaction.

1.4 Why Can Aggregators Save Gas?

From the above process, the aggregator essentially calls third-party contracts, but this does not mean that the transaction's lower limit is determined by the third-party system. The cost composition of an on-chain transaction consists of three aspects:

1. The consumption of a single transaction itself: 21,000 Gas.
2. The consumption of accompanying parameter costs: each non-zero byte requires 68 Gas.
3. The consumption during contract execution: calculated based on the modification of storage slots and EVM workload to determine Gas costs.

Therefore, the savings come from the process of consolidating N transactions into one, saving the costs of N-1 transactions. Further reading: 【Source Code Interpretation】What Exactly Is the NFT You Bought?. Based on the diagram below, the efficiency calculation shows that the more aggregated transactions, the more cost-effective it becomes: if the platform requires 200,000 Gas for a single NFT transaction, then completing 10 transactions as one can save 9*21,000 Gas, accounting for approximately 9.45% of each of their 10 transactions. Aggregation itself also incurs some costs: for example, Gem requires 280,000 for a single transaction, and 500,000 for two transactions, roughly averaging 60,000 of aggregation loss per NFT. Therefore, it only becomes cost-effective when completing three or more transactions.

The above shows the transaction type and Gas table (randomly selected, not statistical results).

1.5 What Is the Value of Aggregators?

The bulk trading function has catered to the demands of project parties for speculation, investors for quick purchases, and retail users for easy-to-use tools, thus generating good traffic and order completion. In fact, half of X2Y2's orders come from aggregators. Compared to traditional trading markets, NFT aggregators have some obvious advantages, including:

• Highly aggregated information: such as trading volume, floor price, trading prices, quantities, top holders, top buyers, etc.
• Highly aggregated operations: users can view, trade, and purchase NFTs across all markets through a single platform.
• Improved trading efficiency: information and operations are aggregated, making it easier to make pricing decisions.
• Diverse payment methods: ideally (if supported by the third-party market protocol), users can pay with any token on the NFT aggregation platform.

Overall, it benefits various users, including project parties for bulk buying and selling, large holders for bulk purchases, and retail users for data observation. Thus, aggregators are increasingly moving along the path of tool attributes, and competition is becoming more intense. This tests how to reduce that 60,000 loss in contract implementation and how to better present data on tool-based platforms. However, the author believes that the main value and goal of Uniswap's NFT market is not merely to create a useful tool but to achieve a unified on-chain interaction protocol, specifically targeting how to facilitate a smoother trading process in less than ideal payment scenarios.

2. UniSwap's NFT Exchange Protocol

Don't rush to counter with the current sluggish trading volume; the author is not endorsing the project or writing a promotional piece. Instead, from its source code implementation, more functional points are reserved, rather than just the currently open features. For UniSwap, which has a daily trading volume exceeding $770 million and over 4 million users, there is no lack of contract development capability or funding. The more pressing question is: what kind of NFT trading protocol do users actually need? This time, UniSwap is not merely launching an aggregator platform and scheduling protocol but has released two complementary protocols: Permit2 and Universal Router.

2.1 Permit2 - An Efficient and Secure Next-Generation Authorization Protocol

2.1.1 Limitations of Traditional Authorization Mechanisms

Do you remember the architecture diagram of X2Y2 mentioned earlier? New users wishing to complete an NFT transaction, for such a simple request, first need to swap WETH and authorize deductions for WETH and the corresponding NFT contract. This incurs at least one to two transaction costs, along with the risk of infinite deductions and theft. Previously, OS faced issues where orders would not automatically expire, such as problems with on-chain settings, leading to losses when users transferred high-value NFTs from cold wallets at low prices.

2.1.2 Deduction Authorization - A Common Issue with ERC20

Although EIP-2612: "Obtaining EIP-20 Approval via EIP-712 secp256k1 Signatures" has already reached its final stage, from a protocol perspective, ERC20 still holds a second-class token status because users cannot interact with Ethereum without holding any ETH. The diagram above illustrates how to use EIP-2612 to achieve authorization-free deductions.

1. Alice signs an off-chain "permit" message msg and sig, indicating her authorization (based on EIP-2612) for the token.
2. The msg and sig submitted by Alice are part of her protocol contract interaction.
3. The contract calls permit(), and the Token contract based on 2612 verifies the permit message and signature, granting permission.
4. At this point, the contract obtains authorization based on EIP-2612 tokens and can deduct Alice's tokens.

This is an improvement to the ERC20 standard, addressing these drawbacks (extra approval expenditure and infinite deduction risks), but it can only be applied to new token contracts that integrate EIP-2612.

2.1.3 Authorization Optimization Mechanism of UniSwap's Permit2

1. To solve the backward compatibility issue caused by the necessity of integrating EIP-2612 into the token contract layer (i.e., old tokens cannot be used), Permit2 is designed to be compatible with any token, essentially serving as a unified authorization management contract.
2. The upper half: Alice calls approve() to grant unlimited authorization to the Permit2 contract based on the ERC20 contract.
3. The lower half: Alice signs an off-chain "Permit2-type" message msg and sig, indicating her signed authorization.
4. Alice calls the interaction function on the protocol contract, including msg and sig.
5. The protocol contract calls the Permit2 contract, which, after verifying msg and sig, controls the ERC20 transfer from her authorization.

Overall, while requiring users to authorize permission first may seem like a step backward, users are not directly granting it to a specific protocol but to the standardized Permit2 contract (which can be the only one on that public chain). Users only need to authorize once, allowing them to skip subsequent authorization operations for all protocols they interact with, replacing them with off-chain signatures.

This means users no longer need to initiate separate transactions for interactions with various protocols. It can also enable more scenario-specific capabilities, such as automatic validity periods for signed authorizations, eliminating concerns about long-term authorization risks, and batch approvals (multiple deduction signatures can be executed in one transaction, and batch cancellation of deduction authorizations can also be executed in one transaction). Automatic validity periods are similar to: 【Source Code Interpretation】How Does Ethereum's New Standard EIP-4907 Achieve NFT Leasing?. Once established, or based on the popularity of Uniswap itself, a completely decentralized protocol controlled solely by user signatures will become a necessity for everyone (who would refuse something that is both safe and cheap?). So, what does this have to do with the launch of the NFT trading market contract?

It does, as the current Permit2 has already been integrated into the Universal Router released simultaneously by Uniswap, which is the underlying protocol for the NFT market. The code is integrated, but the functionality has not yet been opened (as the NFT version of Permit2 has not yet been released), and currently, it is only in a small-scale test of the ERC20 version of Permit2.

2.2 Universal Router - A Unified FT and NFT Swap Protocol

The positioning of this protocol is: Uniswap's next-generation router, which unifies FT and NFT swap transactions into a highly flexible, gas-optimized, secure, and scalable exchange router. This also means that the swap functions used by the subsequent 4 million users will be executed by this protocol. Its application scenario is aggregators, but it is not limited to aggregators; its target is a multi-asset swap protocol that can execute swaps (e.g., Uniswap pools, NFT markets).

2.2.1 What Is the Value of the Universal Protocol?

The value stems from the complexity of the current process for executing NFT purchases.

• There is little protocol-level support for purchasing NFTs with arbitrary ERC20 tokens (except for the naturally supported Seaport protocol by OpenSea). Therefore, if one wants to directly purchase NFTs with any ERC20 (like USDC), it requires at least two transactions: from USDC → ETH, and from ETH → NFT.
• Both NFT purchases and sales require an authorization, and cross-platform transactions require multiple authorizations, leading to high costs for protocol compatibility and upgrades. It can naturally integrate Uniswap V2 and V3, first executing multiple token swaps (as shown in the diagram below) and then purchasing NFTs from multiple markets in one transaction.

In fact, OS's masterpiece, the Seaport protocol, also achieves swaps between any asset combinations (similarly, its web3 site has not yet opened all preset protocol functions). Full on-chain protocol support will allow more applications to naturally integrate direct swaps between on-chain FT and FT, FT and NFT combinations. Higher trading efficiency will also open up more application scenarios (refer to the World of Warcraft trading system; the most basic point-to-point single product trading will eventually be replaced by bulk and mixed trading).

The ultimate value of multi-token payments lies in allowing users not to always hold ETH for transaction fees. This further reduces the transaction chain. Of course, to fully realize this, it may still rely on the future implementation of the ERC-4337 account system blueprint. Further reading: Ethereum Account Abstraction: A Comprehensive Report on 10 Related EIP Proposals and the Seven-Year Journey to Break the Million Daily Active User Bottleneck. However, currently, you cannot see the actual operation of such multi-token payments in on-chain transactions, as it has not been fully released (the NFT version of Permit2 is still needed), and it is still in an optimization phase awaiting vulnerability plan modifications.

2.2.2 How Much Resource Does Approve Occupy?

Based on on-chain data statistics, as of block height 1597W, Ethereum has accumulated a total of 1.757 billion transactions. The total number of transactions executing the ERC20 approve function is 47.7 million, with an average gas consumption of 84,699 per transaction and a historical average gas price of 73 Gwei. Finally, when converted to ETH, the cumulative consumption is 295,345 ETH, amounting to approximately $380 million at current prices.

Conclusion

Although this article may seem soft, even while analyzing the significant on-chain data (insufficient trading volume), the author fundamentally favors such non-upgradable, ownerless protocols, with completely open code and SDK, allowing any application and protocol to integrate. Similarly, although OS's Seaport protocol requires a massive centralized off-chain system to operate, such a highly optimized, fully functional multi-order system, being completely open-source, provides a giant's shoulder for countless DApps (like GameFi) that need to build internal trading platforms, enabling the gradual establishment of value in the web3 world on decentralized protocols.

• Currently, its protocol does have limitations

At present, if one wants to implement NFT interaction functions through the integration of this protocol, the core issue still relies too heavily on centralized order pools. Currently, order information is queried through the Uniswap official website itself for OS, X2Y2, etc. Apart from completely on-chain supported contracts like SudoSwap (which initially had an impressive concept but has seen poor operation due to its token distribution being too skewed towards the development team, leading to a gradual decline in interest).

The gas optimization effect of transaction aggregation still heavily depends on the number of NFTs completed in transactions. This means that the tool-based (targeting project parties and investors) attribute positioning remains unchanged. Although Uniswap's protocol aims to build public infrastructure to promote the advancement of cryptocurrencies, the current product's functionality still starts from the aggregator point, lacking more tool integrations that meet the needs of aggregator users.

Naturally, it was initially overlooked, even with a 5 million USDC airdrop. Uniswap Labs has owned Genie for half a year now, and today's launch of the Uniswap NFT market is almost identical to Genie from six months ago.

Now, with the emergence of NFT markets like X2Y2 and Blur that understand user needs, users no longer have to endure poor product experiences, and the era of using subpar products is over. Uniswap NFT product lead Scott has stated on Twitter that Uniswap will achieve NFT trading by inheriting Sudoswap. It is hoped that the foundational infrastructure released in the future will not be such a bulky protocol but a lean application.