Small fixes

docs/mixins/AssetOperations.md

@@ -45,7 +45,7 @@ uint256 value // amount of ERC20 tokens to transfer
 
 ## `_mint`
 
-Mints a full conditional token set from collateral by calling the `splitPostion` function ont he ctf contract with the provided `conditionId`. This will convert X units of collateral (ERC20) into X units of complementary outcome tokens (ERC1155). The zeroed bytes32 is used as the `parentCollectionId` and the partition is the simple binary case [1,2]. You can read more about Gnosis Conditional Tokens [here](https://docs.gnosis.io/conditionaltokens/docs/devguide01/).
+Mints a full conditional token set from collateral by calling the `splitPostion` function on the ctf contract with the provided `conditionId`. This will convert X units of collateral (ERC20) into X units of complementary outcome tokens (ERC1155). The zeroed bytes32 is used as the `parentCollectionId` and the partition is the simple binary case [1,2]. You can read more about Gnosis Conditional Tokens [here](https://docs.gnosis.io/conditionaltokens/docs/devguide01/).
 
 Parameters:
 
@@ -57,11 +57,11 @@ uint256 amount // quantity of collateral to split. Note the collateral and minte
 
 ## `_merge`
 
-Opposite of `_mint`. Takes complete sets (equal parts of two complementary outcome tokens) and merges (burns) them by calling the `mergePositions` function on the ctf contract with the provided `conditionId`. Specifically this will convert X complete sets (X of token A (ERC1155) and X of its its complement token A' (ERC1155)) into X units of collateral (ERC20). This function assumes merging happens on a binary set and for the zeroed bytes32 `parentCollectionId`. You can read more about Gnosis Conditional Tokens [here](https://docs.gnosis.io/conditionaltokens/docs/devguide01/).
+Opposite of `_mint`. Takes complete sets (equal parts of two complementary outcome tokens) and merges (burns) them by calling the `mergePositions` function on the ctf contract with the provided `conditionId`. Specifically this will convert X complete sets (X of token A (ERC1155) and X of its complement token A' (ERC1155)) into X units of collateral (ERC20). This function assumes merging happens on a binary set and for the zeroed bytes32 `parentCollectionId`. You can read more about Gnosis Conditional Tokens [here](https://docs.gnosis.io/conditionaltokens/docs/devguide01/).
 
 Parameters:
 
 ```java
 bytes32 conditionId // id of condition on which to merge
 uint256 amount // quantity of complete sets to burn for their underlying collateral.
-```
+```

docs/mixins/Assets.md

@@ -4,7 +4,7 @@ Stores the addresses of the ERC20 collateral and ERC155 outcome tokens.
 
 ## `constructor`
 
-Initializes the contract, setting the collateral token address and ctf token address state variables. Also approves the ctf contract to spend usdc on the contract's behalf.
+Initializes the contract, setting the collateral token address and ctf token address state variables. Also approves the ctf contract to spend USDC on the contract's behalf.
 
 Parameters:
 
@@ -31,4 +31,4 @@ Returns:
 
 ```java
 address // ctf address
-```
+```

docs/mixins/NonceManager.md

@@ -5,7 +5,7 @@ The nonce manager is a mixin responsible for maintaining a mapping of account no
 
 ## `incrementNonce`
 
-Increments (by 1) an account's nonce. `msg.sender` is used to determine the account of which to increment the nonce for. 
+Increments (by 1) an account's nonce. `msg.sender` is used to determine the account for which to increment the nonce. 
 
 ## `updateNonce`
 
@@ -32,4 +32,4 @@ Returns:
 
 ```java
 bool // indicates whether a supplied nonce matches the user's nonce as stored in nonces mapping
-```
+```

docs/mixins/Pausable.md

@@ -4,7 +4,7 @@ Used to provide a trading "kill switch". Specifically, the primary entry points
 
 ## `notPaused`
 
-Modifier that reverts in the case that the state variable `paused` is `true` (`bool`). Otherwise, execution of modified function continues without disruption.
+Modifier that reverts in the case that the state variable `paused` is `true` (`bool`). Otherwise, execution of the modified function continues without disruption.
 
 ## `_pauseTrading`
 

docs/mixins/ProxyFactoryHelper.md

@@ -1,6 +1,6 @@
 # ProxyFactoryHelper
 
-`PolyFactoryHelper` manages referenced proxy wallet factory addresses and provides wrappers around functions contained in both `PolySafeLib` and `PolyProxyLib` which calculate wallet addresses given the "owning" or "signing" EOA addresses of the proxy wallets. The `CTFExchange` supports two signature types related to contract wallets. Users of Polymarket's interface trade from contract wallets. Originally, these wallets were a custom implementation, but later, Gnosis safes were used. In order to maintain backwards compatibility, both types are supported by the `CTFExchange`. In both cases, the EOA that deploys/creates the proxy wallet is the approved "owner" of that wallet. This means that they are able to sign/execute transaction on the behalf of the contract. User's funds live in these proxy wallets, thus in order to support off-chain order signing (EOAs), the `CTFExchange` must be able to relate a signer to a corresponding wallet address. This contract along with the supporting library functions allow exactly that. 
+`PolyFactoryHelper` manages referenced proxy wallet factory addresses and provides wrappers around functions contained in both `PolySafeLib` and `PolyProxyLib` which calculate wallet addresses given the "owning" or "signing" EOA addresses of the proxy wallets. The `CTFExchange` supports two signature types related to contract wallets. Users of Polymarket's interface trade from contract wallets. Originally, these wallets were a custom implementation, but later, Gnosis safes were used. In order to maintain backwards compatibility, both types are supported by the `CTFExchange`. In both cases, the EOA that deploys/creates the proxy wallet is the approved "owner" of that wallet. This means that they are able to sign/execute transaction on behalf of the contract. User's funds live in these proxy wallets, thus in order to support off-chain order signing (EOAs), the `CTFExchange` must be able to relate a signer to a corresponding wallet address. This contract along with the supporting library functions allow exactly that. 
 
 ## `constructor`
 
@@ -112,4 +112,4 @@ Internal function to set the `safeFactory` address.
 
 Emits:
 
-- `SafeFactoryUpdated(safeFactory, _safeFactory)`
+- `SafeFactoryUpdated(safeFactory, _safeFactory)`

docs/mixins/Registry.md

@@ -1,6 +1,6 @@
 # Registry
 
-The `CTFExchange` supports "binary matching". This assumes that two complementary tokens are always worth, in sum, 1 unit of underlying collateral. This is enforced by the CTF contract which always allows minting and merging of full sets (complete collection of outcomes, in our case `A` and its binary complement `A'`). What this ultimately unlocks for the `CTFExchange` is matching between buy orders of `A` and `A'` (via a preceeding "mint" operation), and sell orders of `A` and `A'` (via a succeeding "merge" operation). The `CTFExchange` gets orders to match and is able to determine whether or not a "mint" or "merge" operation is ncessary. The challenge, is that the "mint"/"merge" operation requires knowing the order's base asset's (conditional token) corresponding `conditionId`. Thus, there needs to be a way for the `conditionId` to be gotten from the `tokenId`. The `Registry` is responsible for this function and maintains a mapping of `tokenId`s to `OutcomeToken` objects which include information relating to the specific `tokenId` including the `complement`'s `tokenId`, and the parent `conditionId`. It is the responsibility of operators to register new outcome tokens. Note all methods assume benevolent input by the operator, specifically that they are registering the correct tokenIds/complements/conditions and that they are all binary outcomes that are valid in the context of the CTF contract.
+The `CTFExchange` supports "binary matching". This assumes that two complementary tokens are always worth, in sum, 1 unit of underlying collateral. This is enforced by the CTF contract which always allows minting and merging of full sets (complete collection of outcomes, in our case `A` and its binary complement `A'`). What this ultimately unlocks for the `CTFExchange` is matching between buy orders of `A` and `A'` (via a preceeding "mint" operation), and sell orders of `A` and `A'` (via a succeeding "merge" operation). The `CTFExchange` gets orders to match and is able to determine whether or not a "mint" or "merge" operation is necessary. The challenge, is that the "mint"/"merge" operation requires knowing the order's base asset's (conditional token) corresponding `conditionId`. Thus, there needs to be a way for the `conditionId` to be gotten from the `tokenId`. The `Registry` is responsible for this function and maintains a mapping of `tokenId`s to `OutcomeToken` objects which include information relating to the specific `tokenId` including the `complement`'s `tokenId`, and the parent `conditionId`. It is the responsibility of operators to register new outcome tokens. Note all methods assume benevolent input by the operator, specifically that they are registering the correct tokenIds/complements/conditions and that they are all binary outcomes that are valid in the context of the CTF contract.
 
 
 ## `getConditionId`

docs/mixins/Signatures.md

@@ -16,7 +16,7 @@ Parameters:
 
 ```java
 bytes32 orderHash // the has of the order
-Order order // the order which includes the signature
+Order// the order which includes the signature
 ```
 
 ## `isValidSignature`
@@ -115,4 +115,4 @@ Returns:
 
 ```java
 SignatureType // SignatureType enum value of index
-```
+```