Skip to content

docs: clarify pre-155 tx requirement with EIP-155 reference #1382

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.

Sign up for GitHub

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

Open
nikolaysamoil0ff wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: clarify pre-155 tx requirement with EIP-155 reference #1382

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 1 addition & 1 deletion docs/Deployment.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ hidden: false

# Deploying Seaport

Seaport 1.6 and the ConduitController can each be deployed to their respective canonical deployment address on all EVM chains using the CREATE2 Factory. Note that a pre-155 transaction with a gas price of 100 gwei (or a manual workaround) is required as part of the deployment process (subsequent transactions can be submitted without these constraints), and that EVM equivalence (particularly consistent CREATE2 address derivation) is required in order to deploy to the canonical cross-chain deployment addresses.
Seaport 1.6 and the ConduitController can each be deployed to their respective canonical deployment address on all EVM chains using the CREATE2 Factory. Note that a pre-155 transaction (see [EIP-155](https://eips.ethereum.org/EIPS/eip-155)) with a gas price of 100 gwei (or a manual workaround) is required as part of the deployment process (subsequent transactions can be submitted without these constraints), and that EVM equivalence (particularly consistent CREATE2 address derivation) is required in order to deploy to the canonical cross-chain deployment addresses.

If you are deploying a fork of Seaport, it is *highly* advised that you **supply the canonical conduit controller** as its constructor argument; this allows the Seaport fork to use conduits that are fully interoperable with the canonical Seaport instance. (Better yet, deploy the canonical Seaport instance and use a distinct conduit if needed!)

Expand Down