Skip to content

Add reference to frontrunning note #1381

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

Closed
stackoverflowed1 wants to merge 1 commit into from
Closed

Add reference to frontrunning note #1381

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/SeaportDocumentation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ While the standard method can technically be used for fulfilling any order, it s
- It requires the fulfiller to approve each consideration item, even if the consideration item can be fulfilled using an offer item (as is commonly the case when fulfilling an order that offers ERC20 items for an ERC721 or ERC1155 item and also includes consideration items with the same ERC20 item type for paying fees).
- It can result in unnecessary transfers, whereas in the "match" case those transfers can be reduced to a more minimal set.

> Note: Calls to Seaport that would fulfill or match a collection of advanced orders can be monitored and where there are unused offer items, it's possible for a third party to claim them. Anyone can monitor the mempool to find calls to `matchOrders` or `matchAdvancedOrders` without "ad-hoc" orders (where the offerer is the caller, hence does not require a signature) and calculate if there are any unused offer item amounts. If there are unused offer item amounts, the third party can frontrun the transaction and supply themselves as the recipient, thereby allowing that third party to claim the unused offer items for themselves. A Seaport app or a zone could prevent this, or the fulfiller can utilize a private mempool, but by default it's possible.
> Note: Calls to Seaport that would fulfill or match a collection of advanced orders can be monitored and where there are unused offer items, it's possible for a third party to claim them. Anyone can monitor the mempool to find calls to `matchOrders` or `matchAdvancedOrders` without "ad-hoc" orders (where the offerer is the caller, hence does not require a signature) and calculate if there are any unused offer item amounts. If there are unused offer item amounts, the third party can frontrun the transaction and supply themselves as the recipient, thereby allowing that third party to claim the unused offer items for themselves. A Seaport app or a zone could prevent this, or the fulfiller can utilize a private mempool ([e.g. Flashbots Protect](https://docs.flashbots.net/flashbots-protect/overview)), but by default it's possible.

> Note: Contract orders can supply additional offer amounts when the order is executed. However, if they supply extra offer items with criteria, on the fly, the fulfiller won't be able to supply the necessary criteria resolvers, which would make fulfilling the order infeasible. Seaport apps should specifically avoid returning criteria-based items and generally avoid mismatches between previewOrder and what's executed on-chain.

Expand Down