-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #22 from Polymarket/fix/misc
FIX MISC
- Loading branch information
Showing
2 changed files
with
13 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,16 +1,25 @@ | ||
# Polymarket Multi-Outcome Markets | ||
|
||
The contracts in this repository are designed to unify mutually exclusive binary markets into a single multi-outcome market structure. By mutually exclusive binary markets, we mean a set of binary YES/NO of which one and only one will resolve true. The canonical example is a set of markets each representing a candidate in a particular political election, where only one can win. Each component binary market is a YES/NO market for a particular candidate. The fact that only one candidate can win guarantees that there are certain equivalancies amongst certain sets of positions. | ||
The contracts in this repository are designed to unify mutually exclusive binary markets into a single multi-outcome market structure. By mutually exclusive binary markets, we mean a set of binary YES/NO markets of which one and only one will resolve true. The canonical example is a set of markets each representing a candidate in a particular political election, where only one can win. Each component binary market is a YES/NO market for a particular candidate. The fact that only one candidate can win guarantees that there are certain equivalancies amongst certain sets of positions. | ||
|
||
As an example, consider an election with candidates A, B, and C. For each candidate there is a binary YES/NO market, and exactly one candidate will win, i.e., exactly one market will resolve YES, and the rest NO. Consider a position consisting of 1 NO A and 1 NO B. | ||
If A wins, the position is worth 1 USDC. If B wins, the position is again worth 1 USDC. If C wins, the position is worth 2 USDC, as both NO tokens are redeemable for 1 USDC each. We can see that the position is equivalent to 1 USDC and 1 YES C, as the value of the two positions is equal in all three cases. The NegRiskAdapter is designed precisely to allow a position of 1 or more NO tokens to be converted to the equivalent position of YES tokens plus some amount of USDC. | ||
|
||
The underlying binary markets are implemented using Gnosis’s Conditional Tokens contracts: https://github.com/gnosis/conditional-tokens-contracts. Once collateral is split into position tokens, there are only two ways to recover it, either by merging complete sets, or by redeeming positions after resolution. So, in order to allow USDC to be released as part of a conversion from a NO position to a YES position, we wrap USDC into WrappedCollateral, which is then used to collateralize all underlying markets. This enables the NegRiskAdapter to manage USDC separately from the ConditionalTokens contract. | ||
The underlying binary markets are implemented using Gnosis’s [Conditional Tokens contracts](https://github.com/gnosis/conditional-tokens-contracts). Once collateral is split into position tokens, there are only two ways to recover it, either by merging complete sets, or by redeeming positions after resolution. So, in order to allow USDC to be released as part of a conversion from a NO position to a YES position, we wrap USDC into WrappedCollateral, which is then used to collateralize all underlying markets. This enables the NegRiskAdapter to manage USDC separately from the ConditionalTokens contract. | ||
|
||
The NegRiskOperator is designed to allow admin accounts to prepare questions and markets, as well as to integrate with resolution sources. | ||
|
||
The Vault holds USDC and Yes tokens which are collected as fees from users who choose to convert NO positions, given a positive fee rate. | ||
|
||
## Use with the UmaCtfAdapter | ||
|
||
The NegRiskOperator and NegRiskAdapter are designed to be used with the [UmaCtfAdapter](https://github.com/Polymarket/uma-ctf-adapter), or any oracle with the same interface. | ||
A dedicated UmaCtfAdapter will need to be deployed with the UmaCtfAdapter's `ctf` set to the address of the NegRiskAdapter, and the NegRiskOperator's `oracle` set to the address of the UmaCtfAdapter. | ||
|
||
In order to prepare a question for a market using the NegRiskOperator, the question must be initialized on the UmaCtfAdapter first. Then, the question may be prepared on the NegRiskOperator where the `_requestId` parameter is the `questionID` returned by the UmaCtfAdapter. | ||
|
||
Note that the UmaCtfAdapter can return `[1,1]` as a possible outcome, which is not a valid outcome for the NegRiskAdapter. The NegRiskAdapter will revert if it receives this outcome. It is important that markets/questions are chosen carefully so that this outcome is not possible. | ||
|
||
## Questions | ||
|
||
It is vital that markets prepared on the NegRiskAdapter never result in a tie or will be unable to be determined. For any given market, once one question is resolved as Yes/True, all other questions must be resolved as No/False. This means that if the chosen oracle returns a second question as Yes/True, the call to `reportOutcome` will revert, and the market may not be able to fully resolved. Similarly, it is expected that one question will resolve to Yes/True, and it should not be the case that all questions for a given market resolve to No/False. Keep this in mind when preparing markets and questions on the NegRiskAdapter. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters