Markets without invalid

[robert-e-davidson3]

There's an interest in removing invalid as an outcome. When a market would resolve as invalid, it would instead pay out equally to all outcomes.

This involves some core changes because right now there is no inherent notion of invalid: it's just outcomes, one of which wins. There are also some mixins that need to be updated, as well as the Sports market factories.

The Grouped market factory needs to be updated as well but that's in purgatory (not sure if we'll release it) so it can be excluded from this ticket's scope. The Crypto market factory doesn't use invalid so it needn't be updated.

This requires changes in a few places:

1. AbstractMarketFactoryV3.sol
   • The claimWinnings method needs to be rewritten. Probably just tack on an invalid-wins check at the start then follow an alternate code path that iterates over all outcomes to pay them out equally.
   • The Market struct needs to be changed to indicate that a market is resolved as invalid. Right now, having winner==0 means the market is not resolved. Without invalid as a separate outcome, there must be a way to indicate that a market is resolved without referring to an actual outcome token. This could be a flag or something like 0xF..F or 0x0..1. This impacts some methods:
     • isMarketResolved
     • endMarket
2. Mixins: remove everything related to invalid or No Contest:
   • Sport.sol
   • HasHeadToHeadMarket
   • HasSpreadMarket
   • HasOverUnderMarket
   • ResolvesByFiat (contract name and file name differ by a plural)
   • ResolvesByScore (same)
   • TokenNamesFromTeams
3. MarketFactories: remove everything related to invalid or No Contest:
   • NFLMarketFactoryV3
   • NBAMarketFactoryV3
   • MMAMarketFactoryV3
   • MLBMarketFactoryV3 There are other market factories like NCAAFB but they aren't being used so I've excluded them.

There are two broad approaches to take to changing the base code:

1. Copy-paste the AbstractMarketFactory and use the new one for the base of invalidless markets.
2. Split out the relevant code from the AbstractMarketFactory and make them into mixins.

Copy-paste is easier but creates more technical debt.

In either case, the UI will have issues if the contract names aren't changed. The naming scheme is a little hacky but a couple of rules should be sufficient:

• Market factory names are composed of three parts. Consider MMAMarketFactoryV3:
  1. MMA is the kind of markets it creates.
  2. MarketFactory indicates that this contract is a market factory.
  3. V3 is the API version. This comes from the base class AbstractMarketFactoryV3. The API version is relevant to the UI and many scripts.
• If market factories can have multiple base classes WITHOUT affecting the API then it makes sense to add another "channel" to the naming scheme. Perhaps something like MMAMarketFactoryEqV3, where Eq indicates that invalid markets will pay out Equally to all outcomes.

Subtasks:

• [ ] Contracts
• [ ] Deploy
• [ ] Tests
• [ ] Tasks. Can probably delete anything that isn't related to the canned markets since most tasks are now deprecated in favor of polygonscan and tenderly.
• [ ] UI

[bthaile]

UI changes to remove "No Contest"

Displaying market outcomes: UI already handles markets with only two outcomes. Crypto markets only have "Yes" and "No" outcomes. The files that process market data will need to change to remove all usages of NO_CONTEST... constants. Trading and add or remove liquidity UIs will adapt fine.

Resolving a market:

The market structure only allows for one winning outcome winner which is the outcomeId of the winning outcome. For convenience the market object has a flag hasWinner to indicate that the market has been resolved.

The winner property would need to be set to null and hasWinner set to true when the market has resolved without a winner. The fetcher contracts would need to indicate this non-winning resolution for the market. The packages/comps/src/utils/derived-market-data.ts file processes winner and sets hasWinner on the market object.

Claiming winnings:

claimableWinnings property on user object indicates if the user has any winnings that can be claimed. It's populated in populateClaimableWinnings method in contract-calls. This method would need to calculate the winnings based on user's outcome shares balance of the resolved market that has no winner.

After these changes the claim winnings buttons should appear in user's portfolio and allow them to claim winnings.