Binary market predictions

Developers Function X Proposals
1

  1. Number of $FX requested (incubator fund): 50000 $FX;

  2. Proposal belongs to which segments: Developer Fund;

  3. Incubator fund distribution timeframe and milestones.

    • Distribution timeframe: 50k across 4 or 5 months.

    • Milestones:

      • 1st stage - 10k $FX - 1st month - architecture, plans, initial development, figuring out APIs, writing required libraries, partially working code
      • 2nd stage - 10k $FX - 2nd month - code is being tested and matured, initial web interface, polishing edge cases on testnet
      • 3rd stage - 10k $FX - 3rd month - code is matured for the mainnet, initially deployed, web completion, users can start testing
      • 4th final stage - 10k $FX - 4th month - maintanance, community building, smart contract edge cases and bug fixes, addressing repo issues, deploying different configurations (support for different pairs and amounts)
      • extra 10k $FX - cloud and server costs, domains, docs and other resources, extra risk for the unknowns and bugs.
        Note: Estimation for each month (20 working days) is based on ~500fx/day (dev/team and other IT costs).

  4. Proposal details.

    • Name of the proposal: BMP - Binary market predictions (aka binary options) (TBC)

    • Description: Binary market prediction smart contract allows users to bet and profit from the probability of price movements in the given timeframe.

      For example: Users can bet 20 $FX (or different supported amounts) along with prediction whether BTCUSD price will go up or down after 24h period (same time). After the event has been validated, users receives or can request the maximum of 180% (or less in some edge cases) of their original bet as reward on the correct prediction only. On a tie, users are receiving the original bet.

      Amount of 20 $FX, timeframe and pairs can be adjusted at the final phases on separate contracts (bets and time limits could be dynamic if possible). Other rules and edge cases can be adjusted during the development as well. In the future, the smart contract can be expanded to other events which can be validated such as sport or elections.

    • Mechanics: Events are validated either by the contract (if possible) or external approved source (TBC). Users’ bets are safely kept on reward pool (smart contract’s address). Winners are paid from the reward pool (up to 180% each). Rest of tokens (if any) are kept on the reward pool for the next participants (in order to cover edge cases such not enough participants or too many winners). In addition, 3% from the reward pool each month is paid to contract owner for the future development and maintainance costs (web servers, domains, bugs, development).

      To resolve market prediction, in case there isn’t possibility of HTTP requests from the blockchain, external off-chain information needs to be updated onto the chain (provided by single source of truth, a backend script or oracles).

    • Benefits to F(X) ecosystem: It can be used as a business model which can benefit both participants and contract owners.

    • Team: kenorb (kenorb (Rafal W.) · GitHub & User kenorb - Stack Overflow) and team.

      With over 30 years of software engineering experience, I specialize in variety of technologies, programming, tooling and delivering complex projects.
      I’ve been working for large enterprise companies, including a decentralized blockchain company for the enterprise clients across the globe.
      My recent personal project includes free and open source Forex trading robot which was developed across many years.

  5. Reasons why the project should be selected and supported and included an analysis of the competitive landscape;

    Reasons:

    • Open source code smart contract and free to use by anybody.
    • It introduces freedom of trading without rely on exchanges.
    • Transparent progress during stages.

    The proposed project is more competitive to the similar services one provided by the exchanges, because:

    • It’s decentralized (whereas exchanges can always change the rules or add restrictions).

    • Blockchain solution is much safer, as you don’t need to transfer funds to wallets on exchanges that you don’t own in order to trade.

    • Your funds are protected by the smart contract code, not 3rd party exchanges (which can be hacked).

    • Rewards can be more reliable and much higher comparing to most of the exchanges.

    • Transparency of reward logic due to open-source code.

      Due to open-source nature of the code, anybody else could verify the code or use it to deploy the contract with different configurations.

  6. Include attachments, such as GitHub links, product prototype, video, planning, blueprint, twitter, etc.

    Stages of development:

    • New repo, initial plan, dependencies and development of smart contract.
    • Main development, solving challenges.
    • Adding logic for validating bid results from the smart contract or external source(s), and from which sources.
    • Development of a JS library required to interact between smart contract and the website.
    • Development of the website (UI/UX). Django/Flask or Drupal.
    • Setup deploy scripts.
    • Deploy contract to testnet.
    • Setup manual and automatic tests.
    • Testing architecture, flow and different edge cases.
    • Deploy contract to mainnet.
    • Setup demo website.
    • People can start participate on bids.

  7. Additional information;

    Scenario 1:

    • Alice sends 20 $FX to smart contract at 8AM predicting BTCUSD will go up in 24h.
    • Bob sends 20 $FX to smart contract at 9AM (1h later) predicting BTCUSD will go down in 24h (from his point of bet).
    • As the result, the reward pool (smart’s contract address) received 40 $FX in total.
    • At 8AM next day BTCUSD went up from the Alice’s point of reference, therefore she can request a reward of 36 $FX (+180%) from the reward pool.
    • Bob prediction wasn’t successful, so his reward has been rejected.
    • Deadline of requesting rewards is another 24h (or unlimited - TBC), otherwise funds are left at a reward pool awaiting for future participants.
    • Alternative solution: If possible, reward can be scheduled and sent automatically (most likely not).
    • At the end, the reward pool has balance of 4 $FX.

    Scenario 2:

    • Reward pool has still balance of 4 $FX (from the last session).
    • Bob sends 20 $FX to smart contract again at 9AM predicting BTCUSD will go down in next day.
    • Alice didn’t participate this day.
    • Bob prediction was successful this time and he’s happy this time.
    • However there were not enough participants, so Bob’s reward is paid from the reward pool which is 12 $FX short.
    • Bob can request a reward now for 24 $FX (as there are not enough funds in the reward pool to have his +180%).
    • Alternative solution (TBC): Bob can wait another 24h (after confirmation of his reward) for new participants (as there are not enough funds on the reward pool). If he’s successful, he can still request a full reward of 36 $FX).

    Scenario 3 (simplified edge case):

    • Reward pool has already 20 $FX.

    • 12 people sends bets (20 $FX each, 240 total).

    • The next day there are 10 winners and 2 lossers.

    • Desired reward for 10 winners is 360 $FX (+180% each), however the reward pool is 260 $FX (100 short).

    • First few fastest winners can request the full reward of 36 $FX (+180%).

    • The rest of reward pool is protected for pending winners (so they won’t receive less than 20 $FX each).

    • The rest of the winners, can request 20 $FX of the original bid back (due to lack of rewards, as there were too many winners).

    • Or then can wait for the new participants (within 24h of the win confirmation), so the reward pool could accumulate more $FX to cover their full wins (+180%).

    • TBC: Alternative solution - only the first fastest 7-8 winners can request the reward, late winners won’t receive anything.

      Questions to solve:

    • Should we allow users to collect the winnings at any time, or there should be some deadline.

    • Should tie result in loss or users should have right to withdraw the original amount (minus fees).

    • From where we should obtain the prices.

    • What if price results weren’t updated on time.

  8. Licensing: GPL or MIT (open to suggestions).

    Included open-source code: smart contract code, JS library (if required) for the website (UI/UX not included). This will allow people to deploy their instances of smart contracts.

