Already, it has traded 23k ETH and 157k NFTs in volume, earning 620 ETH in fees for liquidity providers and 115 ETH in platform fees, with 25.5k unique wallets trading. The governance token for the SudoAMM protocol $SUDO was also announced recently.

The SudoAMM model makes low-slippage swaps between NFTs and tokens available for traders. Liquidity providers can deploy a pool that will programmatically buy or sell an NFT at a given price (similar to limit orders), ultimately giving more power over the price ranges they fund.

In contrast to OpenSea, users can choose to sell NFTs into a pool at a specified price rather than waiting for a bid. With this, users may instantaneously sell their NFTs into a pool.

The protocol charges a 0.5% fee. Trading fees, which account for most of the fees generated, are sent to pool owners, providing liquidity for trading pairs. Overall, SudoAMM’s low fees come from exempting royalties on their trades, a controversial decision that has recently sparked debates — more on this later.

The most updated trading volume numbers and the details of the token allocation are linked in the resources section at the bottom of this post.

If you want to receive reviews of the latest protocols directly in your inbox, subscribe using the button below. By subscribing, you’ll enter a chance to win an edition of this post as a collectible!

subscribe://

How does SudoAMM work?

The goal is to ensure that anyone can add liquidity to an NFT collection and earn trading fees. To do this, instead of an order book-based paradigm, SudoaMM uses liquidity pools - specifically, distinct liquidity pools. While separate pools increase gas expenses, the protocol has kept them low by writing gas-efficient code and innovating on the clones/proxy paradigm. New pools cost 180k gas.

Those that supply NFTs and tokens (liquidity providers) can earn trading fees on their NFTs, which was never possible before. The creator of liquidity pools can set the price at which NFTs may be purchased or sold for ETH (or other tokens). Trading within the pool is possible as long as sufficient NFTs and ETH are in the pool. SudoAMM’s liquidity pool architecture provides dynamic provisioning using customizable bonding curves: Linear and Exponential Curves.

Each time someone trades within a pool with a linear curve, the pool's pricing will be shifted by a fixed amount of ETH (delta); and each time someone trades within a pool with an exponential curve, the pool's pricing will be multiplied by a percentage amount (delta).

Creator Royalties

Before diving into the technical analysis, we need to address the elephant in the room: SudoAMM does not implement creator royalties. This decision has been discussed at length from all different perspectives; we’ve linked resources at the bottom of this review if you’re interested in reading more about it.

Rather than joining that debate in this section, we want to explain why fees have been optional in the current marketplace landscape; and why it hasn’t been technically feasible to enforce royalty fees with the current standards.

Marketplaces and Tokens

From a technical perspective, two main components make a marketplace — the marketplace contract and the assets traded in the said marketplace.

When an asset is traded, the token transfer is facilitated through the marketplace contract — this is why you usually need to send an approval transaction before you list an NFT; the approval transaction lets the marketplace transfer the NFT from your wallet when a trade is executed. Hence, all the funds and tokens exchanged are routed through the marketplace contract; the NFT does not control where funds go.

The NFT can only specify the amount and account to which royalties should be paid. The standard for specifying royalties is EIP-2981 — but again, the standard only defines a convention, which means some contracts specify them differently, increasing complexity in the marketplace contracts as they try to figure out where to route royalties.

When a sale is completed, conventionally, the marketplace contract routes part of the sale to the royalty recipient specified on the NFT contract. Still, the marketplace can skip that step and send the full purchase amount to the seller — even if the NFT specified royalty information. This is why they cannot be enforced at the protocol level. This is what Sudoswap did; they skipped the royalties step and let the sellers keep the full sale amount.

If you’ve enjoyed this post so far, consider collecting it using the button below!

collect://

Technical Analysis

The protocol is broken down into separate components that define pairs, deploy new pairs and interact with them. In this section, we will go through the key contracts that comprise the protocol. We will break them down into four separate categories:

• Bonding curves — contracts that hold logic to calculate prices

• Pairs — the contract that holds the tokens (also known as pools)

• Factory — a contract used to deploy new token pairs

• Router — a peripheral contract used to interact with token pairs

Bonding Curves

What is it?

A bonding curve is a mathematical curve that defines the relationship between a given asset's price (NFT) and supply. Bonding curves are represented as smart contracts. Currently, the protocol supports two types of curves Linear and Exponential.

How does it accomplish this?

The protocol implements the two bonding curves as contracts that more or less work as libraries. They take inputs from the pairs and return the new prices and other relevant information. The pairs then update their state to reflect new prices.

Each bonding curve implements the ICurve interface, which has four functions: validateDelta, validateSpotPrice, getBuyInfo, and getSellInfo.

For linear curves, function validateDelta and validateSpotPrice accept any delta value. However, in exponential curves, the delta must be greater than 1 for validateDelta, and the new spot price has to be larger than or equal to the minimum price of 1 gwei in validateSpotPrice. Both functions are called when initializing a new pool and the protocol; that way, the protocol can assume the values are correct and use them without verifying them.

Function getBuyInfo first verifies whether or not the user is buying one or more NFTs. Then, for linear curves, getBuyInfo performs an additive calculation that updates the price for each item bought with an additive operation. In exponential curves, getBuyInfo it performs a multiplicative operation to adjust the price for each item bought. With this, both curves update a new buy spot price upwards to avoid arbitraging LPs. The total cost of the items is then added to find the inputValue and the necessary protocol fees are applied.

