Seaport's canonical addresses and the versions it warns you off

One canonical address per version, shared by five chains

Deployment tables in the repository describe one address per contract version, reused on every chain they list. In the canonical cross-chain table, six Seaport versions, 1.1 through 1.6, sit alongside three auxiliary contracts: ConduitController, SeaportValidator and SeaportNavigator. The per-chain table then repeats the same 1.6 address for Ethereum, Sepolia, Polygon, Amoy and Optimism, so a single integration target covers all five networks:

Seaport 1.6
0x0000000000000068F116a894984e2DB1123eB395

ConduitController, SeaportValidator and SeaportNavigator sit at their own fixed addresses in both tables, which places them inside the deployment set rather than outside it as local tooling. What the tables do not give you is a deployment procedure or an upgrade path for any of those addresses, so a team that needs a private instance has nothing to copy and must work from the source under contracts/ instead. Check the address against a block explorer for the chain you target before sending anything, because one wrong character routes a trade to an address nobody controls.

Every listing is an offer paired with a consideration

Listing shape is the protocol's real design decision. An offerer names an arbitrary number of items they are willing to give, the offer, and an arbitrary number of items that must be received, each with its own receiver, the consideration. Because both sides are arrays rather than single fields, one order can swap a token for payment plus a second token routed to a different address without a second transaction.

Off-chain signing has to reproduce that structure exactly. At the top level, an eip-712-types/ directory sits beside a manifest that depends on ethers-eip712 and merkletreejs next to ethers. Typed data you sign and the order struct the contract checks are two halves of one object, and a mismatch between them ends as a failed fill rather than a warning. The README prints no worked example of either half. It points at docs/SeaportDocumentation.md, at ConsiderationInterface.sol inside the seaport-types repository, and at the interface documentation published under docs.opensea.io for the struct definitions.

The caution note covers versions the chain table drops

Three rows in the canonical table carry an asterisk: Seaport 1.2, 1.3 and 1.4. The note under that table says those versions contain known limitations and advises caution when interacting with them, particularly when using restricted or contract orders. Those two order types are where a limitation bites hardest, since both trade parts of the default safety checks for looser conditions.

Read the two tables against each other and they disagree in a sharper way. The per-chain table has no columns for 1.2, 1.3 or 1.4 at all; its columns are Seaport 1.6, Seaport 1.5, Seaport 1.1, ConduitController, SeaportValidator and SeaportNavigator. Deployments under caution are exactly the ones a chain-by-chain lookup will not hand you, while 1.1, which predates the flagged range, is carried in both tables. Treat the second table as a complete inventory and you would conclude 1.2 to 1.4 are unsupported rather than merely risky, which is wrong in both directions: integrations pinned to those versions need auditing, and a new build has no business starting there.

package.json main resolves to a Solidity source file

The published package is named seaport at version 1.6.0, and its main field points at a contract source rather than a JavaScript entry point:

"name": "seaport",
"version": "1.6.0",
"main": "contracts/Seaport.sol",
"license": "MIT",
"engines": {
  "node": ">=18.15.0"
}

The README still carries a badge labelled JS Library, so expecting to require the package and work in JavaScript is a fair assumption that the manifest then refuses. That reads as a statement of intent rather than a packaging bug: the protocol is consumed as a source file, an interface and a pinned set of helper packages.

The three internal dependencies sit at three different patch levels inside one 1.6 line, and that decides whether a clean rebuild reproduces the code you audited:

"seaport-core": "1.6.6",
"seaport-sol": "1.6.0",
"seaport-types": "1.6.3"

Exact versions, no caret, while every external dependency in the same manifest uses a range. A version bump of the umbrella package cannot reach a newer core without an edit to the manifest, and nothing in the tree automates that edit.

Foundry and Hardhat configs sit side by side

Two Solidity toolchains share one tree. A foundry.toml with lib/ and reference/ directories covers the Foundry side, while hardhat.config.ts and four further entry points cover the Hardhat side:

