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 Seaport 1.6 with zone allowlisting and a new SIP-7 Immutable Signed Zone V3 (incl. authorizeOrder), with full tests and CI/dependency updates.

• Contracts:
  • Add contracts/trading/seaport16/ImmutableSeaport.sol (Seaport 1.6 fork) with allowedZones, restricted-order enforcement, and zone validation across fulfill/match paths.
  • Add Conduit wrapper contracts/trading/seaport16/conduit/ConduitController.sol.
• Zones:
  • Add ImmutableSignedZoneV3 (SIP-7) with EIP-712 signing, authorizeOrder, validateOrder, access control, active signer management, and support for substandards 1, 3, 4, 6, 7, 8.
  • Add zone access control and SIP interfaces/errors.
• Validators:
  • Add Seaport 1.6 validator shims (SeaportValidator, ReadOnlyOrderValidator, SeaportValidatorHelper).
• Tests:
  • New Seaport 1.6 and Zone V3 unit/integration tests, helpers, and mocks under test/trading/seaport16/**.
• Tooling/CI:
  • Workflows: add Foundry install/forge steps; add Forge test job; dry-run publish compiles with Foundry.
  • Hardhat: add @nomicfoundation/hardhat-foundry, compiler 0.8.24 (Cancún), per-file overrides for seaport16.
• Deps/Remappings:
  • Add seaport 1.6 libs (seaport-16, seaport-core-16, seaport-types-16), Limit Break creator-token-standards; update remappings.txt, .gitmodules, DEPS.md, foundry.lock, and package.json.
  • .gitignore: add cache_hardhat and Foundry outputs.

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

[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.