Like getBuyInfo functions, getSellInfo functions also perform a check for one or more NFTs. Linear curves first compare the spot price to the total price decrease of all NFTs sold in the swap. If the spotPrice < totalPriceDecrease, the new spot price is set to 0 to calculate the number of items that sell into the linear curve (until it reaches 0, the result is rounded up) and to avoid selling for a negative value. Otherwise, the new spot price would be the difference between the spot price and the total price change (delta * the number of items).

For exponential curves, getSellInfo first computes the inverse value of delta (1/delta). Then, it multiplies the spot price by the inverse delta (or divide by delta) to find the new spot price for each item sold, which is then put into a uint128 if the resulting value is less than 1 gwei. The total revenue of the items is then added up to find the outputValue and the necessary protocol fees are applied.

By summing up the protocolFee, starting inputValue or outputValue, and trade fee (for trade pools only), functions getBuyInfo and getSellInfo return the final inputValue or outputValue, newSpotPrice, newDelta, and protocolFee.

Pairs

What is it?

The protocol’s base contract is LSSVMPair.sol, which can hold NFTs, tokens, or both and holds the core swap logic from NFTs to tokens. Each pool is a unique LSSVMPair contract owned by the account that created the pool and has unique settings such as the bonding curve type, pool type, delta, etc. After pool initialization, these pairings' assets and price quotations are tracked.

How does it accomplish this?

Pairs are either LSSVMPairEnumerable or LSSVMPairMissingEnumerable depending if the NFT/Token pair supports the enumerable ERC721 extension. SudoAMM implements an ID set through LSSVMPairMissingEnumerable to allow easy access to NFT IDs in the pool if enumerable is not supported. Depending on the owner’s preferred token type, NFTs could be paired with either an ETH or ERC20.

Based on what the pair contains, an LSSVM pair can either be one of three types:

1. TOKEN - contains deposited tokens that will be swapped out for users’ NFTs. The pairs provide pricing for how much they will pay for any NFT in the collection.

2. NFT - contains NFTs that will be swapped out for users’ tokens. These pairs produce a quote for how much it will sell for any NFT in its catalog.

3. TRADE - contains NFTs and Tokens. Here, you can buy NFTs with tokens and sell NFTs for tokens (functionality of both TOKEN and NFT pair). The spread between buying and selling would be given to the pair owner as fees.

The initialize function is invoked during pair deployment by the factory contract (more in the next section) to set the initial custom parameters of the new pool. The type of NFT collection, bonding curve, and pool type cannot be changed after the pool is deployed. With the Ownable library, pairs are only initialized once and are verified by ensuring the current owner is address(0). A set pool fee of less than 90% is permitted solely for TRADE pools (< 90% because the maximum protocol fee is 10%), while TOKEN and NFT pools have their pool fees set to 0.

Pairs compute the number of tokens or NFTs to send or receive by calling the assigned bonding curve contract (linear or exponential). Remember, the bonding curves are view-only contracts pairs utilize to establish the next trade’s pricing. Knowing this, the pair’s role is to continuously update the state of the pool’s bonding curve and carry out all input/output validations such as verifying the pool type and ensuring users are swapping more than 0 NFTs, and execute output checks that call the bonding curves for pricing information within its swap functions.

After pair deployment, the owner may adjust certain variables to alter the pair’s pricing and liquidity. The spot price, delta, and trade fee can be modified for TRADE pairs. For ETH pairs, the owner can withdraw their NFTs, ETH, or ERC20.

Factory

What is it?

The factory is a contract that deploys new pools and holds protocol-level configuration. The factory contract name is LSSVMPairFactory. Protocol pairs are deployed as clones; clones are smart contracts that hold storage but delegate logic to a separate smart contract.

How does it accomplish this?

Deploying Pairs:

The factory contract deploys pair clones through two functions,createPairETH and createPairERC20, each for the type of pair.

Each function validates the bonding curve type; validation is the same for both pairs. Since bonding curves are smart contracts, each type has a unique address. The factory stores a map of addresses to boolean values to represent if the bonding curve is allowed.

After validation, a new pair clone is deployed. The factory uses a custom version of the minimal proxy pattern. The standardized version of minimal proxies (EIP-1167) does not support immutable variables. Immutable variables and constants are held in the contract's code and not in storage — hence they’re much cheaper to store and access. The modified version allows proxies/clones to hold immutable variables by appending a few initialization parameters to the code; this optimization was pioneered by wighawag and called it clone-with-immutable-args; they explained:

The immutable arguments are stored in the code region of the created proxy contract, and whenever the proxy is called, it reads the arguments into memory, and then appends them to the calldata of the delegate call to the implementation contract. The implementation contract can thus read the arguments straight from calldata.

By doing so, the gas cost of creating parametrizable clones is reduced, since there's no need to store the parameters in storage, which you need to do with EIP-1167. The cost of using such clones is also reduced, since storage loads are replaced with calldata reading, which is far cheaper.

The parameters stored in the code section are:

• ILSSVMPairFactoryLike factory

• ICurve bondingCurve

• IERC721 nft

• uint8 poolType

• ERC20 token — only for ERC20 pairs

In addition to more gas-efficient reads, the novel clone pattern saves five store operations for ERC20 pairs and four for ETH pairs.

After the pair is deployed, an initialization call is required to store and validate the initial parameters in the pair. The factory initializes the clones by calling initialize and passing in the msg.sender as the first parameter to be set as the pair's owner, as well as the asset-recipient, delta, fee, and spot price.

