Seaport 1.6 and Immutable Signed Zone V3

[lfportal]

Seaport 1.6 and Immutable Signed Zone V3

• Adds Seaport 1.6 contract (Immutable fork with zone restrictions)
• Adds Immutable Signed Zone V3, notable differences compared to V2:
  • Compatibility with Seaport 1.6's updated Zone interface (addition of authorizeOrder function)
  • Adds support for SIP-7 substandards 1, 7 and 8

---

Note

Introduces Immutable Seaport 1.6 with zone allowlisting and a new Immutable Signed Zone V3 (SIP‑7 substandards 1,3,4,6,7,8), plus comprehensive tests and CI/tooling updates.

• Contracts (Seaport 1.6):
  • Add contracts/trading/seaport16/ImmutableSeaport.sol enforcing restricted-order fulfillment and allowedZones allowlist across all fulfillment/match paths.
  • Add conduit wrapper seaport16/conduit/ConduitController.sol and validator facades under seaport16/validators/*.
• Contracts (Immutable Signed Zone V3):
  • Add seaport16/zones/immutable-signed-zone/v3/ImmutableSignedZoneV3.sol implementing SIP‑7 (with authorizeOrder and validateOrder), EIP‑712 signing, access control, and substandards 1, 3, 4, 6, 7, 8.
  • Include zone access control and SIP interfaces/errors; README and harness.
• Tests:
  • New Seaport 1.6 unit/integration tests (config, operational, zone V3, helpers, mocks) and test plan docs.
• Tooling/Config:
  • Hardhat: add 0.8.24 compiler (Cancun), overrides for seaport16, integrate @nomicfoundation/hardhat-foundry.
  • Package/deps/remappings: add Seaport 1.6 libs and Limit Break creator standards; update lock/remappings/DEPS.
  • CI: install Foundry, add Forge test job; run forge install in publish/test workflows.
  • Git: add new submodules; ignore Foundry/Hardhat caches and fuzz artifacts.

^{Written by Cursor Bugbot for commit 4239203. This will update automatically on new commits. Configure here.}

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[drinkcoffee]

I suggest removing this check, and have a new error, InvalidExtraDataLength(string _msg, bytes32 _orderHash, uint256 _length)
The new error could be used in the places where InvalidExtraData is being thrown to indicate invalid length.

[lfportal]

InvalidExtraData is an error defined by the SIP-7 spec, required when extraData is of an unexpected length:

If the extraData component is unable to to be parsed properly due to unexpected size or format, the zone or contract offerer MUST revert with error InvalidExtraData(string reason, bytes32 orderHash).

[drinkcoffee]

Please add this check so a meaningful error is produced if the length is incorrect.

    // Revert with an error if the extraData does not have valid length.
    if (extraData.length < 93) {
        revert InvalidExtraDataLength("extraData length must be at least 93 bytes", orderHash, extraData.length);
    }

[lfportal]

The validateOrder function intentionally avoids redundant checks already validated as part of the authorizeOrder function (which is guaranteed to execute before validateOrder during order fulfilment) to reduce overhead.

[lfportal]

Note for discussion: The authorizeOrder and validateOrder functions are assumed to be called together in that order which Seaport will guarantee. The functions are not view or pure (to support SIP-7 substandards 7 and 8 creator token standard callbacks), so they may change state. The functions are also currently not restricted to any particular caller - this was fine for previous versions of this zone which designated validateOrder as view function. Given the assumptions, the functions should be caller restricted to preserve the semantics of the creator token standard. What options do we have to apply restrictions?

Edit: Added caller (msg.sender) restriction to authorizeOrder and validateOrder functions. The Seaport address is obtained via the zone constructor for simplicity.