Introducing Prophet — Prediction Markets Based On Bonding Curves

Bonding curves seem to be a really productive tool for building DeFi protocols. Now, we have applied them to create prediction markets that are always available to trade, liquid, and make it very easy to provide liquidity and earn from trading fees.

Prophet allows making bets on outcomes of various future events, such as:

• sports: who wins an upcoming game;
• currencies/stocks/commodities: whether the price of a fiat currency, cryptocurrency, stock, or commodity will trade above a specific level on a future date;
• political events: who wins elections;
• economic statistics: whether inflation or GDP growth or unemployment or some other important economic measure will exceed a specific level on a specific date in the future;
• and many others.

By making the correct predictions, bettors make money. If a bettor’s prediction proves to be wrong, they lose their stake.

Betting on specific outcomes is one way of using Prophet. The other way is providing liquidity to prediction markets by betting on all outcomes. Liquidity providers (LPs) earn a share of fees paid by other bettors.

Tokens

To make bets, both bettors and LPs buy tokens that represent specific outcomes. For markets that have only two possible outcomes, there are two tokens:

• YES-token: the event will happen;
• NO-token: the event won’t happen.

To bet on the event, one buys YES-tokens. To bet against it, one buys NO-tokens.

In some sports markets, such as soccer, where draw is a possible outcome, there are 3 tokens:

• YES-token: team A wins (in a team A vs team B game);
• NO-token: team B wins;
• DRAW-token: the game ends with a draw.

Before the event date, each token has its price. After the event’s outcome becomes known, only one token (that represents the correct prediction) has value, all other tokens become worthless. The winning tokens can then be redeemed for the total money paid to buy all tokens, thus the winners divide among themselves the money paid by all the losing traders.

Earlier prediction markets platforms, such as Augur, issue only equal numbers of all token types and do so only when there are buyers for both YES and NO tokens (assuming two-token markets) at matching prices. This works well when there are many traders on the market. However, when there are few traders, liquidity is lacking, spreads are large, and trading conditions are unfavorable for those who just want to make a bet immediately. Like any two-sided market, it is difficult to bootstrap as buyers of YES tokens won’t come until there is a matching number of buyers of NO tokens, and buyers of NO tokens won’t come until there is a matching number of buyers of YES tokens. A catch-22 situation.

Prophet takes a different approach and uses bonding curves to price the tokens.

Bonding curves

We first used multi-dimensional bonding curves to build stablecoins v1. Later, we used a different family of bonding curves to build stablecoins v2. We found that they also fit well for prediction markets.

Bonding curves are mathematical formulas that link the total supplies of issued tokens to the total reserve committed to issuing them.

For prediction markets, a bonding curve would link the supplies of YES, NO, and optionally DRAW tokens to the total reserve staked in the prediction market.

We found that the following bonding curve works well for prediction markets:

where

• r is the total reserve (capital) invested in the prediction market;
• s_yes, s_no, and s_draw are the supplies of YES, NO, and DRAW tokens respectively;
• c is a coefficient that starts with 1 and gradually grows to account for the accrued fees.

We call it Pythagorean bonding curve thanks to its similarity to the famous Pythagorean theorem.

The bonding curve is implemented by an autonomous agent (AA) that issues the YES, NO, and DRAW tokens in exchange for the reserve currency. The AA acts as an automated market maker (AMM) that trades against users when they want to buy or sell tokens of any type.

Whenever a user wants to buy a certain number of tokens, they need to send the additional reserve to the AA that would ensure that the above equation holds true. It’s easy to calculate the required additional reserve: issuing more tokens of any type would increase the right-hand side of the above equation by some value, therefore the left-hand side (the reserve) should increase by the same amount, and they should send exactly this amount of the reserve currency.

The average price of the bought tokens (in terms of the reserve currency) would be the additional reserve spent for buying it divided by the number of tokens bought:

The current price of a token would be determined as the price of infinitesimally small purchases, which is a partial derivative by the token’s supply:

For our curve:

and similar formulas for NO and DRAW tokens.

It is easy to see from this formula that as more YES tokens are bought, their price increases. Also, as more NO and DRAW tokens are bought, the price of YES tokens decreases.

The total value of all YES tokens at the current prices is:

Its share of the total reserve is:

The sum of values of all tokens:

is exactly equal to the reserve, which means that the game is zero-sum — like betting is supposed to be.

It is not necessary to understand all the mathematical details but the main takeaway here is that bonding curves make it possible to buy tokens from the AA at all times (as well as sell them back to the AA), and the token prices automatically change in response to demand. Liquidity is always there — that’s the main difference from the earlier prediction markets platforms.

Trading on the bonding curve automatically stops on the date when the event is supposed to happen (e.g. a sports game begins) or somewhat earlier. As soon as the outcome of the event becomes known, holders of the winning tokens can claim their share of the total reserve while other tokens become worthless.

Fees and liquidity provision

