Number of $FX requested (incubator fund): 50000 $FX;
Proposal belongs to which segments: Developer Fund;
Incubator fund distribution timeframe and milestones.
Distribution timeframe: 50k across 4 or 5 months.
- 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).
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.
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.
Reasons why the project should be selected and supported and included an analysis of the competitive landscape;
- 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.
Include attachments, such as GitHub links, product prototype, video, planning, blueprint, twitter, etc.
- GitHub: TBC (kenorb (Rafal W.) · GitHub)
- Product prototype: on request
- Blueprint: on request
- Twitter: not needed
- Videos: on request
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.
- 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.
- 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.
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.