IBetYou
Decentralized betting protocol that enables users to bet and earn incentives through participation
Abstract:
This project is an experimental customer-facing solution in bringing Ethereum or, more specifically, smart contracts, advantages to the average internet user and explaining its benefits straightforwardly. There are multiple layers of the solution that will be obvious to the user as he progresses through the system. The idea is to slowly lead the user through the concepts like smart contracts, lending protocols, prediction markets, decentralized dispute resolution without first trying to explain it to them. Our hope is they will understand them intuitively through examples and the end value they produce.
The flow will be as follows :
In case of a dispute or the inability to reach a conclusion by the appointed arbitrators we will appoint that decision to Kleros Court or a similar solution for the final decision.
Motivation:
We are still in early days of blockchain where users often have to be quite technical to use any part of the stack. We acknowledge the existence of prediction markets and other complex systems that serve the same purpose but we believe that having a Dapp that tries to solve a problem of simple personal betting in a decentralized manner with UX being as simple and familiar as possible still represents a great obstacle but also an opportunity for the space in general. Our goal in the first year of the project is to reach at least $5M TLV in the platform. We believe this will prove that the game has crossed the UX hurdles and it is ready for the next level of development. This whitepaper explains ways we have addressed technical problems and the way it’s being implemented and the future that awaits us. If you want to bet with us join us on https://ibetyou.me/.
Technical explanation:
Bet finite state machine
State description
S0 - Initial state (Bet Created)
S1 - Assigning bettors
S2 - Assigning judges
S3 - Bet waiting
S4 - Voting stage
S5 - Claiming
S6 - Over
State transitions
S0 -> S1 - ε-transition
S1 -> S2 - Both bettor and counter bettor participated
S2 -> S3 - Both judges participated
S3 -> S4 - Waiting time has expired
S4 -> S5 - Winner decided by having most of all votes cast
S5 -> S6 - Every eligible participant has claimed funds
CANCEL -> S6 - ε-transition
**Every state except S5 and S6 can transition to CANCEL state if number of required cancel votes equals number of bettors present.
Finite state machine flow description
Bet enters state S0 after it has been created. From S0 it goes to S1 after both bettors have accepted a bet. State S2 is reached when both bettor and counter bettor have joined. State S3 is reached after both judges join. State S3 is the “waiting state”. The bet exits state S3 when voting time limit* is reached. In state S4 judges are allowed to vote. The bet stays in state S4 until one of the bettors has more than half of the maximum votes. Bet stays in state S5 until all eligible parties claim their rewards. After that, final state S6 is reached.
*Judges cannot vote until a certain time limit is reached.
Describing the mechanism of yield creation
IBY by itself presents a leap forward in better blockchain UX on so many levels and one of the advantages is bringing non crypto native users and their liquidity on the chain. But once we have that liquidity what are we going to do with it?
We plan for IBY protocol to be one of the biggest liquidity providers on the Quickswap where we “forward” user stakes from their bets and exchange them into ma tokens (maUSDC, maUSDT, maAAVE etc.) and only when the specific bet is concluded we return ma tokens to original tokens with the increased amount. Surplus is then directed towards IBY governance to decide what to do with it. Set of governance proposals will decide what is done with the surplus (yield). Users holding IBY tokens will earn yield without even having to claim it and that will make IBY to be worth more during time. However the exact details of this mechanic will be decided with a community vote via DAO.
Describing the mechanism of yield creation (Notice: technical stuff!)
Here we are going to describe how yield is generated for IBY protocol.
First we define which tokens we want to interact with. In this list are maUSDC, USDC and MATIC (equivalent to ETH on Matic network). Beside that we also define quickswap router address that we want to interact with called IQuickSwapRouter. After we’ve established basics let’s deep dive into mechanics of actual swapping. In this explainer we will cover case where user deposits Matic tokens into betting contract.
Image 1. Quickswap router and tokens definitions (addresses)
After we’ve defined everything let’s deep dive into swapMaticForMaUSDC.
First we ask Quickswap to swap exactETHForTokens where we say, let’s swap ETH to USDC and because we are on Quickswap and not Uniswap that actually means that we are swapping Matic to USDC. After that has been done we check our contract wallets USDC balance and continue to swap USDC for maUSDC. If that is all done successfully then we hold that balance of maUSDC and hold it as it increases in value over time.
Image 2. Swapping Matic for maUSDC
After the bet finishes we have to payout the winner the full amount of deposited bet (bettor + counter bettor). To do that we exchange maUSDC tokens that we have on the wallet and swap them to USDC. After that we swap them for ETH (we are on Matic so this means we are actually transferring them for Matic tokens). And we will see in the end that we have more than what we had on the start.
Example:
In February 2021 on our test contract each side deposited 1 Matic token, so it’s a total of 2 Matic tokens. Those 2 tokens were exchanged for maUSDC tokens following the path above and after that we left them there for 2days. After the bet was finished smart contract automatically converted that maUSDC to Matic and now we had 2.3 Matic which means we earned a yield of 0.3 Matic as simple as that.
Image 3. Swapping maUSDC for Matic
This is just a start as multiple more advanced strategies can be created where not only swap can be done, but also providing liquidity on Quickswap, integrating with Compound etc.
Creating a mainstream appeal
Gasless experience, wallet abstraction, easier onboarding
We will eventually want to reach the broad mainstream but in order to do that we also need to rethink the UX approach, especially with gas prices at all time high. The idea is to abstract gas fees from users so he/she doesn’t even know they exist by integrating Biconomy to achieve gasless experience. Other UX problems that need solving are creating an experience where wallets are abstracted and user flow is much smoother than your usual metamask powered dApp. Ideally we would have an experience where users login with their twitter, facebook or any other social login or username and password even abstracting usage of wallets. There will be two modes : normal and advanced mode. In normal mode you wouldn't need to know how to use crypto wallets, save seed phrases and private keys. Using Arkane network to seamlessly onboard users, create a profile like they are opening an account on a social media website, buy crypto with your credit card, interact with the protocol without even having to know what wallet is and everything is still on chain, gas free and mobile friendly.
IBY DAO - the future
Ultimate goal with all of this is completely decentralized protocol that will earn it’s holders yield for just holding the IBY token. Where DAO will decide on every important governance decision, what to develop in the future and additionally adding advanced farming strategies and integrations with protocols like Compound, Alpha Hommora and similar future opportunities on top of the AAVE integration.
IBY governance mechanics
The proportion of active voters on any given blockchain project or protocol is fairly
low - usually hovering in the single digit percentages - the so called voters apathy. This means that either a “loud minority” controls the protocol or a quorum cannot be reached and proposals are never voted on.
To circumvent these issues, we need a mechanism of representing so-called
“passive token holders”. These are people who are, for one reason or another, not
interested in actively participating in the development and governance of the IBY
protocol - but hold IBY tokens.
Council
The voters' apathy will be solved using a mechanism of elected council members. The council consists of an odd number of council members. The initial number of
council members are set to be seven. The council can grow in size, but never exceed 33
Elections
Council members are elected through a series of log-scaled, liquid democracy
voting mechanisms.
Continuous Liquid Democracy
Liquid democracy is a form of delegative democracy whereby an electorate has the
option of vesting voting power in delegates as well as voting directly themselves. The
electorate which vests power in delegates does so on a continuous basis.
The candidates with the most IBY staked to their name are automatically elected to
the council.
Since IBY holders can either re-stake and revoke their vote constantly - every block
is a “mini election” and a new prospective candidate can “rise through the ranks”
quickly - if decided so by the community. The votes of IBY holders which do not participate in the election mechanism are not counted towards the final tally of the votes.
Phragmén Voting
The IBY Governance council is chosen by means of a Phragmen Election - quite well
described on the following link: https://wiki.polkadot.network/docs/en/learn-phragmen
Anti-Pareto Scaling
To ensure that the governance council is not dominated by “superstar” council
members who are very hard to outvote and thus have indiscriminate control over the
protocol - a system of “Anti-Pareto Scaling” is employed.
The problem of skewed Pareto distributions is seen in many blockchain projects - a
small minority of the participants control the vast majority of the network.
In the left graph , we can see that the amount of inequality in the system can be expressed as the variable α in Generalized Pareto Distribution function.
Anti-Pareto Scaling aims to reduce α to a
pre-decided number - by applying an inverse
logarithmic function to the weighted votes.
By choosing the factor α, we can choose exactly how distributed we want our
system to be. When a system is in an equilibrium - the application of the log scale
function has no effect. It’s only when the system gets too centralized or too
distributed, that the Anti-Pareto mechanism kicks in.
The Initial proposal for α is 1.14. This would reduce the Generalized Pareto
Distribution to the Pareto Principle - often found in nature and known as the “80/20
Rule”.
The best way to determine the α will most likely be through running simulations and
having the community decide before the DAO launch.
Voting for proposals
The council and IBY token holders can vote on proposals. The proposals can vary
from very specific actions - such as network fee amounts, liquidation ratios and
similar - to very broad changes - such as changing the IBY Protocol contracts
themselves.
Weighted Voting
The council members vote by acting as a proxy for the IBY holders that staked their
tokens to them. The amount of voting power they wield is equal to the amount of
IBY staked when voting for them - adjusted by the Anti-Pareto Scaling function
The IBY holders who did not vote for council members vote independently with their
IBY tokens. The proposal is accepted with a simple majority vote (50% + 1 vote).
Submitting and Accepting Proposals
Each IBY holder can submit a proposal for a change by staking a set minimum
amount of IBY tokens into a proposal contract.
The minimum proposal stake can be set by a Governance Vote.
Other members of the community can stake their IBY into the proposal vote - the
proposal with the biggest stake in that voting cycle is selected to be voted on.
Council members can also submit proposals. Council proposals don’t require staking
tokens and are accepted automatically.
Voting Schedule
Voting is done, at max, three-at-a-time - meaning there are never more than two
proposals being voted on at a time. Maximum of one proposal comes from the
public and a maximum of one from the council. Council proposals are put in a queue and voted in order of proposing (earlier proposals being voted on earlier).
A new proposal is voted on once a week.
Automated Token Buyback Mechanism
Even though stakes on the IBY protocol are deployed in multiple tokens, the value they
accrue should be expressed directly through the value of IBY. This is why part of the yield (the exact amount to be decided before the DAO launch) that is earned in any of the tokens like Matic, Quick, USDC or any other token - is deposited into an Automated Token Buyback Contract. The contract has a list of approved DEXes - voted on by a Governance proposal through which it swaps the deposited token for IBY.
Those IBY tokens are then moved to the Treasury. This creates a constant buy
pressure for IBY token and reduces the circulating supply of IBY - ensuring that the
value of the IBY token will have a positive price pressure exactly correlated to the
activity of the IBY protocol. This method is taken from the following article as a better alternative to token burning: https://www.placeholder.vc/blog/2020/9/17/stop-burning-tokens-buyback-and-ma
ke-instead
The Treasury
The IBY Tokens in the treasury are the common good of all IBY holders. The funds
from the treasury can only be assigned by a super-majority vote.
Anyone can apply to receive funds from the treasury. As issuing tokens from the
treasury will inevitably increase the circulating supply of the IBY token and create a
sell pressure - the funds must be used responsibly. This is why a strict super-majority of 2⁄3 of participants must approve the spending of funds from the Treasury.
Sinkhole
The Treasury has an attached “Sinkhole” contract - where funds can be sent to be
removed from the circulating supply forever. Once tokens are sent to the Sinkhole
contract, they are being moved from circulation through the use of an Exponential
Decay Function (https://en.wikipedia.org/wiki/Exponential_decay).
This means that after its made, a decision to burn tokens can be reverted, but the
amount which can be recovered is exponentially reduced with time.
IBY Token Technical Specification & Distribution
ERC20
I Bet You’s IBY is an ERC20 token as defined in https://eips.ethereum.org/EIPS/eip-20
Locking
A certain amount of IBY tokens will be locked at launch. These tokens will belong to
advisors and founders. They will be unlocked through a “cliff and linear unlock”
mechanism where:
● CLIFF - a set amount of blocks where tokens are completely locked. No tokens
can be unlocked during this period
● LINEAR UNLOCK - an interval from starting block Bs to end block Bd through
which the tokens are unlocked on a linear schedule - block by block.
Permissionless
The tokens must be permissionless - they cannot require any special approval from
an “admin” account or have any option of “freezing”.
TODO:
Farming strategies
Compound, Alpha Homorra integration, xchain
Authors:
Edi Sinovčić Luka Sučić Marko Ivanković