Do not delete this part
Disclaimer: This poll is just a tool to get the sentiment around this proposal and it will NOT affect on-chain voting in any way. If your proposal is getting a good sentiment around the community, it might signal that the proposal is good to go to the next phase, otherwise, some modifications might be necessary.

  • YES
  • NO

0 voters

7 Likes
2

Wow. Is this similar to pancakeswap’s prediction game?

Users enter CAKE and bet what price it will be - up or down. Looks similar.

Would be cool.

1 Like
3

Is this similar to pancakeswap’s prediction game?

I haven’t seen or used pancake’s predictions before, I’ve read now, and you’re right - the idea sounds very similar. I’ve checked it, doesn’t seems to work at the moment on their side.

4

Would be very interesting to have a prediction betting system going on in fxCore.

5

Hello @kenorb - Are you not afraid that this will be banned (because it is not allowed everywhere), in Europe there is a complete ban on trading binary options. In the USA I know it is legal but only on regulated exchanges. - Greetings Belgiumguy🇧🇪

1 Like
6

The existence of a smart contract itself is meaningless (it doesn’t executes itself). It’s a piece of code in some virtual storage. It’s like having a dice (or a picture of a dice) at your home.

More sensible question is, who’s (or what legal entity) is using it, executing the contract, for what purpose and in which country (if applicable) the activity happens (who owns a website, who’re the customers, etc.), what kind of activity (whether assets are securities or/and have any real values according to local law or not, from the perspective of the end user who’s using it), and so on. Btw. This is only applicable when using on the mainnet.