After the new pair is deployed and initialized, assets are transferred to the pair contract. For ERC-20 pairs, there are two additional parameters for transferring assets: ERC20 token and uint256 initialTokenBalance. These parameters specify the token and the amount that must be transferred to the pair contract at creation. For ETH pairs, a token doesn’t need to be specified since ETH is the base currency, and the amount used to initialize the pool is the value sent with the transaction, accessed through msg.value. Afterward, the NFTs specified for the pool are transferred from the owner to the pool. All assets are transferred using solmate’s SafeTransferLib.sol.

After the assets are transferred, a NewPair event is emitted to signify a new pair has been deployed.

Protocol Configuration and Ownership:

The factory contract has an owner; the current owner is set to the 0xmons gnosis safe multisig with a 3/5 threshold. The owner has the following capabilities:

• Updating protocol fees with a maximum of 10%

• Updating the protocol fee recipient (currently set to the 0xmons multisig)

• Withdrawing ETH and ERC20 fees from the factory; fees are sent to the protocol fee recipient

• Add or remove bonding curves

• Add or remove allowed routers

• Set allowed contracts that a pair can call arbitrarily

The owner functionality is implemented using OpenZeppelin’s Ownable.sol; one critique of this pattern is that only one transaction is necessary to transfer ownership. A preferred pattern by some requires two — one to initialize the ownership transfer and the second to accept the ownership. With the said pattern, you always ensure that the new owner can submit transactions and it doesn’t lose ownership by accident; this was discussed at length on this Twitter thread.

Router

What is it?

The Router contract consolidates token approvals into a single contract and facilitates swaps. The router contract name is LSSVMRouter.

Swaps work similarly to other DEXs; an input and output amount is specified, as well as a swap route and a deadline. The router addresses two types of swaps, Normal and Robust. A normal swap checks slippage (difference between desired input and output amounts) at the end of trade and reverts if exceeded. A robust swap checks slippage between each swap route and skips the swap if the slippage is exceeded.

The practical difference between both swap types is that sometimes robust swaps will be partially executed where normal swaps fully revert; completing part of the swap order provides a better user experience when trading in volatile pricing environments. More details on robust swaps are below.

How does it accomplish this?

Token to NFT Swaps:

Swapping ETH or ERC20 tokens for NFTs occurs within four functions:

• swapETHForAnyNFTs

• swapETHForSpecificNFTs

• swapERC20ForAnyNFTs

• swapERC20ForSpecificNFTs

Functions with the keyword “specific” permit users to specify which NFT IDs they want from each pair. Functions that contain the keyword “any” transfer an NFT ID determined by the pool.

Each of these functions checks if the swap meets the deadline set by the user through the checkDeadline modifier. If the swap is proposed at/after the assigned deadline, the swap will revert. If the swap is proposed before the deadline, these functions delegate swapping to their internal functions.

Internal functions _swapETHForAnyNFTs and _swapETHForSpecificNFTs query the pair's bonding curve and swap among the pairs specified. When querying, the pairs cannot directly “pull” ETH; so for ETH to NFT swaps, the router needs to calculate the price per swap with the function getBuyNFTQuote from LSSVMPair.sol to total the exact ETH amount it will send to the pool. This ultimately saves gas by eliminating the need to return any excess ETH.

Similarly, _swapERC20ForAnyNFTs and _swapERC20ForSpecificNFTs perform the same checks but don’t need to query the pair’s bonding curve with getBuyNFTQuotebecause when the Pair requires token transfers, it invokes the Router contract (it doesn’t transfer directly from the user’s wallet). The router contract checks if the caller is a Pair clone through the LSSVMPairCloner with the isPair function. If the pair is a clone, the router transfers tokens from the user’s wallet to the pair.

NFT to NFT Swaps:

NFT to NFT swaps occur within four functions:

• swapNFTsForAnyNFTsThroughETH

• swapNFTsForSpecificNFTsThroughETH

• swapNFTsForAnyNFTsThroughERC20

• swapNFTsForSpecificNFTsThroughERC20

Like Token to NFTs Swaps, NFT to NFT swaps also perform deadline checks. However, instead of calling one internal function, it calls two. The first internal function swaps an NFT to a token. Doing so ensures that it does an aggregate slippage check by setting the minOutput, which represents the minimum acceptable total excess ETH received, of the swap to 0 and returns the tokens to the LSSVMRouter. Afterward, a second internal function is called to swap tokens to NFTs and ultimately returns the total amount of ERC20 or ETH tokens received.

Robust Swaps:

For circumstances in which the price of your transaction might fluctuate rapidly between submission and execution, the LSSVMRouter resorts to robust swaps. The functions for robust swaps are:

• robustSwapETHForAnyNFTs

• robustSwapETHForSpecificNFTs

• robustSwapERC20ForAnyNFTs

• robustSwapERC20ForSpecificNFTs

A maximum per-swap cost is established to prevent an intermediate swap from executing if the specified price range is exceeded. Thus, users may request several swaps and have as many of them carried out as feasible. These robust functions are much like normal swaps, but with an added component of looping through swaps to ensure it meets the set maxCost standard with no errors before attempting.

The robustSwapNFTsForToken operation is alike the preceding robust swaps, except that it places value on the per-swap minimum output rather than the per-swap maximum cost. After checking for errors and verifying if it is at least equal to our minOutput, it proceeds to call the swapNFTsForToken function to perform the NFTs for Token swap.