When traders buy or sell tokens, they pay a fee. The paid fee gets added to the reserve and increases the total amount that would be divided between the winners after the outcome of the event becomes known.

To accommodate the fees, we use the coefficient c mentioned above.

After the fee gets added to the reserve, the left-hand side of the bonding curve equation increases while the supplies of the tokens on the right-hand side stay the same. To hold the equality, we have to increase the coefficient c accordingly. This moves us to another bonding curve, with a new c.

As c grows, so do all the token prices, according to the formulas above. In other words, the token prices incorporate the accumulated fees.

This makes every token holder a liquidity provider: their tokens appreciate thanks to the trading fees accumulated after the tokens were bought, and their capital improves the trading conditions for the subsequent traders as the price becomes less sensitive to the changes in token supplies, i.e. slippage reduces.

However, if the tokens are held up to the event date, only holders of the winning tokens get all the earnings from trading fees.

In order to minimize the risk and remove their dependence on the outcome, liquidity providers buy all the tokens in proportions that reflect the probabilities of the respective outcomes, i.e. the share of capital allocated to every token should be equal to the probability of that outcome. This way, they get a share of the trading fees every time, independently of the outcome.

To further reduce the risks, it is prudent to provide liquidity to multiple markets.

Another bonding curve: Robin Hanson’s LMSR

This is not the first time bonding curves are suggested for prediction markets.

Back in 2002, Robin Hanson, a well-known economist from George Mason University, proposed the following cost function (another name for bonding curve) for prediction markets:

where b is a parameter that determines the liquidity of the market (assuming only two outcomes — YES and NO — but easy to generalize to any number of outcomes). This cost function is called logarithmic market scoring rule — LMSR.

The prices of the tokens are then (partial derivatives):

have a nice property of summing up to 1:

and are equal to the probabilities that the market assigns to the respective outcomes. Our Pythagorean bonding curve does not have this property unfortunately.

LMSR was considered in the early versions of Augur, however the Augur team later decided in favor of orderbook exchange. Gnosis also used LMSR before pivoting away from prediction markets.

However, LMSR has one issue that made us search for a different bonding curve and choose the above-mentioned Pythagorean one. This issue also contributed to Augur and Gnosis abandoning LMSR.

The liquidity of LMSR markets depends on the choice of the b parameter above. Greater b values lend better liquidity. With smaller b values, even small trades cause large changes in the prices of tokens and it becomes impossible to place large bets. Does it mean that the larger b the better? No. Note that the initial reserve is non-zero when both YES and NO tokens have zero supplies:

and it is proportional to b. This is the liquidity that has to be provided by someone, probably the market creator, and it can be lost to bettors.

So, the market creator faces a difficult trade-off between creating an illiquid market and risking that the large initial liquidity will be lost while the fees generated from trades don’t cover the loss. Even if the market creator chooses b that they think is large, the demand might still exceed expectations and the liquidity won’t be sufficient again. Unfortunately, b has to be decided once when the market is created and cannot be increased in response to increasing demand. Therefore, to be profitable in LMSR prediction markets, one has to accurately predict market demand.

Also, all liquidity has to be contributed before the market is started, probably by a single liquidity provider, and again cannot be expanded in response to demand.

Thus, incentives to create liquid LMSR markets are problematic.

On top of that, the total value of all tokens is not exactly equal to the reserve, and the prices of the tokens never actually reach 0 or 1.

Our Pythagorean bonding curve doesn’t have any of these issues — liquidity can be added at any time by anybody and is never lost to bettors. Even bettors contribute to liquidity provision when they buy tokens.

Market types

Currently, soccer and currency markets are best supported, although it is possible to create markets about any future events.

The data for sports markets is provided by the sports oracle. Cryptocurrency prices oracle and precious metals prices oracle provide data for the currency markets. All 3 oracles are operated by well-known community members who have been running them for years. They are centralized, however using decentralized oracles built using Counterstake protocol is also possible.

One can add any market they like, and this market can use any of the existing oracles, a new oracle, or you can even be an oracle yourself by posting the outcome of the event from your Obyte wallet.

If there is interest in trading other event types, please let us know via discord.

Cross-chain trading

Similar to our cascading donations dapp Kivach, Prophet allows making bets and providing liquidity by sending funds from other networks such as Ethereum, BSC, and Polygon. So, even users without any funds on Obyte can participate.

The integration is seamless — users just need to select the token they would like to send, and the Counterstake SDK will take care of bridging it via Counterstake and swapping through Oswap.io if necessary.

The YES/NO tokens will be delivered to the user’s (new) Obyte wallet. If the user wins, they will claim the winnings to the same wallet and can participate in subsequent bets directly from Obyte.

Try it now

Prediction markets are live at prophet.ooo. If you don’t trust your prophetic abilities or you are simply not into betting, binary options, and trading, you can still participate by providing liquidity (just make sure the odds are realistic).

Check out the FAQ for more information not covered in this blog post.

If you have any ideas about improvements or further development of Prophet, please share them on discord.