For example if you’re running a smart contract on a testnet with worthless tokens, playing with the predictions, it’s more like a regular game (like playing a monopoly game at home with fake money). So let’s say, the final project is going to be demonstrated and tested on a testnet (until further notice).

If the person is going to use a smart contract on a mainnet, aiming at some valuable outcome out of it (basically to get rich), then a person should check the local regulations and comply with them (especially whether the token counts as security or real money).

Maintenance fees from the contract’s owner aren’t aimed for profit (afaik, it’s not a virtual casino), but mainly used to maintain the contract, updates (a piece of code), sustain the infrastructure and access gates (a website if applicable, but not required). The maintenance fees can be always dropped (disabled) by the contract’s owner if that makes any difference. To further clarify, lost tokens are accumulated (not going to anybody’s pocket) and awaiting for the next winners (there are many online games that does something similar with virtual objects).

In case of the website, which acts as the access gate to the smart contract, could have necessary warnings for the users (asking them to check their local law before proceeding, or stating upfront which residents of which countries shouldn’t use it).

In my understanding, there is no middle man (no central entity which is processing or providing the service), it’s decentralized (peer to peer), it happens on individual cases (on demand), so it’s like going with a friend to pub and bet he won’t drink his beer in 5 minutes. But obviously it’s not a financial advise. So don’t try it at your local pub.

I guess we’ll have to research this in more details to double check.

1 Like
7

Hello @kenorb - Thank you very much for your clear explanation. It never hurts to double check and I think legal advice from someone with knowledge is even appropriate in this regard. Nevertheless, I think it’s very clever what you propose, both this and the chess proposal, great work. - Greetings Belgiumgum🇧🇪

1 Like
8

BMP’s are illigal in the EU since 2018,
Canada is in progress on banning them,
Israel banned them in 2016,
New zealand require registration at their regulatory body
are under FBI scrutiny in the US and those still online require registration and approval of the US exchange regulatory body,
In the UK there regulated as gambling and require a gambling licence (I’m pretty sure a fintech focused on payments cant get a gambling licence for safety reasons) and after over 20 police raids due to fraud there calling on a ban too.

just from the legislative part I don’t think this will work at all, especially Pundi x and Function x are keen on keeping on the good side of regulations.

HTTP? why not HTTPS?

Personally I don’t like the idea of Pundi turning into a casino, crypto is volatile enough, don’t need people losing a large amount of money due to a bad gamble and leaving pundi and fx altogether due to the bad experience.

1 Like
9

@kenorb for scenario 2 and 3, does it mean that the pool will start with negative reward pool?

Because the reward pool has been used (part of it) for the previous winners

10

Reward pool can’t start with a negative balance. A winner in this case can claim less (what’s left) or needs to wait for the new participants who can top-up pool, then he can claim the total desired reward amount.

11

I am going to be really honest, That sounds like a recipe for a fraud lawsuit by those who could not retrieve their winnings. there should always be liquidity to cover all made winnings, otherwise the fund is simply in default.

12

Statistically there should be always liquidity (reward ratio can be always be adjusted), and these mentioned scenarios are just edge cases. In addition smart contract should protect the original bet of the participants in case they win (as priority to the reward claims).
When you open predictions with regular exchanges such as Binance, you’re paying massive fees just to open the position at start, therefore your winnings are guaranteed. Here, we’re dealing with transparent reward pool and code logic which accumulates only tokens from the people, therefore you can’t have winnings out of thin air, and nobody can’t cheat (in comparison to brokers/exchanges where they can), because their code is black boxed and not decentralized.