Similar to NFT to NFT swaps, functions robustSwapETHForSpecificNFTsAndNFTsToToken and robustSwapERC20ForSpecificNFTsAndNFTsToToken also, perform two (robust) swaps in one transaction. The first swap involves buying specific NFTs with ETH or ERC20 tokens, and the second swap sells the NFTs for tokens in one transaction. All parameters are stored in a struct called RobustPairNFTsFoTokenAndTokenforNFTsTrade to prevent the “stack too deep” error.

Conclusion

Sudoswap is a novel and ground-breaking protocol for the NFT ecosystem. NFT traders now have access to instant liquidity, which previously seemed difficult with NFTs. Bringing DeFi and NFT communities together improves the overall NFT market’s efficiency and liquidity, which onboards more users into the space.

Sources

• SudoAMM Source Code on Github

• Sudoswap Docs

• Sudoswap’s SUDO Distribution

• Web3 Data Guide: Sudoswap

• Ilemi’s Dune Dashboard

• Resources on royalties:

  • Secondary Royalties in NFT: Inefficient, anti-market & ethically suspect

  • 👑 Cracking The Code of The NFT Flywheel, Pt. 2: The Royalty

  • punk6529’s threads: first and second

  • Letter 30: Creator Royalties in NFTs

  • On Royalties

Protocol Review is excited to continue publishing accessible reviews for decentralized protocols. We believe in using our deep technical knowledge to distill protocols and increase their mainstream understanding.

To stay up to date with the latest reviews, subscribe to our Mirror publication and follow us on Twitter. If you have suggestions for protocols you’d like to see reviewed or are interested in writing for the PR, fill out this form.

Special thanks to Will Phan for the collaboration on this review.

There is an immediate need for scaling solutions for Ethereum that don’t compromise on its security guarantees. Optimism is one such solution. It makes transacting with Ethereum assets more affordable by constructing a separate “layer 2” blockchain where transactions are cheaper, with exit guarantees back to Ethereum’s Layer 1. To get onto this L2 though, existing Ethereum users need to bridge their assets to Optimism.

The Basics of Bridging

Optimism's execution environment is general purpose and practically the same as Ethereum; Optimism runs only a slight modification of the Ethereum Virtual Machine. This means that the same contract can be deployed to both networks, and we can expect them to work the same way.

Optimism contracts can communicate with Ethereum smart contracts (and vice versa), via a cross-domain messaging protocol. We can use this protocol to build a “bridging contract” that facilitates asset transfers across the two networks – sending balance updates upon each deposit or withdrawal.

For example, the Uniswap $UNI token could be deployed to both Ethereum and Optimism, and users would be able to bridge these tokens back and forth. When a deposit to the bridge is made on Ethereum, the balance on the Optimism contract increases and grants more $UNI tokens to the user on that network.

Note: What’s extraordinary is that bridging in this way has the same security guarantees as an Ethereum transfer – as do all subsequent transfers on Optimism.

Messages that are sent across the two networks arrive asynchronously – unlike the instant calls we are familiar with from the EVM. Depending on whether we’re sending messages to Optimism (e.g. depositing), or from Optimism (e.g. withdrawing), the delay time will be very different. Messages sent to Optimism typically arrive in a few minutes, whereas messages that are sent from Optimism take at least a week. This seven-day delay is called a “challenge period” because during this time the transaction can be contested and overturned, given a valid fault-proof.

Despite the inherent delay in communication from Optimism to Ethereum, a few advanced bridging protocols have already solved withdrawal delays for common ERC20 tokens. Anyone who wants to use those protocols can get instant withdrawals for a small fee. This fee appears to be similar to what we experience in traditional withdrawals in the US – e.g. when withdrawing from Coinbase to a Chase account.

Note: The protocols that solve the withdrawal delay problem typically do so by composing with other stable financial protocols on Ethereum. They are an excellent example of the benefits of permissionless blockchain composability!

The Standard Optimism Bridge

The Standard Optimism Bridge is a simple bridging protocol created by the Optimism team. While it doesn’t solve the withdrawal delay problem, it does give users a safe and standard way to bridge ETH and ERC20s between Optimism and Ethereum.

The protocol consists of two pertinent contracts:

• A bridge contract deployed to Ethereum, called L1StandardBridge

• A bridge contract deployed to Optimism, called L2StandardBridge

The two contracts know about each other; the L1StandardBridge on Ethereum stores an address for the L2StandardBridge deployment on Optimism, and the L2StandardBridge stores an address for the L1StandardBridge. The contracts use these addresses to transmit messages and validate received messages (since they only receive cross-domain messages from each other).

Additionally, the L1StandardBridge stores a balance of deposits for each ERC20 that has been deposited. It does this by mapping the L1 token address to the L2 token’s address, and mapping that to an integer that represents the deposit balance. The deposit amount is incremented when funds are sent to the bridge and subtracted when they are withdrawn.

Walkthrough: Bridging ETH to Optimism

The simplest way to bridge ETH to Optimism is just to send ETH directly to the standard bridge contract. In this case, the bridge’s receive method (which allows it to accept ETH directly), communicates with the L2 bridge contract through the cross-domain messaging protocol, instructing it to mint an ERC20 token that represents ETH on Optimism.

