Update sip-6.md

ProjectOpenSea · Oct 31, 2023 · b7d6dbd · b7d6dbd
1 parent 04e69f7
commit b7d6dbd
Showing 1 changed file with 5 additions and 2 deletions.
diff --git a/SIPS/sip-6.md b/SIPS/sip-6.md
@@ -41,12 +41,15 @@ If `extraData` is supplied as part of a SIP-6-compliant order, it MUST be prefix
 | 0x03         | multiple variable data arrays                                | `abi.decode(extraData[1:], (bytes[]))`          | n/a                                                                                         |
 | 0x04         | multiple fixed data arrays                                   | `abi.decode(extraData[1:], (bytes[]))`          | `keccak256(abi.encode(keccak256(fixedDataArrays[0]), keccak256(fixedDataArrays[1]), ...]))` |
 | 0x05         | multiple variable data arrays and multiple fixed data arrays | `abi.decode(extraData[1:], (bytes[], bytes[]))` | `keccak256(abi.encode(keccak256(fixedDataArrays[0]), keccak256(fixedDataArrays[1]), ...]))` |
+| 0x06         | multiple variable data arrays and single fixed data array | `abi.decode(extraData[1:], (bytes[], bytes))` | `keccak256(fixedDataArray)` |
+| 0x07         | single variable data array and multiple fixed data arrays | `abi.decode(extraData[1:], (bytes, bytes[]))` | `keccak256(abi.encode(keccak256(fixedDataArrays[0]), keccak256(fixedDataArrays[1]), ...]))` |
+| 0x08         | no data arrays | n/a | n/a |
 
-Zones and contract offerers MUST accept extraData encoded using the simplest possible version that adheres to the requirements of the SIPs they implement. Zones and contract offerers MUST reject encodings that do not provide for sufficient variable and/or fixed data arrays to satisfy each of the SIPs they implement by reverting with an `UnsupportedExtraDataVersion(uint8 version)` custom error. Zones and contract offerers MAY support more complex encodings than strictly required by the SIPs they support. Note that the hashing scheme for fixed data arrays will vary based on whether a single array or multiple arrays are required; in these cases, the simplest possible version MUST be used when selecting a fixed data hashing scheme for constructing the zone hash as part of order creation.
+Zones and contract offerers MUST accept extraData encoded using the simplest possible version that adheres to the requirements of the SIPs they implement. Zones and contract offerers MUST reject encodings that do not provide for sufficient variable and/or fixed data arrays to satisfy each of the SIPs they implement by reverting with an `UnsupportedExtraDataVersion(uint8 version)` custom error. Zones and contract offerers MAY support more complex encodings than strictly required by the SIPs they support. Note that the hashing scheme for fixed data arrays will vary based on whether a single array or multiple arrays are required; in these cases, the simplest possible version MUST be used when selecting a fixed data hashing scheme for constructing the zone hash as part of order creation, and zones MUST reject version bytes that do not contain the minimal fixed data hashing scheme (e.g. zones without fixed data MUST reject any SIP-6 version scheme that contains fixed data arrays, zones with a single fixed data array MUST reject any SIP-6 version scheme that does not contain a single fixed data array, and zones with multiple fixed data arrays MUST reject any SIP-6 version scheme that does not contain multiple fixed data arrays).
 
 Zones and contract offerers MUST decode relevant data arrays based on the order that schema IDs are returned by `getSeaportMetadata()` in accordance with SIP-5. If the supplied extraData cannot be decoded using the specified version, or does not contain sufficient array elements to satisfy each of the SIPs implemented, the zone or contract offerer MUST revert, and SHOULD revert with an `InvalidExtraDataEncoding(uint8 version)` custom error.
 
-By way of example, if a zone implements SIP-X, SIP-Y, and SIP-Z and returns schema IDs in the same order when calling `getSeaportMetadata()`, and each SIP requires a single variable data array, then the zone will accept version 0x03 (and optionally version 0x05), rejecting any other versions, and will decode the first element (index 0) in the array of variable data arrays as the variable data array for SIP-X, the second element (index 1) as the variable data array for SIP-Y, and the third element (index 2) as the variable data array for SIP-Z.
+By way of example, if a zone implements SIP-X, SIP-Y, and SIP-Z and returns schema IDs in the same order when calling `getSeaportMetadata()`, and each SIP requires a single variable data array, then the zone will accept version 0x03, rejecting any other versions, and will decode the first element (index 0) in the array of variable data arrays as the variable data array for SIP-X, the second element (index 1) as the variable data array for SIP-Y, and the third element (index 2) as the variable data array for SIP-Z.
 
 When a contract is both a zone and a contract offerer, and implements both zone-specific SIPs and contract-order-specific SIPS, extraData construction MUST be based on the current context. In other words, if the contract is being interacted with as a zone, then contract-order-specific SIPs are to be disregarded; alternately, when the contract is being interacted with as a contract offerer, then zone-specific SIPs are to be disregarded.