Let me clarify some blackchain basics:

  • Project’s logic (rewards) are managed by the smart contract which is immutable (fixed, not changeable) to which everybody should agree before taking a part.
  • Everybody can check its logic by validating smart contract code with the source code (similar to Metamask, people are safely using it, because they know they can verify its code).
  • Each transaction you’re dealing with is using a blockchain contract (a non-changeable piece of code), not 3rd party, therefore there is is no possibility of cheating or frauds as per above (assuming code works as designed).
  • This can be compared to a self-service (with peer to peer features), a person is initializing/executing a transaction (initial bet) and a person himself is claiming his token rewards back (nobody else will send it to him, no human approvals needed, nobody else can touch his money and run away, because no human will have direct access to the pool - which I hope smart contract code could somehow protect its pool address even from the owner to not steal the pool), in other words there is no 3rd party involved (like a broker or exchange, apart of reading and updating the market price from the public API), so a person executing/participating is solely responsible for his/her action. So you can’t sue anybody else, because nobody (no human) was involved in your activity/transaction but yourself and the reward is based on the agreed pre-defined condition. And every transaction can be publicly verified (can you do the same at your exchange?).

In addition:

  • Project assumes each person has the legal rights to execute the contract (there are no code validations, since it’s not possible based on their public address). It’s the person’s responsibility to check their legal rights before using this p2p service.
  • Project assumes an entity/owner of the contract, has the right legal rights to use or manage the contract.
  • Legal responsibility is not part of this project (legality only applies per country of usage of the final product on the mainnet). And the project solely provides a smart contract (a piece of open source code) designed to be deployed to the FX compatible blockchain (decentralized database) which can be executable by anybody who agreed to it (can’t be executed on its own), and can be used or extended to use any tokens (usage of FX could be just an example, as it can use any other valueless tokens).
  • If this project won’t be successful (which aims at full transparency and to hide nothing, where everybody can contribute), in the future no one would be able to stop anybody else from writing dozens of similar smart contracts (which could be black boxed due to compiled code) which can allow cheat people who won’t be able to verify their source code, and nobody could do anything about it, because it’s a blockchain. So I hope this project will teach people an alternative safe solution to the market prediction problem.
13

The only way to have continued liquidity is:

User A puts in 10 FX into the pot
User B puts in 10 FX into the pot

Pot Balance: 20

Max reward : 1.5x ( Ranges from 1.1 - 1.5x max )

Whoever wins, get 1.5x max reward = 15 FX to the winner

5 FX will be left in the pot

As more users play the game, more FX liquidity will be in the pot.

Another way to combat this is: Fixed Entry Fee

A payment of 5 FX is needed to play the game, no matter how much each users plan to bet.

Users can choose their risk level - 1.1x - 1.5x bet reward

You can win a maximum of 1.5x the FX you put in.

You will be only be able to match against players who put equal amounts as you.

In this case, we should set a fixed category option for users to choose.

Fixed Entry Fee: 5 FX
( Ticket to play the game and will be added to the pot or paid to the creator to maintain whatever is needed )

Categories to choose from:
Option 1 - 10 FX
Option 2 - 15 FX
Option 3 - 30 FX

And the list goes on. Do note that players can only match each other if the opposing party is using the same option. 10 for 10 - 15 for 15 or 30 for 30.

Max reward: 1.1 - 1.5x ( reward increases if they pick the higher option aka higher risk because more FX is being put upfront.

Example:

User A enters game: 5 FX Ticket to play
User B enters game: 5 FX Ticket to play

Both enter Option 3 ( 30 FX ) - Max Reward 1.5x

Total Ticket Fee = 10 FX
Total Bet = 60 FX
Total Added to the Pot - 10 + 60 = 70 FX

Each user can win a maximum of 1.5x = 45 FX, and the remaining 25 FX will be left to reroll as insurance fund or maintenance upgrade which users can vote.

Can also increase the max reward to like 1.7x? This will be up to the community to decide. Higher reward means lesser insurance fund / upgrading fund.

My personal opinion is 1.5x is just nice.

Can go as high as 2x reward - Just that the ticket fee will be left in the pot. Can be split up into pot insurance, maintenance and dev wallet.

Entry ticket fee is probably for maintaining whatever is needed while leftover rewards will be used for additional stuff in future like upgrades which needs to be voted.

2 Likes