Opensea <> Spearbit Call

**Speakers**

- z0age
    - Seaport Core Dev
- Alex Beregszaszi
    - Solidity Co-Lead
    - Spearbit Founder
- Hari
    - Solidity Compiler
    - Spearbit Founder
    - Math background
- Gerard Persoon
    - Security Researcher for Spearbit and C4
- Sawmon and Natalie
    - Has been looking at z0age’s work and is into low level code


**Main Questions**

- Q: How did Opensea go about launching Seaport and how did they approach security?
    - Work on Seaport started earlier this year
    - Spent months on architecting
    - Wrote a full suite of Hardhat and Foundry tests
    - Got multiple auditors (OZ + TOB)
    - “Nothing quite gives you the confidence that something is production ready like wide spread review from experts”
- Q: How did the Spearbit team come along?
    - Saw the announcement and realized it was challenging their knowledge of the EVM and solidity
    - Once they started looking at it, it was even more complex than they expected.
- Q: Going into the contest, where there risks you were already aware of / anticipating?
    - Assembly code is really something you only reach for when you need it.
    - Opensea’s prior contract (Wyvern) was at the top of gas guzzlers and was designed in the era when gas prices were not as much of a concern.
- Q: What were some of the surprises that came from the review?
    - Many of the core optimizations and key findings for Seaport didn’t actually involve the assembly code.
    - The fact that this had a lot of assembly actually got more eyes on the code than they expected.
- Q: Spearbit Team & Sawmon - what were some of the surprises when reviewing Seaport?
    - **Gerard**
        - Found something strange in the basic order for filling transactions that was almost a bug but a small piece of solidity prevented the finding from elevating.
    - **z0age**
        - Gerard is impressive when it comes to branchless logic.
        - On the note of constants:
            - On one hand, if you are really fluent (e.g. you know exactly what the offsets for the compiler constructs are going to be, you know how abi encoding works for how you will assemble those structs into inline, etc.) then assembling those constants inline makes sense. We made the decision to blow away constants and replace them with named constants.
            - This has been very helpful for people who don’t have that knowledge to be able to review the code. This is one of many controversial aspects of the seaport code base.
    - **Alex**
        - The cleanup of enums can occur at the end of a solidity function. In this particular case we had assembly blocks and then there was a call to somewhere else. The call would trigger the enum cleanup and validation. This particular case directed us to looking at similar cases to look for areas where this cleanup was or wasn’t happen.
        - There are a bunch of functions that do memory transfers. One of these is the ERC-1155 batch transfer. Some of these functions store the value and re-store it, so you are able to use it multiple times. It is not something you want to use multiple times, it can only be used once and then you terminate.
- Q: Where did you even start when taking a first look at this codebase and putting together an approach given the finite timelines and complexity?
    - **Sawmon**
        - First thing I did was skimmed through the whole codebase.
        - Second I created a diagram of the different classes and contracts to create an inheritance tree.
        - Then I started bottom up (from the very last grandchildren) and worked my way up to the very top.
        - For each contract you have to go through each function, the assembly just makes it take a little bit longer.
        - Once you have a good understanding of each contract on their own, then you have to draw a bigger picture of how things interact with each other.
        - One thing I found interesting about Seaport is that if you look at the code there’s basically 3 storage slots that are private (1 for re-entrancy guard, 1 for counters/nonce, 1 keeping tab of order hash validity). The code is very memory intensive.
            - **z0age**: This is one of the areas where assembly really shines. A lot of work has gone into keeping the solidity compiler memory-safe, but this creates inefficiencies.
            - One of the primary places you would reach for assembly is in memory management.
            - It does make code re-use way more dangerous.
            - Reach out to OS if you are thinking of using portions of the Seaport code base.
    - **Alex**
        - One reason you want to optimize memory is because solidity functions wouldn’t necessarily free memory at all so you can end up with larger memory use than you expect.
        - Wasn’t sure about the memory savings this code has gotten.
        - The code uses two more tricks that I think are even more significant
            - In one part that operates with external data, it ensures that when that data is passed down that it is marked as call data.
            - Solidity expects a generalized decoder and Opensea has strict structuring requirements.
- Discuss some of the findings
    - Can view findings in the Seaport Repo under “seaport test findings”
    - Partial Fulfillment
        - With Seaport you can specify on the order type that you are able to take a partial fulfillment on an order type. It scales everything down on a fraction.
        - You get into trouble when you set very large numerators and denominators.
        - In the unchecked block you could overflow the partial fill fraction and then re-fill an order. You could spend more than you were asked to. You could also construct malicious fractions that essentially block an order from being filled.
        - We solved this by computing the greatest common denominator using a Euclidian algorithm.
    - Criteria resolvers
        - In Seaport you can specify there is a criteria that needs to be satisfied.
        - You can insert a token ID into a merkle root, in Seaport we pushed this too far (treating the token ID as the leaf).
        - This caused some issues:
            - You can resolve intermediate nodes in that tree as though they were token IDs (including the very roots).
        - **Alex:** Same logic has been used in many other projects that I’ve seen.
- How did you convince Opensea and how do you think about security spend?
    - **z0age**: You can come at security spend from “ok it’s going to cost X, it could be spent on something else, but instead it’s going into this.” It’s a cost benefit analysis.
    - On the flipside, what are the odds that something really terrible is going to happen and what are the costs there?
    - For Seaport, even if the chance for something going wrong was really small, the damage would be massive.

**Q&A**

- **Alex to z0age**: Is there anything you would have done differently on the code or security process that Seaport has taken?
    - **z0age**: In terms of the code base, we’re putting finishing touches on a library of verification of orders. Seaport is pretty low level in that it is expressive and there are many ways to ‘footgun’ yourself. For validating those orders, because it is so code and gas optimized there is an expectation that whoever is receiving those orders the code is going to be validating on top to make sure there are no issues.
    - Some of those orders that are malicious we should have caught earlier on.
- **Ikhlas to z0age:**
    - What's the future of Seaport in terms of security and is there any plan to list bug bounties?
        - **z0age**: Seaport immediately became a community owned and led project. Continuing to improve formal verification, test suite and invariants. For now the focus is on deploying Seaport across every EVM compatible chain. I imagine as we move forward in the coming months that we’ll start to see new developments (e.g. Seaport 1.2 or 2.0).
        - In terms of Immunifi - there’s always more you can be doing, that being said, Opensea has a Hacker One setup with Seaport in scope (up to $3m for a crit).
- **Rowin to auditors:**
    - What is the approach you do with the complex contracts?
        - **Gerard**: Get an overview of the code and make a drawing to see how contracts relate. Start at the top of the code to read and understand it. Everything I don’t understand I keep diving deeper until you finally understand the whole codebase. With Opensea there was not enough time to understand it completely so it was nice to work as a team to focus on different areas so you can select pieces of code to dive into.