Disclaimer: I’ve been told by readers that I sometimes have spelling mistakes and poor grammar - I’m not going to fix, that time will be spent reading more code.

Hey everyone welcome back to waints blog. Today we’re walking through the Manager contracts for LooksRare:

CurrencyManager ----- ExecutionManager

CurrencyManager.sol

CurrencyManager is all about which currencies are available on LooksRare, its a pretty quick contract.

First thing to note is the imports -- Ownable and EnumerableSet. We’re aware of what Ownable does, lets someone be the owner of a contract. EnumerableSet is an interesting one though.

EnumerableSet gives us a struct like element that has two internal variables: _values, and indexes*.* values is a list of Bytes, and _indexes is a mapping from bytes to integers. So basically what this gives us is the capability to store items in a list, and know where those items are located in the list. The benefit of this is O(1) time for accessing, adding, removing, and validating items -- so using EnumerableSet is much much more efficient than using a list. In the CurrencyManager we’ll use this to store addresses of currencies so that it’s efficient to access and edit our list of currencies. Now lets checkout the interface quick.

ICurrencyManager.sol

The interface outlines 5 functions for us: (function (input))

1. addCurrency (address) - Add a currency to the list

2. removeCurrency (address) - Remove a currency from the list

3. isCurrencyWhitelisted (address) - Returns true if the currency is in the whitelist

4. viewWhitelistedCurrencies (integer, integer) - Returns whitelisted currencies for the input parameters

5. viewCountWhiteListedCurrencies () - Returns how many currencies are in the whitelist

So basically manage what currencies are available - we should expect these functions to be defined in CurrencyManager.sol. Lets go ..

