Small fixes

SIPS/sip-1.md

@@ -21,7 +21,7 @@ For Seaport implementers, SIPs are a convenient way to track the progress of the
 
 There are three types of SIP:
 
-- A **Standards Track SIP** describes any change that affects most or all Seaport implementations, such as—a change to the protocol, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Seaport. Standards Track SIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the Seaport codebase. Furthermore, Standards Track SIPs can be broken down into the following categories:
+- A **Standards Track SIP** describes any change that affects most or all Seaport implementations, such as a change to the protocol, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Seaport. Standards Track SIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the Seaport codebase. Furthermore, Standards Track SIPs can be broken down into the following categories:
 
   - **Core**: improvements requiring a version upgrade, as well as changes that are not necessarily critical but may be relevant to “core dev” discussions.
   - **Networking**: includes improvements around [the P2P specification](./sip-4.md), as well as proposed improvements to network protocol specifications.
@@ -30,7 +30,7 @@ There are three types of SIP:
 
 - A **Meta SIP** describes a process surrounding Seaport or proposes a change to (or an event in) a process. Process SIPs are like Standards Track SIPs but apply to areas other than the Seaport protocol itself. They may propose an implementation, but not to Seaport's codebase; they often require community consensus; unlike Informational SIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Seaport development. Any meta-SIP is also considered a Process SIP.
 
-- An **Informational SIP** describes an Seaport design issue, or provides general guidelines or information to the Seaport community, but does not propose a new feature. Informational SIPs do not necessarily represent Seaport community consensus or a recommendation, so users and implementers are free to ignore Informational SIPs or follow their advice.
+- An **Informational SIP** describes a Seaport design issue, or provides general guidelines or information to the Seaport community, but does not propose a new feature. Informational SIPs do not necessarily represent Seaport community consensus or a recommendation, so users and implementers are free to ignore Informational SIPs or follow their advice.
 
 It is highly recommended that a single SIP contain a single key proposal or new idea. The more focused the SIP, the more successful it tends to be. A change to one client doesn't require a SIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.
 

SIPS/sip-10.md

@@ -15,7 +15,7 @@ _This document is currently WIP. Please suggest improvements or changes in the d
 
 ## Abstract
 
-This SIP outlines an interface for NFTs to serve as contract offerers. These NFTs then provide orders that unlock transferability of specified tokens for the duration of the Seaport fulfillment. This allows these contracts to declare consideration items based on the tokens being transfered, and Seaport will ensure that those items are transferred to the named recipients. In short, Seaport acts similarly to an "embedded" marketplace for the implementing NFTs. This interface is proposed as a SIP to ensure fulfillers can follow a standard procedure for interacting with Seaport-extended NFTs, either for primary sales, secondary sales, or both.
+This SIP outlines an interface for NFTs to serve as contract offerers. These NFTs then provide orders that unlock transferability of specified tokens for the duration of the Seaport fulfillment. This allows these contracts to declare consideration items based on the tokens being transferred, and Seaport will ensure that those items are transferred to the named recipients. In short, Seaport acts similarly to an "embedded" marketplace for the implementing NFTs. This interface is proposed as a SIP to ensure fulfillers can follow a standard procedure for interacting with Seaport-extended NFTs, either for primary sales, secondary sales, or both.
 
 ## Motivation
 

SIPS/sip-14.md

@@ -190,7 +190,7 @@ The metadata URI MUST conform to the below JSON schema:
     },
     "maxRedemptionsPerToken": {
       "type": "string",
-      "description": "The maximum number of redemptions per token. When isBurn is true should be 1, else can be a number based on the trait redemptions limit."
+      "description": "The maximum number of redemptions per token. When isBurn is true should be 1, else can be a number based on the trait redemption limit."
     },
     "isBurn": {
       "type": "string",

SIPS/sip-3.md

@@ -28,7 +28,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 Permissible origins **MUST** provide a method of uniquely identifying a particular revision of a resource. Examples of such methods may include git commit hashes, version numbers, or publication dates.
 
-Permissible origins **MUST** have a proven history of availability. A origin existing for at least ten years and reliably serving resources would be sufficient—but not necessary—to satisfy this requirement.
+Permissible origins **MUST** have a proven history of availability. An origin existing for at least ten years and reliably serving resources would be sufficient—but not necessary—to satisfy this requirement.
 
 Permissible origins **MUST NOT** charge a fee for accessing resources.
 

SIPS/sip-4.md

@@ -19,7 +19,7 @@ This document is designed to formalize a peer-to-peer specification for sharing
 
 ## Motivation
 
-Since Seaport orders are stored off chain to reduce the cost of listing, this P2P specification helps for participants in the Seaport ecosystem to share orders with each other to increase discoverability and liquidity.
+Since Seaport orders are stored offchain to reduce the cost of listing, this P2P specification helps for participants in the Seaport ecosystem to share orders with each other to increase discoverability and liquidity.
 
 ## Specification
 

SIPS/sip-6.md

@@ -51,7 +51,7 @@ Zones and contract offerers MUST decode relevant data arrays based on the order
 
 By way of example, if a zone implements SIP-X, SIP-Y, and SIP-Z and returns schema IDs in the same order when calling `getSeaportMetadata()`, and each SIP requires a single variable data array, then the zone will accept version 0x03, rejecting any other versions, and will decode the first element (index 0) in the array of variable data arrays as the variable data array for SIP-X, the second element (index 1) as the variable data array for SIP-Y, and the third element (index 2) as the variable data array for SIP-Z.
 
-When a contract is both a zone and a contract offerer, and implements both zone-specific SIPs and contract-order-specific SIPS, extraData construction MUST be based on the current context. In other words, if the contract is being interacted with as a zone, then contract-order-specific SIPs are to be disregarded; alternately, when the contract is being interacted with as a contract offerer, then zone-specific SIPs are to be disregarded.
+When a contract is both a zone and a contract offerer, and implements both zone-specific SIPs and contract-order-specific SIPS, extraData construction MUST be based on the current context. In other words, if the contract is being interacted with as a zone, then contract-order-specific SIPs are to be disregarded; alternatively, when the contract is being interacted with as a contract offerer, then zone-specific SIPs are to be disregarded.
 
 New version bytes MUST be added in new SIPs that require SIP-6.