by | Nov 10, 2021

What is an oracle?

When you’re trying to find out what an Oracle is, you probably get the following answer: a price oracle’s purpose is to maintain a balanced and healthy in-game economy.

This statement is rather broad and raises more questions about what is happening inside this black box.

Before you can understand the what and the why you need to know a few problems that games previously had experienced without this price oracle.

Problem 1. Popular games became unaffordable because of huge token pumps

To start playing a game, you often need a few tokens. Let’s say that you need 10 tokens worth a total of 10$ to mint an NFT before you can engage in play-to-earn. 

10$ is affordable for most people.

But once this game is becoming popular it will see a huge influx of new players. Since they all need to buy 10 tokens to get started, the token price of very popular games will inflate up to 100x.

Instead of 10$, you now need 1000$ to get started, a price that most people cannot afford.

The consequence is that player adoption decreases and the token economy starts breaking down as the market is dominated by sellers.

Problem 2. The income per player is highly skewed.

With P2E games, the ROI is typically 5% per day. So let’s say we bought 500 tokens for 500$, which is good for 25 tokens per day, we would make 25$ per day.

When the game goes 100x, we’d now make $2500 per day.

In any given game, there were dozens of people with an income like this.

The biggest whales were probably making around $10k per day.

The consequence is twofold:

1. Whales will want to cash their income, massively increasing sell pressure compared to buying pressure.

The buying pressure consists of new players buying tokens for probably something like $200 on average. So just to pay out one of the big whales, there need to be 50 new players coming in per day.

A solution to this was the possibility to compound. This means that whales can reinvest their tokens to get more income which would decrease sell pressure.

But compounding actually worsened the problem. The same whale continued scaling for maybe 2 weeks and after that was probably making $50k per day. And then the whale reached a point of selling again, because, well, at some point you just cash out.

2. The reward pool could run out. 

There is always a finite amount of tokens in the pool that gives out the P2E rewards. Popular games that never adjust the outflow of reward pool tokens will at some point deplete due to the high player base. 

If compounding is possible in the game, it can speed this up by an exponential factor, which is really scary.

But this is where the importance of a balanced economy comes in. If there are mechanisms in place that facilitate an inflow of tokens to the reward pool like tax and fees, this consequence can be mitigated.

So to recap the problems: 

  1. Price increase of token price compared to fiat will make some games unaffordable for new players at some point. This will reduce player adoption and buying pressure.
  2. The income per player is highly skewed and the selling activity of high-income players will overwhelm the buying pressure.

Now, the solution to this problem is simple.

  1. Somehow, new players should be able to afford to step in, even the toke price is really high.
  2. Income should either be limited or significantly reduced when token prices rise. 

This is where an oracle comes in.

Here’s my definition of an oracle.

An oracle in play-to-earn crypto games is a program that adjusts the in-game token flow based on certain statistics, like the dollar value of their reward token.

Until now, the oracle only adjusted the token flow based on the dollar value of the token. The oracle would change in-game rewards, minting prices, taxes, and fees according to price swings.

But an oracle could be implemented in many ways. Perhaps in the future, oracles will become much more complex.

Not every oracle is the same though as games typically tweak them a little.

I think Cryptoblades was the first play-to-earn game that used a program to influence token flow based on dollar value and I believe they also coined the term, but correct me if I’m wrong.

The Cryptoblades oracle was using a 7 or 30-day average. This lagging method was heavily complained about because it didn’t catch up with the volatility of the crypto market.

The Cryptomines oracle, therefore, tweaked it and almost pegged it to the dollar. People seem much happier with this real-time evaluation method and it also resulted in much more healthy growth.

Most of the games that used oracles after Cryptomines used a similar one as Cryptomines.

However, it must be noted that Cryptomines is still a very new game as it launched a few months ago so there’s still a lot of information lacking about this oracle implementation.

For starters, we don’t know how the economy will behave when token prices start to decrease as Cryptomines is still going up in price and seeing player adoption at the time of this video.

I do foresee a possible problem with a dollar-pegged oracle that arises when player adoption caps out and a downtrend is forming.

Until now, most games die over time as player adoption is not infinite. So at some point, selling pressure will overshadow buying pressure.

When prices start to decrease, you’ll start to see the opposite effect. People will get more tokens rewarded since the dollar price of the token is now decreasing.

People are very emotional beings, especially in negative situations, so I’d expect people to dump their tokens more often. 

The consequence is a negative feedback loop, where dumping results in people receiving more tokens, which will be dumped again, and so forth. 

But whether this theory holds is still to be seen. 

Price oracles are still very new, especially to the play-to-earn market. So I’m really curious to see how this concept will be tweaked over time.

Although it’s not the only solution to the problems discussed in the beginning, it seems to be working fine.

I would encourage everyone who’s developing a play-to-earn game to critically think about the token flow and perhaps implement something similar to an Oracle.