contract CurrencyManager is ICurrencyManager, Ownable {
    using EnumerableSet for EnumerableSet.AddressSet;

This is 90% of the functionality of the contract - an EnumerableSet full of addresses. Using this as a base the contract adds two events (CurrencyRemoved, CurrencyWhitelisted) on top of it and wraps the add/remove functionality of the sets in functions.

We then have two simple functions to check if the currency is whitelisted, and return the number of currencies in the set.

The last function is one that returns all the whitelisted currencies based on the two input parameters:

1. cursor → Index to start listing currencies at

2. size → Number of currencies to display

Whats weird about this function is that the size input is immediately set to a new variable - length.

uint256 length = size;

I honestly dont know why they did this. There may be some integer wrap that comes with re-assigning it that I dont know about, but if there is nothing then this is a waste of gas. I’m guessing it has something to do with the next two lines but I’m not sure:

if (length > _whitelistedCurrencies.length() - cursor) {
    length = _whitelistedCurrencies.length() - cursor;
}

This is saying if the number of items requested in the input is larger than the number of items remaining in the set starting at the cursor input location, we will use the number of items remaining in the set as the new length.

Next the contract copies all the items from the cursor to set length and returns that array along with the length of the set. This last return is a little weird for me, if they’re returning the length of the OG set they could have done this differently, and if they’re trying to return the length of the new set returned its not correct. Maybe theres something I’m missing here, guess we’ll have to keep reading contracts ..

Aight im done with this one lets move on to ExecutionManager.sol

ExecutionManager.Sol

Damn this one is almost identical ..

The only real difference is instead of currencies, we’re dealing with strategies we discussed earlier. So I guess theres not much more to learn here, time to go deeper

Disclaimer: I’ve been told by readers that I sometimes have spelling mistakes and poor grammar - I’m not going to fix, that time will be spent reading more code.

Strategies

What are Strategies?

In LooksRares contract structure, a strategy is essentially a way to trade over the platform. For instance, you can sell an NFT via private sale, or bid on a collection of NFTs, or you can perform a standard trade for a fixed price. Before we jump into the strategies, we need to discuss the Execution Strategy interface.

IExecutionStrategy.sol

(IExecutionStrategy.sol)

This interface is heavily dependent on the custom OrderTypes library located at OrderTypes.sol. This library contains two structs (MakerOrder, TakerOrder) and a hash function. LooksRare’s exchange protocol is hybrid off/on chain - meaning, it incorporates off-chain signatures (Maker Orders) and on-chain orders (Taker Orders). The specifics of this are not necessary at the moment, just know that this is how they perform NFT transactions and the hash function is there to provide verifiability. To learn more, visit the docs.

Now that we know what order types are, we can easily walk through the ExecutionStrategy interface. This interface has the following functions:

• canExecuteTakerAsk - validates a takerAsk against a makerBid and returns a boolean and two ints.

• canExecuteTakerBid - validates a takerBid against a makerAsk and returns a boolean and two ints.

• viewProtocolFee - returns an int.

So we have two functions to validate trades and a function to see how much the protocol fee is. This means we should probably see some form of these functions in the strategy contract. Now we can jump into StrategyStandardSaleForFixedPrice.sol.

StrategyStandardSaleForFixedPrice.sol

(StrategyStandardSaleForFixedPrice.sol)

As expected, we have the three functions above implemented in this contract. The only other notable is the constructor, this takes integer protocolFee as input and sets it to the public immutable variable PROTOCOL*_*FEE.

Next up the two execution functions. these functions are really simple, they take TakerOrder and MakerOrder type structs as input and return a bool and two ints. Realistically its just object comparison wrapped in a function that also returns what token is being traded and at what price. See below:

Starting on line 40 we have the beginning of the boolean statement. In plain english this is:

For the makerBid and takerAsk, if the price and tokenID (NFT) are equal, and the makeBid is still in an active timeframe, validate the order as true, if any of these are inconsistent, its false.

Then also throw in the tokenId and number of tokens that are being traded. Next up is the TakerBid function which has almost the same logic.

Pretty much identical.

Final function: viewProtocolFee which returns the protocol fee that was set in the constructor.

Easiest one is out of the way, shall we continue? The next two, we’ll cover together.

StrategyPrivateSale.sol & StrategyAnyItemFromCollectionForFixedPrice.sol

(StrategyPrivateSale.sol & StrategyAnyItemFromCollectionForFixedPrice.sol)

I’m covering these two in the same section because they have the same exact structure as the standard sale one outlined above. The only difference for these is that in the private sale strategy, the canExecuteTakerAsk function always returns false, 0, 0 while in the collection based strategy, the canExecuteTakerBid always returns false, 0, 0 Additionally, the private sale strategy verifies that the targetAddress of the transaction is also the address where the takerAsk originated - hence, private sale.

In the private sale strategy, a taker accepts an offer from the maker to buy an NFT, whereas in the collection based strategy, the taker accepts an offer from the maker to sell the NFT.

The maker / taker system is an efficient way to have a hybrid bid/ask system and pack all strategies into a single interface.

Now we got all the strategies down, its time to continue with the LooksRare core architecture before jumping into the exchange contract. Next up: CurrencyManager.sol

Whats going on everyone, my name is waint and I’m gunna start a blog to take notes on smart contracts, write about NFTs, and I dont really know yet. So this is it, I’m kinda just going to write about random shit, so welcome.

🔰 First up: LooksRare

I’m going to read all of LooksRares contracts and note anything I see and walk through what they’re doing. I’ll be using this piece as a semi introduction to smart contract development -- going line-by-line-ish describing whats going on. Later reviews will gloss over some of these details.

1. LooksRareToken

Contract Address: 0xf4d2888d29d722226fafa5d9b24f9164c092421e

Standard opening, looks like we’ll be having an ERC20 token that is Ownable. Before we go further, lets see whats good with the interface.

Pretty simple, we have the SUPPLY_CAP and mint as this contracts interface. This would allow someone to import the structure of LooksRareToken into their smart contract, thus enabling its functions to be executed (if the correct LooksRareToken address is used).

Back to the OG file.

Line 46 is the contract declaration. Says this contract is called LooksRareToken and it is utilizes the ERC20 and Ownable protocols and is accessible using the LooksRareToken interface.

In Line 46 the variable _SUPPLY_CAP is initialized as a uint256 (number) which is private (not public facing variable) as well as immutable (cannot be changed).

Line 55 is where the constructor function is located, this function is run when the contract is deployed and it only runs once. When deploying this contract there is 3 required inputs:

1. _premintReceiver - Address to mint the pre-mint amount to. (Line 56)

2. premintAmount - How many tokens to mint to _premintReceiver (Line 57)

3. _cap - the supply cap of the token. (Line 58)

The constructor function makes sure the supply cap is greater than the premint amount, it then mints that amount to the premint address, and sets the _SUPPLY_CAP variable to the supply cap input (_cap).

Next up is the mint function. This is where the tokens are distributed. Before jumping into the code its important to highlight what it means to be an ERC20 and Ownable contract (Line 46). Being an ECR20 contract means you are also abiding by all functionality of an ERC20 token, this includes being able to be traded over Ethereum. There are also additional functionality that comes with it, including the _mint function which lets you create tokens. You can read more about ERC20s here:

https://docs.openzeppelin.com/contracts/4.x/erc20

As for being Ownable, this means we can utilize the onlyOwner modifier (amongst other things) which lets us limit functions from executing if the origin message sender was not the owner of the contract. Read more about it here:

https://docs.openzeppelin.com/contracts/4.x/access-control

Now lets talk about the mint function LooksRare implemented. It looks like there are two input variables:

1. account → An address to mint tokens to.

2. amount → An integer number amount to mint.

This function is externally facing, overrides other interface mint functions, is only callable by the owner, and returns a bool (True/False) when finished executing.

The function first ensures that the number of tokens being asked to mint does not exceed the supply cap of the token (line 73). If it does exceed, then the function immediately returns false.

If it is determined that we can mint this many tokens we call the ERC20 token standard function _mint to mint the amount of tokens to the inputted account. The function then finishes by returning true.

In the last lines of the program, we have the SUPPLY_CAP function. this function is externally facing, view (which means it does not affect contract state), and overrides a default SUPPLY_CAP function. This function returns the integer value for _SUPPLY_CAP.

Thats it, that the LooksRareToken contract. I dont see any vulnerabilities in this one, seems all buttoned up and really standard. This mirror is already pretty long and theres no way I proof read it so I hope you enjoyed it and are have a great day!

Next Contract: StrategyStandardSaleForFixedPrice.sol - 0x56244bb70cbd3ea9dc8007399f61dfc065190031