Using Tokens for Parimutuel Wagers

This post describes an alternative implementation of parimutuel wagering to
my original post. This implementation will use ERC20 tokens to represent wagers.

Tokens for Outcomes

The original contract used a mapping to keep track of how much each account had wagered on each outcome. The new contract will delegate that bookkeeping to
mintable ERC20 token contracts
that represent the outcomes.

For each outcome, there will be a different token. To bet on an outcome, a bettor buys tokens representing that outcome from the parimutuel contract. These tokens are minted on demand. To claim their winnings once the bet is settled, a bettor sells tokens back to the parimutuel contract. These tokens are then burned.

Parameterization

The token-based parimutuel contract is very similar to the original. It’s parameterized in the same way, with descriptions of the proposition and outcomes. The constructor also accepts an array of “symbols” that are used for ERC20 tokens. The constructor’s significant difference is that it must deploy token contracts for each of the possible outcomes:

Claiming Winnings

Once a winning outcome has been declared, anyone can exchange winning tokens for ether. First, the token holder must approve a transfer of the tokens to the parimutuel contract. Then the bettor can call claim which burns the redeemed tokens so that they can never be redeemed again.

Other Functions

The other functions of the original contract (close, resolve, and cancel) are unchanged in this new contract.

Token Comparison

Using mintable ERC20 tokens provides one advantage over the previous contract—it allows wagers to be bought and sold without any needed support from the parimutuel contract itself. This is useful to people who would like to hedge their bets after the proposition has closed but before it has been resolved.

This token-based implementation has one disadvantage compared to the original—it limits the number of outcomes to the number of tokens that can be deployed by the constructor. The original contract could conceivably have supported 2256-1 different outcomes. (To avoid running out of gas, the outcomes array would have to be ignored.)