From e6b92e43e2fb4a7ab2e4df8b243ffd6cd4bf0810 Mon Sep 17 00:00:00 2001 From: itsasecret <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 30 Jan 2025 15:44:37 +0200 Subject: [PATCH 1/5] Update AssetOperations.md --- docs/mixins/AssetOperations.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/mixins/AssetOperations.md b/docs/mixins/AssetOperations.md index 29ec6a0..b4d4c97 100644 --- a/docs/mixins/AssetOperations.md +++ b/docs/mixins/AssetOperations.md @@ -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 +``` From 1d108f598c41d43aff43199c43b15b4c43ed6d9d Mon Sep 17 00:00:00 2001 From: itsasecret <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 30 Jan 2025 15:47:45 +0200 Subject: [PATCH 2/5] Update ProxyFactoryHelper.md --- docs/mixins/ProxyFactoryHelper.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/mixins/ProxyFactoryHelper.md b/docs/mixins/ProxyFactoryHelper.md index fe39a70..d25b4b6 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 transactions 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. ## `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)` From b3d2268a6cd20d2afc7d191ae2b855acadae193d Mon Sep 17 00:00:00 2001 From: itsasecret <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 30 Jan 2025 15:49:50 +0200 Subject: [PATCH 3/5] Update Trading.md --- docs/mixins/Trading.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/mixins/Trading.md b/docs/mixins/Trading.md index 4841c8b..61666e9 100644 --- a/docs/mixins/Trading.md +++ b/docs/mixins/Trading.md @@ -6,7 +6,7 @@ Trading implements the core exchange logic for trading CTF assets. ## `getOrderStatus` -Get the status of an order. An order can either be not-filled, partially filled or fully filled. If an order has not been filled, its hash will not exist in the `orderStatus` mapping. If it has been partially filled its hash will exist in this mapping and the maker amount `remaining` will be defined. If the order has been fully filled the hash will exist and the `isCompleted` bool in the `OrderStatus` object will be `true` +Get the status of an order. An order can either be not filled, partially filled or fully filled. If an order has not been filled, its hash will not exist in the `orderStatus` mapping. If it has been partially filled its hash will exist in this mapping and the maker amount `remaining` will be defined. If the order has been fully filled the hash will exist and the `isCompleted` bool in the `OrderStatus` object will be `true` Parameters: @@ -32,12 +32,12 @@ Order order // order to be validated ## `cancelOrder` -Cancels an order. Calls `_cancelOrder` with the order. An order can only be cancelled by its maker, the address which holds funds for the order. +Cancels an order. Calls `_cancelOrder` with the order. An order can only be canceled by its maker, the address which holds funds for the order. Parameters: ```java -Order order // order to be cancelled +Order order // order to be canceled ``` ## `cancelOrders` @@ -328,4 +328,4 @@ Returns: ```java uint256 // amount of tokenId in contract -``` \ No newline at end of file +``` From df9ea9eb8ab893d2932f52109d2e221ea8b4382a Mon Sep 17 00:00:00 2001 From: itsasecret <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 30 Jan 2025 16:04:04 +0200 Subject: [PATCH 4/5] Update Overview.md --- docs/Overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Overview.md b/docs/Overview.md index b154af4..68c03c6 100644 --- a/docs/Overview.md +++ b/docs/Overview.md @@ -2,7 +2,7 @@ ## Overview -The `CTFExchange` contract facilitates atomic swaps between binary outcome tokens (ERC1155) and the collateral asset (ERC20). It is intended to be used in a hybrid-decentralized exchange model wherein there is an operator that provides matching/ordering/execution services while settlement happens on-chain,non-custodially according to instructions in the form of signed order messages. The CTF exchange allows for matching operations that include a mint/merge operation which allows orders for complementary outcome tokens to be crossed. Orders are represented as signed typed structured data (EIP712). Additionally, the CTFExchange implements symmetric fees. When orders are matched, one side is considered the maker and the other side is considered the taker. The relationship is always either one to one or many to one (maker to taker) and any price improvement is captured by the taking agent. +The `CTFExchange` contract facilitates atomic swaps between binary outcome tokens (ERC1155) and the collateral asset (ERC20). It is intended to be used in a hybrid-decentralized exchange model wherein there is an operator that provides matching/ordering/execution services while settlement happens on-chain, non-custodial according to instructions in the form of signed order messages. The CTF exchange allows for matching operations that include a mint/merge operation which allows orders for complementary outcome tokens to be crossed. Orders are represented as signed typed structured data (EIP712). Additionally, the CTFExchange implements symmetric fees. When orders are matched, one side is considered the maker and the other side is considered the taker. The relationship is always either one to one or many to one (maker to taker) and any price improvement is captured by the taking agent. ## Matching Scenarios From f1507fe0e8f715377d2944f1fd970fdafe671f6d Mon Sep 17 00:00:00 2001 From: itsasecret <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 30 Jan 2025 16:05:34 +0200 Subject: [PATCH 5/5] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f94d6d8..bfcc3bf 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ The Polymarket CTF Exchange is an exchange protocol that facilitates atomic swaps between [Conditional Tokens Framework(CTF)](https://docs.gnosis.io/conditionaltokens/) ERC1155 assets and an ERC20 collateral asset. -It is intended to be used in a hybrid-decentralized exchange model wherein there is an operator that provides offchain matching services while settlement happens on-chain, non-custodially. +It is intended to be used in a hybrid-decentralized exchange model wherein there is an operator that provides offchain matching services while settlement happens on-chain, non-custodial. ## Documentation