The BETR Betting Model
By eliminating the “middle man” – essentially the escrow agent – using blockchain technology it is possible to build sportsbook clients that operate with no human or business entity between betting pairs.
Components of a Distributed Model
Escrow and Settlement
Placing a bet with another party entails two important functions. The first is to hold funds from the time that a bet is made until it is settled. The second is settlement in favour of the winner (assuming there is one – refunds to both parties in the event of a tie or cancellation).
Settlement poses a challenge. Any system that is automated would have to have a robust and agreed settlement system that is immune to human or system error. We will to cater for a number of different resulting/settlement systems – the differences being simply how the winner is determined.
While parties may remain anonymous it is intended that this system can also be integrated with existing sports books or exchanges. In this scenario placing a bet may require an account at the counterparty – bets that are offered may be flagged as requiring an account and authentication.
The process of registration and authentication would also imply that those bets would not be pooled with others. We intend to introduce a distributed authentication mechanism to facilitate the offering of bets by entities that require player accounts.
It is no use having a wonderful betting system if the users cannot find the bet that they want. Not only that, in order for the system to present sufficient liquidity (so bettors can find the bet that they want to make), and to provide optimal volume for consensus settlement, it is important that all software clients see the same selections as the same thing. As an example, it is equally valid to call a match winner market “match winner” or “winner” or even “moneyline 1X2”. The system needs to provide a mechanism to avoid duplication of markets and present a unified interface between disparate parties.
A distributed directory of bets will be built in to the system making it simple for software clients to present a logically ordered menu of choices. The system will combine the many “standards” for event and market naming so that the same bet is treated equally regardless of the source.
This system presents two distinct advantages to the overall ecology. In the first instance it makes it easy to find any specific bet.
Secondly, and very importantly it makes it possible for bets to be standardised and pooled together.
By ensuring that anyone wishing to offer a specific bet uses a common registry we are able to increase the reliability of the consensus, and also to combine liquidity into a pool so bets are not simply one on one. So (as an example) assume I want to lay the Chelsea to win bet for this weekend’s premier league fixture. I decide I am prepared to lay $1000. Someone else also wishes to lay $1000. There is now $2000 available for anyone wishing to back Chelsea. The user would see a unified interface – disparate layors are agreeing on the identification of the same bet and their liquidity combined. As a punter I can come in and back Chelsea to win for $1500 and this would be shared across both Layors – as two separate transactions.
The more entities on either side of the bet that exist the better consensus settlement will work.
Different views based on Target Market
While the API will provide all functionality to all participants it is anticipated that there would be more specific apps built that focus on the intended end user. As an example, a sports bettor would in general use an interface similar to modern sports betting apps where bets can easily be found and taken with no concern for the underlying markets and events or laying prices.
Sportsbooks and wholesale bettors would utilise the lay side of bets and may or may not integrate the directory services. Some implementation of directory services and lay pricing may be purely API level integrations with existing sports books or exchanges.