Along the way, the protocol will need to produce a new block on Optimism, by queuing a transaction up on Optimism’s Canonical Transaction Chain. Here’s a technical breakdown of the process; the call-stack looks like this:

L1 Call-Stack

• receive() - first, the contract handles the directly deposited ETH

  • _initiateETHDeposit() - it calls an internal function to initiate the deposit, specifying the transaction sender’s address as the beneficiary of the L2 funds.

    • sendCrossDomainMessage() - it uses a cross-domain messaging protocol to communicate with the L2 bridge contract. The method we want to call on the L2 contract is finalizeDeposit().

      • Since this makes use of a proxy contract, the first step will be to find the implementation and delegate the call.

      • getAddress() - within the messaging protocol, an address is retrieved for the messenger’s implementation address, named OVM_L1CrossDomainMessenger.

      • sendMessage() once the implementation is found, the call is delegated.

        • resolve() and enqueue() – finally, the transaction is enqueued onto the CanonicalTransactionChain.

L2 Call-Stack

• relayMessage() – Still within the cross-domain messaging protocol, but now running on the L2, a contract called OVM_L2CrossDomainMessenger relays the transaction to the relevant L2 contract: the L2StandardBridge. The message will be marked as successfully relayed after the L2 bridge’s method is called.

  • finalizeDeposit() – This method will check that the token is valid, and then attempt to mint the same amount that was deposited on the L1, to the transaction’s sender.

Depositing ERC20s

Besides sending ETH directly to the bridge contract, there are two other methods for depositing ERC20s to the bridge. The difference between them is just the ability to specify the recipient of the L2 token once the bridge transaction is complete. This difference is made clear by the function names:

• depositETH - accepts deposits from an EOA (a non-contract account)

• depositETHTo - accepts deposits from an EOA or a contract, with the recipient specified

• depositERC20 - transfers an ERC20 token from an EOA into the bridge contract

• depositERC20To - transfers an ERC20 token from an EOA or another contract into the bridge contract

Walkthrough: Withdrawing from Optimism to Ethereum

L2 Call-Stack

• withdraw() - the user calls on the L2StandardBridge contract, specifying the amount and the token (e.g. 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0000 for Optimism’s Ether token)

  • _burn() - the L2 contract then attempts to burn the number of tokens specified. This will remove it from the sender’s balance, and decrease the total supply of those tokens on Optimism.

  • At this point, a WithdrawalInitiated event is emitted from the bridge contract. Also, the tokens are burned on Optimism, but nothing has happened yet on Ethereum.

  • sendMessage() - The bridge now attempts to send a message to the L1 bridge, via the cross-domain messaging protocol.

    • The message to send is that finalizeETHWithdrawal or finalizeERC20Withdrawal should be called (depending on whether ETH or an ERC20 is being withdrawn), given arguments that include the equivalent amount of the token that was burned, and the address that should receive those tokens on Ethereum.

    • Specifically, it uses the L2CrossDomainMessenger contract to communicate this, invoking the method called passMessageToL1.

At this point, the 7-day delay is invoked. The withdrawal transaction is received by the L1 bridging contract after one week. This window is called a “challenge period”, and it gives actors on the network time to challenge transactions with a fault-proof. Funds cannot exit from the Optimism network without this time delay.

Note: The length of this challenging period could technically actually be updated! Advocates for changing the challenge duration can argue their case via Github issues.

Transaction Fees

Transactions on Optimism are cheap but not free. Like on Ethereum, Optimism users have to pay gas for the amount of computation and storage they use.

Deposit Fees

A transaction that bridges Ethereum and Optimism will trigger a contract execution on both networks. The major cost of an Ethereum to Optimism deposit transaction comes from sending the transaction on Ethereum.

Optimism makes a particular concession on deposits – it gives away the first 1.92 million gas on L2 for free. Since the execution typically uses less gas than this, the L2 charge ends up being free. Users only pay for the L1 charge when bridging to Optimism.

Note: Optimism charges for gas limits higher than 1.92 million, to prevent denial of service attacks on the network. The amount is paid on Ethereum, at a rate of 1/32 of the Optimism computation beyond the free amount.

Both the 1.92 million gas concession and the 1/32 rate are updatable parameters – so they may change in the future.

Withdrawal Fees

A withdrawal from Optimism to Ethereum combines the L2 initialization transaction and the L1 finalization transaction. The L1 finalization transaction is usually more expensive than the L2 initialization transaction.

Since gas prices on Ethereum may be volatile and bridging transactions are asynchronous, it becomes Optimism’s responsibility to pay whatever the L1 gas price is after the sequencer has processed the transaction. If the L1 gas price spikes during the withdrawal, Optimism will need to pay a higher cost.

Note: Optimism currently does not have a mempool, which means there is no gas price auction when submitting transactions on Optimism. Instead, the network will reject low-fee transactions.

Conclusions

We hope this has provided a thorough “walk across the Optimism bridge”, and that it provides some insight into how bridging in general works on Optimism. We are considering diving more deeply into other bridges that are more advanced, and comparing those to the standard bridge.

We expect a significant amount of ETH to move into the Optimism network, and that will need to happen across secure bridges such as these. Protocol Review is here to review!

Protocol Review is excited to continue publishing accessible reviews for decentralized protocols. We believe in using our deep technical knowledge to distill protocols and increase their mainstream understanding. To stay up to date with the latest reviews or if you’re interested in writing for the publication follow us on Twitter.

