Through its head of protocol development, oage, OpenSea announced that it had published Seaport version 1.4. The improvement will hopefully result in a more satisfying and complete user experience. In addition, version 1.4 fixes a few bugs in earlier “development preview” versions of Seaport (v1.2 and v1.3), which are not intended for usage in production environments.
Seaport v1.4 has been deployed and is ready for production use!
0x00000000000001ad428e4906aE43D8F9852d0dD6
Version 1.4 addresses a few issues on Seaport v1.2 & v1.3, "developer preview" versions not recommended for production use
Let's go over v1.4 changes & lessons learned ⤵️
— 0age (@z0age) February 21, 2023
What did previous versions miss?
Seaport version v1.2 contained a bug in which, under some circumstances, token transfers might take place after zone checks. This problem was the fundamental motivation for the deployment of Seaport version 1.3.
Nevertheless, the “patch” supplied in version 1.3 led OpenSea to discover a new problem during the final round of testing. As a result, a second iteration of each listing was included in version 1.3 after all fulfillments were finished to guarantee that all zone and contract offerer checks were performed after all transfers.
Listings being “skipped” as part of the fulfillAvailable process were still being examined, and trash data was not found. Therefore, when the underlying listing has been flagged as unavailable, Seaport 1.4 will, as is appropriate, bypass the zone and contract offerer checks.
This underscores the significance of evaluating, testing, and carefully analyzing every code change since resolving one problem might lead to other issues in neighboring areas according to OpenSea.
Because of this revelation, investigating the actions taken by zones and contract offerers when no listings were available was carried out in greater depth. Throughout the inquiry, a corner case became clear. When a listing cannot be seen, contract offerers should never be allowed to change their state.
In the past, if a contract offerer had returned an invalid offer or consideration array, the listing would have been marked as unavailable. This safeguarded contract fulfillers but left contract offerers vulnerable if those offerers made any further state modifications. Because of this, Seaport 1.4 will roll back if insufficient data is received.
Further remarks from the Chief of Protocol Development
According to Opensea’s Oage, developing marketplace protocols that were performant, expressive, and durable proved to be a complex undertaking.
However, he adds that this challenge was one of the most important aspects that led to the creation of Seaport. Oage thinks that if they all collaborate on an open-source codebase, they will be able to create an adaptable, efficient, and safe marketplace.
“Challenging the limits of what can be accomplished in NFT markets was never going to be easy.” However, Seaport’s dependability improves noticeably with each subsequent iteration. The features that Seaport v1.4 has made available are cutting-edge. Incredible joy at seeing the beginning of a new era in the NFT ecosystem!
To conclude, Oage says.
