Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update sip-6.md #22

Merged
merged 1 commit into from
Oct 31, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions SIPS/sip-6.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down