The Gnosis Challenge
In the Future of Blockchain competition, you can choose to build your own idea or answer a partner challenge. In return for answering a partner challenge, you can win one of up to 3 x £2,000 cash prizes as well as being considered for the £20,000 top prize.
One of our challenge partners is Gnosis, which builds new market mechanisms to make this future possible. Through decentralized platforms, we enable the distribution of resources — from assets to incentives, and information to ideas. Our products are interoperable, allowing you to create, trade, and hold assets. While our prediction market platform allows anyone to build customized forecasting applications, our decentralized exchange models and enable access to arbitrage-free marketplaces. Additionally, our Gnosis Safe wallet aims to set a standard for secure, user-controlled fund storage.
Within the Future of Blockchain competition, we encourage you to build projects on top of our three platforms. We will give out a prize for each product.
Platform 1: Prediction Markets
A prediction market is a vehicle to collect information on the expected outcome of a future event. Participants with unique knowledge will participate in those markets by buying shares of their predicted outcome. The shares of the market will reflect the probability of the future event to occur and quickly incorporate new information. Participants who picked the right outcome turn a profit, the others turn a loss. This mechanism incentivises only users to participate if they possess unique information. Prediction markets are, thus, beneficial to conventional information aggregation as it combines dispersed knowledge into one number. The range of relevant prediction market use cases is huge. They could be used to forecast climate change or forecast natural disasters, predict economic variables like the GDP or the unemployment rate. We see many more possibilities to apply this forecasting technology and believe that it will revolutionize the current information gathering.
Our prediction market platforms allow anyone to build customized forecasting applications, and thus to create an entirely new kind of asset: outcome tokens, which make trading the outcome of any event possible, and hence surface relevant information.
Within the Future of Blockchain Challenge you can build a prediction market use cases build on top of the Gnosis platform. The use case can range from prediction markets on climate change, reproductibility of research, spread of epidemics or complettion of mega construction sites. The use cases are endless and we invite you to come up with your own idea. For more inspiration check out our blog especially our futurescape series.
Within the challenge we would like you to come up with an original and influential prediction market use case. Analyze the use case including its necessity, the current shortcoming it would solve, the market volume and targeted user group. Furthermore we would like you to actually implement your idea and build your prediction market dapp using the Gnosis Smart contracts. To get started have a look at your documentation.
Specific Challenge 1.1
Integrating realitio to our prediction market smart contracts
Background
Realitio has built an arbitration platform for information correctness. People can ask Realitio any questions and then people report the correct answer into the system. The trick is that people reporting the facts need to bond themself. If someone else thinks the answer is a different one, then they can provide this different answer, but they need to double the bond. This results in an escalation game, which can be ended at any time, if one party decides to pay a predefined arbitrator of the system. Arbitration by this game is usually cheap, but arbitration by the arbitrators of the system would be quite expensive (some thousand dollars).
Task
Build an interface between our latest prediction markets contracts to the realitio contracts. This is an interesting challenge as the realitio platform allows a huge variety of arbitrators.
Follow the subtasks:
- build the smart contracts bridging the pull oracle realitio with the push oracle interface from the prediction markets
- Write tests, which cover the mayor workflows:
- Posting questions in realitio, linking oracle to the prediction market setups, test the correct payout after the bonding game finished via (1) game only and (2) arbitrator answe
- Post the questions on realtio for the prediction markets on rinkeby
- Host the Apollo interface serving your dapp for one prediction market on rinkeby
For more information please look at our and realitio documentation
Specific Challenge 1.2
Use the forkonomic protocol as an oracle for the prediction markets
Background
We built already an interface between our prediction markets contracts (from here) to the realitio contracts (from here with documentation here) with the forkonomics protocol. The forkonomics protocol is a new solution for the decentralized oracle problem. It basically combines the Vitalik’s proposals for subjectivicoracy with economic abstraction.
The smart contracts can be found here for the forkonomic system and the tokenization with forkonomic tokens is realized over here.
Task
Build a frontend for trading the tokens of the tokenized-events. The frontend should facilitate
- a convenient trading interface, using the LMSR market mechanims.
- an easy way to pick the right branches/forks of the forkonomic system
- provide the users with the option to redeem any winnings from the tokenized-events.
One very important criterium is that the frontend should be hosted in a completely decentralized manner via IPFS.
Platform 2: Safe — Enter the decentralized web
The Gnosis Safe is a multi-signature Ethereum wallet providing users with a convenient, secure way to manage their digital assets and interact with the decentralized web.
Since it is based on smart contracts, the Gnosis Safe offers advanced recovery mechanisms and improved dApp interaction, besides multi-factor authentication for transactions. Furthermore, users can set up a Safe easily via a trustless deployment process. Transaction fees are paid with funds from within the contract via a relay service.
The Gnosis Safe is available as mobile app (Android & iOS) and as Chrome browser extension.
We are looking for an integration of our safe. You can build recovery modules, integrate the Gnosis Safe into a Dapp or build an alternative Front end as described below.
Check out our documentation to get started https://gnosis-safe.readthedocs.io/en/latest/
Specified Challenge 2
Alternative frontends / clients
Background
The Gnosis Safe is available for a set of frontends. There might be opportunities to improve them and their UX. Also for some use cases, different aspects of the UX are more important than others and have to be considered differently.
Besides that, some people might be interested in interaction with the Safe from a different client / framework which we don’t support yet.
Task 1
Implement a frontend for the Safe contracts on a platform/framework of you choice (e.g. Android, iOS, react-js, ReactNative, Mac App, Windows app etc.). Some ideas that could help:
- You could leave out Safe creation, but just allow existing Safes to be loaded. This would improve things. (Instead create the Safe via one of our frontends)
- Build a Safe with a very bare-bones UI that is close to the contract functions.
- Build a Safe that is read-only, i.e. you cannot trigger new transactions, but you could view all info. (An example for our old Gnosis MultiSig is this one: https://transparency.aragon.org/)
Task 2
Implement a command-line client in a language of your choice in order to interact with a Safe and perform the following actions:
- Display Safe ETH balance
- Display Safe token balance
- Display Safe owners
- Display Safe threshold
- Change Safe threshold
- Add A Safe owner
- Remove Safe owner
- Swap a Safe owner
- Add a Safe module
- Remove a Safe module
- Execute a data transaction
- Transfer ETH
- Transfer tokens
For both tasks, the following repos might help:
https://github.com/gnosis/safe-ios/
https://github.com/gnosis/safe-android
https://github.com/gnosis/safe-react
https://github.com/gnosis/safe-browser-extension
https://github.com/gnosis/svalinn-kotlin
https://github.com/gnosis/bivrost-swift
https://github.com/gnosis/bivrost-kotlin
Platform 3: DutchX — the first fully decentralized exchange
The DutchX is an open, decentralized trading protocol for ERC-20 tokens using the Dutch auction mechanism for determining a fair value for tokens. Coupled with a pure on-chain design, the DutchX doubles a price oracle and is built to enable users, bots, as well as other smart contracts to exchange tokens: no strategy for participation is needed. Trading on the DutchX, users benefit from getting a fair price for their tokens through the bundling of liquidity. Additionally, all fees levied in the exchange remain in the exchange — no value is extracted!
Any decentralized application in need of exchanging tokens or integrating a price feed can make use of the DutchX. The possibilities are tremendous!
The DutchX will soon be governed by a DAO.
Check out https://slow.trade — a graphical user interface that lets you interact with the DutchX.
Feel free to pick one of our integration ideas here or work on our integration idea especially outlined for the Future of Blockchain Challenge. All the needed information can be found in our documentation.
Specified Challenge 3
“End to end”- participation
Background
The current design of participating in the decentralised DutchX trading protocol is not very user friendly. Mainly, this is by limitations of the Ethereum blockchain. However, picture a way around it to make the experience more user friendly — finding a workable solution and implementing this idea is your challenge.
What makes the current implementation not as user friendly? By technology restrictions, at the moment, a user of the DutchX must sign several transactions for proceeding with the order (i.e. an exchange of two tokens). On top of this, a participant must then come back after the auction has finished to claim and withdraw the tokens he/she receives in return. Not only having to sign several transactions but also having to claim and withdraw only at the end of the auction cycle, requires patience and a lot of attention of the user. The user has to actively do something before the tokens are back in his/her wallet.
Task
We are looking for a team to design an “end-to-end-participation” solution, which will allow any user to submit one transaction only — to a smart contract that then interacts with the DutchX protocol. The smart contract would go through the various transactions and claim and withdraw the funds at the end of the auction to then automatically transfer the tokens back to the user’s wallet. The user still profits from the slow execution of the order in the auction based model, however, does not have the pain of returning to claim.
A business model could be merely the collection of Magnolia. Additionally, a service fee could easily be placed on top by adding a small “service” fee for executing the smart contract on behalf of the user. The team would also have to solve for the gas challenge as well as setting an incentive for the smart contract to trigger the claim & withdraw from the DutchX protocol.
More specifics to the challenge:
Currently these are the transactions that a seller has to go through:
- Wrapping ETH (if WETH is not available, which should be assumed)
- Paying with OWL (if available and the user chooses to); ideally this is also available in the solution to this challenge.
- Allowance specific token (can be a one-time high allowance but otherwise might be for every transaction).
- Confirmation of Order
- Claim and Withdraw (depending on functions used, this might be one or two separate transactions)
To go through a transaction cycle, try it on https://slow.trade — a graphical interface that let’s the user interact with the DutchX smart protocol.
Within the following graph you may see which transactions happen within the DutchX smart contract layer and which are with the user’s wallet:
Intended user story:
- User sends Token A from their wallet to this specific smart contract address and does nothing else. Will automatically have the receive Token back in his/her wallet after the time of the auction has passed.
Within the challenge you will have to solve for some problems:
- The user has to set an allowance to the smart contract
- Smart contract must know how much comes from which address and allocate the exchanged token to the respective addresses
- Must overcome gas problem (your smart contract will spent on gas which somehow has to be rolled over to the user, possibly by setting a fee)
- Must overcome problem that the pre-set gas limit in most applications might be too low to do one transaction up to confirmation of order.
- Consider how to calculate the fee level that is passed onto the user and how. Are all users treated equally with the rate of the smart contract?
- Consider how to fairly distribute Magnolia or offset with gas incurred by the smart contract.
Further requirements:
- User’s funds should always be secured and safely stored in a smart contract
- Calculation and transfers should happen on-chain
- Should host a simple interface or alternatively a telegram bot (or similar), with which non-technical users can interact with.
- Should ideally be a generic smart contract such that other projects may build on top (e.g. simple sell-widgets)
- It should always be possible for the user to claim/withdraw from this smart contract also, in case it is not automatically sent (which is the goal of course)
- Optional: Consider how to optimise for gas usage.
- Optional: Consider how to distribute Magnolia back to the user — not, they would have to be unlocked at once to transfer (however, could also be used by the smart contract to reduce fees).
Decrease complexity by considering:
- Implementing this for a certain auction pair only (and possibly only for one auction, e.g. sending ETH to obtain RDN)
- Implementing this only for the participation as a seller
