diff --git a/docs/SeaportDocumentation.md b/docs/SeaportDocumentation.md index be74c91d..11a652e2 100644 --- a/docs/SeaportDocumentation.md +++ b/docs/SeaportDocumentation.md @@ -24,7 +24,7 @@ Documentation around creating orders, fulfillment, and interacting with Seaport. Each order contains eleven key components: -- The `offerer` of the order supplies all offered items and must either fulfill the order personally (i.e. `msg.sender == offerer`) or approve the order via signature (either standard 65-byte EDCSA, 64-byte EIP-2098, or an EIP-1271 `isValidSignature` check) or by listing the order on-chain (i.e. calling `validate`). +- The `offerer` of the order supplies all offered items and must either fulfill the order personally (i.e. `msg.sender == offerer`) or approve the order via signature (either standard 65-byte ECDSA, 64-byte EIP-2098, or an EIP-1271 `isValidSignature` check) or by listing the order on-chain (i.e. calling `validate`). - The `zone` of the order is an optional secondary account attached to the order with two additional privileges: - The zone may cancel orders where it is named as the zone by calling `cancel`. (Note that offerers can also cancel their own orders, either individually or for all orders signed with their current counter at once by calling `incrementCounter`). - "Restricted" orders (as specified by the order type) must either be executed by the zone or the offerer, or must be approved as indicated by a call to `validateOrder` when the caller is not the zone. @@ -405,6 +405,13 @@ contract ExampleContractOfferer is ContractOffererInterface { } ``` +**Security Note** + +This `ExampleContractOfferer` is intentionally simplified and is **not** a secure +reference implementation. Production contract offerers must carefully consider +authorization logic, reentrancy risks, state consistency, and validation of all +external inputs. + Remember to create a [Seaport Improvement Protocol (SIP)](https://github.com/ProjectOpenSea/SIPs) proposal for any novel Seaport app. ## Bulk Order Creation