The Problem With Dublup.io
dublup.io released over a month ago when I tried the platform making an initial User Experience Review on it never to return after. As someone who is looking to make predictions/bets on something knowing for sure in advance what odds I'm getting or be the house allowing others to gamble potentially making a profit on that it simply falls short.
The price of PAL pumped on the announcement and release but came all the way down again. There are some events available for predictions but even if you want to take a gamble, you will be most times end up with a lose a lot win a little proposition regardless of the risk. Here is an example of the event with 2nd most liquidity...
Basically, if you right now would bet on YES and BTC trades above 50k before June 30th, a lot more money will come in just before the market closes completely slashing your odds. If it trades below you lose your entire stake. The entire system is just really weird and can be improved upon tremendously.
Prediction Market Model Improvement
I'm by no means an expert in this so take everything I write down here with a big grain of salt just as someone who brainstorms some ideas.
So a proper prediction market needs (1) events to be created properly, (2) liquidity to be provided for those who want to bet, and (3) an oracle model which settles the results in a proper way. All this in a decentralized way with the people doing the creation/liquidity/oracle work getting some kind of reward for their work.
1. Event Creation
I like event creator on dublup.io as it limits the options to what oracles can easily verify while also offering a wide variety of options and customization.
Last time I checked, a fee of 100 PAL needed to be paid to create a market just so the platform isn't flooded with a ton of predictions nobody is really betting on for the oracles to put work into. The problem here is that is unlikely for those who create a market to recover that 100 PAL cost making it very unrewarding overall.
A solution could be to work with staked coins and resource credits where it costs a certain amount to create a market that replenishes over time. A creation fee can be attached to it which goes into a pool that flows back to those who created markets (and possibly the oracles) based on the total volume they processed. So the ones that create markets that are very popular get more back compared to what they put in while those that create niche markets that have less interest pay a small fee for doing so.
2. Liquidity Providing
This by far is the biggest problem for dublup.io since it is impossible to know what odds you will get in advance and are almost always sure to lose when looking at the EV (Expected Value) based on how the system is designed.
A system similar to Automated Market Makers (AMM) and individuals providing liquidity on both sides (or one side) in a very customizable way could solve this issue. This way the liquidity providers act as the bookie while the ones who want to bet are sure of the odds they will get at the time when they make their prediction. 1% of every taken bet can go directly to a pool with the purpose to reward Market Creators/Liquidity Providers/Oracles based on a specific ruleset.
Example: A market is created between Outcome A or Outcome B and everyone who wants is free to provide liquidity based on their own rules that they are able to set.
Let's say as a bookie at the time of providing Liquidity you estimate the chances as 50%-50% and you want a 108% edge on that providing 500 liquidity on each side with a minimum/maximum bet of 10 that results in a 0.01 edge point change in the odds. This would result in dynamic odds which go up and down based on where bets come in and it could look like something in the table below...
The one who provides liquidity acting as the bookie takes the risk of the bettors winning with the benefit of having an edge on the odds that he allows to be taken so given enough volume and good line setting the house should have the advantage while the bettors are able to get the odds and potential payout guaranteed at the time of taking the bet.
Multiple different liquidity providers acting as a bookie can operate at the same time on the same market setting their own specific rules and they are free to pull out their liquidity or adjust the rules at any given time to the point where the bets that were already taken are not affected. Those who are betting can also bet bigger amounts at once with the automated market maker doing all the calculations of what odds they will get on average taking multiple bets from possibly different liquidity providers. Someone can also provide liquidity on 1 side set at fixed odds as a way to bet the other side hoping it gets filled.
There are potentially many options for customization that can be programmed into the contracts for liquidity providers. Just to name a few, a decreasing edge over time, increasing stakes over time, minimum time in between bets that are accepted as a safety measure in case news comes out so liquidity can be pulled/paused while changing the odds without getting taken advantage of. The possibilities are endless really and the volume that potentially can be taken also far surpasses the provided liquidity if there are enough bettors on both sides.
3. Oracles
Right now on dublup.io you need 10000 PAL staked to act as an oracle and they earn a whopping 4% of fees which cuts down quite hard in the edge of bettors. I'm not quite sure about all the exact numbers and how realistic it is, but having some kind of system where coins are staked giving resource credits that get drained when submitting results as an oracle earning part of the fees that are taken from each bet that is taken could work and get more people involved. Some kind of dispute system that can be triggered should also be in place where those acting as oracles can potentially miss out on earnings or lose coins when making mistakes.
This is all just a basic idea mostly focussed on the dynamic odds through liquidity pools and an AMM solving the issue of actually knowing what you bet on.
 |
 |
 |