Thank you to everyone that made this post possible. @avichalp and @zachobront for your research and notes. @julianjhutton for your brand and design work.

0xSplits is a trustless protocol for splitting on-chain income. The protocol takes the form of a “hyperstructure”—a permissionless piece of infrastructure that distributes value to all users, operates at gas cost, and persists as long as the underlying blockchain reaches consensus. The smart contracts have been deployed to Ethereum mainnet and independently audited by Shipyard.

The core components of the income-splitting mechanism are Splits and Recipients. A Split is a payable smart contract that receives ETH and ERC-20 tokens and proportionally allocates received funds to Recipients. A Recipient can be any address associated with an EOA (externally owned account) or smart contract. As of 3/27/2022, 580 ETH and 16 different ERC20 tokens have flowed through 267 Splits.

Splits can be designated as either Mutable or Immutable at creation, with Mutable Splits requiring a Controller address (the Controller of Immutable Splits is set to 0x0, the Null Address). The Controller can modify a Mutable Split’s Recipients, percent allocations, and Distributor Fee after a Split has been created. The Controller can also transfer control to another address. While a Mutable Split can be set to immutable, an Immutable Split cannot be set to mutable. As of writing, 170 Immutable Splits and 97 Mutable Splits have been deployed, splitting income to 644 unique Recipients.

Splits are able to run at gas cost by relying on a third-party distributor to execute the transaction that updates Recipients’ withdrawable balances. In exchange for incurring gas costs, the distributor is rewarded with a Distributor Fee, a percentage of the total Split balance at the time of distribution. This fee can range anywhere from 0-10%. As of 3/27/22, the highest Distributor Fee earned is 0.22 ETH for a 0.1% Split. As the protocol’s documentation notes, a higher fee would likely lead to more frequent distributions, but the Recipients will be left splitting a smaller balance of funds.

We created a Dune dashboard with data analysis of existing Splits. Explore the data here.

Interacting with the Protocol

Creating a Split

createSplit takes in four parameters:

• a list of Recipient addresses

• a list of percent allocations corresponding to Recipients

• a Distributor Fee, ranging from 0-10%

• and a Controller address (if Mutable)

Under the hood, createSplit deploys a minimal proxy clone that redirects function calls to SplitWallet; effectively, this Split proxy mimics the logic found in SplitWallet but costs minimal gas to deploy. As a result, every Split has a unique address that can receive funds and send them to SplitMain.

EIP-1167 defines a standard for a minimal proxy contract, but 0xSplits extends EIP-1167. Split proxies refrain from calling DELEGATECALL in their receive function to avoid delegating a function call to SplitWallet. Instead, the receive function emits a ReceiveEth event, with parameters of the Split proxy address and the amount of ETH received. This modification allows proxies to accept ETH sent by send and transfer. Both of these functions only forward 2300 gas, which would not be enough to cover a DELEGATECALL to SplitWallet. Accepting ETH sent with send and transfer improves the composability of Splits since some accounts or smart contracts may send funds using these hard-capped functions. While this non-standard proxy pattern offers more flexibility for sending funds to Splits, this modification prevents Etherscan from verifying Split proxy contracts.

The technical architecture separating SplitMain and SplitWallet proxies allows balances to be stored at the account level. Since account balances are stored on SplitMain and updated once a Split balance is distributed, Recipients can withdraw funds received from multiple Splits in one transaction.

Distributing Split Balances

Third parties can call distributeETH and distributeERC20 to distribute Split balances to Recipients in exchange for a percentage of the total balance, defined as the Distributor Fee. Each ERC20 token requires a separate transaction call to distributeERC20.

The protocol ensures that distributors cannot alter Recipient addresses or their percentage shares by storing a hash of the Recipients, percent allocations, and Distributor Fee when a Split is first created. When either distributeETH or distributeERC20 is called, a similar hash is created with the function’s parameters. This hash must match the original hash stored for a particular Split.

Withdrawing Account Balance

ETH and ERC20 token balances can be withdrawn in one transaction. Balances are stored at the account level in SplitMain, so Recipients can withdraw funds from multiple Splits once they have been distributed. withdraw takes in the Recipient address whose balances are being withdrawn as a parameter, meaning that anyone can withdraw funds on behalf of another account. Although the user interface currently only allows accounts to withdraw their own balances, users can manually withdraw for another account on Etherscan today. The 0xSplits team is in the process of adding delegated withdrawals to the user interface.

Conclusion

0xSplits is a powerful and intuitive form of public infrastructure. The protocol encourages communities to create novel income streams and distribute them efficiently without worrying about additional overhead costs. At the same time, third parties can profit from arbitrage by distributing Splits with fees that outweigh transaction costs.

The full composability of Splits also engenders positive feedback as Splits can flush funds to other Splits and smart contracts. As of writing, donations.0xsplits.eth, the donations Split created by the team, is receiving income from 96 upstream Splits. Users should be cautious of sending funds to Mutable Splits that can be altered at any time, though the user interface provides sufficient warning on Mutable Split pages.

Thanks to everyone that helped get this review completed. Julian for the illustration, the 0xSplits team, and Andrew for the dashboard.

The protocol is EVM compatible and is still in development (see Github). A version of it has been deployed to the Polygon Mumbai testnet.

Nomenclature:

• Account refers to an Ethereum account. It could be an EOA or a Smart Contract.

• NFTs refer to ERC-721 Non-Fungible Token Standard

Lens Hub

