diff --git a/docs/mixins/AssetOperations.md b/docs/mixins/AssetOperations.md index 29ec6a0..b4378bd 100644 --- a/docs/mixins/AssetOperations.md +++ b/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. -``` \ No newline at end of file +``` diff --git a/docs/mixins/Assets.md b/docs/mixins/Assets.md index 1f48d9d..4bdae13 100644 --- a/docs/mixins/Assets.md +++ b/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 -``` \ No newline at end of file +``` diff --git a/docs/mixins/NonceManager.md b/docs/mixins/NonceManager.md index 105269d..fca1851 100644 --- a/docs/mixins/NonceManager.md +++ b/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 -``` \ No newline at end of file +``` diff --git a/docs/mixins/Pausable.md b/docs/mixins/Pausable.md index 2133866..7eb6d56 100644 --- a/docs/mixins/Pausable.md +++ b/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` diff --git a/docs/mixins/ProxyFactoryHelper.md b/docs/mixins/ProxyFactoryHelper.md index fe39a70..7199ed6 100644 --- a/docs/mixins/ProxyFactoryHelper.md +++ b/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)` \ No newline at end of file +- `SafeFactoryUpdated(safeFactory, _safeFactory)` diff --git a/docs/mixins/Registry.md b/docs/mixins/Registry.md index 6299b42..a40e99c 100644 --- a/docs/mixins/Registry.md +++ b/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` diff --git a/docs/mixins/Signatures.md b/docs/mixins/Signatures.md index 8464a53..624cb27 100644 --- a/docs/mixins/Signatures.md +++ b/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 -``` \ No newline at end of file +```