Guesser Protocol

The Guesser protocol aims to be the simplest set of smart contracts built to provide developers with the necessary tools to create betting platforms on Ethereum. In this post, we want to provide a high level outline of the structure of the smart contracts and how they interrelate to one another.

How does it work?

The best way to start describing the protocol is by providing a broad view of how it works, and then following up with a short description of the basic contracts.

Like the the 0x Protocol, we use relayers to show the data that the protocol stores. These relayers’ basic task is to handle the access to the bets they want to show, because the bets are not easily accessible to anyone. The protocol works with relayers for several reasons:

• Privacy: The event created by a user has a unique 256 bytes hash providing it a hidden status. This lets you differentiate between private and public bets.
• Base layer approach: We want to build the protocol as open and spark as much creativity as we can, providing bet creators and developers an easy way to work with collectibles, private bets, group bets, games… We think this will enable new kinds of betting that haven’t been invented yet to be built on top of Guesser.
• Creator Incentives: One of the incentives for someone building a client on top of the Guesser protocol is to be able to have events only accessible from their client (while being able to have events accessible from every client, too) and create a community around these. This plus the ability to create new kinds of custom bets with their own set of properties is a huge advantage from previous betting systems.
• Scalability: Scalability issues are well known by blockchain developers and enthusiasts. Storing all the data in a contract makes no sense and requires a lot of resources to be able to maintain it, ending up with a more costly protocol. Following 0x’s steps, scalability is handled off-chain by the decentralized relayers.

In this simple way, we give all the power to the creators (the relayers) to make the usage of the protocol they need in a highly custom way. With an easy to use protocol that also has the right financial incentives in place, creators of betting events or platforms will use the Guesser protocol in ways we might not imagine yet.

Eventually, some relayers may even want to join forces and share information to give users a better experience. They might do this to allow collaborative clients to have a higher amount of betting events or to make these events gather larger payouts, making them more attractive for the players.

If you want to have a look at the current code, check out: https://github.com/GuesserProtocol/GuesserCore/tree/master/contracts. You can read more about the structure of the 0x protocol in their whitepaper: https://0xproject.com/pdfs/0x_white_paper.pdf.

Kernel

The kernel is the first entrance door of the protocol, and any developer that wants to use the protocol in the typical way should use these contracts by default and interact with them. To make the kernel fully upgradeable and still allow it to be easily improved, we are using two kinds of patterns:

• First, an eternal storage, which is basically a contract that contains the data and getters and setters.
• Second, a delegated proxy (we’ll talk more about it in the next section)

Thanks to the eternal storage of this structure, the contracts have the basic data they need in a storage contract and the functionality in a different set of contracts. These both sides are tied together by a registry that tracks who is allowed (and who isn’t) to access the storage contract.

This way, only contracts are allowed to see and modify the data. Future improvements as well as contracts with new functionalities can be added, allowing the protocol to grow its long term utility and not be deprecated in the early days.

If you want to have a deeper understanding of the Eternal Storage pattern, you can find more information here. https://fravoll.github.io/solidity-patterns/eternal_storage.html. There is a lot of available resources about the proxy delegate, a nice one can be found here. https://fravoll.github.io/solidity-patterns/proxy_delegate.html.

Main kernel contracts

There are three main contracts in the kernel:

- Kernel: it’s the contract that ties everything together. It accesses the other solidity files and storage data. It’s the main contract the end user will use to interact with the system.

- Payments: the functions needed to interact with the payments, like the prize distribution mechanism.

- Oracle: This contract gets the outcome of an event.

- Terms: This contract contains the access some bet metadata. It has some limitations in terms of storage, since it saves the data in a bytes32 variable. This provides enough data for dates, which is its main purpose.

All these contracts only implement the basic stuff, and they are connected to a specific contract for a certain action. They are the kernel of the protocol. As mentioned, there is also a storage contract where we store the data and a registry providing programmable accessibility to the data.

Delegated proxies

These are a very important part of the protocol and probably deserve more attention than this short explanation. As we described in the previous section, the kernel contract’s purpose is just to communicate some functions and processing orders, but in the end, the proxies is where the action will be handled. This actions are separated by the same sections as the kernel: Kernel, Payments, Oracle, Terms.

For example, the Oracle kernel simply communicates with the proxies asking them for the information it needs. An Oracle Proxy can be, let’s say, a contract connected to Witnet. It could also be fixed to the owner of the bet, who will provide the outcome of his own event. In other cases, it could be the Payment proxies which handle the ERC20 and ERC721 transfers and balance for the bets.

The good thing about these proxies is that are fully upgradeable and can modify data as if they were its owners. Of course, adding new proxies to work with the protocol requires a few processes in order to double check that the contracts are secure to use. Once the protocol is able to implement a decentralized governance system, the community will be the one that will handle the process of accepting new proxies for the protocol so that developers can use them freely.

Easy to use

A protocol like Guesser is nothing without the help of a community. It has to be easy for developers to contribute to the protocol, and for developers that want to build their apps to use the protocol. It makes no sense to build a protocol that few people are able to use. For that reason, developing a set of modules that make it super easy to create custom betting systems is a priority to us as well. The development of this part hasn’t started yet, but it isn’t too far in our roadmap.

Our long term vision for the Guesser protocol is simple: to create a javascript npm module that developers can export with ease and, with no more that 6 well documented lines of code, have the platform ready to create custom betting systems.

On top of Guesser, developers will be able to create parimutuel betting systems, their own bookies, or mechanisms like lotteries. We plan to support any system that implies staking money on a prediction. Whether you as a developer want that to be a YouTube views forecaster, an e-sports betting platform or a casino roulette is up to your own creativity!