Most interactions happen through the Lens Hub — a contract that implements profiles and publication interactions. Each profile and publication is an NFT created through this contract. Below is a list of interactions supported by the protocol:

• Create profiles

• Follow profiles

• Create posts

• Collect posts

• Comment on posts

• Mirror posts (reposting)

The Lens Hub keeps track of interactions through a mix of storage on the Lens Hub contract and callbacks that mint NFTs or provide custom logic through modules.

Profiles

Accounts can create profiles with a profile handle name, a profile image, a Follow NFT URI, and a Follow module. After creating a profile, a Lens Hub NFT is minted to the account that controls the profile.

The protocol uses its own profile name handling and restricts profile creation to an allowed list of accounts. The reason for this restriction is that the low fee environment of Polygon could lead to an excessive amount of profile name squatting. The protocol governance maintains the list of allowed profile creators. See the Security and Ownership section for more details on governance.

The Follow NFT URI is a content URI that is stored in the Lens Hub contract.

Currently, the profile image is just a URL. An improvement could be to allow profiles to have image modules. Image modules could delegate profile logic to NFT contracts.

Following

Following a profile consists of two main mechanisms: Follow NFTs and Follow modules.

Follow NFT

Follow NFTs are minted to follower accounts after following a profile. This means that following a profile comes with all the financial functionality and interoperability of NFTs. Some benefits could be airdrops, token gated content, or simply belonging to a cohort of accounts that hold a specific piece of digital art.

Each profile gets its own Follow NFT contract. If a profile does not have any followers, the first follow transaction deploys the Follow NFT contract. Since the follower is initializing the Follow NFT contract deployment, the protocol decides the name and symbol parameters for the Follow NFT. The name is set to the profile handle name with the suffix -Follower appended, and the symbol is the first 4 bytes of the handle name with the suffix -Fl appended.

The Follow NFT content function (tokenURI) calls back into the Lens Hub contract and returns the Follow NFT URI profiles specified when creating the profile.

An improvement would be to allow accounts to set up their own Follow NFT contract when setting up their profile. With this approach, the profile decides their name and symbol, and the first follower does not have to pay for the gas of deploying the Follow NFT.

Follow Module

Follow modules are contracts that specify the rules for new followers. The rules determine whether your account can follow a specific profile. There are a few different types of following modules:

• Permissioned — only accounts that you approved can follow you.

• Fee — all accounts can follow you, but they need to pay a fee amount in the currency of your choice (ERC20).

Currently, the FeeFollowModule implementation takes a percentage of the fee and sends it to a treasury.

Taking a modular approach to the following feature can be explored widely. A few ideas for new following modules are:

• NFT Follow Module — only accounts that hold specific NFTs can follow you.

• Follow Back — only accounts that you follow can follow you.

Creating profiles and publishing is a restricted feature, but all accounts can follow profiles as long as they satisfy the Follow module conditions.

Publishing

Publishing refers to creating posts and their interactions (collecting, comments, and mirrors). Only profiles can create posts, comments, and mirrors. However, similarly to following, collecting posts is open to all accounts.

Posts are created and stored on the Lens Hub by providing a content reference as well as a Reference and Collect module:

• A content reference is a string URL that points to content hosted outside the protocol.

• A Reference module is a contract that determines the rules for commenting and mirroring the publication.

• A Collect module is a contract that determines the rules for collecting the post.

Collecting and commenting are subject to Reference and Collect module rules, while Mirroring is only subject to the Reference module rules.

Collecting

Collecting a post, mints an NFT with a reference to the original post. The Collect NFT stores the profile and post IDs used later to retrieve the post content.

Commenting

Commenting on posts mints an NFT with a reference to the original post and an additional content reference that holds the comment's content.

Mirroring

A Mirror refers to a “repost” of content. When you Mirror a post, the original post’s profile and publication ID are stored as a new post. No content references are stored since the Mirror can point to the original post for content.

Signatures

A good design choice has been to allow publishing with signatures using a meta transaction approach. Transactions using signatures are supported for posting, commenting, mirroring, burning, and following.

This means that the end-user can interact with the protocol without spending any gas as long as someone else is willing to submit the transaction for you. This pattern is used in EIP-2612, which describes a standard for granting ERC20 token approvals with signatures. A similar design has been used by Mirror by using Ethereum wallet signatures to publish content to Arweave.

Security and Ownership

Dispatchers

Profiles can specify a “dispatcher.” A dispatcher is an account that can act on behalf of a profile as a form of delegation or sharing profile access. Dispatchers can update profile information, post, comment, and mirror. Only the profile owner can update dispatchers.

Profiles can only specify a single dispatcher. However, a dispatcher could be a contract that allows multiple accounts to submit transactions, effectively allowing multiple accounts to control a single profile.

Governance

The Lens Protocol has a governance module currently in control of a multisig that has special privileges.

Admin

The governance role can update an “emergency admin” role. The emergency admin can update the state of the protocol. The states are:

• Paused — creating profiles and publishing (posts, comments, mirrors) is paused.

• Unpaused — everything is unpaused.

• PublishingPaused — creating posts, comments, and mirrors are paused.

Closing Thoughts

The Lens protocol lays a foundational infrastructure to create connections between creators and their communities through on-chain interactions. The use of ERC-721 tokens gives users open access to their social graphs without any intermediaries. The Lens protocol is the beginning of social media moving away from old extractive models and letting creators own their social graphs.

