Docs improvements

docs/Code4rena-Guidelines.md

@@ -11,7 +11,7 @@ At a high level, the core invariants that we expect to be upheld are that:
 - Only items that are explicitly offered as part of a valid order may be transferred from an offerer’s account as long as they only set token approvals on either Seaport directly or on a conduit that only has Seaport set as a channel.
 - No order fulfillment may spend more than the offer items that are explicitly set for the order in question. Note that not all offer items need to be spent.
 - All consideration items (or fractions thereof in the case of orders that support partial fills) must be received in full by the named recipients in order for the corresponding offer items (or fractions thereof) to be spent. Note that additional consideration items may be added to any order on fulfillment as “tips”. Note also that when calling any fulfillment method other than `matchOrders` or `matchAdvancedOrders` that an implied “mirror” order is created for the fulfiller and so offer items on fulfilled orders should be treated as consideration items for the fulfiller (with the exception of `fulfillBasicOrder` where ERC721 ⇒ ERC20 and ERC1155 ⇒ ERC20 route types will use a portion of the offered item on the fulfilled order to pay out consideration items on that order).
-- In all cases, assume that that all items contain standard ERC20/721/1155 behavior. This may include popular tokens or contracts (though reporting particular tokens that would violate these invariants would be categorized as a low-severity finding).
+- In all cases, assume that all items contain standard ERC20/721/1155 behavior. This may include popular tokens or contracts (though reporting particular tokens that would violate these invariants would be categorized as a low-severity finding).
 
 ## Out of scope
 

docs/OrderValidator.md

@@ -39,7 +39,7 @@ The contract is deployed to the following addresses:
 Special thanks to:
 - [arr00](https://github.com/arr00), who deployed an earlier version of a SeaportValidator contract which can be found [here](https://etherscan.io/address/0xF75194740067D6E4000000003b350688DD770000#code)
 - [stephankmin](https://github.com/stephankmin), who extended the SeaportValidator contract to support more errors/warnings and arbitary Seaport instances with compatible versions
-- [horsefacts](https://github.com/horsefacts), who implemented support for a ready-only version of the helper contract
+- [horsefacts](https://github.com/horsefacts), who implemented support for a read-only version of the helper contract
 
 ## Errors and Warnings
 | Code | Issue | Type

docs/SeaportDocumentation.md

@@ -425,7 +425,7 @@ Note that orders created in the course of bulk order creation still need to be c
 
 A bulk signature is an EIP 712 type Merkle tree where the root is a `BulkOrder` and the leaves are `OrderComponents`.  Each level will be either a pair of orders or an order and an array.  Each level gets hashed up the tree until it’s all rolled up into a single hash, which gets signed.  The signature on the rolled up hash is the ECDSA signature referred to throughout.
 
-A marketplace can either use the signature in combination with the entire set of orders (to fulfill the entire set of orders) or enable the maker to iterate over each order, set the appropriate key, and compute the proof for each order.  Then, each proof gets appended onto the end of the ECDSA signature, which allows a fulfiller to target one or more specific orders from the bulk signature payload.  See below for more detail.
+A marketplace can either use the signature in combination with the entire set of orders (to fulfill the entire set of orders) or enable the maker to iterate over each order, set the appropriate key, and compute the proof for each order.  Then, each proof gets appended onto the end of the ECDSA signature, which allows a fulfiller to target one or more specific orders from the bulk signature payload.  See below for more details.
 
 Because of the Merkle tree structure of the bulk order payload and the limitations of EIP 712, each payload must contain exactly 2^N orders, where 1 ≤ N ≤ 24.  If the desired number of orders to sign for is not a permissible value, empty (and hence unfulfillable) orders must be provided to bring the total order count to an acceptable value (4, 8, 16, 32, etc.).  In other words, you can create any number of orders between 2 and 2^24, but the bulk signature payload needs to be padded with dummy orders.  The dummy orders need to be present and have the right “shape” to make the bulk signature payload play nicely with EIP 712, but they should have no other effect and they should not be actionable.  See [the `signSparseBulkOrder` function](https://github.com/ProjectOpenSea/seaport/blob/main/test/foundry/utils/EIP712MerkleTree.sol#L102-L180) in the Seaport Foundry tests, for an example of a bulk signature payload padded with empty orders.
 

docs/ZoneDocumentation.md

@@ -16,7 +16,7 @@ The `zone` of the order is an optional secondary account attached to the order w
 
 An example zone contract implementation can be found at `/contracts/zones/PausableZone.sol`.
 
-The `PausableZone` contract can be used by its controller to cancel orders, execute fulfillment on restricted order, and pause all orders which use it as a zone.
+The `PausableZone` contract can be used by its controller to cancel orders, execute fulfillment on restricted orders, and pause all orders which use it as a zone.
 
 ## Ideas