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

Introduce Seaport 1.6 (Immutable fork) with zone allowlisting and add Immutable Signed Zone v3 with SIP‑7 substandards and 1.6 Zone interface support, plus tooling/CI and tests.

• Contracts:
  • Add contracts/trading/seaport16/ImmutableSeaport.sol (Seaport 1.6 fork): enforces restricted orders and allowed zone allowlist across fulfill/match flows; emits AllowedZoneSet.
  • Add zones/immutable-signed-zone/v3/ImmutableSignedZoneV3.sol: SIP‑7 zone with substandards 1,3,4,6,7,8, EIP‑712 signing, authorizeOrder/validateOrder, role-based management (ZoneAccessControl), transfer validator hooks (substandards 7/8).
  • Add adapters: conduit/ConduitController.sol (seaport-core-16), validators (SeaportValidator*, ReadOnlyOrderValidator).
• Tests:
  • New Seaport 1.6 test suite and integration tests for Signed Zone v3; extensive unit tests for access control, EIP‑712, substandards, and operational flows.
• Tooling/Config:
  • Hardhat: add @nomicfoundation/hardhat-foundry, compiler 0.8.24 (Cancún), overrides for seaport16; network hardfork set to cancun.
  • CI: install Foundry in publish/test workflows; add Forge steps; dry‑run publish job compiles/builds.
• Dependencies/Repo:
  • Add seaport-16, seaport-core-16, seaport-types-16, @limitbreak/creator-token-standards; update remappings, foundry.lock, and docs (DEPS.md).
  • Update .gitignore (e.g., cache_hardhat) and lockfiles.

^{Written by Cursor Bugbot for commit 6bc039f. 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?