Protocol Review is excited to continue publishing accessible reviews for decentralized protocols. We believe in using our deep technical knowledge to distill protocols and increase their mainstream understanding. To stay up to date with the latest reviews or if you’re interested in writing for the publication follow us on Twitter and join Discord.

Thanks to everyone that helped get this review completed. Julian for the illustration. Julie, Graeme, Denis, Lauren, and Davidbrai for reading and editing the drafts.

Collections allow artists to express a thematic relation among a group of their NFTs (just as a musician would for an album) and to describe the collection using the NFT's metadata. Collections also allow Foundation to aggregate and present data about a collection for potential buyers — such as its total sales, limits on the collection size, and floor price.

Each collection is described by a name, symbol, description, and an optional limit on the collection size.

Foundation's creators understood the implications of the feature quickly, as 228 artists deployed a collection within 24 hours (over 450 deployments at time of writing) — despite paying an Ethereum transaction fee to do so.

https://twitter.com/saturnial/status/1466198872875667460?s=20

Previously, all of Foundation's artists minted NFTs on a single shared contract deployed by the platform. Although this made it cheaper to mint, it also meant that all artists were represented under the Foundation brand (instead of their own) on third-party marketplaces like OpenSea.

In our technical review, we explain how Collections are cheap to deploy, what the ownership and trust properties are, and generally dissect the engineering decisions that went into the most relevant features of the contracts.

Efficient Deploys: The Foundation Collection Factory

Collections are deployed via the Foundation Collection Factory. Deploying a Collection costs around 168k in Ethereum gas, which is very cheap — enabled by using OpenZeppelin's Clones library, which implements the EIP-1167 standard. Foundation also used this pattern in their Splits feature.

The goal of the standard is to deploy a minimal amount of code to Ethereum for any functionality that is intended to be used by many contracts. It achieves this by separating the contract's storage from its functionality.

The state is deployed many times as separate, minimal, identical contracts (hence called a "clone"), and the large logic contract is only deployed once. The clones simply delegate transaction calls to the logic contract, which can modify the clone's state. This delegation pattern is known as a proxy pattern.

As a result, artists on Foundation only pay for deploying a small clone that holds information about the collection (including its name and symbol) but that has the full functionality of a collection (such as minting and transferring).

A drawback of using a factory is that it makes the deployment an internal deploy call from the factory, and so some platforms might interpret the "creator" as the factory's address rather than the user's wallet. We've seen this happen on OpenSea before when using factories to deploy ERC721 contracts.

On the other hand, using a factory makes tracking collections easier (e.g. via a subgraph on The Graph Protocol), and it's easy enough to define the creator as the wallet where the transaction originated.

Additionally, an optimization could be to deploy the contract and perform the first mint in the same transaction; currently, two transactions are needed to get to the point where a token is minted.

Another thing to note: The minimal proxy standard should not be confused with "upgradable" proxies — the proxies deployed through the Foundation Collection Factory are not upgradable.

Enforced Rarity: Limiting the Number of Tokens Per Collection

Collections provide an optional way for artists to guarantee rarity in their collections — by allowing them to set a limit to the number of tokens that can be minted.

Each collection has a field maxTokenId, which defaults to zero, but can be set to a positive integer by the owner. Since each token's ID is effective an index — starting from zero and increasing once per mint — this field is used to prevent a token from being minted if its ID will be greater than the intended limit.

Limits

If the maxTokenId is never set and remains at zero, the owner can mint an unlimited number of tokens to the collection. However, once set, it can only be modified to a value that is lower than the current value. In other words, once the artist has committed to a limit for the collection's size, the collection is guaranteed never to grow beyond that limit.

Royalties

Each token can have its own royalty payment address defined by the owner when minting. Royalties are set to a fixed amount of 1000 basis points (10%). The collections contract implements the royalties system defined originally by Rarible.

The royalties implementation differs from the NFT Royalty Standard defined by EIP-2981. Builders in the space will benefit if a large platform like Foundation implements the EIP royalty standard as it allows for easier interoperability. Manifold has recently written a meticulous library for marketplaces to aggregate all royalty implementations into a standard. Standardization reduces the need to use libraries that aggregate many disparate strategies in a single function as added optionality is error-prone.

Ownership and Trust Assumptions

The collections factory and logic have roles that manage different privileges.

Factory Contract

The collections factory contract has a roles contract set to Foundation's treasury, which extends OpenZeppelin's Access Control implementation. The roles contract serves two purposes:

• It defines the admin role that has privileges such as updating the implementation of the collections contract, meaning it can update which "logic" gets deployed with the proxies

• It defines the operator roles queried from the collections contract

Collections Contract

The collection contract implements a standard ERC-721 with two roles. An owner role that is set to the user's wallet; and an operator role that is set to a role contract specified by the factory.

Owner capabilities:

• Set the maximum number of tokens that can be minted in the collection

• Update the baseURL

• Burn any tokens owned by the collection owner. Collectors cannot burn tokens.

• Mint tokens with a combination of automatically approving a specified operator (auction house, marketplace, etc) and setting a royalties recipient

Operator capabilities:

• Migrate tokens from one account to another with the original token owner's permission (using signatures)

Final Thoughts

Web3 is about ownership. Foundation has taken a necessary step towards giving creators more ownership over their work and image while making it as accessible as possible through opinionated product decisions and inexpensive deployments. We like the collections.

References:

• Factory Contract

• Implementation Contract