foundry.toml
hardhat.config.ts
hardhat-coverage.config.ts
hardhat-reference.config.ts
hardhat-reference-coverage.config.ts
hardhat-validator.config.ts

Each Hardhat variant is a separate config file rather than a flag on one file, so coverage runs, reference gas runs and validator runs are distinct invocations with their own settings. Gas is treated as a tracked artifact: .gas-snapshot and a .gas_reports/ directory sit at the top level, hardhat-gas-reporter is a dev dependency, and codecov.yml configures coverage output. That suits a team that cares about execution cost and contract size. It also means a contributor has to know which of the six configs produced the numbers they are comparing against.

The install commands the README promises are absent

Its table of contents promises Background, Deployments, Diagram, Docs, Install, Usage with Foundry Tests and Linting subsections, Audits and Contributing. The text breaks off inside the Optimism row of the per-chain table, so nothing from Install, Linting or Audits can be quoted or checked against it. There is no clone command, no package manager invocation and no Foundry test line in the published text. What the project does publish is the tree, the pinned manifest and the address list.

Concretely, the top level carries yarn.lock as its only lockfile, a .nvmrc whose value is never quoted, plus .npmignore and .npmrc. Companion repositories named in the README are seaport-core, seaport-sol and seaport-types, and the split is described as being for easier use and integration, so a team can depend on one piece instead of the whole protocol:

seaport-core
seaport-sol
seaport-types

A first real integration therefore starts at an address rather than at a package. Point the client at the canonical 1.6 deployment, take the struct shapes from ConsiderationInterface.sol in the types repository, and check the address against a block explorer before the first signature is produced.

Three split repositories or the umbrella package

The alternative to depending on seaport is depending on one of the three repositories it was split from, and the choice changes your supply chain rather than your convenience. seaport-core, seaport-sol and seaport-types carry 1.6.6, 1.6.0 and 1.6.3 inside the same 1.6 line, so taking one of them decouples that piece from the update pace of the other two. The types repository is the reference the README links for ConsiderationInterface.sol, so an integrator reading Solidity alone is reading a definition that moves independently of the contract itself.

Forking the umbrella repository gives you the opposite property: the manifest freezes every helper version you will build against, and an upgrade becomes a deliberate edit of three lines instead of a registry resolution. Neither route has a documented upgrade flow anywhere in the README, so both freeze your inputs at whatever the pins said on the day you copied them. A fix landing in a helper package reaches you only when you edit those pins, which is the single maintenance task this repository imposes on every fork that keeps its own deployments.

Upgrade cost shows up in gas snapshots and pins

Two facts bound the decision. The last push to main was on 2026-09-01, so the Solidity in the tree is current even though the newest deployment in the tables is still 1.6. The package.json declares MIT and a LICENSE file sits at the repository root, so a fork can carry modifications as long as the notice stays in place; the licence reaches this source, not the assets moving through a live instance.

The upgrade cost is measured in gas. With .gas-snapshot, a .gas_reports/ directory and hardhat-gas-reporter in the tree, a fork inherits a baseline to compare against, and reference/ exists to hold the version a measurement came from. No rollback procedure is documented in the README, so the pattern the project has used so far is the safer one: every listed version owns a different canonical address, which means a live marketplace upgrades by pointing clients at a new number rather than by replacing code under an address that already holds state.

Editorial conclusion

Seaport fits teams that want one marketplace address to integrate against across five EVM chains and that accept Solidity as the integration surface rather than a JavaScript library. It does not fit teams needing a private deployment procedure, a rollback path or an upgrade guide, because the README documents none of the three. Before adopting, check which version your integration targets against the caution note covering 1.2 through 1.4, and confirm the canonical address on a block explorer for the chain you use.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ProjectOpenSea/seaport on GitHub
4. README
5. Releases