A place for storing nuanced details on the individual NFT models

---

NFT SALES

Sudoswap

• Sudoswap is a dex for NFTs - you can supply to the nft/token pool and earn a trade fee, or buy and sell nft to/from the pool
• Sudoswap v2 supports both erc1155 and erc721 while v1 only supports 721
• Both follows a similar structure - there's a pools model for all pools created and a sales model that records all sales
• There are 'swap contracts' which facilitates certain types of swaps, e.g. erc20 to erc721 , eth to erc1155. There are bonding curve which determines the price of the nft after a swap. Bonding curves are not used in the sales calculation.
• Each section should be divided based on their nft types. So to debug, simply insert tx_hash in the base CTE and check the corresponding nft type sections

Element

• A multichain nft marketplace
• There are 2 known implementation contracts (IC) for Element in which we'll call the older contract 'old' in the model. In the old IC, the fees (platform and royalties) are not emitted in events while the new IC includes the fees information.
• Because of this, we need to account for fees for old IC separately - using token transfers and native transfers to deduce platform and royalty fees.

---

NFT MEV

Mev Arbitrage

• Arbitrage in this table is defined by the buying and selling of the same nft (address + tokenid) within the same transaction. This can happen between marketplaces (opensea, looksrare, etc) and pools(sudoswap, nftx). There are arbitrages within the same block, but those are much less than within the same tx and also a lot more complicated
• The base of the arbitrage is a self join of the nft sales table where the buyer of an nft, is also the seller of the same nft in the same transaction.
• The other logic besides this base logic are methods to capture the various known mev strategies.
• E.g. For joining on Dex swaps : If the arb is a "direct arb" between marketplaces, the end result is straight forward but because there are pools involved, there is usually an extra step to get the value of the pool token - which is where joining on dexes come into play. This can happen in 2 ways; it can happen at the end of the transaction where the arb-er sells the nft back to the pool and receives a token, which is then swapped to WETH. It can also happen at the start of the tx, where the arb-er swaps WETH for an erc20 token to redeem an nft from the pool.
• There is also a join on dex swaps to get the value of APE tokens that are redeemed and swapped in the transaction.
• Because of all these strategies, it is not feasible to have the amount + currency for each buy and sell side of the transaction. We would have to include columns that represent the extra swaps taken into account - which is why the final table for the mev arbitrage only includes values in USD where we sum everything under the hood.
• A few things that needed manual clean up:

1. Cryptopunks emitted a 0 amount sale. The 0 amount sale is expected when a sale doesn't directly take place in the larvalabs marketplace. Other marketplaces use this "feature" to transfer the cryptopunk between addresses. Because of this, we have to filter these out.
2. Flash loan completeness - this table relies on the flash loan curated table to identify if the source of this arb transaction is from a flash loan but there are some lending markets that are not covered yet, notably dydx so that was added in manually.