├── Proposals ├── assets │ ├── .DS_Store │ ├── SocialImpact.png │ └── Flyingcarpet │ │ ├── FLCA_logo.jpg │ │ ├── FC_Gnosis_workflow.png │ │ ├── gnosis_prediction.png │ │ └── Model_Viability_Prediction_Market_Dashboard.png ├── PoolX-Proposal-For-Gnosis-Fund.pdf ├── BidderUI │ ├── GECO-Protofire.io_BidderUI.pdf │ └── BidderUI-proposal.md ├── PM-ScaleCases (presentation slides).pptx ├── Groundhog - Gnosis Ecosystem Fund Proposal.pdf ├── SubmissionProcess.md ├── ProposalTemplate.md ├── SablierSafeApp.md ├── DiademNetwork.md ├── Funded Projects │ ├── MultiCard.md │ ├── BondedCurvesForDAOs.md │ ├── Linkdrop.md │ ├── TasitSDK.md │ ├── Flyingcarpet.md │ ├── SocialImpactPredictionMarkets.md │ └── InstantDX.md ├── wave2 │ ├── LevelKFutarchy.md │ ├── Fairdex v2.md │ ├── token-registration-and-push.md │ ├── DutchXSubgraph.md │ ├── SAFE_wallet_provisioning.md │ ├── tokenary.md │ ├── Dapplets.md │ └── PM-ScaleCases.md ├── conditional_investment_interface.md └── Wave1 │ ├── jiffy.md │ ├── Tribes.md │ └── Convergent.md ├── geco_rgb_horizontal_left_darkblue.png ├── Project Ideas ├── Project description - Gnosis Gas Station.pdf ├── Project description- Statistics Dashboard.pdf ├── ApplicationTemplate.md └── Safe Apps Grants.md ├── WalletConnect Microgrant ├── Application template.md └── Info.md ├── Conditional Token Nanogrants └── Info.md └── README.md /Proposals/assets/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/assets/.DS_Store -------------------------------------------------------------------------------- /Proposals/assets/SocialImpact.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/assets/SocialImpact.png -------------------------------------------------------------------------------- /geco_rgb_horizontal_left_darkblue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/geco_rgb_horizontal_left_darkblue.png -------------------------------------------------------------------------------- /Proposals/assets/Flyingcarpet/FLCA_logo.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/assets/Flyingcarpet/FLCA_logo.jpg -------------------------------------------------------------------------------- /Proposals/PoolX-Proposal-For-Gnosis-Fund.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/PoolX-Proposal-For-Gnosis-Fund.pdf -------------------------------------------------------------------------------- /Proposals/BidderUI/GECO-Protofire.io_BidderUI.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/BidderUI/GECO-Protofire.io_BidderUI.pdf -------------------------------------------------------------------------------- /Proposals/PM-ScaleCases (presentation slides).pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/PM-ScaleCases (presentation slides).pptx -------------------------------------------------------------------------------- /Proposals/assets/Flyingcarpet/FC_Gnosis_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/assets/Flyingcarpet/FC_Gnosis_workflow.png -------------------------------------------------------------------------------- /Proposals/assets/Flyingcarpet/gnosis_prediction.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/assets/Flyingcarpet/gnosis_prediction.png -------------------------------------------------------------------------------- /Project Ideas/Project description - Gnosis Gas Station.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Project Ideas/Project description - Gnosis Gas Station.pdf -------------------------------------------------------------------------------- /Proposals/Groundhog - Gnosis Ecosystem Fund Proposal.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/Groundhog - Gnosis Ecosystem Fund Proposal.pdf -------------------------------------------------------------------------------- /Project Ideas/Project description- Statistics Dashboard.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Project Ideas/Project description- Statistics Dashboard.pdf -------------------------------------------------------------------------------- /Proposals/assets/Flyingcarpet/Model_Viability_Prediction_Market_Dashboard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gnosis/GECO/HEAD/Proposals/assets/Flyingcarpet/Model_Viability_Prediction_Market_Dashboard.png -------------------------------------------------------------------------------- /Proposals/SubmissionProcess.md: -------------------------------------------------------------------------------- 1 | # How to submit your proposal 2 | 3 | * Fork the [Gnosis Ecosystem Fund GitHub repository](https://github.com/gnosis/Gnosis-Ecosystem-Fund) 4 | * Create a new file with your project’s name 5 | * Outline your proposal in that file 6 | * Add a 2-3 slides presentation pitching your idea (summary of your project, deliverables, timeline and team) 7 | * Create a Pull Request to merge your submission into the our repository 8 | 9 | Check out our proposal template [here](https://github.com/gnosis/Gnosis-Ecosystem-Fund/blob/master/Proposals/ProposalTemplate.md)! 10 | 11 | -------------------------------------------------------------------------------- /Project Ideas/ApplicationTemplate.md: -------------------------------------------------------------------------------- 1 | # Project Application 2 | _This is a guideline on how to apply for a project provided by Gnosis_ 3 | 4 | ### Project 5 | > For which of the projects are you applying 6 | 7 | ### Team members 8 | > Name your team members 9 | 10 | ### GitHub Repo 11 | > Link to your GitHub Repo 12 | 13 | ### Project Portfolio 14 | > Link to your projects you want to share with us 15 | 16 | ### Expertise 17 | > Short summary of the expertise within your team? 18 | 19 | ### Why are you interested in working on the project? 20 | > Short summary of your motivation 21 | 22 | ### How long will you need to build the project? 23 | > Estimation of how long you will need to implement the project. 24 | 25 | ### Project implementation? 26 | > Outline a detailed description of the project realization. How do you plan to implement this project, which tools and framework will you use? Please provide details on Architecture, Mockups, etc. 27 | 28 | ### How did you hear about the GECO? 29 | > Website, Twitter, Conference and others 30 | 31 | ### Others 32 | > Anything else you want to share with us 33 | -------------------------------------------------------------------------------- /WalletConnect Microgrant/Application template.md: -------------------------------------------------------------------------------- 1 | # Microgrant Application 2 | _This is a guideline on how to apply for a WalletConnect microgrant_ 3 | 4 | 5 | ### Dapp name 6 | > Name of your project and provide an URL to access it 7 | 8 | ### Team members 9 | > Name your team members 10 | 11 | ### GitHub Repo 12 | > Link to your GitHub Repo 13 | 14 | ### What is your Dapp about? 15 | > Short summary/abstract of your project. What can a user do with your dapp? 16 | 17 | ### Why did you decide to build it? 18 | > Short summary of your motivation 19 | 20 | ### How big is your user base? 21 | > How many users does your Dapp have? How many active users does your Dapp have? 22 | 23 | ### How long will you need to integrate a Gnosis Safe compatible WalletConnect integration? 24 | > Estimation of how long you will need to build the integration 25 | 26 | ### Does your Dapp use message signing? 27 | > The Gnosis Safe is a smart contract wallet. That means there is no single private key that can be used to sign messages. If your dapp requires message signing, please map out a high level plan on how you want to make it compatible with the Safe. We are working on contract signature support via EIP1271 and hope to be able to have it live by the beginning of Q4 on Android and iOS. 28 | 29 | ### How did you hear about the GECO? 30 | > Website, Twitter, Conference and others 31 | 32 | ### Others 33 | > Anything else you want to share with us 34 | -------------------------------------------------------------------------------- /Proposals/BidderUI/BidderUI-proposal.md: -------------------------------------------------------------------------------- 1 | # Bidder UI for the DutchX open protocol 2 | 3 | ## Project Overview 4 | The DutchX open protocol currently has the following tools and application to interact with it: 5 | - Seller Interface (React Webapp) 6 | - Command Line Interface 7 | - Public REST API 8 | - Bots (Liquidity Bot) 9 | - Tasks scheduler (example usage: reporting and auto-claiming) 10 | 11 | 12 | The Protofire team is glad to present this proposal to build the next most important application: a **Bidder Interface**. 13 | 14 | 15 | ### Project name 16 | Bidder UI 17 | 18 | ### Team members 19 | - Manuel Garcia (https://www.linkedin.com/in/mgarciap) 20 | - Leonardo Lower (https://github.com/leolower) 21 | - Sebastian Galiano (https://github.com/sistemico) 22 | - Lisandro Corballan (https://github.com/lmcorbalan) 23 | - Pavel Kosobutskiy (https://www.linkedin.com/in/pavel-kosobutskiy-b4ab9157) 24 | 25 | ### What project are you building 26 | Bidder UI for the DutchX open protocol 27 | 28 | ### Why did you decide to build it 29 | We've been following the DutchX open protocol closely over its development and saw how the http://slow.trade was created and launched. This dApp targets sellers mainly. Therefore we identified the need for the counterparty dApp, for the bidder. 30 | 31 | ### How long will it take 32 | Between 8 to 10 weeks. The UX/UI design and development has already started. We target to deliver an MVP by mid February. 33 | 34 | 35 | ### How much funding are you requesting 36 | USD 40000 worth of DAI 37 | 38 | ### How did you hear about the GECO 39 | Directly from the Gnosis team when we reached to them with the proposal. 40 | 41 | ## Your Proposal 42 | A more detailed proposal description can be found in [GECO-Protofire.io_ BidderUI.pdf](./GECO-Protofire.io_BidderUI.pdf). -------------------------------------------------------------------------------- /Proposals/ProposalTemplate.md: -------------------------------------------------------------------------------- 1 | # Proposal Guideline 2 | _This is a guideline on how to best structure your proposal._ 3 | 4 | ## Project Overview 5 | 6 | ### Project name 7 | > Name of your project 8 | ### Team members 9 | > Name your team members 10 | ### What project are you building 11 | > Short summary/abstract of your project 12 | ### Why did you decide to build it 13 | > Short summary of your motivation 14 | ### How long will it take 15 | > Estimation of how long you will need to finalize the project 16 | ### How much funding are you requesting 17 | > How much money do will you need to finalize the project 18 | ### How did you hear about the GECO 19 | > Website, Twitter, Conference and others 20 | 21 | ## Your Proposal 22 | ### Project description 23 | _Outline a detailed description of your project, why you chose to build this project, the overall goal and future outlook of your project and why we should fund you._ 24 | ### Features 25 | _How do you plan to implement your project, which tools and framework will you use? Optional: Architecture, Mockups, etc._ 26 | ### Team description 27 | _Who are your team members, what is your background and what you built before._ 28 | ### Timeline, Milestones and Deliverables 29 | _Detailed description of your timeline milestones and the corresponding payouts_ 30 | 31 | **Phase I** _Outline the different phases_ 32 | 33 | **Deliverables** _What features will be implemented_ 34 | 35 | **Time and Price Estimate** _How long will it take and what is the estimated price_ 36 | 37 | **Phase II** _Outline the different phases_ 38 | 39 | **Deliverables** _What features will be implemented_ 40 | 41 | **Time and Price Estimate** _How long will it take and what is the estimated price_ 42 | 43 | **Phase III** _..._ 44 | 45 | 46 | ### Others 47 | Anything else you want to share with us 48 | -------------------------------------------------------------------------------- /Proposals/SablierSafeApp.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | 5 | Sablier Safe App 6 | 7 | ### Team members 8 | 9 | - @PaulRBerg - building [Sablier](https://sablier.finance) and [Create Eth App](https://github.com/paulrberg-create-eth-app) 10 | - @TomAFrench - just received his MSc at Imperial and looking for opportunities in Ethereum land 11 | 12 | ### What project are you building 13 | 14 | A minimalistic port of the [Sablier Interface](https://pay.sablier.finance) into Safe. It will facilitate creating, 15 | monitoring and cancelling streams, but not withdrawing from streams. You can read more about how Sablier-style money 16 | streaming works in our [FAQ page](https://faq.sablier.finance). 17 | 18 | Use cases: 19 | 20 | 1. "Continuous" payroll or freelancing 21 | 2. Subscriptions, paying for a product or a service in real-time 22 | 3. Investing, continuous ICOs; imagine a DAO using a Safe and streaming DAI to a founder and the founder streaming 23 | equity tokens or social money back 24 | 25 | ### Why did you decide to build it 26 | 27 | We (the Sablier team) have been looking for a multisig solution that could interact with custom smart contracts for a 28 | while. We ended up using the legacy [Gnosis Multisig](wallet.gnosis.pm), as it's the only one that provided us 29 | with top-notch security 30 | and extensibility (interacting with third-party contracts) at the same time. 31 | 32 | Having a dedicated UI for calling Sablier from a multisig would be 10x better. We'd be our very first users. 33 | 34 | ### How long will it take 35 | 36 | One week, or maybe a tad later than that. 37 | 38 | ### How much funding are you requesting 39 | 40 | \$1,500 since it's a project of medium complexity. 41 | 42 | ### How did you hear about the GECO 43 | 44 | Twitter + DM on Telegram. 45 | 46 | ### Others 47 | 48 | Even if this proposal doesn't pass, I wanted to say thank you for doing this. I find it awesome that you guys grow your user 49 | base by encouraging and rewarding FOSS developers for contributing to your product. 50 | -------------------------------------------------------------------------------- /Conditional Token Nanogrants/Info.md: -------------------------------------------------------------------------------- 1 | # Conditional Tokens Nanogrants 2 | 3 | We’ve revamped our prediction market contracts and created the new conditional tokens smart contracts. Conditional tokens are a fundamentally new type of asset class based on the ERC1155 token standard, which allows you to use multiple types of tokens within a single application. 4 | In prediction markets applications, conditional tokens allow you to: 5 | 1. Make simple markets on the likelihood of a given event. 6 | 2. Make complex markets about how the likelihood of an event is affected by any other event. 7 | 3. Trade any asset under the condition that a specific event happens. 8 | 9 | Currently, prediction markets are our main use case for conditional tokens. 10 | However, conditional tokens are so versatile that they can be used for many different applications—from games with in-game assets like rewards and incentives to grant systems with conditional payouts based on milestones being reached. 11 | 12 | To encourage the development of conditional tokens use cases, we are reaching out to the community for inspiration. We will give out Nanogrants from $50 to $500 for exceptional use cases. We will reward the best Twitter threads with $50 Nanogrants, payouts for projects using alternative mediums (e.g. blogpost or community call) will be determined based on their complexity and utility. 13 | 14 | ## How can I apply? 15 | The GECO Nanogrants program will run via [Bounties.Network](https://explorer.bounties.network/bounty/3727). You can submit your project idea on their platform. At the end of each month, we will select the best submissions. 16 | ## Is my project eligible? 17 | We will consider projects that showcase interesting and new use cases for conditional tokens. We are especially interested in use cases that spark discussion within the ecosystem. 18 | ## How should I format my submission? 19 | The use case description can be submitted in different forms: 20 | * Twitter threads 21 | * Blog post or article 22 | * Video 23 | * Proof of Concept 24 | * Platform integration 25 | * Community call 26 | * … 27 | 28 | Please submit a proposal **first** if you will be creating a video, proof of concept, platform integration, or leading a community call. 29 | ## Additional Information: 30 | * [Documentation](https://gnosis.github.io/conditional-tokens/) 31 | * [GitHub](https://github.com/gnosis/conditional-tokens-contracts) 32 | * [Sight](https://sight.pm/) 33 | -------------------------------------------------------------------------------- /Proposals/DiademNetwork.md: -------------------------------------------------------------------------------- 1 | # Proposal Guideline 2 | 3 | ## Project Overview 4 | Truly change the world and build a more fair and inclusive society by inspiring more good and social behaviour. 5 | 6 | ### Project name 7 | Diadem.Network 8 | 9 | ### Team members 10 | * Clement Bresson - team@diadem.network - https://github.com/Clement-Bresson 11 | * Igor Berlenko - igor@berlenko.com - https://github.com/7flash 12 | 13 | ### What project are you building 14 | We are creating an open source protocol on top of Ethereum, which enables the frictionless exchange of crypto-rewards for actions in real life. We connect the real world with blockchain, by providing an easy to use interface anyone, even without any technical knowledge can use. 15 | 16 | ### Why did you decide to build it 17 | Today positive actions and accomplishments cannot be easily measured, proven and rewarded, as there is no technological connection and we need to rely on third parties. 18 | People are fallible, they make mistakes and often people who provide the highest value are often rewarded the least or even overlooked altogether. 19 | 20 | Usecases: 21 | 1. Employers have little to no guarantees that a freelancer or contractor will accomplish any work after they wire a pre-payment. And on the the other side of the table freelancers often don’t get paid. 22 | 2. Sponsors of charities have no confidence how budgets are spent. 23 | 3. People haven't got enough motivation to change habits and behaviours. 24 | 25 | ### How long will it take 26 | Gnosis integration will take one month 27 | 28 | ### How much funding are you requesting 29 | $10 000 30 | 31 | ### How did you hear about the GECO 32 | Looking for progress of Gnosis ecosystem 33 | 34 | ## Your Proposal 35 | 36 | ### Project description 37 | Think about Diadem as an escrow service where crypto-funds are released only when predefined actions, activities, accomplishments or triggers are met. 38 | We are developing a trustless protocol empowering everyone and anyone to create transparent escrow services for human activities. 39 | 40 | ### Features 41 | * Connect Gnosis wallet without plugins 42 | * Connect facebook profile to Gnosis wallet 43 | * Publish your achievements 44 | * Verify and confirm accomplishment of achievements of other people 45 | * Support other people for the accomplishment of chosen achievements with Gnosis cryptocurrency 46 | 47 | ### Team description 48 | We are a young and enthusiastic team with a strong technical background, inspired by our mission to empower everyone to get recognition and rewards for their accomplishments and social achievements. 49 | 50 | ### Timeline, Milestones and Deliverables 51 | TBD 52 | 53 | ### Others 54 | We want to truly change the world and build a more fair and inclusive society by inspiring more good and social behaviour, by rewarding people who are the initiators of such behaviour by giving them easier access to recognition and financial support. 55 | By rewarding good behaviour we believe we can transform our society. 56 | -------------------------------------------------------------------------------- /WalletConnect Microgrant/Info.md: -------------------------------------------------------------------------------- 1 | # WalletConnect Microgrant 2 | 3 | 4 | One of our primary goals at Gnosis is to increase the usability of dapps which we believe will play a vital role in the widespread adoption of blockchain technology. Supporting projects that improve the decentralized application user experience will prove an essential contribution to Ethereum wallet infrastructure. 5 | 6 | In an effort to improve the Safe’s dapp interoperability, we have decided to offer microgrants to teams that are interested in building a WalletConnect integration that is compatible with the Safe. [WalletConnect](https://walletconnect.org/) is an open protocol that allows users to establish a secure connection between a decentralized application and mobile wallet by simply scanning a QR code. This makes connecting to and interacting with the Ethereum blockchain quick and painless. We are therefore big supporters of WalletConnect and recently released a [WalletConnect integration with the Safe](https://blog.gnosis.pm/the-gnosis-safe-now-has-a-wallet-connect-integration-61000b098657). 7 | Moving forward, the Gnosis Ecosystem Fund will provide microgrants to teams interested in creating a WalletConnect integration that is compatible with the Gnosis Safe We will support successful integrations with up to $3,000 in funding. 8 | 9 | ## How can I apply? 10 | At the end of each month, we will give out one grant, although teams can submit a proposal at any time. Please complete [this document](https://github.com/gnosis/GECO/blob/master/WalletConnect%20Microgrant/Application%20template.md) if you are interested in applying. 11 | 12 | ## How to submit your proposal 13 | * Fork the GECO repo 14 | * Create a new file with your project’s name 15 | * Outline your proposal in that file 16 | * Create a Pull Request to merge your submission into our repository 17 | 18 | ## Is my project eligible? 19 | We will only consider projects with a user base who have not received funding from VCs or token sales. 20 | 21 | ## What functionalities do I need to deliver? 22 | 23 | The integration with the Safe through WalletConnect should have the following attributes: 24 | 25 | * **Supports WalletConnect** > [v1.0.0](https://docs.walletconnect.org/) (i.e. not v0.7.x) 26 | * **Compatible with the Safe** 27 | * The dapp should not use message signing 28 | * If you do use message signing, you need to build a workaround for the Safe (eg. Like the one done for [Alchemy](https://github.com/daostack/alchemy)) 29 | * Teams can also work with us on a contract signature integration please note that this is not a live feature yet, but will be available on Android by DappCon (Aug 21st) 30 | * **Runs on mainnet** 31 | * **Visible WalletConnect integration** 32 | * The WalletConnect connection should be directly visible in the UI e.g. https://web3connect.com/ 33 | * **Bridge server** 34 | * You should host your own bridge server or use the Gnosis bridge server hosted at https://safe-walletconnect.gnosis.io 35 | 36 | ## Some final points... 37 | The WalletConnect integration must be open source as well as your project. 38 | You should create a screencast or video on how to use the Safe with your dapp via WalletConnect as shown in this example. 39 | 40 | ## Additional Information: 41 | * Gnosis Safe WalletConnect integration: https://github.com/gnosis/wallet-connect-swift 42 | * Blog Post: The Gnosis Safe Now Has a WalletConnect Integration! 43 | * WalletConnect Docs: https://docs.walletconnect.org 44 | * Examples: https://walletconnect.org/apps 45 | -------------------------------------------------------------------------------- /Proposals/Funded Projects/MultiCard.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | MultiCard 5 | 6 | ### Team members 7 | Dietmar Hofer, Peter Grassberger, Thomas Haller (all members of [lab10 collective](https://lab10.coop)) 8 | 9 | ### What project are you building 10 | We want to build an MVP which allows holders of [Blockchain Security 2Go smart cards](https://github.com/infineon/blockchain) to sign Safe transactions with a Raspberry Pi connected NFC reader. 11 | 12 | ### Why did you decide to build it 13 | This NFC smard cards combine high safety and usability. They encapsulate the private key and make signing transactions as easy as scanning the card with an NFC reader. 14 | The lack of a way to backup the private key is a big issue for many conventional use cases. But this issue can be mitigated by using such keys as key shares of a multisig. 15 | 16 | We believe that using such smard cards in combination with Gnosis Safe unlocks many interesting use cases, thus we want to explore that, starting with an MVP. 17 | 18 | ### How long will it take 19 | We plan to have a nice MVP in one month. 20 | 21 | ### How much funding are you requesting 22 | We're requesting the minimal amount of 5k $. 23 | 24 | ### How did you hear about the GECO 25 | A lab10 team member told me about it a few hours before the first submission deadline. 26 | 27 | ## Your Proposal 28 | ### Project description 29 | The MultiCard MVP will consist of 30 | * a setup module which allows to initiate cards as key holders for a Safe contract 31 | * a simple UI which allows to initiate Safe transactions and shows the state of that transaction (e.g. process of collecting signatures, lifecycle of the wrapping Ethereum tx) 32 | * a background process which handles NFC communication with the cards and communication with the Gnosis Safe contracts 33 | 34 | We already had an opportunity to get hands-on with this smart cards at a Hackathon hosted in the context of its first public release ([link](https://letscluster.com/infineon-hackathon/)). In the context of this Hackathon we also started studying the Gnosis Safe contract system and got intrigued about the possibilities it opens up. 35 | At lab10 we are also working on the concept and initial implementation of [Minerva - a digital wallet](https://lab10.coop/en/projects/minerva) for identities, valuables and credentials. 36 | 37 | This MVP is intended to help us explore and understand the best ways to build easy to use and easy to explain/understand applications and systems which are needed in order to unlock the advantages of decentralized systems to a larger audience. This could for example be a backup/recovery mechanisms for the Minerva wallet, or standalone applications which solve very specific problems (e.g. use cases which nowadays still require paper to travel around in order to collect ink signatures). 38 | 39 | ### Features 40 | We plan to implement the MVP as a node.js / web application which will of course be released as open source. 41 | 42 | ### Team description 43 | * [Dietmar Hofer](https://github.com/d10r) dived into Ethereum in 2016, learning blockchain basics [by implementing one](https://github.com/d10r/l10chain), likes to explore [what else could be done](https://github.com/lab10-coop/streem-poc). 44 | * [Peter Grassberger](https://github.com/PeterTheOne) is an avowing [pirate](https://www.piratenpartei.at/) who actively defends our freedom and privacy in the digital space. He already wrote several Dapps at lab10. 45 | * [Thomas Haller](https://github.com/SurfingNerd) likes surfing and gaming, in between he also maintains the governance Dapps and Explorer of the [ARTIS blockchain](https://artis.eco) (a lab10 initiated Ethereum sidechain). 46 | -------------------------------------------------------------------------------- /Proposals/wave2/LevelKFutarchy.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | > Futarchy Signalling with PM 2.0 5 | ### Team members 6 | John Kelleher - https://www.linkedin.com/in/john-kelleher-86190b/ 7 | Mike Calvanese - https://www.linkedin.com/in/michael-calvanese-940b356/ 8 | Emily Williams - https://www.linkedin.com/in/ecwilliams66/ 9 | Chris Whinfrey - https://www.linkedin.com/in/christopher-whinfrey-5a166783/ 10 | 11 | ### What project are you building 12 | We are building a futarchy signalling market using Gnosis prediction markets (PM) 2.0, with the idea that they can be used alongside dxDAO decisions. This is also a step towards allowing voters to delegate votes to futarchy markets in the dxDAO or other DAOs. We will be building on work previously done with Gnosis (https://github.com/levelkdev/fcr-project, https://github.com/levelkdev/fcr-js) and Aragon (https://github.com/aragon/nest/pull/97). 13 | 14 | **Futarchy Setup** 15 | Success Metric - This implementation will use Magnolia market cap as the success metric for a decision. An oracle for magnolia's market cap will be developed. 16 | 17 | Decision Function - The "decision" will be made based on the outcome that has the higher predicted marketcap for the largest percentage of the decision period. However, this "decision" will only be for display purposes and will not result in any action while the implementation remains as a signalling market. 18 | 19 | Tokenized Event Configuration - For each futarchy decision, a categorical event for the decision being accepted or not accepted will be deployed. The outcome tokens of the categorical event will be used as the collateral tokens for two scalar events that will be used to predict the marketcap given that outcome. For more information on this setup, please see the first configuration described [here.] (https://ethresear.ch/t/possible-futarchy-setups/1820) 20 | 21 | LMSR Markets - For each scalar event, an LMSR market will be started for the trading of the scalar event's outcome tokens. LMSR markets require up front funding to ensure a sufficiently liquid market. The burden of funding the market will lie on the user that creates the futarchy decision. 22 | 23 | 24 | ### Why did you decide to build it 25 | We want to enable DAOs to vote their values and bet their beliefs. 26 | 27 | 28 | ### How long will it take 29 | 3 months 30 | 31 | ### How much funding are you requesting 32 | $108,000 USD (cost of 2.5 developers over three months) 33 | 34 | ### How did you hear about the GECO 35 | Through the Gnosis team. 36 | 37 | 38 | ### Team description 39 | Level K is an established ethereum development company that has been operating since fall of 2017. We provide blockchain technical architecture, auditing, and development. We have previously worked on futarchy with Gnosis (presented at DappCon) and Aragon (presented at Aracon). 40 | 41 | ### Timeline, Milestones and Deliverables 42 | 43 | **Phase I** 44 | Gnosis PM 2.0 Integration 45 | 46 | **Deliverables** 47 | - Aragon futarchy upgraded to use Gnosis PM 2.0 contracts 48 | - Testnet launch of example Aragon DAO 49 | 50 | **Time and Price Estimate** 1 month (Feb 18th - March 18th) / 36,000 USD 51 | 52 | **Phase II** 53 | dxDAO Adaptations 54 | 55 | **Deliverables** 56 | - UI improvements for main net launch 57 | - Upgraded scalar market resolution oracle compatible with dxDAO. Will likely use market cap of magnolia token as the success metric and DutchX for token information. 58 | - Implement a way to trigger signalling markets when dxDAO decisions are launched. 59 | 60 | **Time and Price Estimate** 1 month (March 18th - April 18th) / 36,000 USD 61 | 62 | **Phase III** 63 | Main Net Launch of Signaling Market 64 | 65 | **Deliverables** 66 | - Test net launch of signaling market 67 | - Main net launch of signaling market 68 | - dxDAO community outreach 69 | - Blogging and PR to encourage 70 | 71 | **Time and Price Estimate** 1 month (April 18th - May 18th) / 36,000 USD 72 | 73 | 74 | -------------------------------------------------------------------------------- /Proposals/wave2/Fairdex v2.md: -------------------------------------------------------------------------------- 1 | # GECO proposal: FairDex v2 2 | 3 | ## Project Overview 4 | 5 | **Project name** 6 | 7 | > FairDex v2 8 | 9 | **Team members** 10 | 11 | - Manuel García 12 | - Leo Lower 13 | - Sebastián Galiano 14 | - Lisandro Corbalán 15 | 16 | This is the same team that designed and developed FairDex v1, the first UI that enabled bidding on the DutchX platform. 17 | 18 | **What project are you building** 19 | 20 | > FairDex is the first UI dApp that allows traders to bid on the DutchX platform. Fardex v1 demonstrated that it is possible to transform complex protocols into usable applications allowing common users to reap the benefits of a fair and decentralized trading platform. 21 | > FairDex v2 will go much further, helping traders make the right decisions in time and educating them in the works of the underlying platform. It focuses on improving the duchX users onboarding and platform awareness. 22 | 23 | **Why did you decide to build it** 24 | 25 | > After the successful release of FairDex and a lot of (mostly) positive feedback we want to present a proposal to improve FairDex, focusing on the UX to achieve mass adoption. 26 | > Most people know about fairdex because of the $1M DAI-ETH auction initiated by gnosis. 27 | > We want to capitalize on the momentum generated by the successful launch and show that the platform will continue to evolve after this event is over. 28 | > 29 | > Some of these ideas come directly from users that provided feedback through the `publick DutchX group` and `dxDAO Public Chat` telegram channeels as well as direct contacts and Google meet live events. Others come from the original v1 proposal that was reduced in scope to achieve a working MVP on time for the release of DutchX v2 smart contracts. 30 | 31 | **How long will it take** 32 | 33 | > ~ 200 hours 34 | 35 | **How much funding are you requesting** 36 | 37 | > $13.000 38 | 39 | **How did you hear about the GECO** 40 | 41 | > Protofire, the team behind FairDex has been working closely with Gnosis for several months in order to deliver the best possible bidder experience on top of the DutchX protocol. FairDex v1 was one of the first projects that came to life thanks to the Gnosis Ecosystem Community Fund. 42 | ## Your Proposal 43 | 44 | **Project description** 45 | 46 | *FairDex is becoming a key member of the DutchX family. Thanks to the GECO and close collaboration with Gnosis team we have been able to create a product we are really proud of.* 47 | 48 | FairDex v2’s new additions complements the initial MVP with a set of features that will give users that confidence necessary to operate on a more mature platform. Price analytics, detailed graphs with historic and predicted prices, price comparison with other exchanges and personalized notifications will provide both experienced and new traders all the information they need to make good decisions when choosing the DutchX as their trading platform. 49 | 50 | **Team description** 51 | *Protofire is a team of engineers which helps token-based protocols and developer platforms accelerate growth of their ecosystems. By providing hands-on coding and contributions, Protofire specializes in supercharging developer adoption and network usage. We ship applications, engineer elegant smart contracts, craft awesome developer tools (SDKs/APIs/sample apps), or simply improve performance/cost of oracles.* 52 | *Protofire works exclusively with entrepreneurs who are builders of decentralized infrastructure protocols, applications and ecosystems. http://protofire.io* 53 | 54 | **Timeline, Milestones and Deliverables** 55 | The work will be done in 2-week sprints, each one with a set delivery date in which a demonstration will take place. Feedback for each sprint will be included on the following sprint. 56 | 57 | 58 | **Sprint 1** 59 | **Deliverables** 60 | 61 | - Simplify user interaction by bundling actions. 62 | - Add video tutorial and help section. 63 | - Make all “Max” labels clickable. 64 | - UI tweaks. 65 | 66 | **Time and Price Estimate** *80 hours. $5200.* 67 | 68 | 69 | **Sprint 2** 70 | **Deliverables** 71 | 72 | - Very small balances are not user friendly. 73 | - Improve notifications explaining what each action means and the next steps to follow. 74 | - Current price curve chart over time. 75 | 76 | **Time and Price Estimate** *80 hours. $5200.* 77 | 78 | 79 | **Sprint 3** 80 | **Deliverables** 81 | 82 | - Sell or Bid volume chart over time. 83 | - Historical closing price charts. 84 | 85 | **Time and Price Estimate** *40 hours. $2600.* 86 | 87 | 88 | -------------------------------------------------------------------------------- /Proposals/wave2/token-registration-and-push.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | 5 | Token registration and push 6 | 7 | ### Team members 8 | 9 | Mikko Ohtamaa 10 | Ville Sundell 11 | Voith Mascarenhas 12 | 13 | ### What project are you building 14 | 15 | A protocol that allows the end user to register token entries in different wallets easily. 16 | 17 | ### Why did you decide to build it 18 | 19 | Token and tokenised assets drive the decentralised finance ecosystem. When new users are onboarded, the first UX challenge is usually get and display different tokens in the wallet the user is having. The user wants to confirm they receive tokens sent to the user. 20 | 21 | Currently all wallet providers manage default centralised token lists that their wallets support. This is not good as 1) centralisation and whitelisting is against the blockchain ethos 2) for a token issuer updating different token lists for wallets is very cumbersome. 22 | 23 | We expect the number of tokens to grow thousands folds in the future. Managing good centralised list will be impossible. Thus, we propose a different solution. A way for the issuers to push and easily allow users to register tokens in their wallets when the user receives the tokens for the first time. 24 | 25 | ### How long will it take 26 | 27 | 3-5 months. 28 | 29 | ### How much funding are you requesting 30 | 31 | $74,000 32 | 33 | ### How did you hear about the GECO 34 | 35 | A personal relationship with Gnosis. 36 | 37 | ## Your Proposal 38 | 39 | ### Project description 40 | 41 | A protocol candidate and the first reference implementation to push token registrations with Gnosis SAFE wallet and one other wallet provider. 42 | 43 | ### Features 44 | 45 | - An ERC proposal for a token registrations 46 | 47 | - A protocol to push a token registration over WalletConnect API 48 | - If the user is using a decentralised service with WalletConnect, the service can registers the tokens needed for it in the user wallet 49 | - A protocol to push a token registration by scanning a QR code 50 | - Works with mobile wallets - the issuer published the registration QR code on their website 51 | - A protocol to push a token registration via URL handler or copy-paste 52 | - A use case for MyEtherWallet like wallets 53 | - A use case for a web browser plugin wallets 54 | - A protocol to automatically register and show any tokens send to the user 55 | - A mechanism against spam / airdrops to ensure random airdrops do not cause user distraction 56 | - Reputation and fee based opt-in decentralised system for issuers and users to co-operate e.g. using GNO token 57 | - An example project with HTML/JS for developers how to integrate this with their dApps and websites 58 | 59 | 60 | ### Team description 61 | 62 | All team members are on TokenMarket payroll. TokenMarket have issued out 30+ utility tokens and is now working with regulated security token issuances and security token decentralised exchange. We work with Python backend, JavaScript/React frontends. 63 | 64 | ### Timeline, Milestones and Deliverables 65 | 66 | **Phase I: specification** 67 | 68 | ERC proposal for the specifications 69 | - JSON format 70 | - WalletConnect changes needed 71 | - Gather feedback from Ethereum community with ERC process and asking in a person in meet ups and hackathlons 72 | 73 | **Time and Price Estimate** 74 | 75 | 1 working month 76 | $12,000 77 | 78 | **Phase II: reference implementation with Gnosis SAFE ** 79 | 80 | **Deliverables** 81 | 82 | A way to register tokens for the Gnosis SAFE user wallet using two different methods (e.g. WalletConnect or QR scan). 83 | - Browser plugin changes 84 | - Mobile app changes (Android OR iOS) 85 | - Server-side infrastructure changes (Gnosis SAFE WalletConnect) 86 | An example HTML/JS application how to implement and test this 87 | A promotion of the example for Ethereum developer community. 88 | 89 | **Time and Price Estimate** 90 | 91 | 3 working months 92 | $36,000 93 | 94 | **Phase III: from concept to robust implementation** 95 | 96 | - Another mobile app support (Android OR iOS remaining) 97 | - A decentralised system that allows user wallets to receive token registration without explicit action needed from the user, focused on good UX and spam protection 98 | 99 | **Time and Price Estimate** 100 | 101 | 3 working months 102 | $36,000 103 | 104 | ### Others 105 | 106 | TokenMarket is facing the challenge of having the securities token show up in the third party wallets. After dozens of issuances and working with multiple wallet providers, we believe we have the best experience can solve this problem by working with the wallet providers and other industry partners to solve this problem for the ecosystem as a whole. We also believe that Gnosis SAFE is a good candidate for the reference implementation, as all of their source code is open and Gnosis is open for co-operation. 107 | 108 | For another reference implementation, other than Gnosis SAFE wallet, we will open a dialogue with different wallet providers and see how would be likely to implement ERC. 109 | -------------------------------------------------------------------------------- /Proposals/conditional_investment_interface.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | > Simple Conditional Investment Interface 5 | ### Team members 6 | > [David Johnston](https://www.linkedin.com/in/david-johnston-50461b141/) 7 | ### What project are you building 8 | > Gnosis conditional token based prediction markets have been used to support DAO decision making using [Gnosis Impact](https://impact.gnosis.io/), but ordinary prediction markets are [inefficient](https://forum.gnosis.io/t/change-the-funding-structure-of-gnosis-impact-markets/794/15) for estimating the impact of a proposal. 9 | 10 | > "Conditional investment" is a more efficient market structure for estimating proposal impact. Given a proposal with "yes" and "no" outcomes, a conditional investment market allows people to exchange USDyes for ORGTOKENyes and USDno for ORGTOKENno. The USDyes:ORGTOKENyes market reflects the anticipated value of ORGTOKEN if "yes" is the resolution and the USDno:ORGTOKENno market reflects the anticipated value of ORGTOKEN if the resolution is "no". Unlike standard prediction markets, conditonal investment liquidity providers aren't exposed to large losses if they fail to correctly predict the ultimate outcome when providing their initial investment. 11 | ### Why did you decide to build it 12 | > I am excited to see a world in which conditional investment markets can provide reliable answers to crucial questions and anyone can profit from using their knowledge, skill and judgement to discover answers to these questions. Ethereum is where these ideas are being most actively developed and where, due to DeFi and DAOs, there are potential users interested in experimental decision making technologies and novel financial instruments. 13 | 14 | > A simple conditional investment interface may be useful for GnosisDAO to pursue its mission of showing that futarchy can be a high-performance decision making technology, and given my interests it is personally valuable to me to learn about development on Ethereum. 15 | ### How long will it take 16 | > I am a novice at both web development and Ethereum development, and will be working on it part time. I estimate the project will take one month. 17 | ### How much funding are you requesting 18 | > $750 19 | ### How did you hear about the GECO 20 | > GECO grants were explained to me on the GNOSISDAO forum. 21 | 22 | ## Your Proposal 23 | ### Project description 24 | > The key infrastructure for conditional investment has already been built and deployed to Ethereum mainnet, but but actually making the trades is a deeply convoluted process. I want to build an interface for conditional investment removes two of the biggest obstacles to conditional trades: 25 | 26 | - The need to make transactions on two different interfaces, one for splitting tokens and one for exchaning them 27 | - The need to manually look up conditional token addresses and import them to the exchange interface 28 | 29 | > I believe solving these problems will allow for experimentation with conditional investment with some trading volume, though much more work would be required for a platform intended for general use and large volumes. An experimental platform can be used by GnosisDAO to reintroduce impact estimates to its GIPs in a more cost-efficient manner and to experiment with other ideas related to conditional investment such as creating markets for hyped proposals like EIP 1559 or [measuring the accuracy of impact forecasts](https://docs.google.com/document/d/128PSz7i5JDArrz5EhTeowfzdrlqZPqiyKUP9eLRicwY/edit?usp=sharing)) 30 | 31 | > GnosisDAO has a commitment to exploring and scaling governance with futarchy, and has an interest in developing a more refined platform for conditional investment. A minimal implementation that can serve as a starting point to identify early adopters and learn about key concerns and issues. 32 | 33 | ### Features 34 | The conditional investment interface will combine the condition list, split and wrap functions of the [Conditional Token Explorer](https://cte.gnosis.io) with the [Uniswap](https://app.uniswap.org/) exchange interface. 35 | 36 | In addition to normal Uniswap interface interactions: 37 | - Swap page: 38 | - Select from a list of conditions with readable names 39 | - Populate the currency list with collateral and wrapped conditional tokens related to the selected condition 40 | - Split collateral against the condition to a default partition with one outcome in each partition 41 | - Wrap conditional tokens to ERC20 42 | 43 | This will use existing smart contracts - Uniswap Core + Router, Conditional Tokens and ERC1155-ERC20 wrapper. I believe a WIP [updated ERC20 wrapper](https://github.com/gnosis/1155-to-20/tree/feature/support-dynamic-fields) will be needed as currently all wrapped tokens have the same name so users will not easily be able to recognise which tokens they are trading. 44 | 45 | ### Team description 46 | > > [David Johnston](https://www.linkedin.com/in/david-johnston-50461b141/) ([github](https://github.com/davidoj)) - working on an AI PhD & as a consulting data scientist 47 | ### Timeline, Milestones and Deliverables 48 | 49 | - Uniswap trade interface with split & wrap capability (April 23, 2021) 50 | - Medium article explaining conditional investment & how to do it with splits and trades (April 30, 2021) 51 | 52 | ### Others 53 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | :bangbang:**_UPDATE: The Gnosis Ecosystem Fund was discontinued._** Projects can now directly apply for funding through the [GnosisDAO](https://forum.gnosis.io/t/readme-gnosisdao-governance-process/736) 2 | 3 |

4 | 5 |

6 | 7 | **_Creating an environment where ambitious teams can expand and shape the blockchain ecosystem towards a redistributed future._** 8 | 9 | The Gnosis Ecosystem Fund empowers teams to drive the global adoption of decentralized applications by leveraging the full potential of Gnosis' products and protocols. Our mission is to create a collaborative environment where ambitious projects can expand and shape the Ethereum ecosystem. 10 | 11 | We provide selected applicants with funding, mentoring, and outreach support to help them activate and engage with the community around their project. Our team also offers resources to onboard students and developers new to decentralized technologies. To us, developing the community means investing in diverse talent with a variety of interests and backgrounds. 12 | 13 | We welcome you to explore a diverse range of topics, such as tooling, infrastructure, and research, that fall in line with the products we're building at Gnosis. Are you enthusiastic about building modules and integrations for our products, enhancing user experience, or passionate about new market mechanisms and governance. 14 | 15 | Well, this is your opportunity to #BUIDL! 16 | 17 | To reach our goal of a decentralized future, it is imperative that we support developers who want to build on distributed platforms. We believe that the Gnosis Ecosystem Fund will bring us one step closer to the redistributed future we’re imagining! 18 | ### What kind of projects are we looking for? 19 | 20 | The main focus of the grant is to support projects that further the Gnosis ecosystem and our core mission to redistribute the future. Your proposed project should be directly connected to our products and vision. 21 | Proposals should focus on: 22 | 23 | - Building on top of one of our platforms, or 24 | - Integrating our smart contracts, or 25 | - Creating tools/modules/extension for our products 26 | 27 | Our platforms and potential buidl ideas include: 28 | 29 | - Gnosis Safe: recovery modules, transfer limits or Gnosis Safe integration into Dapps 30 | - PM: prediction market use cases, oracle integrations, wallet integrations or a futarchy interface 31 | 32 | Furthermore, we will also consider projects involved in research and education related to: 33 | 34 | - Prediction markets/ Futarchy 35 | - Market mechanism 36 | - Governance 37 | - Dapp useability 38 | - Dapp scalability 39 | 40 | ### What are we offering? 41 | 42 | **Funding** 43 | 44 | We want to support a wide range of projects in both topic and scale. For this reason, we are offering grants of between $5.000 and $100.000. The allocated funding will reflect the scope and ambition of your proposal. To get a sense of how much funding to request for your proposal, check out our [bounties](https://gitcoin.co/profile/GnosisEcosystemFund) and current projects for an estimation. 45 | 46 | **Mentoring** 47 | 48 | The Gnosis Ecosystem Fund provides more than just financial support. You will also be assigned and receive support from a Gnosis developer who will act as your project mentor. Furthermore, we can connect you to experts in the field and to experienced legal, admin, and financial advisors as needed. As our ecosystem continues to develop, we hope to foster a supportive community where past projects are willing to support and mentor new projects. 49 | 50 | **Community/ Outreach** 51 | 52 | Teams will have the option of working at [Full Node](https://www.fullnode.berlin/), our co-working space in Berlin. The Gnosis Communications team will provide branding and outreach support to encourage engagement with the larger blockchain community. Bigger projects will have the opportunity to present their work at [DappCon](https://dappcon.io/). 53 | 54 | ### How to apply for a grant: 55 | From 2020 on we will accept application on a monthly basis. Submit your proposal until the end of each month and will get back to you. 56 | 57 | ### Your proposal should include: 58 | * What you want to build 59 | * Why you want to build it 60 | * The overall goal of your project 61 | * A detailed technical description of your project 62 | * A schedule including milestones and overall timeframe 63 | * How much funding you’d like to request 64 | * Your programming portfolio 65 | * A brief description of your team 66 | * Where you've applied for other sources of funding if applicable 67 | 68 | Check out our template [here](https://github.com/gnosis/Gnosis-Ecosystem-Fund/blob/master/Proposals/ProposalTemplate.md)! 69 | 70 | ### How to submit your proposal 71 | * Fork the [Gnosis Ecosystem Fund GitHub repository](https://github.com/gnosis/Gnosis-Ecosystem-Fund) 72 | * Create a new file with your project’s name 73 | * Outline your proposal in that file 74 | * Create a Pull Request to merge your submission into the our repository 75 | 76 | #### Pitches 77 | We will select up to 10 teams per submission round to pitch their project to a selected group of people from the Gnosis team. 78 | 79 | ### Others: 80 | The Intellectual Property of your projects will be owned by you, and you are responsible for hosting, maintaining and, the compliance of your project. 81 | 82 | ### Additional Information 83 | * Reach out to our Devs and Product Managers via [Gitter](https://gitter.im/gnosis) 84 | * We put together different bounties for tools/modules/ extension which help improve our products. Check them out [here](https://gitcoin.co/explorer?keywords=gnosis&order_by=-web3_created) 85 | * Check out the documentation of our [Prediction markets](https://gnosis-apollo.readthedocs.io/en/latest/) and the [Gnosis Safe](https://gnosis-safe.readthedocs.io/en/latest/) protocols 86 | -------------------------------------------------------------------------------- /Proposals/Wave1/jiffy.md: -------------------------------------------------------------------------------- 1 | # Jiffy Proposal 2 | 3 | ## Abstract 4 | 5 | Ethereum allows developers to create applications without worrying about servers, frontend, security of data and a plethora of other stuff web2.0 applications have to worry about. Its a great feeling to deploy the contract on a testnet and just share the contract address to possible users. Interacting with contracts deployed is tough without a dedicated front-end even for experienced technocrats, you have to get the abi, contract address,make sure he/she has ether, know the inputs and expected outputs to make sure you are doing it right. A user runs out of patience and/or motivation to try out your contract if he has to go through so much hassle. We want to encourage on boarding of new users so that they can interact with contracts in a **jiffy** without worrying about the overhead stuff. We want to make trying out contracts as straight-forward as possible for new users as well as existing devs. 6 | 7 | 8 | ### Features 9 | 10 | - Creation of markdown labels/widgets/QR(anything behind which we can hide a URI :)) which can be attached to readme files of github repo, users can just click that to send a single or multiple transactions for a required functionality.For Example: approve and transferForm can be done with a single label. Interesting thing to note is these labels can also become `testing` or `autoDeployment` tools with no changes whatsoever. 11 | 12 | - Allowing meta transactions ie users can interact with the contract with erc20 tokens or with no ether/erc20 tokens. We plan to allow the contract creators to `seed` their contract with some ether/tokens using which initial users can interact with contracts with no ether or token. 13 | 14 | - Every contract will have a unique URI which can be shared everywhere just like domain name, users could visit the URL and interact with the whole contract ,we allow the contract owner to pin frequently used dapps at the top for better usability. 15 | 16 | - Allowing users to watch a specific types of transactions using ethereum events. For example a user may like to get an email when he gets some tokens , when someone withdraws from his multisig, when someone interacts with one of his contracts and a 1000 other cases. Users will be able to watch these events easily and be at ease. 17 | 18 | - View dapps by traffic , recently created and multiple other categories. 19 | 20 | - Allow users to bunch together different labels created by others. For example someone created a label for "Approve and transferFrom" , you could add "StakeFor" to it and display it on your readme as "Staking" for your contract implementing EIP 900. 21 | 22 | - Matching contract to nearest interface. For example we could show contracts that match ERC-20 interface by percentage while user is interacting with it.So you would know that you are interacting with a contract which is 80% ERC20 . 23 | 24 | - `Create PWA for your dapp` using which users after being redirected to a particular contract can pin it to their homescreen by creating a PWA for using later. 25 | 26 | UI/UX , usability being the primary motivation we aim to bring new users onboard as quickly as possible without knowing anything about blockchain. This could also help in first experimenting with new contracts/dapps without building a front end and then when dapp gains enough traction you can build a custom UI/UX 27 | 28 | ### Deliverables 29 | 30 | We have several things in the roadmap to make this happen: 31 | 32 | 1. Creation of Mockups, Database models. 33 | 2. Contract Registration. 34 | 3. Label Registration. 35 | 4. AUTH using ethereum signatures. 36 | 5. Meta Transaction support. 37 | 6. Event Watchers. 38 | 7. Contract Interface Matching. 39 | 8. Create PWA for dapp. 40 | 9. Sort dapp by various categories. 41 | 42 | 43 | ##### Tech Stack 44 | 45 | We will be using React+Typescript on the frontend and golang on the backend with mongodb as the database 46 | 47 | 48 | ## Grant size 49 | 50 | Funding: 60k-80k USD worth ETH,delivered in chunks paid out before/after achieving deliverables 51 | 52 | ## Integrations 53 | 54 | We dont want to reinvent the wheel we want to build a car hence we encourage use of existing solutions to build up synergy. 55 | 1. Dappratus(https://github.com/austintgriffith/dapparatus) 56 | 2. Dagger(https://matic.network/dagger/) 57 | 3. Remix 58 | 4. EthFiddle 59 | 60 | ### Team 61 | 62 | #### Vaibhav Chellani - Project Lead, Blockchain and Backend Developer 63 | Commitment: Part time 64 | Links: github(https://github.com/vaibhavchellani) 65 | 66 | #### Shubham Singh - Full Stack Developer 67 | Commitment: Full time 68 | Links: github(https://github.com/imshubhamsingh) 69 | 70 | #### Kautuk Kundan - Front End Developer 71 | Commitment: Full time 72 | Links: github(https://github.com/kautukkundan) 73 | 74 | PS: We have completed grant projects for other projects like Zilliqa successfully: https://github.com/merkaliser/scilla-vanilla 75 | 76 | ### BurnRate 77 | 5 devs : 2 Full time, 1 Part time 78 | 3 - 4 month job 79 | $20k USD per month 80 | 81 | ## Development timeline 82 | 83 | The development timeline will be the following one in regards to each deliverable: 84 | 85 | 1. First Month - Deliverable 1,2,3,4 86 | 2. Second Month - Deliverables 5,8,9 87 | 3. Third Month - Deliverables 6,7 88 | 4. Fouth Month - Testing and Refactoring 89 | 90 | ## Category 91 | 92 | We would most probably lie on the `dapp usability` side . We will allow users to interact with multiple contracts without a custom frontend thus lowering the barrier to create a proper usable product , developers just have to write contracts now! 93 | 94 | PS: We have started building 95 | 1. [FrontEnd](https://github.com/vaibhavchellani/jiffy) 96 | 2. [BackEnd](https://github.com/vaibhavchellani/jiffy-backend) 97 | 3. [Designs](https://drive.google.com/open?id=1t-Nl_II8Vs_z35HQuVCgk2fc_QvPvSnR) 98 | -------------------------------------------------------------------------------- /Project Ideas/Safe Apps Grants.md: -------------------------------------------------------------------------------- 1 | # Safe Apps Grants 2 | ### Get started building with Safe Apps and receive up to $3,000 3 | 4 | 5 | ### What are Safe Apps? 6 | 7 | 8 | Safe Apps allow users to interact with Ethereum applications straight from the Safe Multisig interface. Users are able to customize their own interface by selecting from a list of apps. If an app is not listed in the UI by default, it’s possible to add a custom app by simply putting in the link to that app. Once apps are added, interacting with them will feel like executing any other multisig transaction. If your Safe has multiple signatures required to execute a transaction, those same requirements apply to Safe Apps. 9 | 10 | **We think this makes Safe Multisig a browser into the “internet of value” and we want to build this browser together with the entire Ethereum ecosystem.** 11 | 12 | See the [Safe Apps announcement post](https://blog.gnosis.pm/introducing-gnosis-safe-apps-faef908f69c6) for more details. 13 | 14 | ### What are Safe Apps Grants? 15 | We are introducing Safe Apps grants to incentivize the community to extend the functionality of the Safe Multisig and enable small projects or independent developers to build their first Safe App. 16 | 17 | ### Scope 18 | 19 | Safe Apps are a blank canvas with a lot of opportunities to build useful applications and extend the feature set of the Safe Multisig. Just a few example use-cases include: 20 | 21 | - Swapping tokens on a decentralized exchange such as Kyber or Uniswap 22 | - Buy cover on Nexus Mutual 23 | - Open / manage Maker Vaults 24 | - Register and manage ENS domains 25 | - Mixer integration (e.g. Tornado Cash) 26 | - ... and many more 27 | 28 | ### Who can participate? 29 | 30 | Anyone can participate in this grant program and start building Safe Apps. However, we will only pay out grants to projects/ companies with less than 10 members. Also, we will only consider Safe Apps from projects/ teams that have not received funding from VCs or token sales. 31 | 32 | ### Grant Payouts 33 | 34 | Grants are paid out at the sole discretion of Gnosis, with varying rewards depending on the perceived complexity of the app. As a rough heuristic, we have added the amount of work we would expect to be put into building a Safe App to achieve a specific reward level. 35 | 36 | ### Grant Levels 37 | 38 | **Low complexity: $750** 39 | (1-3 days of work) 40 | 41 | **Medium complexity: $1,500** 42 | (3-10 days of work) 43 | 44 | **High complexity: $3,000** 45 | (>10 days of work) 46 | 47 | 48 | 49 | ### Ressources 50 | 51 | Here are a few tools and resources that will help you build your first Safe App: 52 | 53 | * [Documentation](https://docs.gnosis.io/safe/docs/sdks_safe_apps/) 54 | * [Safe App SDK](https://github.com/gnosis/safe-apps-sdk) 55 | * [UI Styleguide](https://drive.google.com/file/d/18QxvqPzJ39Da3peSId0hJe9dL2mSB818/view) 56 | * [Reusable React Components](https://components.gnosis-safe.io) 57 | * [Safe Multisig Web Interface](https://github.com/gnosis/safe-react) 58 | 59 | Please let us know if you have ideas to improve the developer tooling! 60 | 61 | ### How to apply for a Grant? 62 | 63 | To ensure your Safe App is considered "valuable" by the Gnosis team, please submit your proposal beforehand here: 64 | 65 | 1. Fork the [GECO repo](https://github.com/gnosis/GECO). 66 | 1. Create a new file with your project’s name in the Proposals folder 67 | 1. Outline your proposal in that file including the use case and functionality of the Safe App (250-500 words). 68 | 1. Create a Pull Request to merge your submission into our repository. 69 | 70 | The applications are evaluated on a rolling basis, and you can expect a decision regarding a potential grant payout within 14 days. 71 | 72 | 73 | ### Evaluation / Requirements 74 | 75 | In order to be eligible for a grant, a Safe App needs to fulfill the following criteria: 76 | 77 | #### Valuable 78 | Safe Apps that are considered for one of the above-mentioned grants, must be considered “valuable” by the Gnosis team. We want to make sure Safe Apps are built around actual use cases. This is a subjective evaluation, but factors included in the consideration are the potential size of the user base, expected transaction volume, or user experience improvements. 79 | 80 | #### Production-ready 81 | The Safe App must be ready to be used by actual Safe Multisig users on mainnet. In case your Safe App interacts with smart contracts, make sure they are audited and generally perceived as production-ready. Your Safe App should overall be considered “safe” and feature a decent user experience. Risks associated with the usage of the Safe App must be communicated to the user transparently. 82 | 83 | #### Multisig-compatible 84 | It must be possible to integrate the Safe App into the [Safe Multisig web interface](https://gnosis-safe.io/app/#/) via URL. Safe Apps must also be compatible with the asynchronous nature of a Multisig wallet. This means that they should also work considering that a) multiple people might be required to sign a transaction and b) there might be some time delay between a Safe App action being initiated and its execution on the blockchain. We highly recommend to stick to the UI Styleguide, and use the reusable React components provided in the Resources section below. 85 | 86 | ### How to Submit the Final Safe App? 87 | 88 | When you have finished work on the Safe App, please update your proposal with the following information: 89 | 90 | * Link to the open-source repository including all code associated with your Safe App 91 | * Link to a hosted version of your Safe App (ideally on IPFS) 92 | * Walkthrough screencast of your Safe App 93 | 94 | After your final submission, we will evaluate the Safe App, and initiate the payout of the grant. Note that there is no guarantee of a grant being paid out before your submission has been evaluated. If the submission lacks quality, Gnosis reserves the right to not pay out the grant. 95 | 96 | ### Support 97 | 98 | For developer support, please join the #safe channel on our [Discord](https://discord.gg/FPMRAwK). 99 | 100 | -------------------------------------------------------------------------------- /Proposals/Funded Projects/BondedCurvesForDAOs.md: -------------------------------------------------------------------------------- 1 | # GECO app 2 | 3 | ## **Project Overview** 4 | 5 | --- 6 | 7 | ### **Project name** 8 | 9 | Bonded Curves for DAOs 10 | 11 | ### **Team members** 12 | Jordan Ellis 13 | Asgier Sognefest 14 | Seth Fabius 15 | Ori Shimony 16 | 17 | Advisor: Matan Field (DAOstack) 18 | 19 | ### **What project are you building** 20 | 21 | We are giving DAOstack DAOs like dxDAO the ability to launch and interact with token bonding curves. A DAO will be able to opt-in to this functionality by registering the BondedCurve scheme to its governance controller. Once registered, the DAO can: 22 | - Launch a new continuous token with one of the supported reference implementations or with their own contracts. 23 | - Buy / Sell from / to a curve. 24 | 25 | All of the DAO's interactions with the curve are performed through proposals. We will build an integration for Alchemy Earth (DAOstack's U.I.) that allows the DAO's reputation holders to submit proposals that execute the functionality described above. 26 | 27 | In the future, we're hoping it will also be possible for the DAO (through other schemes) to assign additional functionality / utility to the token. For example, a balance of the token could be required to call certain functions in a dApp owned by the DAO. 28 | 29 | ### **Why did you decide to build it** 30 | 31 | Most existing use-cases for token bonding curves do not address the governance of the funds that are generated through the activity of speculators. At the same time, most existing DAOs lack sound valuation models and, largely as a result, sustainable sources of funding. 32 | 33 | Creating a bridge between token bonding curves and the DAOstack governance framework will allow new DAOs like dxDAO, Genesis Alpha, polkaDAO and others to experiment with new models for DAO valuation and funding. This would create accountable mechanisms for speculators to invest in promising DAOs. Because the DAO's governance is fully transparent, speculators can easily track fund usage and remove or add support on that basis. 34 | 35 | For instance, dxDAO could launch a continuous token on a bonding curve that gives token-holders a self-enforcing claim on future DutchX fees. We would expect the price on such a curve to reflect the dxDAO's [Present Value of Future Cash Flows](https://www.investopedia.com/articles/fundamental-analysis/11/present-value-free-cash-flow.asp). Such a scheme could bootstrap the dxDAO's treasury, allowing it to fund the development of DutchX and other dApps ahead of significant revenues from dApp fees. 36 | 37 | ### **How long will it take** 38 | 39 | 4 months 40 | 41 | ### **How much funding are you requesting** 42 | 43 | $50,000 44 | 45 | ### **How did you hear about the GECO** 46 | 47 | Word of mouth 48 | 49 | ## **Your Proposal** 50 | 51 | --- 52 | 53 | ### **Project description** 54 | 55 | Token bonding curves come in many different shapes and sizes. Configurations can vary across various factors including: 56 | 57 | - *Curve*: linear, exponential, polynomial, square root, sigmoid 58 | - *Reserve Currency*: ether, particular erc-20's 59 | - *Spread:* difference between buy & sell curves that goes to the DAO 60 | - *Time Locks*: prevent pump & dumps by restricting sells for a certain period after purchase or until tiered thresholds are met 61 | - *Front-Running Guards*: batching, gas price caps 62 | - *Additional Functions*: burn, beneficiary buyback, etc. 63 | - *Mutability*: can curve parameters be changed after launch? 64 | 65 | Bonding curves are also being implemented for a variety of use-cases: 66 | 67 | - *Automated Market Makers* enable seamless, real-time token swaps that eliminate the need to match buyers and sellers (e.g. DutchX, Bancor) 68 | - *TCR's & Curation Markets* allow communities to curate lists and signal support for different memes or social causes (e.g. Ocean Protocol, Zap) 69 | - *Continuous Organizations* let organizations raise funds on an ongoing basis while keeping them accountable to contributors 70 | 71 | Each use-case requires a designer to configure the curve according to particular goals, user classes and attack vectors. 72 | 73 | We believe that DAOs like dxDAO are best-positioned to realize such use-cases in the pursuit of their stakeholders' goals. For this reason, we want to build the tooling to make it easy for DAOs to launch, manage and interact with their own bonding curves. 74 | 75 | ### **Features** 76 | 77 | This functionality will be built on top of and integrated with DAOstack's existing software stack. Our implementation will take the form of: 78 | 79 | **On-Chain Functionality** 80 | 81 | - DAOstack Scheme: 82 | - Buy (Mint) & Sell (Burn) Tokens 83 | - Create Bonding Curve Market 84 | 85 | **Application Functionality** 86 | 87 | - Alchemy Earth Integration: 88 | - Create Proposals 89 | - Proposal will trigger a vote for initiating a bonding curve with the specified parameters 90 | - The user will be able to specify parameters like curve, reserve token, spread, time locks etc., when creating the proposal 91 | - Proposed bonding curve and associated parameters will be displayed to the DAO's reputation holders in an intuitive way 92 | - View DAO's Token Holdings 93 | - View DAO's Curve 94 | - Buy / Sell History 95 | - Circulating Token Supply 96 | - Market Reserve Balance 97 | 98 | ### **Team description** 99 | 100 | We are members of [dOrg](https://github.com/dOrgTech), a freelancer cooperative building open-source DAO tooling. 101 | 102 | Matan from DAOstack will also be advising on scientific, economic and architectural design decisions. 103 | 104 | ### **Timeline, Milestones and Deliverables** 105 | 106 | **Phase I: On-Chain Contracts** 107 | 108 | **Deliverables:** 109 | 110 | 1. DAOstack Scheme 111 | 112 | **Time and Price Estimate:** $25,000 for 2 months 113 | 114 | **Phase II: Application Integration** 115 | 116 | **Deliverables:** 117 | 118 | 1. Alchemy Earth Integration 119 | 120 | **Time and Price Estimate:** $25,000 for 2 months 121 | 122 | ### **Others** 123 | 124 | You can find a summary and links to our current projects [here](https://github.com/dOrgTech/vision/blob/master/README.md). 125 | -------------------------------------------------------------------------------- /Proposals/Funded Projects/Linkdrop.md: -------------------------------------------------------------------------------- 1 | 2 | ## Linkdrop Protocol 3 | 4 | ### Team members 5 | 6 | Mikhail Dobrokhvalov, 7 | Dev lead, 8 | https://github.com/Dobrokhvalov 9 | 10 | Gustav Friis, 11 | Biz lead, 12 | https://www.linkedin.com/in/gustav-friis-20201086/ 13 | 14 | Artiom Ignatyev, 15 | Product lead, 16 | https://www.linkedin.com/in/artyomignatyev 17 | 18 | Amir Jumaniyazov, 19 | Backend dev, 20 | https://github.com/amiromayer 21 | 22 | Haz Baikulov, 23 | Frontend dev, 24 | https://github.com/spacehaz 25 | 26 | 27 | ### What project are you building 28 | 29 | **General description** 30 | 31 | [Linkdrop](https://linkdrop.org/) is an open protocol for including digital assets and onboarding properties into links and QR codes. This allows non-crypto users to simply click a URL or scan a linkdrop QR code to get onboarded. Place check out our already live [mainnet demo applications](https://linkdrop.org/demo/) to see how this looks like for one-to-many and one-to-one linkdrops. 32 | 33 | **GECO specific** 34 | 35 | We wish to develop a full meta-linkdrop implementation in order to extend linkdrop functionality to Gnosis Safe in order to simplify Ethereum onboarding. 36 | 37 | ### Why did you decide to build it 38 | 39 | Our general motivation for working on the Linkdrop Protocol is that we see usability of web3 being a major blocker for mainstream adoption in an equivalent manner to scalability. Web3 needs to learn from Web2 best practice of onboarding. 40 | 41 | 42 | ![Web2 Onboarding](https://i.imgur.com/ruiWXd9.png) 43 | 44 | ![Linkdrop](https://i.imgur.com/SOlmvZs.png) 45 | 46 | 47 | We believe meta-linkdrop module is a very useful feature to include in the wallet contract of the Gnosis Safe to seamlessly allow referral programs and invitation schemes to onboard new users. 48 | 49 | ### How long will it take 50 | 51 | The entire [linkdrop protocol roadmap](https://github.com/LinkdropProtocol/Proposal-Paper/blob/master/README.md) spands for a year. The specific meta-linkdrop implementation is estimated to spand over Q2 and Q3 of 2019. 52 | 53 | ### How much funding are you requesting 54 | We are requesting $50.000 to develop the generalized meta-linkdrop SDK as well as and provide an end-to-end working solution for the Gnosis Safe 55 | 56 | ### How did you hear about the GECO 57 | 58 | Through whispers in the full node office 59 | 60 | ## Your Proposal 61 | ### Project description 62 | 63 | **Regular linkdrops** 64 | 65 | In our existing mainnet dapp implementations such as [eth2.io](https://eth2.io/) (one-to-one linkdrops) and volca (https://volca.tech/) (one-to-many linkdrops) a regular external Ethereum account is used. 66 | 67 | **Meta linkdrops** 68 | 69 | A meta-linkdrop is based on meta-tx accounts, instead of working with an external Ethereum account, a meta-linkdrop works with digital asset stored in wallet contracts, such as Gnosis Safe and Universal Login based wallets. 70 | This will be working quite similiar to this PoC of a [gassless webwallet utilizing Universal Login SDK](https://github.com/LinkdropProtocol/Gasless-Webwallet) we have recently built. 71 | 72 | Our goal for this proposal is to make linkdrops work with the Gnosis Safe end-to-end, as well as deliver a generalized meta-link SDK implementation that other developers can use to integrate interoperable meta-linkdrops into their projects. 73 | 74 | 75 | ### Meta-linkdrop key scheme for Universal Login, ENS, ERC20 and ERC721 76 | 77 | ![invite scheme](https://user-images.githubusercontent.com/18598519/48316096-10f8ab00-e5df-11e8-89f0-63a0397c904c.png) 78 | 79 | 1. Alice shares an invite link or QR code with Bob, including a transit private key and a signature 80 | 1. Clicking the link, Bob is directed to a webpage 81 | 2. Bob generates his own private key stored in the browser 82 | 3. Bob uses the transit private key to sign Bob’s address 83 | 4. Bob’s browser sends his two signatures to the relayer 84 | 5. The Relayer calls Alice’s identity contract 85 | 6. Then Alice’s identity contract creates an identity contract for Bob and sends a Robot 86 | 7. In addition, Bob can now also help Alice recover access to her identity contract in the future using a social key recovery mechanism 87 | 8. Bob now got the tokens he wanted, and in addition has a Universal Login Contract and ENS name which allows him to use the best of web3 to login to all other Ethereum dapps. 88 | 89 | ### Meta-linkdrop demo and contract 90 | 91 | [This demo](https://screencast-o-matic.com/watch/cqeblx0k7e) video shows a similiar meta-linkdrop scheme utilizing Universal Login we implemented within the "Daily" wallet targeting Venezuelans. The contract implementation for this meta-linkdrop example can be found [here](https://gist.github.com/Dobrokhvalov/00e2bbca13a1378636fa5a400bd692f5#file-invitelink-sol). 92 | 93 | 94 | 95 | ### Underlying Assumptions 96 | 97 | In order for the invite functionality scheme to work in practice, the following assumptions needs to be valid: 98 | 99 | - Alice has an EIP 1078 identity contract and wants to send an ERC721 or ERC20 token to Bob 100 | - Bob is a new user without ETH, wallet or any prior crypto knowledge 101 | - Alice share the QR code or invite link with Bob over a secure channel e.g Signal 102 | - There is a proper incentive in place (on a user, dapp or relay level) to pay gas 103 | 104 | 105 | ### Team description 106 | 107 | 1. Most of us intially met at the Status Hackathon before Devcon 4 where we won two first prizes, for building the [onbotting.eth webapp](https://www.youtube.com/watch?v=K67dOixMBWI&t=). Prior to that Mikhail and Artiom had develped earlier versions of eth2.io and Volca 108 | 2. Since then we together created the [cryptoxmas.xyz NFT charity for Venezuela](https://cryptoxmas.xyz/) and raised roughly 18 ETH to Venezuelans utilizing linkdrops and a Giveth campaign. 109 | 3. We have now developed the gasless-webwallet, and began on our roadmap to generalize the linkdrop protocol. 110 | 111 | We described [a bit about us and our story](https://medium.com/@Gfriiis/linkdrops-an-open-source-standard-for-invite-digital-asset-links-on-ethereum-29f34b3fa5ec) in this blogpost. 112 | 113 | 114 | ### Timeline, Milestones and Deliverables 115 | 116 | 117 | - Q2: Meta-linkdrop module to Gnosis Safe Contracts, estimated $15.000 118 | 119 | - Q2: Relay implementation, assumed to extending on existing Gnosis backend, estimated $10.000 120 | 121 | - Q3: Meta-Linkdrop SDK, estimated $15.000 122 | 123 | - Q3: Front-end Javascript libraries, estimated $10.000 124 | 125 | ### Github 126 | 127 | https://github.com/LinkdropProtocol 128 | -------------------------------------------------------------------------------- /Proposals/wave2/DutchXSubgraph.md: -------------------------------------------------------------------------------- 1 | # DutchX Subgraph 2 | 3 | ## Project Overview 4 | 5 | The project being proposed in this document is a supplementary data management solution for the DutchX protocol built using [The Graph](https://thegraph.com/). 6 | 7 | This project was conceived of at the recent [ETHDenver Buidlathon](https://www.ethdenver.com/). Both Gnosis and the The Graph were sponsoring awards for anyone that used their solutions in an entry. Having some experience using the DutchX, I knew that historical data storage and access is something that could be improved upon in the DutchX and saw that The Graph offered a good solution. 8 | 9 | **POC**: [Hackathon Entry](https://github.com/g-r-a-n-t/dutchx-subgraph) (winner of both competitions mentioned) 10 | 11 | **Time**: ~2 months 12 | 13 | **Funding**: $15,500 14 | 15 | **Referral Source**: Mareen Gläske 16 | 17 | **Team Members**: 18 | - Grant Wuerker 19 | - LinkedIn: https://www.linkedin.com/in/grant-wuerker-6a687284/ 20 | - Github: https://github.com/g-r-a-n-t 21 | 22 | ## Proposal 23 | 24 | The Graph is a general purpose data persistence solution for Ethereum. It uses events emitted by the Ethereum network to update entities in its database and allows for the retrieval of these entities using [GraphQL](https://graphql.org/). Developers are able to create what's known as a "subgraph" to integrate their projects with the platform. 25 | 26 | The DutchX, being a protocol developed entirely using smart contracts, stands to benefit from the Graph significantly, as it would make the storage of historic information cost-efficient and flexible and the retrieval of information simple. 27 | 28 | By creating a subgraph, developers are able to separate the storage of historic data from data that is required for smart contract execution. This design is somewhat analogous to traditional application design where long term storage is delegated from memory to disk due to physical limitations. In the current Ethereum system, long term storage on the blockchain is free after initial costs. However, it is likely that mechanisms will be introduced in the future that disincentivize this behavior [[x]](https://ethresear.ch/tags/storage-fee-rent). If this is the case, it would make sense from an economic perspective to lean out smart contract storage and leverage a specialized storage tool for data that is not functionally necessary. The specialized storage tool in this case is The Graph. 29 | 30 | There are also considerations relating to iterability. Since the management of entities is handled off-chain, it is possible to make changes to the subgraph frequently. In comparison to the DutchX API, where data is pulled directly from smart contracts, adding new endpoints could be hindered by limitations in the contracts. A subgraph does not have this issue since it does not source data directly from smart contracts. As long as you can find an event that is relevant to the entity, you can keep it up-to-date. 31 | 32 | In terms of developer appeal, a subgraph has some charms. To name a few: GraphQL is a powerful open-source language built for contemporary applications. It is easy to learn and can be used to perform complex tasks. Being able to perform queries on the DutchX using GraphQL would be very cool. In addition to this, The Graph has built an explorer, so if developers want to learn how to use the DutchX subgraph without configuring their environment, they can just go to this [page](https://thegraph.com/explorer/subgraph/g-r-a-n-t/dutchx) and try it out. Both of these things would make the DutchX subgraph appealing to anyone hoping to build on the platform. There is a wide range dapps people could use this subgraph for, but some examples include: Exchange interfaces, analytical software, and trading bots. 33 | 34 | ### Features 35 | 36 | Below is a table showing which events currently exist in the DutchX and the entities that they could **potentially** map to. Note that there would not be any changes made to the DutchX contracts themselves; the subgraph would be implemented as a standalone component that uses existing events. 37 | 38 | contract | event | entities | phase 39 | -------------- | --------------------- | -------------------------------| --- 40 | DutchExchange | NewDeposit | Balances, Deposits | I 41 | DutchExchange | NewWithdrawal | Balances, Withdrawals | I 42 | DutchExchange | NewSellOrder | Balances, Auctions, SellOrders | I 43 | DutchExchange | NewBuyOrder | Balances, Auctions, BuyOrders | I 44 | DutchExchange | NewSellerFundsClaim | Balances, SellerFundsClaims | I 45 | DutchExchange | NewBuyerFundsClaim | Balances, BuyerFundsClaims | I 46 | DutchExchange | NewTokenPair | Markets | I 47 | DutchExchange | NewAuctionScheduled | Auctions | I 48 | DutchExchange | NewAuctionCleared | Auctions | I 49 | DutchExchange | Fee | Fees | I 50 | DxUpgrade | NewMasterCopyProposal | MasterCopyProposals | II 51 | EthOracle | NewOracleProposal | OracleProposals | II 52 | TokenWhitelist | Approval | WhitelistedTokens | II 53 | DsAuth | LogSetAuthority | LogSetAuthority | II 54 | DsAuth | LogSetOwner | LogSetOwner | II 55 | DsNote | LogNote | LogNotes | II 56 | 57 | *The entities listed above could be subject to change.* 58 | 59 | ### Team 60 | 61 | Grant Wuerker, the sole developer on the proposed project, has been working in the field of computer science for ~6 years. He has experience working in academic research, system administration, and software engineering as well as experience working on the Gnosis Safe via Gitcoin. His interest in decentralized systems stems from a belief that this technology will lead to a more fair and transparent world. Any opportunities to contribute to the ecosystem in a sustainable way are met with excitement. 62 | 63 | ### Timeline, Milestones and Deliverables 64 | 65 | The development of this project would be broken up into four phases. Two of which would be coding the project, one is is for documentation, and another is for making changes that come out of a review from the DutchX team. 66 | 67 | --- 68 | 69 | **Phase I**: `DutchExchange.sol` entities and listeners 70 | 71 | **Deliverables**: All entities and listeners for the `DutchExchange.sol` contract are implemented. Each functional unit of code would have sufficient test coverage. 72 | 73 | **Time and Price Estimate** 3 weeks; $6,500 74 | 75 | ---- 76 | 77 | **Phase II**: Remaining entities and listeners 78 | 79 | **Deliverables**: All entities and listeners for the remaining contracts are created. Each functional unit of code would have sufficient test coverage. 80 | 81 | **Time and Price Estimate** 1 week; $2,250 82 | 83 | --- 84 | 85 | **Phase III**: Documentation 86 | 87 | **Deliverables**: Thorough documentation around technical implementation and usage. 88 | 89 | **Time and Price Estimate**: 2 weeks; $4,500 90 | 91 | --- 92 | 93 | **Phase IV**: Changes based on review 94 | 95 | **Deliverables**: Any changes that come out of a review from the DutchX team. 96 | 97 | **Time and Price Estimate**: 1-3 weeks (dependent on availability); $2,250 98 | 99 | -------------------------------------------------------------------------------- /Proposals/wave2/SAFE_wallet_provisioning.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | 5 | SAFE wallet provisioning 6 | 7 | ### Team members 8 | 9 | Mikko Ohtamaa 10 | Alexander Smith 11 | Rainer Koirikivi 12 | 13 | ### What project are you building 14 | 15 | An automated wallet provisioning for new users for decentralised finance services. 16 | 17 | ### Why did you decide to build it 18 | 19 | TokenMarket, a security token marketplace, is facing the problem that it is too difficult for non-tech-savvy users to get a secure blockchain wallet installed for themselves. 20 | 21 | To participate the decentralised finance, the users first need to have a wallet. Furthermore they need to have loaded it with some cryptocurrency and tokens to make it useful. There is a lot of separate steps to get the wallet in the hands of the user. 22 | 23 | This problem is also described on this slide from https://pbs.twimg.com/media/D1C-p3WWwAUuyWv.jpg 24 | 25 | We want to make the process smoother for the end user. For new users, we assume they come through a website, with their normal web browser. We want to streamline the experience, so that the users can get a secure, mobile based, wallet in their hands with minimal amount of clicks. 26 | 27 | ### How long will it take 28 | 29 | 3-5 months. 30 | 31 | ### How much funding are you requesting 32 | 33 | $74,000 34 | 35 | ### How did you hear about the GECO 36 | 37 | A personal relationship with Gnosis. 38 | 39 | ## Your Proposal 40 | 41 | ### Project description 42 | 43 | Gnosis SAFE wallet automated installer for decentralised finance application vendors. 44 | 45 | We assume that the best way to make new users to want to install a wallet is through a service that they want to use and they need a wallet for it: install the wallet when it is required for the first time. 46 | 47 | The users, who do not have a wallet yet, are prompted to install one on a website. The process starts by asking a mobile phone number from the users. After entering the mobile phone number, we send an SMS link to Gnosis SAFE installation (iOS/Android). 48 | 49 | After the user installs the app, and the seed phrase is safely set up, a backend service receives a notification about the installation. 50 | 51 | The original vendor, from whom the installation request came from, receives a notification that the user has now successfully installed a wallet. 52 | 53 | If the finance application vendor chooses so, they can also pay the initial fees for the user (ETH seed money) and transfer any other finance application specific tokens to the user wallet. 54 | 55 | The vendor can automatically whitelist the new address of the user in their service, the wallet is automatically WalletConnect'ed and also push the user any token registration needed in order to use the service. 56 | 57 | Ultimately, the wallet adoption process should take only four steps from the user point of view 58 | 1. Enter your phone number on a website that needs the wallet 59 | 2. Click a link in the SMS that takes you the appropriate app store purchase page 60 | 3. Install the wallet app 61 | 4. Choose a seed phrase backup option 62 | (5.) The service is now aware that the user has a working wallet in their hands 63 | 64 | ### Features 65 | 66 | - A wallet installation module for a website 67 | - An IFRAME integration on any website 68 | - Asks for a phone number and sends the relevant app installation SMS 69 | - Tracks the installation id, so that the after the wallet installation we can trigger a webhook notification 70 | - Either hosted within Gnosis SAFE server side infrastructure or a (self hosted) standalone server side Python application 71 | - Spam protection e.g. through API key and deposit or similar 72 | 73 | - Alternative installation mechanism (not SMS) 74 | - Scan a tagged QR link, with a vendor generated tag, which takes user to the app store installation page 75 | - E.g. for Asian audience where QR code method may be more prevalent 76 | 77 | - A vendor payment service 78 | - Pay the installation of the wallets on behalf of the user 79 | - Pay the initial ETH fees on the behalf of the users 80 | - Also load any other tokens in the wallet 81 | - Potentially using GNO token 82 | 83 | - Automated registration of tokens in the new wallet installations 84 | - When a wallet is installed, make sure the relevant tokens needed for the vendor service show up in the wallet 85 | 86 | ### Team description 87 | 88 | All team members are on TokenMarket payroll. TokenMarket have issued out 30+ utility tokens and is now working with regulated security token issuances and security token decentralised exchange. We work with Python backend, JavaScript/React frontends. 89 | 90 | ### Timeline, Milestones and Deliverables 91 | 92 | **Phase I: specification** 93 | 94 | A proposal for changes in Gnosis SAFE architecture in order to have the streamlined installation flow 95 | - Mobile user experience changes needed 96 | - SMS gateway - who will operate it and how to pay the SMS gees 97 | - How to serve IFRAME for phone number input 98 | - How the vendor receive a notification after the user has successfully installed SAFE wallet 99 | - Privacy concerns and how to address them 100 | - Integration to the other components of SAFE architecture, like coupons or referral fees 101 | - How to automatically set up WalletConnect for the installed wallet 102 | 103 | **Time and Price Estimate** 104 | 105 | 1 working month 106 | $12,000 107 | 108 | **Phase II: minimal viable product (MVP)** 109 | 110 | **Deliverables** 111 | 112 | An alpha version of Gnosis SAFE where the installation flow is supported. 113 | 114 | - Mobile app changes in one ecosystem (either Android OR iOS) 115 | - Server-side code changes 116 | - An SMS gateway set up 117 | - A vendor notification webhook / polling API endpoint set up 118 | - An example HTML/JS application how to implement and test this 119 | - A ready to be published in the app store, but the features hidden from the end user 120 | - Present the service in relevant Ethereum meetups 121 | 122 | **Time and Price Estimate** 123 | 124 | 3 working months 125 | $36,000 126 | 127 | **Phase III: beta implementation and vendor tooling** 128 | 129 | - Another mobile ecosystem supported (Android OR iOS remaining) 130 | - A vendor dashboard 131 | - Receive your API key, either through website sign up or a smart contract transaction sign up 132 | - Vendors can self sign up for the service 133 | - A vendor have a dashboard to have visibility to Gnosis SAFE flow (number of installs, countries, users currently stuck in the pipeline) 134 | - Gnosis SAFE dashboard 135 | - Number of vendors signed up 136 | - Total installations the vendors have driven for SAFE 137 | - Best performing vendors 138 | - Enable/disable vendors in the case of manual troubleshooting 139 | - Polished developer documentation 140 | - Present the service in relevant Ethereum meetups 141 | 142 | **Time and Price Estimate** 143 | 144 | 3 working months 145 | $36,000 146 | 147 | ### Others 148 | 149 | TokenMarket is facing the challenge of having the user to install wallets. After dozens of issuances and working with multiple wallet providers, we believe we have the best experience can solve this problem by working with the wallet providers. We also believe that Gnosis SAFE is a good candidate for pushing the envelope in this matter, as all of their source code is open and Gnosis is open for co-operation. 150 | 151 | We have also worked in the past with the www.linktexting.com that solves this problem for mobile apps in a generic manner, but lacks the necessary bits for the cryptocurrency integration and vendor callbacks to inform when the wallet is ready for the action. 152 | -------------------------------------------------------------------------------- /Proposals/wave2/tokenary.md: -------------------------------------------------------------------------------- 1 | # Proposal Guideline 2 | 3 | ## Project Overview 4 | 5 | ### Project name 6 | Tokenary 7 | 8 | ### Team members 9 | * Vadim Zakharenko — vadim.zakhar42@gmail.com — https://github.com/vadimantiy 10 | * Igor Shmakov — shmakoff.work@gmail.com — https://github.com/shmakovigor 11 | * Ivan Grachyov — mail@grachyov.com — https://github.com/grachyov 12 | * Olga Kolekonova — anoniav@gmail.com — https://github.com/duprass 13 | 14 | ### What project are you building 15 | We are building Tokenary, a simple and seamless cross-device ethereum wallet for crypto newcomers. Our main priorities are security and usability. We want to help users interact with the Ethereum network and DApps in a simple, straightforward way while preserving their favorite features like cross-device sync, push notifications, and extra layers of security (Face ID, Touch ID, KeyChain, etc.). Our initial target market is the crypto-enthusiast Apple user that desires Apple’s simple UX in all of their interactions with the crypto world, which is currently impossible to find—especially for decentralized finance applications. Eventually, we plan on building complementary Android and web-client interfaces to reach additional market segments. 16 | In Summer 2017, our core team won second place at the Qtum hackathon in Moscow and have been working full-time on Tokenary ever since. In Summer 2018, we published a macOS app in the Mac App Store to complement our existing iOS application. After some additional research and user-testing, we identified a need for Safari-based solution for interacting with Dapps from our wallet. This Safari extension injects a Web3 provider into the Tokenary interface to transmit signing requests. 17 | We are always on the lookout for the latest UX protocols like WalletConnect and implement them to make the cross-device wallet experience even better. 18 | 19 | ### Why did you decide to build it 20 | When we first started using the Ethereum network in 2016, we faced many usability problems common to new technologies. In an attempt to address them, during the Qtum hackathon in Moscow in the summer of 2017, our team developed a prototype of a simple wallet application. 21 | 22 | We want to make interaction with Ethereum smart contracts, tokens and DApps as familiar as possible with all the features we love from the Apple Ecosystem — cross-device sync, push notification and extra layers of security (Face ID, Touch ID, KeyChain, etc.). Current UX solutions do not offer these features or were implemented on a single platform without the crucial cross-device experience. 23 | 24 | ### How long will it take 25 | We are continuously working on our clients for mobile, desktop and web. Here is our roadmap for 2019: 26 | 27 | **Q1-2019** 28 | * Safari extension to enable DApp interaction 29 | * In-app and web explorer to make transactions more understandable for the new crypto user 30 | * In-app token exchange with the best rates across different DEXs 31 | * ENS support 32 | 33 | **Q2-2019** 34 | * Meta Transactions for alternative gas payments 35 | * Universal Login or another simple key-recovery system 36 | * Cross-device transaction memo synchronization with IPFS 37 | * Address book and user profile support 38 | * Asset information discovery and in-app educational content 39 | 40 | **Q3-2019** 41 | * Android client parity with iOS 42 | * Major hardware wallet support for macOS 43 | * P2P exchange for NFTs and other assets 44 | * Transaction signing from keyless devices. 45 | 46 | **Q4-2019** 47 | * Apple Pay purchase of Ether and various stable coins (DAI) 48 | * In-app crypto purchasing with credit cards/apple pay 49 | * Adding Bitcoin and WBTC bridge support 50 | * Sending crypto via messages and other channels to onboard new users 51 | * Light client implementation 52 | 53 | ### How much funding are you requesting 54 | $60 000 55 | 56 | ### How did you hear about the GECO 57 | We met Stefan George at a DeFi meetup in Berlin and saw mentions of the program on Twitter 58 | 59 | ## Your Proposal 60 | 61 | ### Project description 62 | We want to give users the ability to use shared accounts to manage their crypto assets. Setting up a shared account to hold Ethereum assets is a tricky process now. Besides additional security that a shared account gives, it allows users to manage their funds together which is hard to do within the existent financial infrastructure (i.e. bank accounts). Using our existing software, iOS, macOS and web wallet interfaces, we want to provide our users with the best user experience. We want to make the process of submitting and confirming transactions as fast and convenient as possible. 63 | 64 | ### Features 65 | * Shared account creation (deployment of a contract with required parameters) 66 | * Invitations to a shared account (notifications and email requests) 67 | * Sync of shared accounts addresses (sync via iCloud, local storage, etc.) 68 | * Wallet configuration (setting owners, limits, number of approvals) 69 | * Notifications (on payment requests and approvals) 70 | * Shared memos about transactions (with IPFS and shared key cryptography) 71 | * Transaction creation and execution (ETH, ERC-20, ERC-721) 72 | * List of transactions 73 | 74 | ### Team description 75 | The 4-person Tokenary team is purely technical and includes developers with experiences in various industries. Most of the team members have a CS or Mathematical degree from the top Russian universities. 76 | 77 | **Ivan Grachyov** (Product manager & iOS developer) 78 | * Apple WWDC scholarship winner 79 | * Bachelor in Computer Science from Lomonosov Moscow State University 80 | * Founded and developed [Emoji Cosmos](https://www.producthunt.com/posts/emoji-cosmos) 81 | 82 | **Vadim Zakharenko** (iOS developer) 83 | * Google intern 84 | * Apple WWDC scholarship winner 85 | * Bachelor of Computer Science at Lomonosov Moscow State University 86 | * Competitive programming olympiads winner 87 | 88 | **Igor Shmakov** (macOS & iOS developer) 89 | * Founded and developed [Arseny](https://itunes.apple.com/ru/app/id1340250301), [Spont](https://itunes.apple.com/us/app/spont-make-events-meet-new-people/id1125189088?mt=8) 90 | * Bachelor of Computer Science and Engineering at National Research Nuclear University MEPhI 91 | * Co-author of [Classifiers based on Bayesian neural networks](https://ieeexplore.ieee.org/document/7910653) 92 | 93 | **Olga Kolekonova** (Android developer) 94 | * Software Engineering Degree from Higher School of Economics 95 | 96 | ### Timeline, Milestones and Deliverables 97 | 98 | **Phase 1** — Alpha\ 99 | **Deliverables** — Creating accounts, Adding owners, Transacting\ 100 | We plan to release the basic flow of a multisig creation with predefined owners, signing and sending ETH and ERC-20 transactions (iOS and macOS)\ 101 | **Time and Price Estimate** — 2 months (20 000$) 102 | 103 | **Phase 2** — Beta\ 104 | **Deliverables** — Invitations, Synchronization, Settings 105 | The next step will be to enable inviting of other owners usign signed messages delivered via email or messengers. We will also implement synchronization of the multisigs list via iCloud to prevent users from losing their addresses. Additional settings will be available in the settings tab to make limits and a number of confirmations configurable.\ 106 | **Time and Price Estimate** — 1.5 months (15 000$) 107 | 108 | **Phase 3** — Release\ 109 | **Deliverables** — Shared Memos, Transactions, Notifications\ 110 | Once multisig participants are able to send transactions and configure everything from our interface, we plan to implement notifications about transaction requests, incoming and outgoing transactions. Also, we will add a screen where users will be able to track all historical, pending, and partially-signed transactions. Additionally, we want to add a feature of shared transaction memos (stored on IPFS), so that each participant can write and see the same notes related to a transaction.\ 111 | **Time and Price Estimate** — 1.5 months (15 000$) 112 | 113 | **Phase 4** — Polishing\ 114 | **Deliverables** — Design & UX Improvements\ 115 | Once everything is set up, we plan to start working with user feedback and analytics, improving our interface according to the user needs. Also, we see a potential need to integrate other smart contract interfaces in our app, i.e. allow users to seamlessly interact with ERC-721 tokens.\ 116 | **Time and Price Estimate** — 1 month (10 000$) 117 | 118 | ### Others 119 | We are glad to receive your feedback on our beta release of Safari extension 120 | * https://youtu.be/Wk00fIOj2E8 — video 121 | * https://tokenary.io/beta/Tokenary.dmg — download 122 | -------------------------------------------------------------------------------- /Proposals/wave2/Dapplets.md: -------------------------------------------------------------------------------- 1 | # Dapplets: improved secure signing protocol 2 | 3 | ## Project Overview 4 | 5 | ### Project name 6 | 7 | [Dapplets](https://medium.com/@Ethernian/dapplets-part-1-introduce-new-dapp-architecture-for-better-ux-and-security-75a4881b4765) 8 | 9 | ### Team members 10 | 11 | Dmitry Palchun (AKA [@Ethernian](https://ethereum-magicians.org/u/ethernian)) - ethereum developer, founder 12 | 13 | Ralf Sturm - UI/UX designer, frontend developer 14 | 15 | Alexander Sakhaev (from SkillUnion) - fullstack developer 16 | 17 | Andrey Chukhonin (from SkillUnion) - fullstack developer 18 | 19 | staffing from SkillUnion may vary. 20 | 21 | ### What project are you building 22 | *Dapplets* is a research- and infrastructural project enabling new business models and mass adoption for Dapps. It allows embedding ethereum based actions into existing web2 legacy websites and communities like Twitter. Moreover, the project fixes current flaws in the web3 architecture, repairing [WYSiWYS](https://en.wikipedia.org/wiki/WYSIWYS) property of secure signing process and make it more secure and seamless. 23 | 24 | ### Why did you decide to build it 25 | I (Ethernian) was looking for ways to implement ethereum based workflows on the top existing communities. It is essential for Ethereum Governance (Signaling) and for [routing EIPs](https://ethereum-magicians.org/t/decentralizing-eip-workflow/1525) between specialized communities. It turned out, that the current secure signing infrastructure based in current web3 architecture doesn't support existing legacy sites. 26 | The broken [WYSiWYS](https://en.wikipedia.org/wiki/WYSIWYS) was the second driver to start the project. 27 | 28 | 29 | ### How long will it take 30 | 31 | 1. Phase 1: a Gnosis MVP - 2 months 32 | 1. Phase 2: public beta - 3 months 33 | 1. Phase 3: public release - 3 months 34 | 35 | 36 | 37 | ### How much funding are you requesting 38 | 1. Phase 1: 12000 euro 39 | 1. Phase 2: 18000 euro 40 | 1. Phase 3: 18000 euro 41 | 42 | Total: 48000 euro 43 | 44 | 45 | ### How did you hear about the GECO 46 | 47 | personal conversation in FullNode with Dmitry Bespalov and then with Mareen Gläske and Tobias Schubotz. 48 | 49 | ## Your Proposal 50 | 51 | ### Project description 52 | 53 | The Dapplets proposal improves the current web3 architecture by splitting web3 workflows into two groups: the “UX-focused” and the “Security-focused” and executes the latter workflows in the Signer’s secure environment. For usual Dapps the architecture solves "UX vs. Security" trade-off and achieves both: UX and security. For an existing legacy website it allows defining ethereum actions running in Signer even if the site has no web3 support at all. It means, now we can reach millions of users on sites like Twitter. 54 | 55 | More generally speaking, the Dapplets proposal allows setting up an ethereum based incentivization layer on the top of existing web2 communities. 56 | 57 | Legacy site support makes the _Dapplets_ to the vehicle for mass adoption and creates this way an incentive for wallet devs to implement the standard. 58 | 59 | In particular, a dapplet integration with Gnosis-Safe will allow users to create Prediction Markets seamless in the context of the website where the User is currently on. For example, the User can join a Prediction Market about US election results or create a bet against some fake news _directly from the news site he or she is reading_ even if the news site has no web3 support at all. I have already discussed the implementation details with Dmitry Bespalov: it looks positive. 60 | 61 | ### Features 62 | 63 | As for now, we are planning to create a browser plugin for injecting dapplet controls. We use WalletConnect to pair the wallet and the browser. A dapplet description language (a Dapplet DSL) is to be defined but will be a subset of HTML or Markdown or similar. 64 | Dapplet Auditor Community planned to be a DAO or TCR. 65 | 66 | ### Team description 67 | 68 | *Dmitry Palchun (Ethernian)* - former java developer with more than 25 years of experience. Since 2015 - an ethereum developer and architect. Implemented ethereum based PoC projects and researched blockchain business cases at Lufthansa. In 2017 created independently all contracts around Santiment ICO, token and subscriptions. [Active in Ethereum Magicians](https://ethereum-magicians.org/u/ethernian) forum. An author of Dapplets proposal. 69 | Based in Hamburg. 70 | 71 | 72 | *Ralf Sturm (meekmocha)* - an experienced UI/UX designer. 20+ years of experience. 73 | UX tests and guidance for Olympus audio recorder, UX/UI for interactive GPS driven outdoor games, UI/UX for Jabber-based messenger, various network game designs since 1999, UX/UI for Cycosmos (pre-Facebook). 74 | DJ and musician. 75 | Based in Hamburg. 76 | 77 | *Alexander Sakhaev* - fullstack developer at SkillUnion. Implemented a Dapplets PoC at ETHParis hackathon in Paris, as well as various pre-Dapplets experimentations like Metamask forking & hacking. 3+ years of experience. 78 | Based in St.Petersburg. 79 | 80 | *Andrey Chukhonin* - fullstack developer at SkillUnion. A lot of industrial ERP integrations with 10+ years of experience. 81 | Based in St.Petersburg. 82 | 83 | 84 | SkillUnion is a traditional IT company in St.Petersburg, founded by Sergey Palchun. It implements ERP systems for industrial customers. 85 | 86 | ### Timeline, Milestones and Deliverables 87 | 88 | The project is divided into several modules: 89 | 90 | * *Injector:* a browser plugin loading and injecting controls into the website depending on context. 91 | * *Protocol:* a DSL for dapplets and controls definition. 92 | * *Infrastructure:* to maintain the dapplet's security status and for serving the data. 93 | * *Wallet support:* implement the Dapplets support in Wallets/Signers. 94 | * *TestCases:* real live dapplets and business cases, creating incentives for Wallet Devs to adopt the Dapplets protocol. 95 | 96 | 97 | **Phase 0** 98 | Weeks of hacking around Metamask and TCR. 99 | A quick and dirty [implementation was made at ETHParis hackathon](https://twitter.com/Ethernian/status/1104596777519452160) based on WalletConnect. 100 | 101 | *<==== YOU ARE HERE =====>* 102 | 103 | **Phase I** 104 | Gnosis MVP: a supporting one gnosis use case as a test. 105 | **Deliverables** 106 | * Injector: a browser plugin loading and injecting context dependent controls. 107 | * Protocol: threats and security model research for secure signing; create a simple DSL to define controls and dapplets. 108 | * Infrastructure: simplified and mostly centralized audit infrastructure and data delivery. 109 | * Wallet support: one wallet PoC integration (Gnosis-Safe would be great). 110 | * TestCases: one TestCase to be defined together with Gnosis Team 111 | (like Twitter or news feeds integrations). 112 | 113 | **Time and Price Estimate** 114 | 2 months, 12000 Euro 115 | 116 | 117 | 118 | **Phase II** 119 | First public beta: support for many independent dapplets and authors. 120 | **Deliverables** 121 | * Injector: security levels, checks and events; user-based favorites and ignores 122 | * Protocol: implementing the security model and DSL. 123 | * Infrastructure: simple decentralized audit and security management. Simple project web site, dapplet documentation and developer community. 124 | * Wallet support: dapplet container implemented in Gnosis-Safe. 125 | * TestCase: Gnosis test case: rolling out and collecting feedback. 126 | 127 | **Time and Price Estimate** 128 | 3 months, 18000 Euro 129 | 130 | 131 | **Phase III** 132 | First public release. 133 | **Deliverables** 134 | * Injector: implement fixes and changes from Phase II. 135 | * Protocol: implement fixes and changes from Phase II. 136 | * Infrastructure: decentralized audit and security management with economic incentives. 137 | * Wallet support: second wallet integration. Documentation. 138 | * TestCases: one more UseCase (to be defined). 139 | 140 | **Time and Price Estimate** 141 | 3 months, 18000 Euro 142 | 143 | 144 | ### Others 145 | 146 | Technical and business details of the Gnosis-Safe integration were already discussed with Dmitry and Tobias. 147 | It would be great to become a chance to bring ideas to reality. 148 | 149 | Technical Whitepaper: http://bitly.com/dapplets-part1 150 | 151 | PoC video: http://bitly.com/dapplets-poc-video 152 | 153 | Forum discussion: http://bitly.com/dapplets-forum 154 | 155 | 156 | PoC github (created at ETHParis Hackathon): 157 | 158 | https://github.com/skillunion/dapplet-extension 159 | 160 | https://github.com/skillunion/walletconnect-mock-wallet 161 | 162 | https://github.com/skillunion/dapplet-static 163 | -------------------------------------------------------------------------------- /Proposals/Funded Projects/TasitSDK.md: -------------------------------------------------------------------------------- 1 | # Tasit SDK 2 | 3 | ## Project Overview 4 | 5 | ### Project name 6 | 7 | > [Tasit SDK](https://github.com/tasitlabs/tasitsdk) 8 | 9 | ### Team members 10 | 11 | > Paul Cowgill, Marcelo Morgado 12 | 13 | ### What project are you building 14 | 15 | > The Tasit SDK is a JavaScript SDK for making standalone native mobile Ethereum dapps using React Native. It integrates seamlessly with the Gnosis Safe so that mobile dapps can use funds stored in the Safe wallet. 16 | 17 | ### Why did you decide to build it 18 | 19 | > I (Paul) often feel frustrated that I can't use Ethereum dapps on my mobile phone the way I would with any "web 2" app. For instance, sometimes I want to add someone to the Aragon DAO for my Meetup group on my phone while I'm talking to them at a meetup, but instead I have to set a reminder to do it when I'm back at my computer at home. I could do it within a dapp browser, but the UX of a webview inside of another app is clunky enough that I don't consider it as a realistic option. If I'm noticing this inconvenience as someone who's technical, the average potential Ethereum/dapp user surely feels that pain much more. The Ethereum community loses mainstream people from the onboarding funnel because of this. 20 | 21 | > Young people use mobile devices way more than laptops, and the same is true in general for people worldwide - it feels very "centralized" of the Ethereum community to focus primarily on web-based dapp experiences on a laptop. 22 | 23 | > About a year ago, I originally was interested in building an Ethereum dapp data explorer tool with simpler UX. Gradually, I realized that since my top priority is delighting mainstream users and introducing them to crypto and Ethereum (without them necessarily knowing that they’re using Ethereum), enabling developers to create mobile apps for using dapps would impact mainstream users far more than an exploratory tool. Talking to other people in the Ethereum community online and at conferences only strengthened this conviction and helped to refine the specifics of the idea. 24 | 25 | ### How long will it take 26 | 27 | > We will need 3 months to ship version 1.0.0 of the project. 28 | 29 | ### How much funding are you requesting 30 | 31 | > \$34000 _(Please see the timeline section for a detailed breakdown of the reasoning behind this number.)_ 32 | 33 | ### How did you hear about the GECO 34 | 35 | > Talking with Gnosis software engineers at Devcon4 in Prague 36 | 37 | ## Your Proposal 38 | 39 | ### Project description 40 | 41 | ##### A detailed description of your project 42 | 43 | > One major reason most dapps don’t have standalone mobile apps today is because it’s harder for developers to build mobile Ethereum dapps than it is to build web-based dapps. There isn’t any good tooling for Ethereum in the React Native ecosystem. The Tasit SDK provides this. React Native is an especially great fit for mobile dapps since React is such a commonly used technology for web-based dapps - this allows for more code reuse. Moreover, many talented younger developers are opting to build their apps in React Native as opposed to Swift (for iOS) or Java (for Android) so that their app "automagically" works on both platforms. 44 | 45 | > The three main source of UX friction this SDK addresses are: 46 | 47 | > (A) Using a dapp within a web3-enabled browser dapp is an unacceptable UX. Almost all legitimate experiences on mobile today happen in standalone native apps. 48 | 49 | > (B) As someone who already has ETH and tokens, needing to transfer some of these funds permanently from my preferred mobile wallet to another account in order to use a dapp is an awkward experience. 50 | 51 | > (C) Needing ETH or tokens in the first place to try a dapp presents too much onboarding friction. 52 | 53 | > These problems can be solved with a JavaScript SDK for writing mobile apps for Ethereum dapps in React Native with a few advanced onboarding features built in. This helps developers to build new mobile dapps faster without reinventing the wheel for basic features. 54 | 55 | > The app also supports: ephemeral account and private key generation; a high-level abstraction for reading and writing data and reacting to events that will be familiar to "traditional" mobile developers; advanced support for popular ERC standards; simple onboarding, especially for users of the Gnosis Safe; and automatic app scaffolding using the Tasit CLI. 56 | 57 | ##### The overall goal and future outlook of your project 58 | 59 | > Once the Tasit SDK is around, more dapps will have dedicated mobile apps. This will remove a key barrier to mainstream adoption of Ethereum dapps. 60 | 61 | > Developers shouldn't need to reinvent the wheel for each new dapp: account and private key generation, linking to another wallet or adding meta-transaction support, etc. Let the Tasit SDK handle that bit and focus on the business logic for your dapp. 62 | 63 | > In the future, we'll support the following based on demand: 64 | 65 | > - Serenity (eWASM, sharding, proof of stake) 66 | > - State channels 67 | > - Plasma 68 | > - Future popular ERC standards 69 | > - In-app and/or singleton-on-device light and/or ultralight clients with a simple abstraction around them 70 | > - Use of upgradeable and nonupgradeable contracts 71 | > - The Graph protocol 72 | > - Tool for finding the current address of a popular smart contract 73 | > - etc. 74 | 75 | ##### Why we should fund you. 76 | 77 | > Tasit will serve as "proof of decentralization" for the dapps we support. Vitalik tweeted 'One simple litmus test for whether or not a blockchain project is truly decentralized: can a third party independently make a client for it, and do everything that the "official" client can?'. 78 | 79 | > It's time for major decoupling of "back end" and front end. This decoupling provides users with "right to exit". 80 | 81 | > Plus, I (Paul) have a unique eye for product. I've shipped production mobile apps and worked with a team on an evolving JavaScript code base. I'm experienced with React Native and Ethereum. I've vetted the idea at conferences like Dappcon, TruffleCon, and Devcon4. 82 | 83 | > Marcelo is a very talented developer who's already proven himself over the past month by contributing to the open-source Tasit SDK and the Tasit demo mobile app. 84 | 85 | ### Features 86 | 87 | > - Ephemeral account and private key generation 88 | > - A high-level abstraction for reading and writing data and reacting to events that will be familiar to "traditional" mobile developers 89 | > - Advanced support for popular ERC standards 90 | > - Simple onboarding, especially for users of the Gnosis Safe 91 | > - Configurable JSON-RPC client 92 | > - Automatic app scaffolding using the Tasit CLI 93 | 94 | ##### Tools and frameworks 95 | 96 | > ethers.js, React Native, Expo, Jest, Truffle, Babel, Infura, Lerna, smart-contract-based wallets (Gnosis Safe in particular), meta-transactions, ERC721, ERC165, Fastlane, CircleCI 97 | 98 | ##### Architecture, mockups, etc. 99 | 100 | > - [Architecture](https://www.dropbox.com/s/gw88c5ua4ssthvg/TasitProjectStructure.png?dl=0) 101 | > - A README with [more details on the Tasit SDK](https://github.com/tasitlabs/TasitSDK/blob/develop/README.md) 102 | > - A README with [more details on the Tasit apps](https://github.com/tasitlabs/tasit/blob/develop/README.md) - all the mainstream-user-facing apps for popular web-based dapps (like Decentraland, Aragon, etc.) that will be built using the Tasit SDK 103 | > - [Slides about the Tasit SDK](https://bit.ly/2018-12-04-chicago-ethereum-meetup) 104 | > - [Video with example app onboarding flow](https://youtu.be/iJQtDPQrRsE) (interactive wireframes) 105 | > - [Demo app using the Tasit SDK](https://github.com/tasitlabs/tasit/tree/develop/demo) 106 | 107 | ### Team description 108 | 109 | ##### Paul Cowgill 110 | 111 | [LinkedIn](https://www.linkedin.com/in/pcowgill/) // [Twitter](https://twitter.com/paulcowgill) // [GitHub](https://github.com/pcowgill) 112 | 113 | > Paul recently worked on a smart contract audit for OpenZeppelin 2.0 with the team at Level K (plus a few other high-profile audits). For the past year and a half he has been working as a freelance software engineer specializing in Solidity, IPFS, Truffle, React, and React Native. He has a lot of experience working on native mobile apps, most recently including the Heatworks mobile app. 114 | 115 | > Before that he was the first hire and CTO at the YC-backed IoT startup Edyn - he wrote the initial code for much of the tech stack (Node.js, AWS, mobile, etc.), and as CTO he led the growth of the software and data science teams to 12 people. The Edyn team shipped 10,000 units of their IoT products and continuously iterated on a production mobile app to use with them. 116 | 117 | > _Education:_ He received a BSE from Princeton in Electrical Engineering in 2008, and he received his Master's degree from Harvard in Systems Biology in 2014. 118 | 119 | ##### Marcelo Morgado 120 | 121 | [LinkedIn](https://www.linkedin.com/in/marcelo-morgado/) // [Medium](https://medium.com/@marcelomorgado) // [GitHub](https://github.com/marcelomorgado) 122 | 123 | > Marcelo is a full-stack developer with >5 years of experience and a sysadmin with >10 years of experience. He has participated in and lead multiple software development projects. He is passionate about cryptocurrencies, decentralization, and open-source. 124 | 125 | > Marcelo has personally faced the problem that we're trying to solve. He participated in a Status Hackathon in September 2018. The web app he built works and received the 2nd place award at the hackathon. However, the associated React Native mobile project still is only a prototype, because he didn't have enough time to build an Ethereum wallet from scratch and then build a dapp during the hackathon. He has been following crypto technologies for 4 years now, and he thinks that one of the greatest barriers to the mass adoption of crypto and dapps is the friction with handling private keys, identity, and gas. 126 | 127 | > _Education_: He recently took a course on Digital Currencies (DFIN-511) at the University of Nicosia in Cyprus. In 2013, he received his bachelor's degree in Information Systems from PUC-RIO (the #1 Brazillian private university). 128 | 129 | ### Timeline, Milestones and Deliverables 130 | 131 | **Phase I** 132 | 133 | > **v0.1.0: proof of concept** 134 | 135 | **Deliverables** 136 | 137 | > - Ephemeral account and private key generation 138 | > - Higher-level abstraction for reading and writing data and reacting to events 139 | > - Advanced support for ERC721 140 | > - A working demo of onboarding using the Gnosis Safe with a few things still hardcoded for users who already have funds stored in the Safe wallet 141 | > - Minimal proof-of-concept app for Decentraland on TestFlight for iOS using a testnet 142 | 143 | **Time and Price Estimate** 144 | 145 | > **1 month, \$16500 total** 146 | 147 | > - $13500 1 month of $6,750/month pay for 2 software engineers 148 | > - \$2000 design contract work 149 | > - \$500 SAAS costs, like an Apple Developer Program account to have a test implementation of an app using the SDK, etc. 150 | > - \$500 legal costs with Stripe Atlas 151 | 152 | **Phase II** 153 | 154 | > **v1.0.0: a wider launch of the beta with a stable API for 1.x releases** 155 | 156 | **Deliverables** 157 | 158 | > - Advanced support for one of these: (A) DAOs, (B) TCRs, or (C) two-sided marketplaces. 159 | > - "tasit init" scaffolds out a mobile dapp 160 | > - Onboarding using the Gnosis Safe for users new to Ethereum 161 | > - Configurable JSON-RPC client 162 | > - Proof-of-concept app for Decentraland on TestFlight for iOS and Google Play beta track on mainnet 163 | 164 | **Time and Price Estimate** 165 | 166 | > **2 additional months, \$17500** 167 | 168 | > - $13500 1 month of $6,750/month pay for 2 software engineers (salary for the 3rd month to be secured from elsewhere) 169 | > - \$2000 design contract work 170 | > - \$2000 travel to conferences to speak about the project and attract other developers to use and/or contribute to the SDK. 171 | 172 | **Phase III** 173 | 174 | > We have plans for phase III and beyond, but we're intentionally keeping the scope of this initial grant request smaller. 175 | 176 | ### Other 177 | 178 | > - Paul previously has spoken with the following people from the Gnosis team about this grant application: Richard, Dmitry, Anna, and Mareen 179 | > - Our website is [tasit.io](https://tasit.io/) 180 | > - [@TasitLabs](https://twitter.com/tasitlabs) on Twitter 181 | > - [GitHub Kanban board](https://github.com/orgs/tasitlabs/projects/1) for the project 182 | > - [Telegram](https://t.me/tasitlabs) 183 | > - Email us at [founders@tasit.io](mailto:founders@tasit.io) 184 | > - Create / upvote [feature requests](https://tasit.canny.io/feature-requests) for the SDK 185 | > - [Here's a video](https://youtu.be/PPbwf1-4Jpk) of Paul Cowgill pitching Tasit Labs (the company doing most of the initial work on the Tasit SDK). 186 | -------------------------------------------------------------------------------- /Proposals/wave2/PM-ScaleCases.md: -------------------------------------------------------------------------------- 1 | # PM-ScaleCases: Scalable Prediction Market Use Cases 2 | 3 | ## Project Overview 4 | ### Project name 5 | Prediction Market ScaleCases: InvestorX, SurveyX, and NonRepudiationX (NRX) BlockChain Scalability Solution 6 | 7 | ### Team members 8 | 9 | _Muhammad Altabba_ - CEO 10 | 11 |    LinkedIn: https://www.linkedin.com/in/muhammadaltabba/ 12 | 13 | _Muhammed Mazen Hafez_ - Web/BlockChain Developer 14 | 15 | 16 |    LinkedIn: https://www.linkedin.com/in/mhmazen/ 17 | 18 | 19 | _Qamar Al-zaman Hafez_ - System Analyst 20 | 21 |    LinkedIn: https://www.linkedin.com/in/qamaral-zamanhafez/ 22 | 23 | ### What project are you building 24 | 25 | We are building three components: 26 | 27 | 1) **InvestorX** 28 | 29 | A prediction market use-case that aims to provide the best financial advice for investors on Ethereum platform. 30 | 31 | 2) **SurveyX** 32 | 33 | A system that facilitates crowd opinion mining and incentivization for any survey that is made for any purpose. This not a prediction market use-case. But, it is a nice example of how some projects could be modeled and built with Gnosis Apollo packages as it is a prediction market use-case. 34 | 35 | 3) **NonRepudiationX** 36 | 37 | A BlockChain scalability solution that best fit for prediction markets and can leverage Gnosis Apollo and exposes it to more use-cases. In addition to increasing the speed and lowering the cost paid by the end users. 38 | 39 | 40 | ### Why did you decide to build it 41 | 42 | We believe that successful projects have to touch the pain of a real business case. 43 | 44 | ***InvestorX:*** 45 | Almost all crypto community are investors who would appreciate good advice and could be engaged relatively easy in investment voting activities. There are already lots of Technical Analysts (on Telegram and specialized sites) with many followers and we will target them all. 46 | 47 | 48 | ***SurveyX:*** Incentivizing the crowd opinion is the main pain point of any survey maker. So, having a website that facilitates crowd mining and rewarding will solve a real business problem. 49 | 50 | 51 | ***NRX (NonRepudiationX) Scalability Solution:*** BlockChain till now did not reach mass-adoption. And two main reasons for that are the scalability (limited number of transactions per second) and cost (transaction cost is relatively high). 52 | 53 | Using _off-chain non-repudiation communication_, that could be claimed on-chain, will enable the users to vote, participate in surveys and do any other activities for free, and they will only pay for the transaction when they will claim their rewards (if there is any). 54 | 55 | 56 | Actually, we think that InvestorX and SurveyX, like almost all other use-cases that could be built with _Gnosis Apollo_, will stay under the hood, if they were not provided with a scalability solution. And we believe that NonRepudiationX is fairly simple, yet powerful enough, and best fit for a prediction market. And it can attract developers and end-users to use Gnosis Apollo and the solutions built with. 57 | 58 | ### How long will it take 59 | The 3 projects are estimated to take 4 months for core functionality. 60 | 61 | However, because we believe in high-quality and because achieving the business goals will need extra time, we will spend an additional 4 months for things like enhancements, stabilization and code refactoring. And another 4 months for manly for community building and business model fine-tuning in parallel with adding the art-touches on the technical solutions. 62 | 63 | ### How much funding are you requesting 64 | 90 000 USD for working 12 months on the three components: _InvestorX_, _SurveyX_, and _NonRepudiationX (NRX) Scalability Solution_. 65 | 66 | Actually, we can have the fund to only one selected item of the above (which is the Scalability Solution). However, we strongly recommend that funding them 3 together. Especially that, InvestorX is built with Angular, SurveyX is built with React and the NRX will expose them, and all other similar cases that can be built with Gnosis Apollo, to mass-adoption. 67 | 68 | If you chose to fund only NonRepudiationX, we will need 65 000 USD. This does not mean that InvestorX and SurveyX are very less cheap to implement; But this is because it will be is easier to have a successful business model and/or gather funds to them, away from Gnosis, after their MVP is implemented. However, you may choose to fund NonRepudiationX in this round; And we will apply for InvestorX, SurveyX in the next funding round after 3 months. 69 | 70 | ### How did you hear about the GECO 71 | [Gnosis](https://gnosis.pm/ "Gnosis") website 72 | 73 | 74 | ## Your Proposal 75 | 76 | ### Project Description 77 | 78 | ***InvestorX*** 79 | 80 | An Ethereum decentralized application for crypto-investment with decentralized nomination and elections. The DApp aims to elect top investment wallet in term of ROI (return on investment) for a given period. 81 | 82 | 83 | ***SurveyX*** 84 | 85 | Crowd opinion mining and rewarding DApp. 86 | 87 | 88 | ***NRX (NonRepudiationX) Scalability Solution*** 89 | 90 | BlockChain Off-Chain/On-Chain Scalability Solution. 91 | 92 | This scalability solution is based on non-repudiation that can be ensured by the digital signatures which can be signed with Ethereum external-accounts with private/public keys. In this solution, users can participate in a prediction market off-chain. And, the winner can claim his/here reward by posting an on-chain transaction that contains a valid message signed early by the market maker. This will minimize the number of transactions made on Ethereum for any given prediction market. And this will result in 0 participation-cost in any market, in addition to the higher speed. Where the only winner(s) will pay for the fees of the on-chain claim transaction. 93 | 94 | 95 | ### Features 96 | 97 | ***InvestorX*** 98 | 99 | As said, "A picture is worth a thousand words" and a running prototype worth a thousand pictures. So, we made a POC that you can check at http://investorx.io. And the code is available here https://github.com/apper-tech/investorX and we encourage you to check the readme file as you can find some detailed information there. 100 | 101 | Actually, the POC (http://investorx.io) is built with Angular, Truffle 5 & and solidity 0.5. However, after being funded by Gnosis, we will re-implement it utilizing Gnosis Apollo packages. But we will keep it in Angular. 102 | 103 | ***SurveyX*** 104 | 105 | This DApp POC is also available at http://surveyx.io. And you can find the source code, and helpful information in the readme file, at https://github.com/apper-tech/surveyx. 106 | 107 | Actually, the POC (http://surveyx.io) is built with React, Truffle 5 & and solidity 0.5. However, after getting the grant from Gnosis we will re-implement it utilizing Gnosis Apollo packages; And we will keep it in React. 108 | 109 | ***NRX (NonRepudiationX) Scalability Solution*** 110 | 111 | What is non-repudiation? It is the assurance that someone cannot deny the validity of something. Non-repudiation could be achieved with digital signatures made with the public-key/private-key of Ethereum external accounts (wallets). 112 | 113 | The execution flow, that you can see in the next [Sequence Diagram](#nonrepudiationx-sequence-diagram "Sequence Diagram"), is basically that we will ask both the user and the system-owner (the maker or an oracle) to sign, off-chain, their confirmation messages. Such that, the user will first sign his data off-chain. And then the system-owner, as a confirmation, will off-chain sign the signed message he receives from the user. The user can then use the confirmation he received from the system-owner to claim his reward on-chain. Just like magic, the off-chain signature will be easily done because of the EIP712 standard that is [already implemented in MetaMask](https://medium.com/metamask/eip712-is-coming-what-to-expect-and-how-to-use-it-bb92fd1a7a26 "already implemented in MetaMask"). And thanks to solidity for having [`ecrecover` function](https://solidity.readthedocs.io/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions) that can be used for on-chain verification. Additionally, OpenZeppelin provided a standard hash-verification library: https://docs.openzeppelin.org/docs/cryptography_ecdsa. 114 | 115 | As a result, this enables the users to participate in any prediction market off-chain. But the one(s) who deserve a reward will be able to claim his/her reward, on-chain. You may find more at https://github.com/apper-tech/nonrepudiationX. 116 | 117 | 118 | 119 | | ![Sequence Diagram of NonRepudiationX](https://github.com/apper-tech/nonrepudiationX/raw/master/nrx-sequence-diagram.png) | 120 | | :------------: | 121 | | Sequence Diagram of NonRepudiationX | 122 | 123 | 124 | 125 | ## Team description 126 | 127 | ***Muhammad Altabba*** - CEO 128 | Full Stack BlockChain Developer 129 | Solid and extensive commercial experience in BlockChain DApps and Web Apps development. 130 | 131 |        LinkedIn: https://www.linkedin.com/in/muhammadaltabba/ 132 | 133 |        Stack Overflow: https://stackoverflow.com/users/8303489/muhammad-altabba 134 | 135 |        Ethereum Stack Exchange: https://ethereum.stackexchange.com/users/23253/muhammad-altabba 136 | 137 |        GitHub: https://github.com/Muhammad-Altabba 138 | 139 |        Medium BlockChain Articles: https://medium.com/@maltabba 140 | 141 |        Google Scholar: https://scholar.google.com/citations?user=sdbpUkYAAAAJ (17 Citations for a bachelor-degree graduation project report that is cited as it is a thesis) 142 | 143 | ***Muhammed Mazen Hafez*** 144 | 145 | Experienced Full-Stack Web Developer & BlockChain DApp Developer 146 | 147 |        LinkedIn: https://www.linkedin.com/in/mhmazen/ 148 | 149 |        GitHub: https://github.com/mh-mazen 150 | 151 | ***Qamar Al-zaman Hafez*** 152 | 153 | An experienced System Analyst 154 | 155 |        LinkedIn: https://www.linkedin.com/in/qamaral-zamanhafez/ 156 | 157 |        GitHub: https://github.com/Nayoshca 158 | 159 | We will consult and employ many full-time and part-time qualified professionals as needed. But the mentioned above are, the 12 months full-time, dedicated team members who will work hard and smart to turn the ideas to successful projects. 160 | 161 | 162 | ## Timeline, Milestones, and Deliverables 163 | **Phase I:** 164 | Implementing Core Features 165 | - Deliverables 166 | - Rebuild InvestorX and SurveyX with Gnosis Apollo 167 | - InvestorX beta version 168 | - SurveyX beta version 169 | - Create Truffle Boxes (https://truffleframework.com/boxes) 170 | - Truffle Box for InvestorX as a fully featured sample starting Angular project built with Gnosis Apollo. 171 | - Truffle Box for SurveyX as a fully featured sample starting React project built with Gnosis Apollo. 172 | - Creating Truffle boxes means clear and clean code that fit for the purpose, but also generalized for other cases. 173 | - Implement NonRepudiationX and use it with InvestorX and SurveyX. 174 | - Time and Price Estimate 4 months - 30 000 USD 175 | 176 | 177 | 178 | **Phase II:** 179 | 180 | Enhancements, Stabilization and Code Refactoring 181 | - Deliverables 182 | - Perform heavy testing and bugs fixes for InvestorX and SurveyX. 183 | - Deploy InvestorX and SurveyX to Ethereum main net. 184 | - Integrate NRX with Gnosis Apollo packages (we will fork the repositories and make pull-requests for Gnosis repositories: pm-contracts, pm-js, pm-trading-db and pm-trading-ui). 185 | - Implement additional app-specific features like pages to view historical data, reports and a dashboard for InvestorX and SurveyX. 186 | - Design and implement a business model for InvestorX and SurveyX. 187 | - Time and Price Estimate 4 months - 30 000 USD 188 | 189 | **Phase III:** 190 | 191 | Final Technical Touches, Community Building, and Business Model Fine-Tuning. 192 | 193 | This phase is where we will look more for achievements from a business point of view. And, this is only doable having a solid and sound solution. So, achieving the deliverables bellow, that could measure how much effect we could make in the market, is a proof of a good technical solution in addition to hard and smart work. 194 | - Deliverables: Ensure a successful achievement to at least 5 of the following numbers: 195 | - 20 enhancements or feature-requests implemented for opened issues at github.com 196 | - 2000 users on InvestorX.io and SurveyX.io together (this ensures a good business model in addition to a good technical solution). 197 | - 2000 viewers for 2 or more Medium articles on how to use Gnosis and Gnosis Apollo (starting from our Truffle Boxes). 198 | - 2000 viewers for YouTube marketing video(s) that we use to promote InvestorX and SurveyX. 199 | - 2000 viewers for YouTube video(s) in which we will explain about Gnosis, Gnosis Apollo, including our Truffle Boxes and how to use NonRepudiationX. 200 | - One or more published research paper (most likely about NonRepudationX) in an academic journal or conference. 201 | - 2 partnerships with other projects. 202 | - Time and Price Estimate 4 months - 30 000 USD 203 | -------------------------------------------------------------------------------- /Proposals/Wave1/Tribes.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | 5 | [Tribes](https://tribes0x.com) 6 | 7 | ### Team members 8 | 9 | Derek Alia - Full Stack Developer - https://www.linkedin.com/in/derekalia 10 | 11 | Benji Richards - Full Stack / Solidity Developer - https://www.linkedin.com/in/benji-richards 12 | 13 | ### What project are you building 14 | 15 | Tribes is a platform for online communities, similar to Reddit and Patreon. It incorporates elements from blockchain cryptocurrency such as DAOs, monetary incentives, and governance to enable engaged communities. 16 | 17 | ### Why did you decide to build it 18 | 19 | Tribes was born from the need to create better collaboration and monetization tools for people who create content. 20 | 21 | ### How long will it take 22 | 23 | 4 months. 24 | 25 | ### How much funding are you requesting 26 | 27 | 42k EUR. 28 | 29 | ### How did you hear about the GECO 30 | 31 | I first heard about it from Mareen Gläske’s Medium post, “Unveiling the Gnosis Ecosystem Fund”. 32 | 33 | ## Your Proposal 34 | 35 | ### Project description 36 | 37 | Tribes is a platform where people come together to form online communities around various topics they're passionate about. Each tribe on our platform is a Gnosis Safe DAO with additional smart contracts for extra functionality, including marketplaces and governance. We’ve made it easy for users to visit Tribes and begin using the Gnosis Safe contract without having prior experience interacting with the blockchain--no Metamask or other extensions are required. We allow creators to start a tribe that is structured around the needs of their community. Each tribe can have paid monthly subscription tiers for community members who want greater access. Tribe members can get paid by receiving votes on the content they post to the tribe. Subscriptions to the tribe come in the form of ERC721 tokens that are created when a user subscribes to a tribe. Every month subscription funds are sent to the moderators of the tribe and members who posted content and received votes. Tribes incentivizes an ecosystem of reputation and quality driven content creation. 38 | 39 | An example of a tribe might be a community around a DutchX with custom modules allowing them to monitor and affect their DAO all from the Tribes platform. 40 | 41 | An important goal of Tribes is to increase dapp usability and scalability. One of the ways we will achieve this is by creating a UI for tribes to add custom modules that interface with the Gnosis Safe contract and make the modules easily exportable for use outside of the Tribes platform. 42 | 43 | Another feature is to extend the Gnosis Safe to allow for DAO type elements such as weighted votes. Currently, the Gnosis Safe executes by taking into account how many members approve an action. The action gets processed based on the number of users and the Safe's threshold. 44 | 45 | I plan to build a governance module that takes into account a user’s stake in a tribe. An action will be executed depending on how members vote (yes/no) and the weight of each member's vote will depend on his or her stake in the tribe. Prior to deploying this module, members will agree on a voting threshold that must be met for approving an action. This would be a simple and useful approach to DAO governance until we develop more interesting governance structures like Futarchy and Liquid Democracy. An example is provided in Other section of this document. 46 | 47 | Open sourcing Tribes' governance module will help other blockchain projects that require similar functionality for their Gnosis Safe. Tribes takes a hybrid approach to decentralization and we plan on decentralizing core aspects such as storage and governance. Designing Tribes with modularity in mind to reach decentralization is an important goal. 48 | 49 | This project will help onboard the next wave of users into the crypto space by significantly lowering UX barriers and providing real value for communities with governance, monetization tools, NFT engagement, lower fees, and censorship-resistance. The modules created for Tribes will benefit scaling dapps and promote usability for new and experienced users. 50 | 51 | ### Features 52 | 53 | **Governance module** - Module to change Gnosis Safe contract execution based on users ownership percentage in the tribe and the direction of their vote. The module will set a time duration for each vote. The UI for interacting with this module will be built out as an NPM package for other projects to use. 54 | 55 | **Safe Module UI** - A ReactJs UI for adding and removing modules to a Gnosis Safe. 56 | 57 | **Custody solution** - A solution that allows Tribes to onboard users with zero knowledge of crypto and to make transactions on their behalf, mainly the handling of signing transactions without storing private keys. 58 | 59 | **Tribe contract** - Each tribe uses this contract it's a modular and customizable token contract keeping track of subscribers, Gnosis Safe, member stake, and subscription tiers. 60 | 61 | **Subscriptions** - Users can subscribe to a tribe without needing to sign a payment transaction every month. Two potential options to handle this, one is with meta transactions using EIP1337, and the other is to do manual transactions on a shared Safe with the user. 62 | 63 | **Security audit** - Once the token contract is ready Tribes can start the contract audit phase. We expect this to take longer because of the back and forth required between developers and auditors. 64 | 65 | **UX/UI** - Tribes will develop fundamental UX flows from onboarding to trading tokens. I’ve personally designed most of the site and would prefer if a designer would join and create mockups that we can implement. We also need to create animations for actions and transitions on the frontend. 66 | 67 | ### Team description 68 | 69 | Derek Alia - Full stack and web3 development experience. The Largest project that I've worked on is Simplr.ai, a service that enables distributed customer service workers to make money answering questions. 70 | 71 | Benji Richards - I am a full-stack engineer with a strong background in JavaScript. All aspects of coding become a different puzzle in some way that I absolutely love solving. 72 | 73 | ### Timeline, Milestones and Deliverables 74 | 75 | **Phase I** 76 | 77 | 1. Build a custody solution 78 | 2. Develop tribe contract 79 | 3. Develop Gnosis Safe contract integrations 80 | 4. Hire a designer to help with UX flow and UI elements 81 | 82 | **Deliverables** 83 | 84 | Tribes will create an ethereum account on behalf of the user if he or she does not already have Metamask installed. The custody solution allows users to interact with the Gnosis Safe contract and the ethereum blockchain all within the browser and without third-party plugins. For example, users using Safari browser on mobile will be able to interact with the Gnosis Safe securely without downloading any extensions. Tribes accomplishes this using a two-factor authentication approach as described in the [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). This is an important step because it lowers the barrier for people who are new to the blockchain space and want to use its services. The only requirement for users to sign transactions is to remember their password. 85 | 86 | Once the user has the ability to sign transactions we can enable him or her to start a tribe or subscribe to one. To start a tribe the user inputs all the requirements and the type of community to launch, such as a single creator, multi-creator, subscription tiers, allocation of funds, and governance style. The tribe contract will take this information and set up a Gnosis Safe contract with the required modules. The Gnosis Safe contract will also be responsible for sending funds to creators on a monthly basis. 87 | 88 | **Time and Price Estimate** 89 | 90 | 1 month 91 | 92 | 10k EUR 93 | 94 | **Phase II** 95 | 96 | 1. Start fiat to crypto integration 97 | 2. Build subscriptions solution 98 | 3. Develop flow for Metamask users 99 | 4. Begin development on governance module 100 | 5. Implement UX/UI 101 | 102 | **Deliverables** 103 | 104 | This phase will entail implementing a path for users to purchase ETH after going through a KYC process. We plan on using a fiat to crypto provider to help us with this approach but it is necessary to make sure this flow is very clear and easy to follow. This is an important step to allow users to pay gas to send transactions. The two most common transactions will be setting up a tribe and subscribing to a tribe. For the subscription solution, we intend to use the [ERC948](https://github.com/ethereum/EIPs/pull/1337) contract as the first approach. Ultimately this will allow creators to receive funds every month without the user having to sign each month. 105 | 106 | For users who are uncomfortable with using a two-factor custody process for signing transactions, we will enable a path for them to use Metamask instead. Using Metamsk implies that the user most likely already owns ETH and does not need to go through our fiat to crypto process. Creating a different signing pipeline will be built to enable this. 107 | 108 | This phase will also deliver a working version of the governance module that interfaces with a tribe's Safe. When a tribe owner requests to change a setting this starts the governance process of collecting votes and factoring in the users' stakes in the tribe. The outcome of the vote can change settings on the tribe's Gnosis Safe or tribe contract including modifying owners' stakes, adding/removing a member, and adding/removing a module. 109 | 110 | New UI/UX mockups should be 30-50% finished. Development on those mockups into code will have started. 111 | 112 | **Time and Price Estimate** 113 | 114 | 1 month 115 | 116 | 10k EUR 117 | 118 | **Phase III** 119 | 120 | 1. Subscriptions test 121 | 2. Develop Safe Module Manager UI 122 | 3. Tribe token test 123 | 4. Governance test 124 | 5. Security Audit 125 | 6. Finish UX/UI 126 | 127 | **Deliverables** 128 | 129 | Phase III will oversee testing of subscriptions and governance to ensure there are no security vulnerabilities. It will also deliver a UI for subscriber to pause and cancel their subscriptions, as well as a UI for owners of tribes to add and remove modules to the Safe. 130 | 131 | Once this phase is complete we can start the audit to apply fixes during the last month. UX mockups should be completed and implemented. 132 | 133 | **Time and Price Estimate** 134 | 135 | 1 month 136 | 137 | 14k EUR 138 | 139 | **Phase IV** 140 | 141 | 1. Testing 142 | 2. Implement changes from audit 143 | 3. Alpha test - On-board projects and communities 144 | 145 | **Time and Price Estimate** 146 | 147 | 1 month 148 | 149 | 8k EUR 150 | 151 | **Deliverables** 152 | 153 | During Phase IV we will implement feedback from security audits and begin onboarding selected communities. By this time we should have 80% testing coverage and all flows should have been through multiple rounds of user testing. 154 | 155 | ### Other 156 | 157 | **Governance** 158 | 159 | Tribes is creating a module for the Gnosis Safe which is a smart contract to enable governance. It will take into account each users percentage of ownership of the organization. On deployment, the user will set a threshold of how much percent is needed to pass a vote and the duration for each vote. 160 | 161 | An example would be three people start a tribe/organization and set the threshold to 51 and the duration to 3 days. The ownership breakdown would look like the following: 162 | 163 | - Bob - 50% 164 | - Jill - 30% 165 | - Zane - 20% 166 | 167 | At this point, Jill and Zane can’t pass a vote without Bob. To pass a vote they need at least 51%. As they grow they decide to add three more people (Tom, Sarah, Marc) to the project. The new breakdown is: 168 | 169 | - Bob - 45% 170 | - Jill - 27% 171 | - Zane - 19% 172 | - Sarah - 5% 173 | - Tom - 3% 174 | - Marc - 2% 175 | 176 | Now there are more combinations to pass requests through the organization as it grows with new members. As standard, the Gnosis Safe contract execution function uses a threshold that looks at the number of approvals by members of the Gnosis Safe. While in most cases this works well, but if you have a growing organization with people coming in and out, using weighted votes gives more control to larger stakeholders before giving up so much control to new members. This is an example of how the governance module would function and why its needed going forward. 177 | 178 | **Safe Module Manager UI** 179 | 180 | Tribes will be creating a common interface for adding/removing new modules to the Gnosis Safe contract and developing this into a ReactJS NPM for other projects to use. 181 | 182 | An example of this might be if a Gnosis Safe module is declared on Github a user would point to that URL and NPM would pull the description, contract code, and current version of that module. Then users would vote in order to have the package added to their Gnosis Safe modules. 183 | 184 | **Adoption** 185 | 186 | All tribes and potentially each user is a Gnosis Safe contract, we are pushing the adoption of Gnosis Safe DAOs. For perspective there are currently over 1 million subreddits on reddit.com, even 1% of that is a huge amount of Safe Contracts that we are hoping to create 187 | 188 | **Reducing barriers** 189 | 190 | I mention Metamask because most users interact with dapps by using Metamask. We are allowing users to use Metamask or other browser extensions to interact with our platform, but it is not a requirement. Our goal is to allow totally new users into the ecosystem and this is why we mention the custody solution, which is a system to generate a wallet for users who don't have one. With this method, users can interact with the blockchain and later on move to a more trustless system like the Gnosis Safe browser extension or Metamask. 191 | -------------------------------------------------------------------------------- /Proposals/Wave1/Convergent.md: -------------------------------------------------------------------------------- 1 | # GECO Proposal 2 | 3 | ## Project Overview 4 | 5 | ### Project name 6 | [Convergent](https://convergent.cx) 7 | 8 | ### Team members 9 | Logan Saether 10 | Achill Rudolph 11 | 12 | ### What project are you building 13 | Convergent is an open source, extensible cryptoeconomic social network that enables creators to launch a token and build an ecosystem around it. We want to extend this project by adding modules for personal prediction markets that take the form of polls and a futarchy app which allows followers to make governance decisions for individuals. Users will not only be able to invest in personal tokens and benefit from their long term growth, but also to influence and bet on concrete actions, decisions and outcomes of tokenized individuals. 14 | 15 | ### Why did you decide to build it 16 | Market mechanisms that allow people to invest in and take part in determining the future of organizations and corporations have existed for many years as shareholder agreements. As we imagine the social networks of Web3, we believe the key innovation is the underlying vein of value constantly being transacted. To enable individuals and creators to tap into this latent network of social value of their work, time, attention, or future we decided to build our project. 17 | 18 | We want to make these features accessible to smaller organizations down to the singular individual. Personal prediction markets, in the form of polls, could become one of the most exciting and engaging user experiences of our product. It forms the base for the more advanced application of an entire futarchy extension to our base platform that we believe is beneficial to the entire ecosystem. 19 | 20 | ### How long will it take 21 | 5 months 22 | 23 | ### How much funding are you requesting 24 | €8,000 / month --- €40,000 total for 5 months 25 | ### How did you hear about the GECO 26 | Word of mouth, then Twitter and Medium post by Mareen Gläske. 27 | 28 | ## Your Proposal 29 | 30 | ### Project description 31 | _Outline a detailed description of your project, why you chose to build this project, the overall goal and future outlook of your project and why we should fund you._ 32 | 33 | Convergent is pioneering the realm of personal token economies: We allow individuals to create and interact through cryptoeconomic mechanisms around their personal brand. 34 | 35 | To illustrate the basic mechanism consider the following example: A young author who is writing her first book launches a personal token and promises 1 signed copy of the book to anyone who pays her 1 of her personal token. If the author is trusted to actually honor her commitment, the token will come to represent the market value of 1 signed copy of the book, even when the book does not exist, yet. People can buy and sell that token from a bonding curve contract (i.e. without an ICO and without having to go through an exchange). If someone discovers early that the book will become a success, they can benefit from this by investing in the author’s personal token and selling when demand has grown. We expect this to become useful in particular for people who have to build a personal brand and find ways for their audiences to engage with it: artists, content creators and the ever growing independent work-force at large. But the mechanism can be used to tokenize many other kinds of goods and services, not just future artistic creations, but also attention, influence, governance, expertise, or simply time. 36 | 37 | The project has three distinct touchpoints with Gnosis which we would like to expand with the help of GECO funding. First, we are conducting research in novel market mechanisms and cryptoeconomics. Second, we want to integrate Gnosis prediction markets as the next feature in our product. And third, we are prototyping and testing futarchy for personal economies. In the following, each of these three touch points is described in detail: 38 | 39 | #### 1. We are researching personal prediction markets. 40 | 41 | Our product allows individuals to tokenize their work, time, or attention and raise funds from supporters who believe that these aspects of the individual are currently undervalued. Although it does not follow the traditional setup of a prediction market, our core protocol is in some sense a continuous personal prediction market. However, the bonding curve allows for novel business models, thereby giving this prediction market an additional feature: It not only incentivizes participants (henceforth referred to as contributors) to predict and discover successful individuals, but also helps those individuals (henceforth referred to as creators) to fund investments in their personal growth. We are researching the technology and cryptoeconomic primitives that can make such alternative personal prediction markets sustainable and useful for all parties involved. 42 | 43 | #### 2. We are integrating a standard prediction market, using the Gnosis platform. 44 | 45 | The core feature of our product allows creators to generate their own currency and back it with their offered services. Contributors may then invest in the personal brand and personal value streams of the creator and benefit from that creator’s long-term growth. To create a more engaging day-to-day user experience, we want to extend the platform with more direct opportunities for cryptoeconomic interaction. Predictions are one of the most intuitive and natural ways of interacting with our social environment: When we think about the people and organizations we care about, we wonder what choices they will make and what will happen to them. Therefore, with the help of GECO, we want to include prediction markets, in the form of polls, as the first cryptoeconomic extension of our platform. 46 | 47 | #### 3. We are experimenting with futarchy. 48 | 49 | Another interesting interaction of prediction markets and personal economies is to be found in futarchy. We believe that prediction markets can be used to elicit good decisions - not only for governments and firms, but also for individuals and small organizations. We want to experiment with this idea and build a basic prototype to test it. 50 | 51 | In conclusion, our work is highly relevant to Gnosis’ vision of redistributing the future. However, we are at a very early stage with this project and do not plan a token launch for fundraising in the near future. Even within the blockchain ecosystem our field is very experimental and research-heavy. We are also radically transparent, open source and community driven. Altogether, this makes funding through traditional sources hard. Therefore we rely on securing a grant for this work. We would appreciate any support at this critical moment in the project lifecycle. We would work our asses off to leverage it most efficiently and make our vision of redistributing personal futures come true. 52 | 53 | ### Features 54 | _How do you plan to implement your project, which tools and framework will you use? Optional: Architecture, Mockups, etc._ 55 | 56 | The [current prototype of the Convergent platform](https://proto.convergent.cx) already allows users to launch their own token economy and endow their token with value by linking it to offered services. We are currently using React JS for the frontend webapp, Solidity for smart contracts and Drizzle to connect the two. We are deploying and testing contracts with Truffle. For consistency, the features described in this proposal will be built using the same technology stack. 57 | 58 | The project encompasses the technical implementation of point 2 and 3 from the project description above. Both will be built by integrating the existing Convergent platform with Gnosis’ smart contracts and interfaces. 59 | 60 | #### A. Standard Prediction Markets Integration 61 | 62 | The integration of standard prediction markets into the personal economy platform will be the main feature to be built as part of this project. This extension will allow users to open prediction markets about their personal future with an integrated interface on their Convergent profile page. It will look reminiscent of social polls on web 2.0 platforms. However, a prediction market will be a far more engaging experience for web3 users because it entails real skin in the game, thereby making the game more exciting. 63 | 64 | In all likelihood, most of these personal prediction markets will be small in size and therefore not highly profitable or significant in financial terms. Nevertheless, they can be immensely valuable and entertaining for many groups of supporters as a new direct way of interacting with the creators and organizations they care about. The creator on the other hand would gain valuable insights into the sentiment and opinions of her audience. The prediction market would give her an additional instrument to harness the wisdom of her crowd and create engagement around her personal brand. The main challenge for the technical implementation, will be to create a UX that conveys this spirit and adapts the standard setup to the personal economy context. The main outcome of this project will be a complete software module that will make it fun and rewarding to set up, interact with and analyse low-stake personal prediction markets. 65 | 66 | Furthermore, the combination of prediction markets and personal bonding curve tokens results in interesting new cryptoeconomics. For example, we are planning to allow the use of personal tokens as the reserve currency for the personal prediction market. This improves incentive alignment and provides more value to the personal token as a focal point for the personal economy of the creator. 67 | 68 | #### B. Personal Futarchy Prototype 69 | 70 | As the second deliverable of this project scope, we will build a basic prototype to explore a potential extension of the standard prediction market setup. Rather than just opening a market for predicting a future outcome, users might also want to elicit the crowd’s wisdom to actually help them make decisions and shape their future. We will create a prototype that integrates this extension into the Convergent platform, conduct comprehensive user tests and document the results. 71 | 72 | We are already seeing existing use cases, where the creator of a personal token economy allows token holders to influence her decisions. Most people would not give personal life decisions away to an open market (though there are some isolated instances of this). However, when the token represents the professional identity of an individual or a small organization, governance and decision rights can easily be conceived as a core part of the token economy. For example, the existing Jonas Lund Token gives its holder “agency over future decisions concerning Jonas Lund's artistic practice”. 73 | 74 | Futarchy provides a promising variation of this model. Rather than allowing token holders to directly vote on the decision of the creator, they could enter a conditional prediction market and let the outcome of that prediction market determine the creator’s decision. This is similar in spirit to the idea of Futarchy Curated Registries, as pioneered by Gnosis in cooperation with Chris Whinfrey and Level-K. Personal token economies provide the perfect testing ground for such models because they provide many opportunities for low-stake, yet exciting and fun decisions. 75 | 76 | ### Team description 77 | _Who are your team members, what is your background and what you built before._ 78 | 79 | [Logan](https://github.com/lsaether) is a professional smart contracts engineer with a humanistic background. He started coding at the age of 12 and went on to study complex systems and English literature. Before initiating Convergent, he rebooted and maintained the Ethereum Alarm Clock (a protocol for scheduling Ethereum transactions) as a developer at ChronoLogic and conducted research into a similar protocol for the scheduling of meta-transactions. He offers code reviews and security audits on a case-by-case basis through his [audit firm](https://trustless.design). 80 | 81 | [Achill](https://github.com/acrdlph) is a rigorous economist, self-taught full-stack developer and passionate entrepreneur. He studied philosophy and economics at Bayreuth, Harvard and Yale. Over various career steps he gained extensive experience in quantitative economic research, business strategy and product management. Before initiating Convergent, he was the co-founder and CEO of Way Network and built its [beta prototype](https://cryptogeeks.berlin), a decentrally curated local chat app. He is also an Ethereum community organizer regularly hosting the Curation Markets meetup in Berlin. 82 | 83 | We met in September 2018 and discovered our shared interest in continuous bonding curves and personal token models. After some prototyping and hackathon implementations, we started working full-time on the idea in early November. Ever since, we are working together around the clock. We are both fully and indefinitely committed to this project. 84 | 85 | ### Timeline, Milestones and Deliverables 86 | We divide the work up into two large chunks with smaller deliverables every two weeks. 87 | 88 | #### Phase I (3 months) - Prediction Markets "Polls" and Integration 89 | During this phase we will build the poll front-end to the prediction market contracts and work on integration of it into our platform. 90 | 91 | | Deliverables | Time | Price | 92 | | :------------- | :----------: | -----------: | 93 | | Preliminary research, wireframes and specification of integration | weeks 1-2 | €4,000 | 94 | | First standalone prototype of polls tool | weeks 3-4 | €4,000 | 95 | | Optimizations and UX testing | weeks 5-6 | €4,000 | 96 | | Complete standalone version of polls tool | weeks 7-8 | €4,000 | 97 | | Integration into personal economies platform (contributor perspective) | weeks 9-10 | €4,000 | 98 | | Integration into personal economies platform (creator/dashboard perspective) | weeks 11-12 | €4,000 | 99 | 100 | #### Phase II (2 months) - Futarchy Application 101 | This phase will build on the work we accomplished by building the prediction markets poll app and research and build a working futarchy application on top. 102 | 103 | | Deliverables | Time | Price | 104 | | :------------- | :----------: | -----------: | 105 | | Futarchy research report, detailed specification and wireframes of futarchy app | weeks 13-14 | €4,000 | 106 | | Create interface from contributor (voter) perspective | weeks 15-16 | €4,000 | 107 | | Create Dashboard interface for creator perspective, UX feedback on front-end | weeks 17-18 | €4,000 | 108 | | Complete futarchy application on personal economies platform | weeks 19-20 | €4,000 | 109 | 110 | 111 | 112 | ### Others 113 | We have applied to the Ethereum Community Fund, the Samsung NEXT Stack Zero Grant, Consensys and several other investors but have not received any responses so far. 114 | 115 | Here you can find our current live prototype on the Rinkeby testnet: https://proto.convergent.cx All our work is done in plain sight and we constantly share updates through our public channels: https://convergent.cx/, https://github.com/convergentcx, https://twitter.com/ConvergentCx, https://discordapp.com/invite/JUPx5Xg, https://medium.com/convergentcx. 116 | 117 | We know this is new but innovation requires courage and boldness. Thank you for your consideration. 118 | -------------------------------------------------------------------------------- /Proposals/Funded Projects/Flyingcarpet.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 |

3 | 4 |

5 | 6 | ### Project name 7 | Flyingcarpet Network 8 | 9 | **Website:** https://www.flyingcarpet.network/ 10 | 11 | **Github:** https://github.com/flyingcarpet-network 12 | 13 | **Research:** https://github.com/flyingcarpet-network/Research/blob/master/Whitepaper_Flyingcarpet.pdf 14 | 15 | ### Team members 16 | Julien Bouteloup - https://www.linkedin.com/in/jbouteloup/ 17 | 18 | Leopold Joy - https://www.linkedin.com/in/leopoldjoy/ 19 | 20 | Victor Faramond - https://www.linkedin.com/in/victorfaramond/ 21 | 22 | Mike Onorato - https://www.linkedin.com/in/mikeonorato 23 | 24 | Satya Doraisamy - https://www.linkedin.com/in/satya-doraisamy-a51962104/ 25 | ### What project are you building 26 | At Flyingcarpet, we are building a decentralised geospatial layer for Earth Observation. The Flyingcarpet Network incentivises data scientists to build an open library of geospatial analytics-extraction models. Analytics are made continually available to paying organisations via our Analytics API, which will also function as an oracle that can be integrated directly into smart contracts. Models are tokenised so that anyone can invest in them and share in their future revenue. 27 | 28 | As a component of the Flyingcarpet Network, we are creating two Flyingcarpet prediction markets on top of the new Gnosis Mercury smart contracts. The first, our Flyingcarpet Predictions Dashboard, will enable anybody in the world to make predictions from Flyingcarpet model insights. The second, our Model Viability Prediction Market, will be a conditional prediction market, enabling Flyingcarpet users to bet on the future profitability/demand for models that haven’t been created yet. 29 | 30 | 31 | #### Flyingcarpet Network Workflow 32 | 33 | 1. **Model Viability Prediction Market (Gnosis Integration):** A Gnosis Mercury `PredictionMarketSystem` instance crowdsources sentiment from Flyingcarpet Network participants to determine the prospects of future models (how the Flyingcarpet community predicts the future profitability/demand of, for example, a model that analyses Amazonian deforestation vs a model that analyses Arctic ice melt). See "Model Viability Prediction Market" section below. 34 | 2. **Model Sourcing:** Data scientists produce optimal models for the paying organisation’s request. Effective models are stored decentrally with all computation taking place off-chain. 35 | 3. **Models Dashboard & Predictions Dashboard (Gnosis Integration):** The Flyingcarpet Predictions Dashboard enables participants to make predictions on physical-world events with models acting as arbiters of truth (condition orcales). Analytics from Flyingcarpet models are made continually available to paying organisations via our Analytics API and smart contract oracles. 36 | 4. **Model Investments and Financial Instruments:** Models are tokenised and converted into investible entities that can function as financial instruments (see Additional Decentralized Financial Instruments section below) so that anyone, anywhere can capture the value of Earth observation. 37 | 38 | ### Why did you decide to build it 39 | Julien picked this idea because he had previously worked on building AI-powered IoT swarms. The increasing number of Earth observation satellites, combined with recent advances in both machine learning and blockchain led to a greater vision: using blockchain-based incentives to build a decentralised library of machine learning Earth observation models. 40 | 41 | Earth observation satellite imagery has such broad applications across all organisations and industries that it will be a key driver of economic growth in the next decade and beyond. However, since such analytics are currently provided by centralised and pricey firms, only organisations with considerable financial resources can access geospatial analytics. As a result, many organisations that would benefit the most from these analytics, such as SMEs, non-profits, NGOs and humanitarian efforts, are priced out. 42 | 43 | In a world where economic inequality is increasing and power is becoming increasingly centralised, we at Flyingcarpet are determined to ensure that the value of Earth observation is open to everyone. We envisage that Flyingcarpet will massively increase organisational access to Earth observation analytics—and predictions built on these insights—while also distributing value to data scientists in a fairer way. 44 | 45 | 46 | ### How long will it take 47 | Eight months, split between two milestones (four months each). 48 | 49 | ### How much funding are you requesting 50 | **$60k total funding. Breakdown:** 51 | 1. **$30k: Feb - May 2019** — Concurrent development of the Flyingcarpet Predictions Dashboard and the Flyingcarpet Model Viability PM Dashboard. This front-end development will entail creation of both web3-enabled Dapps. 52 | 2. **$30k: June - Sept 2019** — Full integration of Predictions Dashboard with all existing and future Flyingcarpet models (e.g. coffee, ice melt, deforestation, catastrophes etc.) so that users can start making predictions on Gnosis PM with Flyingcarpet oracles as more come online. Also, back-end development of Model Viability PM Dashboard, including integration with both Gnosis Mercury `PredictionMarketSystem` and Flyingcarpet smart contracts, followed by a marketing push to drive our community of data scientists and paying organizations to participate in this new Mercury PM. 53 | 54 | ### How did you hear about the GECO 55 | Website 56 | 57 | ## Your Proposal 58 | ### Project description 59 | **The Flyingcarpet Predictions Dashboard** 60 | 61 | A Flyingcarpet Predictions Dashboard will open up more uses for our decentralised Earth observation models. The Flyingcarpet Predictions Dashboard will enable anyone to create conditions relating to the physical world insofar as a Flyingcarpet model exists for a particular prediction. Flyingcarpet models will serve as oracles and provide a single source of truth for these predictions, thereby allowing conditions relating to the physical world to be made in a trust-minimised manner and without a rent-seeker acting as an arbiter of truth. 62 | 63 | We envisage that the Flyingcarpet Predictions Dashboard will be popular with corporate entities that already plan to use Flyingcarpet for their operations as a way to hedge against unfavourable events. For example, one of our clients is a multinational coffee trader that is using a Flyingcarpet model to estimate crop yields in Brazil; the Flyingcarpet Predictions Dashboard will enable this specific client to hedge against a poor yield using analytics extracted by the same model. We believe that corporates will be some of the biggest users of secure prediction markets, since bets can often amount to disintermediated insurance; the Flyingcarpet Predictions Dashboard will aim to accelerate this future. 64 | 65 | We anticipate that some models, such as those relating to climate change and the environment, will attract larger volumes of prediction market users. We are building a model in partnership with Ice Alive, for which we recently received a grant from Microsoft and National Geographic, that monitors glacial melt in the Arctic and a model for Reforestum that monitors biomass in order to measure CO2 reductions. In the case of the former, we anticipate that everyone from NGOs to researchers engaged in tackling Arctic ice melt will have an incentive to create conditions around the precise rate of glacial melt. Regarding the latter, individuals and organisations that purchase carbon offsets (an immense market) would have an incentive to bet that CO2 reductions are increasing. 66 | 67 | For both of the above climate-related use cases, we believe that corporations and high net worth individuals may use prediction markets to indicate in a transparent and cryptographically secure way to the public that they have serious “skin in the game” vis-à-vis the causes that they profess to champion. 68 |

69 | 70 |

71 | 72 | **The Model Viability Prediction Market Dashboard** 73 | 74 | The Flyingcarpet Network will source optimal models for particular use cases by incentivising data scientists with bounties. Optimal models are then stored decentrally and made available to analytics-hungry organisations. 75 | 76 | Flyingcarpet will integrate the new Gnosis Mercury smart contracts with our Model Viability PM Dashboard front-end in order to enable participants to create conditions about the future demand for, and financial profitability of, potential models (e.g. predictions like “if a model for soybeans in the United States gets created, will it generate $100k of revenue (in Dai) in the first 6 months?”). All Flyingcarpet Network participants, including data scientists, satellite imagery providers and paying organisations, have a vested interest in what model use cases get created. Our initial models are being built based on direct relationships with clients, however since the Flyingcarpet Network will be fully decentralised, it needs an ongoing mechanism to crowdsource sentiment from network participants in a trustless manner; therefore, this is an ideal use case for a prediction market. 77 | 78 | Given the volume of Flyingcarpet participants that will have an incentive to participate in the Model Viability Prediction Market, we anticipate that this integration will bring substantial users to Gnosis’ platform. Once Flyingcarpet attracts large numbers of data scientists, network effects will kick in and we expect large businesses to participate in the Model Viability Prediction Market in order to leverage Flyingcarpet data scientists to suit their specific needs, which will further drive activity on Gnosis’ platform. 79 | 80 | ### Features 81 | Below we will expand on the technical features of our two Gnosis prediction markets and outline some additional financial instruments we intend to develop on top of Gnosis. 82 | 83 | **The Flyingcarpet Predictions Dashboard** 84 | 85 | The Predictions Dashboard functions as a front-end interface where users can interact with Gnosis predictions that use analytics from Flyingcarpet models. This web3-enabled dashboard will be integrated with both the Gnosis PM and Flyingcarpet smart contracts. 86 | While the Flyingcarpet contracts will provide model information (e.g. what model oracles are available), the Gnosis Mercury `PredictionMarketSystem` contracts will function as the interface for all predictions based on Flyingcarpet insights, allowing prediction bets to be created and sending back event outcome information. 87 | The Flyingcarpet smart contracts only contain hashes (e.g. IPFS) corresponding to models and their extracted analytics, as models are both stored and executed off-chain. The Flyingcarpet smart contract will provide Gnosis Mercury v2.0 smart contracts access to extracted model analytics (e.g. to determine condition outcomes). 88 | 89 | 90 |

91 | 92 |

93 | 94 | 95 | The Flyingcarpet model contract acts as an oracle for conditions created on the Gnosis Mercury prediction market. The Flyingcarpet Predictions Dashboard integrates directly with both the Gnosis Mercury contract and the Flyingcarpet oracles contract. Predictions market interactions—such as calls to `prepareCondition()` and `redeemPositions()`—are made directly to the Mercury `PredictionMarketSystem` contract, while the Flyingcarpet models contracts settles condition outcomes (by calling `receiveResult()`) with the Mercury contract. 96 | 97 | **Model Viability Prediction Market Dashboard** 98 | Conditions created around the demand / profitability of future models will be used to gauge the interest of the Flyingcarpet community with regard to model creation options (e.g. a corn yield model vs a large cargo ship counting model). Since this application requires conditional market support (e.g. predictions of the format: “if x model is built and x model is arbitrarily profitable/in demand”), it is an ideal use case for Gnosis’ new v2.0 Mercury contracts which enable more efficient conditionals due to all contract functionality being consolidated into a single monolithic design (e.g. fewer transaction fees, etc.). 99 | 100 |

101 | 102 |

103 | 104 | **Additional Decentralized Financial Instruments** 105 | In addition to the aforementioned Flyingcarpet prediction markets, we plan to construct a number of other financial instruments on top of Gnosis, including: 106 | 1. Partial model ownership tokens (see Whitepaper) as collateral against loans and conditions created on Flyingcarpet’s (Gnosis) Predictions Dashboard. 107 | 2. Trading of partial model ownership assets on DutchX exchange contracts. 108 | 3. Integration of Gnosis Safe for storing partial model ownership tokens and interacting with Flyingcarpet PMs and our future DutchX exchange integration. 109 | 110 | ### Team description 111 | **Julien Bouteloup, CEO** 112 | 113 | Julien holds a Master’s degree in electrical engineering from the USA and a Master’s degree in electrical engineering from France, where he specialised in artificial intelligence, decentralised systems and security back in 2009. He has built multiple tech businesses ranging from energy trading, high frequency trading, decentralised identity to autonomous transportation systems and won multiple competitions worldwide. He was first introduced into Bitcoin in 2010 and then Ethereum in 2015. He is a full-stack engineer and developer, a regular speaker at Ethereum and Blockchain conferences, including Devcon. He teaches blockchain in London (https://www.theblockchainconnector.com/meet-the-team), advises OECD (Organisation for Economic Co-operation and Development), ADB (Asian Development Bank) and BBA (British Blockchain Association). 114 | 115 | 116 | **Leopold Joy, Lead Developer** 117 | 118 | Leopold is a full-stack software developer. He taught himself to program at the age of 13 and founded and built his first startup at the age of 15. As an undergraduate he studied Computer Science at Bard College and the Rensselaer Polytechnic Institute (RPI), both in New York. Leo has extensive experience in open-source software development, Ethereum and blockchain, and co-founded a number of early stage startups, including an early large-scale Monero mining operation and campus messaging app. He is an active member of the open-source blockchain community and excited to radically disrupt the geospatial analytics space with Flyingcarpet. 119 | 120 | 121 | **Victor Faramond, Developer** 122 | 123 | Victor is a full-stack developer with an MSc in maths and computer science. He founded MoonPay, a credit card facility for purchasing crypto and is the Head of Engineering at Hodl.vc. Previously, he completed an 11-month software engineering internship at Apple. 124 | 125 | **Mike Onorato, Developer** 126 | 127 | Mike received his B.S.E. from Princeton University with a senior thesis in machine learning and a certificate in robotics and intelligent systems. He has extensive startup software engineering experience and, most recently, worked as a Senior Software Engineer at DroneBase, building next-generation software for drones. 128 | 129 | **Satya Doraisamy, Legal Lead** 130 | 131 | Satya has experience in investment banking and venture capital, and has also founded Nebula Learning, an education startup. At Flyingcarpet, he handles legal documentation, assists with business development, and co-authored the white paper. 132 | 133 | ### Timeline, Milestones and Deliverables 134 | **Phase I: Front-End Development Prediction Market Dashboards** 135 | 136 | **Deliverables:** 137 | 138 | 1. **Complete development of Flyingcarpet Predictions Dashboard:** the Predictions Dashboard, a web3-enabled dApp, will be a fully featured UI enabling users to interact with predictions based on Flyingcarpets model oracles. Users will be able to make predictions directly from the interface, as well as view charts/graphs of relevant historical analytics extracted in the past. 139 | 140 | 141 | 2. **Complete development of Flyingcarpet Model Viability Prediction Market Dashboard:** Another web3-enabled dApp, the Model Viability Prediction Market will provide Flyingcarpet community members with a market to bet on the future profitability and demand for new models. The dashboard will provide a UI to compare these conditional predictions and view details about the function of, and market for, each potential future model. Users will be able to view their existing bets and submit new ones via an intuitive UI. 142 | 143 | **Time and Price Estimate:** 144 | $30,000 and completed by end of May 2019. This money will be used to take the pressure off our development teams who are currently self-funding the project. 145 | 146 | **Phase II: Back-End Development of Prediction Markets + Scaling and Launch** 147 | 148 | **Deliverables:** 149 | 150 | 1. **Flyingcarpet Predictions Dashboard Back-End:** We will integrate the Predictions Dashboard with both the Gnosis PM v2.0 Mercury smart contracts and the Flyingcarpet model management smart contracts—these Flyingcarpet contracts will also talk directly to the Gnosis Mercury contracts (see earlier diagram). 151 | 152 | 2. **Integration of Models with Predictions Dashboard:** We will integrate existing Flyingcarpet models with the Predictions Dashboard (e.g. the coffee yield model for our client Sucafina, a multinational commodity trader). The dashboard will then be setup to provide predictions for all future models as they come online—for example: our glacial melt model with Ice Alive (via a partnership with National Geographic & Microsoft), our various insurance catastrophe models with Nephila and AXA and our deforestation model for Reforestum, a platform for purchasing carbon-offsets. 153 | 154 | 3. **Flyingcarpet Model Viability Prediction Market Back-End:** We will integrate the Model Viability Prediction Market Dashboard with the Gnosis PM Mercury v2.0 smart contracts to provide the backbone of the Flyingcarpet community evaluation platform for future models. 155 | 156 | 4. **Drive Adoption of Model Viability Prediction Market by Flyingcarpet Community:** We will continue to develop a strong community and begin to query the sentiment of the community about future model possibilities. This will drive Flyingcarpet community members to Gnosis (via our Model Viability Prediction Market). Because our team is currently very developer-heavy, we will need to hire the necessary talent to grow a strong marketing team to ensure continued community growth and engagement. 157 | 158 | **Time and Price Estimate:** 159 | $30,000 and completed by end of September 2019. We will use this money to fund development of the back-end of the PM dashboards, integration of Flyingcarpet models and to incentivise marketing people to join our team. 160 | 161 | -------------------------------------------------------------------------------- /Proposals/Funded Projects/SocialImpactPredictionMarkets.md: -------------------------------------------------------------------------------- 1 | ## Project Overview 2 | 3 | ### Project name 4 | Social Impact Prediction Markets 5 | 6 | ### Team members 7 | [Raphaël Mazet](https://www.linkedin.com/in/rapha%C3%ABl-mazet-5b76721/) - Project Management 8 | 9 | [Jakub Wojciechowski](https://www.linkedin.com/in/jakub-wojciechowski-5901b68/) - Blockchain dev / Tech lead 10 | 11 | [Alex Suvorov](https://www.linkedin.com/in/alex-suvorov-40528b158/) - Full-stack dev 12 | 13 | [Areti Kampyli](https://www.linkedin.com/in/aretikampyli/) - Ux design 14 | 15 | [Dhen Padilla](https://www.linkedin.com/in/dhenpadilla/) - Front-end dev 16 | 17 | ### The project we’re building 18 | 19 | Since 2015, the Alice team has been building a transparent social impact platform on Ethereum. The core mechanism is a “donation by results” mechanism whereby nonprofits only receive donations once they prove that they’ve achieved their goals. This proof is verified by an independent validator (human or machine), aka an impact oracle. This dApp has been live since 2017, with 3 pilots run to date, and another 10 due to be launched this year. 20 | 21 | Last year, we started working on a complementary impact investment platform, which allows investors to provide upfront seed capital to NGOs so that they can start projects (as NGOs only get donations after achieving their goals). Investors underwrite the risk of projects failing, but they also get paid back automatically and with interest, from the donations, as and when outcomes are achieved. 22 | 23 | In our system, impact investors receive what we call “coupon tokens” in exchange for their investment. In effect, these are conditional tokens that give them a right to be paid back from escrowed donations. 24 | 25 | The aim of this grant application is to refactor our code so that we use the Gnosis conditional tokens instead of our existing implementation. We expect that this will improve usability, increase liquidity, and allow for project signalling, far beyond what we could achieve if we rolled our own conditional token system. 26 | 27 | ### Why we decided to build it 28 | Impact investing has been on our roadmap from the start, and our system is inspired by an existing impact investing asset class called social impact bonds (SIBs), where the outcome payer is generally the government, rather than individual donors on Alice. Alice is essentially creating a platform for decentralised impact bonds with the following benefits: 29 | 30 | * **Tradeable**: currently, governmental SIBs are bonds only in name. They cannot be traded, and certainly cannot benefit from the advantages of a prediction market 31 | 32 | * **Scaleable**: SIBs are temporary contracts that end when all funds set aside by the outcome payer (generally the government) have been exhausted. Alice allows for a perpetual funding model, where NGOs can keep raising donations and impact investment as long as they can demonstrate their impact. 33 | 34 | * **Transparent**: the contractual terms of government-backed SIBs are opaque, as is the track record of the NGOs that are funded by them. Alice provides full transparency on both these fronts. 35 | 36 | Overall, our ambition is to completely transform how social impact is funded, with full transparency that allows funders to discover the most effective social and environmental projects, and help them scale rapidly. 37 | 38 | ### Expected timeline 39 | We expect this project to take 8 months to complete. 40 | 41 | ### Funding request 42 | 43 | $25,000 (Phase I - core impact investing tokens) + $25,000 (Phase II - Signalling) 44 | 45 | ### How we heard about the GECO 46 | 47 | A presentation at EthCC in Paris. 48 | 49 | ## Our Proposal 50 | ### Project description 51 | 52 | In the Alice ecosystem, there are two types of nonprofit funders: 53 | 54 | * **Donors**: these funders make philanthropic gifts to social and environmental projects. These gifts are conditional however, and are held in escrow in a smart contract until the nonprofit running a project proves that it has achieved its predefined goals (e.g. helping a homeless person find long term accommodation). 55 | 56 | * **Impact investors**: these funders provide upfront money to nonprofits, so that they have the resources to start a project. Crucially, the nonprofit is not directly liable to pay back investors. Instead, investors are repaid from escrowed donations, as and when the nonprofit achieves its goals. In effect, these investments are collateralized loans, repaid automatically on the condition that the nonprofit’s goals are achieved. 57 | 58 | *This proposal will focus on Alice’s impact investment protocol, not on the donation side.* 59 | 60 | In the first implementation of Alice’s impact investment process, investors received “coupon tokens” in exchange for their investment, with new tokens minted each time an investment was made. These followed the ERC20 standard, and were meant to be tradeable in our future roadmap. A demo of the process can be found [here](http://demo.alice.si/), and the code base [here](https://github.com/alice-si/contracts). 61 | 62 | With this GECO grant, we propose to refactor the Alice code base to substitute our coupon tokens with Gnosis conditional tokens, that will give investors a much richer set of options than currently available. 63 | 64 | #### I. Base implementation of conditional social impact tokens in the core Alice impact investment protocol 65 | 66 | Gnosis [conditional tokens](https://gnosis-mercury.readthedocs.io/en/latest/index.html) from the [Mercury](https://github.com/gnosis/hg-contracts/blob/master/contracts/PredictionMarketSystem.sol) release are a very interesting abstraction to implement the investment flow in Alice, given that each investment is in effect a collateralized loan, which is only repaid on the condition that social projects achieve their goals. Our implementation of the Gnosis conditional tokens will be called conditional social impact tokens throughout this proposal, and the protocol will be implemented as follows: 67 | 68 | 1. A nonprofit creates a new social project on Alice. It specifies the goals it is aiming to achieve, and the amount that will be paid for the completion of each goal 69 | 70 | 2. Donors make donations to a specific project. These funds are held in escrow in a project wallet. 71 | 72 | 3. Impact investors make loans to the social projects, so that the nonprofit running it can start the work needed to achieve its goals. In exchange for their investments, investors receive conditional social impact tokens. 73 | 74 | 4. Once a goal is achieved, the nonprofit makes a claim and provides the proof of its achievement to an independent validator (aka an impact oracle), tasked with verifying that the claim is correct. 75 | 76 | 5. This validator effectively acts as an oracle for the contract, and if a claim is accepted, it triggers two transactions: part of the escrowed donations are paid directly to the nonprofit, and part is allocated to pay back investors, at which time part of their conditional social impact tokens are burnt. 77 | 78 | The following diagram shows a high-level technical architecure of the Social Impact Investment platfrom: 79 | 80 |

81 | 82 |

83 | 84 | 85 | #### II. New hedging and signalling mechanisms enabled by the use of the Gnosis protocol 86 | 87 | The new version of the Gnosis [prediction markets](https://blog.gnosis.pm/prediction-markets-2-0-teaser-4ee1cfa3d61f) contracts provides very powerful features that can be used in the Alice protocol for hedging and signalling purposes. 88 | This is because of the way that social projects are structured on Alice, with multiple goals, that can be parsed as conditions in a Gnosis framework. 89 | 90 | For example, a social project that aims to help people on the brink of homelessness by helping them find a job may be structured as a sequence of goals: 91 | 1. a person in need is referred to the program and is assigned a key worker, 92 | 2. interview and job training starts, 93 | 3. the person graduates from training, 94 | 4. the nonprofit helps the person secure an internship, and then finally 95 | 5. a permanent job. Each of these milestones may be verified by an impact oracle and trigger payments in the Alice protocol. 96 | 97 | #### 1. Hedging 98 | 99 | Implementing every milestone as a separate condition will offer a fine-grained project structure that could be used for more accurate signalling or well-tailored investments. 100 | 101 | We will use this grant to develop three distinct hedging mechanisms using prediction markets enabled by the use of conditional social impact tokens: 102 | 103 | * The first and simplest will simply allow impact investors who have provided money upfront to nonprofits to take the opposite position on a prediction, hence ensuring that they do not lose their entire investment if the project fails. 104 | 105 | * The second hedging mechanism will allow impact investors to split the various “conditions” of their token, and trade them on. This would allow complex social projects (e.g. a project providing mental health support and job training) to be split into component parts, and allow investors to only keep outcomes that they are interested in (e.g. an investor may only care about the mental health support and not the rest). 106 | 107 | * Finally, conditional tokens will allow investors to hedge their risks against external factors. For example, an investor in a job training project may consider that Brexit could lead to higher unemployment rates hence making it significantly more difficult for the nonprofit to achieve its goals. In this case, the investor could split the tokens on the condition of Brexit happening and sell on that risk to a third party who would be willing to accept the higher risk exposure in return for higher potential returns. 108 | 109 | #### 2. Signalling 110 | 111 | The use of a prediction market based on each project’s conditional social impact token will allow for precise market signals and potentially integrate the voice of people being supported by projects directly. 112 | 113 | * **Precise signalling**: splitting and merging conditions (each project’s specific goals) will allow the markets to help guide investment decisions and even provide operational suggestions to nonprofits. For example, if the markets believe that a key part of the program, such as the process for finding internships, is flawed, it can bet against the achievement of this goal while support all previous conditions. 114 | 115 | * **Beneficiary signalling**: we would like to use this grant to implement a specific kind of signalling provided by the beneficiaries of a project themselves. To do so, we would airdrop conditional social impact tokens on beneficiaries to allow them to weigh in on whether they believe that the social project is well adapted to their needs or not. This could obviously lead to skewed incentives and attack vectors, and part of the grant will be used to explore these and mitigation tactics. 116 | 117 | 118 | 119 | ### Features 120 | 121 | #### Phase I: Social impact investing protocol 122 | 123 | 1. **Integration of conditional tokens in the core Alice protocol** 124 | 125 | We will refactor our social impact investment [contracts](https://github.com/alice-si/contracts) to utilise the [conditional tokens](https://gnosis-mercury.readthedocs.io/en/latest/index.html) from the Gnosis Mercury release as a base component of our conditional social impact token (previously known as the “coupon token” as explained above). This will provide the required flexibility of token splitting and trading and avoid the use of more complex external contracts. 126 | 127 | As the conditional tokens are still a relatively new concept, the integration will involve in-depth testing of the new approach, internal security audits and attempts to optimise the gas consumption. We will also explore the possibility of splitting multiple collaterals and provide a full implementation of position transfer/trading features interfaced by the [ERC-1135](https://github.com/enjin/erc-1155/blob/master/contracts/ERC1155.sol) base contract. We would like to pioneer the new set of use cases for the conditional tokens to be seen as generic building blocks for investment contracts. 128 | 129 | 2. **Simple UI for bonds creation, trading & splitting** 130 | 131 | Impact investors should be able to easily split and merge the conditional tokens to improve their flexibility of risk handling. We are going to implement a simple UI based on a dapp architecture that will allow defining the conditions for a split, connecting to external oracles and merging the previously split tokens. 132 | 133 | The interface will consist of a view that will display a list of conditional tokens currently held by investors. There will be also a detailed view per every token that will show the conditions and connected oracle. Users will have the ability to propose splits and provide the oracle details. 134 | 135 | 3. **Regulated trading-splitting controllers** 136 | 137 | A token representing social impact is a financial product that could be classified as a security. Therefore there is a need to implement restrictions that will govern how the tokens are distributed and traded. Currently, we’re working with two international law firms on the specification for blockchain based social impact investment tokens to assure that they are fully compliant with the financial regulations. 138 | 139 | We plan to implement a controller contract that will contain all of the regulatory imposed limitations. The controller contract will act as a wrapper around a conditional token that will mediate the transfer methods. There will be a way to exchange the controller if tokens need to be adapted to another jurisdiction. 140 | 141 | #### Phase II: Signalling 142 | 143 | 1. **Prediction market creator (integration with our project wizard)** 144 | 145 | The parameters for prediction markets must be based on the structure of the social projects hosted on the Alice website. We want to automate the process of deployment and configuration of gnosis contracts. The solution is going to be implemented as a process that will monitor the state of Alice donation contracts and once it detects that the contracts are fully approved and operational it will deploy the matching prediction market contracts and set up all of the necessary references. It will handle the gas payments, transaction monitoring and error handling. 146 | 147 | The solution will be fully open-sourced and will hopefully provide a reference implementation for other projects to automate integration with the Gnosis protocol. 148 | 149 | 2. **Market monitoring dashboard** 150 | 151 | Fetching all of the data through a web3 protocol could be a slow and frustrating experience for users who are used to fast loading dashboards. If we want to integrate multiple prediction market monitoring on the investors dashboard we should implement a solution that will speed up the initial loading process. Moreover, the Alice platform attracts mainstream donor for whom getting the web3 browser only to check the status of a prediction market may not justify the effort of installing proper tools. 152 | 153 | Therefore, we want to implement the proxy and caching layer to fetch data and store it into an intermediary database for fast access. We already have extensive expertise in this, gained through our experience of building Etheroscope, an open-source smart contract explorer. We hope that these solution may boost adoption of prediction markets especially among less tech savvy users who’d like to monitor the market before making the effort of installing necessary tools and actively interacting with the contracts. 154 | 155 | 3. **Market tracking notification** 156 | 157 | Prediction market mechanism offered by gnosis could be a powerful tool to get instant warning if a social project is facing challenges that may affect its success rate. The instant reaction and involvement from the side of social impact investors may often help to put the project back on track and reduce the risk of not achieving the promised goals. 158 | 159 | Therefore, we are going to implement an instant notification module that will directly inform engaged parties when there is sudden change in the prediction market. The solution will be built as a monitoring daemon which will listen to the smart contract events and determine when a market alert should be triggered. The monitoring process will be connected to a messaging service that will automatically notify the previously specified recipients. 160 | 161 | 4. **Special-purpose beneficiary wallets** 162 | 163 | We are going to design and implement a special purpose wallet that will be funded with air-dropped tokens for beneficiaries. The wallet will restrict the token usage only to the specific market that the beneficiaries participate in. It will also control the investment flow reducing the risk of sudden spending and speculation. 164 | 165 | 5. **Project feedback interface for beneficiaries** 166 | 167 | We cannot assume that beneficiaries are either tech-savvy or blockchain experts. Therefore, the usability of the interface for reporting project progress are key requirements for this module. 168 | 169 | We are going to integrate with browser-based ephemeral wallet such as the [burner-wallet](https://github.com/austintgriffith/burner-wallet) to remove the need of installing extra tools. We also plan to use gas-less transactions support by leveraging the technology offered by [gas-network](https://medium.com/tabookey/1-800-ethereum-gas-stations-network-for-toll-free-transactions-4bbfc03a0a56) or other similar [meta-transaction](https://meta-tx.github.io/) solutions. The final design of the interface will be based on our experience in implementing highly accessible blockchain solutions like our [donation app](https://donationsapp.alice.si/). We believe that the implementation of prediction markets with the focus on usability and accessibility of the final interface could boost the adoption of similar projects based on the gnosis infrastructure. 170 | 171 | ### Team description 172 | 173 | **Raphaël Mazet** 174 | 175 | Before co-founding Alice, he was co-founder of CliqStart, a digital activism startup focused on charity advocacy campaigns. Before becoming a social tech entrepreneur, he spent ten years managing a team responsible for corporate communications in Europe and Latin America. Raphaël is Franco-British and trained as a political scientist at the London School of Economics and Sciences-Po Paris. He’s actively engaged in the blockchain space for over 3 year as an expert and conference speaker. He’ll work as a project manager. 176 | 177 | 178 | **Jakub Wojciechowski** 179 | 180 | Jakub is a software engineer specialised in blockchain technology and financial services. He has a Master’s degree in computer science from the University of Warsaw, where he also obtained an undergraduate degree in economic psychology. Before co-founding Alice, Jakub was the founder of Silvertown, a proptech company powered by the blockchain and using IoT to automate the management of large social housing estates. Prior to this, he worked for several years at Efinity, a Polish insuretech startup, and as a flex and java consultant for financial sector clients at Infovide-Matrix. He’s contributing to various open-source projects like: OpenZeppelin, Etheroscope, SensorTrx and speaker of a few Ethereum tech-conferences including devCon, ethCC, Ethereum London Meetup. He also runs a Warsaw Smart Contracts Code Club. He’ll work as a blockchain developer. 181 | 182 | 183 | **Areti Kampyli** 184 | 185 | Areti has a background in advertising, communication and design. She started her career in advertising at Ogilvy & Mather, where she managed clients including Delta Airlines and BT. She launched her first tech startup in 2009 and prior to Alice, Areti was CEO of CliqStart. She is a London School of Economics graduate, where she did her MSc in media and communications. She will be responsible for the UX design, implementation and user testing. 186 | 187 | **Alex Suvorau** 188 | 189 | Alex is a software engineer. He studied computer science program at the University of Warsaw. Before joining Alice Alex worked as a software engineer at Polish software agency Atinea. He’s a winner of national mathematical competition of Belarus. He’s been passionate about the blockchain space for two years attending a few hackathons and working on his own projects. He’ll work as a full-stack developer. 190 | 191 | **Dhen Padilla** 192 | 193 | Dhen is a software engineer, with a background in UI/UX and machine learning. He has worked on projects with Nuffield Health and NHS Royal College of Surgeons, designing and producing interoperable Web & iOS Applications. Dhen is presently pursuing his MEng at University College London, specialising in decentralised network anonymisation and deep learning. He’ll be responsible for front-end development. 194 | 195 | 196 | ### Timeline, Milestones and Deliverables 197 | 198 | **Phase I: Social impact investing protocol** 199 | 200 | **1. Implementing impact investments as smart-contracts powered by conditional tokens** 201 | 202 | **Deliverables:** 203 | 204 | * Use conditional tokens as a base building block for tokenized impact investments 205 | * Implement the investment creation factory 206 | * Implement the investment and interest repayment flow 207 | * Integrate the conditional token splitting/merging mechanism as a way to increase liquidity 208 | 209 | **Time and price estimate** - 1 month, $6,250 210 | 211 | **2. Social impact investment management platform** 212 | 213 | **Deliverables:** 214 | 215 | * Implement UI for creating/funding social impact investments 216 | * Implement UI for splitting/merging bonds 217 | * Implement the integration with Alice’s donation and validation (impact oracles) modules 218 | 219 | **Time and Price Estimate** - 2 months, $12,500 220 | 221 | **3. Social impact investment controllers** 222 | 223 | **Deliverables:** 224 | 225 | * Specify the generic regulatory requirements 226 | * Implement smart-contract powered controllers mediating interactions with bond contracts to assure following the regulatory requirements 227 | 228 | **Time and Price Estimate** - 1 month, $6,250 229 | 230 | **Phase II: Signalling** 231 | 232 | **1. Integrating Gnosis markets as a signaling tool for the Alice platform** 233 | 234 | **Deliverables:** 235 | 236 | * Integrate market deployment into the project creation wizard 237 | * Integrate market monitoring into the Impact tracking dashboard 238 | * Integrate market events into the donor feedback mechanism 239 | 240 | **Time and price estimate** - 2 months, $12,500 241 | 242 | **2. Building an app for beneficiaries to provide feedback about project status** 243 | 244 | **Deliverables:** 245 | 246 | * Implement a special purpose wallet in the form of a pre-funded smart-contract proxying the interaction with the prediction markets 247 | * Build a convenient interface for beneficiaries to report progress of the social project 248 | 249 | **Time and Price Estimate** - 2 months, $12,500 250 | 251 | 252 | -------------------------------------------------------------------------------- /Proposals/Funded Projects/InstantDX.md: -------------------------------------------------------------------------------- 1 | 2 | # Gnosis Grant Application 3 | 4 | ## Project Overview 5 | ### Project name: [InstantDX](https://github.com/collateralized/instant-dutchx) 6 | -------- 7 | ### Team members 8 | **Hilmar Orth (Hilmar X)** - [Twitter](https://twitter.com/hilmarxo), [Github](https://github.com/hilmarx), [Linkedin](https://www.linkedin.com/in/hilmarx/) 9 | 10 | **Luis Schliesske (Bytezantium)** - [Twitter](https://twitter.com/bytezantium), [Github](https://github.com/bytezantium), [LinkedIn](https://www.linkedin.com/in/schliesskeluis/) 11 | 12 | ------- 13 | ### The Project 14 | 15 | #### Abstract 16 | [Quote](https://blog.gnosis.pm/the-mechanism-design-of-the-gnosis-dutch-exchange-4299a045d523) by Nadja Beneš: 17 | *“The Dutch Auction mechanism is game theoretically known to be an efficient way of determining a fair market price for fungible goods. One drawback of the auction model is that the exchange is not instantaneous (and funds can’t immediately be withdrawn), which makes fast trading impossible.“* 18 | 19 | InstantDX is an application built on top of DutchX that will provide an instant payout option to sellers, enabling them to opt out of the various drawbacks associated with having one’s liquidity locked up in long-running DutchX auctions. Instead, they can receive part of their expected payout instantaneously in the form of a bridge loan from the InstantDX liquidity pool. The initial immediate payout is followed by a second payout, after the auction has cleared, to settle the total remaining balance payable to the seller at the actual price that was discovered in the auction. 20 | 21 | This will allow users of the DutchX to benefit from all of its benefits, such as fair pricing, gas efficiency, smart-contract enabled trading and the impossibility of front-running, while still being able to perform actions that require an instant exchange of tokens, such as: 22 | - Interacting with dapps 23 | - Paying down large CDPs 24 | - Paying infrastructure fees without the need to hold the network token in large reserves 25 | - Applying certain risk management techniques, to avoid financial losses or make a profit. 26 | - Earning an interest by lending out their liquidity 27 | … and many more. 28 | 29 | #### Why did we decide to build InstantDX? 30 | Current decentralized exchanges enable their users to retain true ownership of their assets while trading peer-to-peer in open markets. However, many of the early implementations suffer from flaws concerning their fairness and decentralization in crucial aspects, such as their price discovery mechanism. Gnosis Dutch Exchange offers the first fully decentralized mechanism for finding fair market prices for most crypto assets, especially for those lacking adequate liquidity. In our opinion, being able to always access liquidity at a fair price is essential to create a thriving crypto economy that is not only accessible by the financial and technology savvy, but opens up participation to everyone that wants to be a part of this ecosystem. 31 | 32 | However, in order to gain mainstream adoption from both Dapp developers and investors, there needs to be an option to remove the costs of time and illiquidity from the sellers participating in the DutchX mechanism. This is why we think InstantDX can help accelerate the adoption of the DutchX and with it significantly improve the efficiency, fairness and reduce the internal frictions of the Ethereum protocol, in order to fulfil its potential as a global decentralized value transfer protocol. 33 | 34 | At the same time, we are very focussed on the possibilities of decentralized lending. Enabling users from all over the world to gain access to cheap capital and move assets from larger investors to smaller ones, allows the creation of wealth to gradually spread more evenly through the ecosystem. Allowing holders of crypto assets to earn an interest on their idle assets is needed to attract more people to switch over to crypto from the old financial institutions, where their dollars in the bank still earn them a ‘risk-free’ interest payment. 35 | 36 | We are extremely excited about the improvements the DutchX project and decentralized lending can bring to the current economic systems. We want to contribute to the mainstream adoption of both by providing these synergies to the participants in the ecosystem with continuous liquidity via DutchX-InstantDX. 37 | 38 | #### How long will it take? 39 | 22 weeks (5.5 months) - Deadline: 15.10.2019 40 | 41 | #### How much funding do we need? 42 | Since we intend to work full-time on InstantDX, the budget for the 5.5 months consists of covering our basic living expenses in Berlin. We estimate those to be $2k before taxes per person per month. Hence the budget for 5.5 months would be $22k (4k per month). Both of us will be working full time throughout the duration of this project phase and would be glad to work at Gnosis HQ in Full Node Berlin, if possible. 43 | 44 | #### How did we hear about the GECO? 45 | [Medium post](https://blog.gnosis.pm/unveiling-the-gnosis-ecosystem-fund-7353926bfb65) by Mareen Gläske from December 2018. 46 | 47 | -------- 48 | ## Proposal 49 | 50 | ### Project description 51 | #### Why DutchX? 52 | Upon learning about DutchX, we felt encouraged to take action and do our part in bringing about the removal or alleviation of some of current problems facing decentralized exchanges, which include 1) lack of full end-to-end decentralization in DEX designs, 2) Ethereum’s gas model and fees, 3) lack of adequate liquidity to determine a fair price and 4) DEXs not facilitating smart contracts buying and selling on them. 53 | 54 | From the stated main problems facing decentralized exchanges today, DutchX sufficiently solves at least the following four of them: 55 | 1. Centralized order books and front-running in current DEX environments 56 | 2. Ethereum’s gas fees for cancelled orders. 57 | 3. Finding a fair market price for less liquid tokens. 58 | 4. Smart-contract enabled trading 59 | 60 | Regarding participation in the DutchX, however, usability constraints undoubtedly emerge for those, who are unwilling to part from liquidity for longer periods of time (~6-12 hours). This concerns any human or smart contract that operates with the need for a continuous flow of liquidity, not just speculators and day-traders. Probably the way people perceive risk in general, and the time-value of money, will urge a significant amount of people to prefer instant order execution over delayed payouts. This hurdle to adoption is exactly what InstantDX aims to remove. 61 | 62 | #### A detailed description of the project: 63 | First of all, we would like to make it clear that when we refer to ‘users’, ‘participators’ or ‘sellers’ in what follows, we include both smart contracts and humans in our thinking. Indeed we expect that, sooner or later, a majority of direct traders on the DutchX will likely be smart contracts. 64 | 65 | Gnosis vision is to “build new market mechanisms to enable the distribution of resources—from assets to incentives, and information to ideas”. We share those ideals and want to contribute to the adoption of the mechanisms that will facilitate a fairer distribution of resources across the upcoming global financial crypto economy. 66 | 67 | The goal of InstantDX is to improve the user experience of the DutchX and to greatly accelerate its adoption. To do so, we plan to extend the DutchX suite of features with an option for sellers to bridge the periods of lost liquidity that are an unfortunate byproduct of the workings of this auction mechanism. The time-span of the auctions is forecasted to last 6 hours at a minimum. However, the duration of seller illiquidity could well average on 10 hours, given that sellers cannot submit asks to ongoing auctions, but have to post sell orders beforehand and then wait for the next auction of their trading pair to begin and clear. 68 | 69 | Here, InstantDX adds significant value to the DutchX, by providing sellers with instantaneous liquidity via our liquidity pool and payout formulae. It does so by opening the DutchX to users, who operate and trade with a continuous need for unrestrained liquidity. Examples include: 1) The need to pay for infrastructure fees, 2) apply risk management techniques, 3) interact with dapps, or 4) the opportunity to earn interest on their tokens. 70 | 71 | The application achieves the provision of instant liquidity by lending sellers the tokens they want to trade into. InstantDX smart contracts source the tokens to be paid out from a liquidity pool, which in its infancy will be funded from whitelisted addresses. In later stages of the project we will further open the funding of the pool to be permissionless. Token holders are incentivized to contribute to the InstantDX pool with the opportunity to earn an interest on their stake. Interest payments to liquidity providers are funded by the DutchX-InstantDX users’ interest payments on the instant liquidity they have received. We also intend to source liquidity from lending protocols such as Compound or Maker in future releases. 72 | 73 | *Figure 1: InstantDX standard payout mechanism with the following example parameters: previous auction price: 1 ETH = 100 Dai, instant payout rate (‘loan-to-value ratio’) = 67%, auction price: 1 ETH = 100 Dai, interest rate = 0.1%.* 74 | ![InstantDX standard payout mechanism](https://github.com/collateralized/instant-dutchx/blob/master/charts/InstantDX-payout-%20mechanism-%20chart.png "InstantDX standard payout mechanism") 75 | 76 | In essence, the application offers DutchX users a new choice in their interactions with the exchange. If instant liquidity and time is not of interest to the seller, they can proceed with the normal auction process. However, if liquidity and time is of importance, as will be the case for many humans and automata, they can gain value from InstantDX in the normal scenario like so: 77 | 78 | #### Payout Formula: 79 | 80 | _Note: The payout formula is written from the perspective of the InstantDX liquidity pool_ 81 | 82 | **Payable1ToUser** = P0 * Q * LVR 83 | 84 | **AuctionReceivable** = P1 * Q 85 | 86 | **Payable2ToUser** = AuctionReceivable - Payable1ToUser - interest 87 | 88 | -------- 89 | 90 | **Where:** 91 | 92 | **P0** is price of previous auction 93 | 94 | **P1** price of upcoming auction, 95 | 96 | **Q** is quantity sold by the seller, 97 | 98 | **LVR** is the loan-to-value ratio , 99 | 100 | **interest** is the interest paid to the pool. 101 | 102 | *Figure 2: InstantDX vs. regular DutchX payout process* 103 | ![InstantDX vs. regular DutchX payout process chart](https://github.com/collateralized/instant-dutchx/blob/master/charts/InstantDX-vs-DX-payouts-chart.png "InstantDX vs. regular DutchX payout process") 104 | 105 | 1. A seller wants to sell a certain quantity _**(Q)**_ of a token on the DutchX using InstantDX and sends the tokens to our smart contract. 106 | 2. The smart contract places the sell order on the DutchX 107 | 3. The InstantDX pool immediately transfers a bridge loan _**(Payable1ToUser)**_, meaning _**Q * LVR (e.g. ~67%)**_ of expected tokens, to the seller using the previous auction price _**(P0)**_ as a benchmark. 108 | 4. The auction settles on a price _**(P1)**_ and clears the total sell volume _**(Q)**_. The purchased tokens _**(AuctionReceivable)**_ are transferred from the DutchX to InstantDX’s smart contracts 109 | 5. InstantDX smart contracts pay out the outstanding trade balance _**(Payable2ToUser)**_ to the seller. 110 | 6. The interest paid by the seller gets distributed among InstantDXs liquidity providers 111 | 112 | In order to protect the liquidity providers of the InstantDX pool against possible black swan events, in which the auction settles on a price for the receivable token that is less than the 1 - LVR safety margin, we introduce three safety mechanisms: 113 | 114 | 1) For every sale through InstantDX, 10% of the pools earned interest is accumulated within the pools buffer. Those funds will be used to compensate potential losses of the overall pool. 115 | 2) Similar to other lending protocols, in our early versions we will only include low risk collateral tokens combined with low LVRs. We intend to gradually introduce more token pairings as the volatility of these assets decreases over time. 116 | Only in an extreme edge case where these two safety mechanisms fail, the pool automatically conducts safety mechanism number three: 117 | 3) Haircutting the entire pools liquidity by the incurred losses. 118 | 119 | We are convinced that despite the aforementioned risk, liquidity providers will still be strongly incentivized to contribute funds to the InstantDX pool. They will be compensated for the minor risk they incur, by having significantly more interest accrue to them compared to that of other lending protocols, like Compound, which aim to be the risk-free rate of the market. This is possible because, even though interest paid by individual sellers participating in the DutchX-InstantDX will be very small, these isolated marginal payments are compensated for in the high sell volumes to be expected on the DutchX. In fact, the interest earned by liquidity providers will accumulate every 6 hours on average. 120 | 121 | 122 | #### Overall goal and future outlook: 123 | 124 | #### Overall goal 125 | The overall goal of the project is to build and seamlessly integrate a first version of InstantDX with the DutchX protocol, in order to enable sellers to be able to receive instant payouts on their DutchX sell orders. Our target users are developers, smart contracts and sophisticated end users that want to provide themselves, or their users, with access to the DutchX auction mechanism and its promise of fair pricing, whilst still having access to instant liquidity, thanks to InstantDX’s real-time payout feature. 126 | 127 | #### Future Outlook 128 | After enabling the InstantDX application for the first trading pair, other crypto assets can gradually be added to the offering. Beyond that, the system can offer a variety of additional features to the DutchX users, such as: 129 | 1. Automated price insurance, which guarantees the seller a minimum ask price for their sell order by automatically placing a buy order in the auction at a minimum ask price they can specify. 130 | 2. Automated lending of sellers’ liquidity on lending platforms, to have instant interest accrue to them. 131 | 3. Integrations of InstantDX with other applications, like dapps built on top of MakerDAO that manage CDPs, by enabling them to automatically purchase large sums of Dai on the DutchX instantaneously, in order to avoid liquidation of their CDPs 132 | 4. Usage in prediction markets, such as Gnosis, to provide instant liquidity for certain types of bets when the outcome can be predicted with high probability, similar to the “cash out” service of modern sport betting companies. 133 | 134 | ------- 135 | ### Features 136 | 137 | #### How do we plan to implement InstantDX? 138 | *Figure 3: Smart Contract Architecture* 139 | ![Smart Contract Architecture diagram](https://github.com/collateralized/instant-dutchx/blob/master/charts/InstantDX-smart-contract-architecture.png "InstantDX Smart Contract Architecture") 140 | 141 | *Note: Version 0.1 of the InstantDX app comprises parts 1 & 2. Part 3 will be part of the next iteration:* 142 | 143 | #### Part 1: Creating an escrow contract that interacts with the DutchX 144 | The escrow smart contracts objective is to act as the address that sells and collects the users tokens to and from the DutchX. For each sell order, a unique escrow contract will be deployed by the respective pool contract. The escrow contract provides 4 core functionalities: 145 | 1) Accepting funds from the pool contract. 146 | 2) Selling the received tokens on the DutchX. 147 | 3) Claiming the funds receivable upon settlement of the auction. 148 | 4) Transfering the received tokens to the pool contract. 149 | 150 | #### Part 2: Pooling collateral from investors and creating a micro lending platform 151 | The counterpart of the escrow contract is the pool contract. Its purpose is to pool funds from individual contributors, calculate and facilitate the payouts to sellers, and transfer the earned interest to the liquidity providers of the pool. There will be an individual pool contract for each ERC20 token locked in the InstantDX system with customized LVR and interest fees. Each of these pools contain a ledger of all transactions to borrowers and liquidity providers. 152 | 153 | #### The core functionalities of the Pool Contract are: 154 | 1) Verifying that sufficient funds are present to cover the initial instant payout. 155 | 2) Accepting seller tokens, if sufficient funds are present. 156 | 3) Deploying an individual escrow contract. 157 | 4) Paying out the first payout (bridge loan) to the seller. 158 | 5) Receiving tokens after auction settlement from escrow contract. 159 | 6) Transfering the second payment to the seller after the auction ends. 160 | 7) Distributing interest among liquidity providers. 161 | 8) Building up an internal liquidity buffer to defend against possible black swan events. 162 | 9) Accepting withdrawals and transferring requested funds back to liquidity providers. 163 | 164 | We are aware that, at start, it requires some additional funding to initialize the liquidity pool. However, by restricting the total sell volume to be handled by InstantDX at any given time, and by limiting the supported token pairs we can gauge the required up-front capital and set it to a manageable amount, in order to scale the project in a controlled fashion. 165 | 166 | At the beginning the list of possible investors to the pool will be whitelisted, meaning that before accepting permissionless third-party money, the contracts will have to be tested rigorously on mainnet and with selected investors that accept the risk of losing funds. 167 | 168 | #### Part 3: Connecting InstantDX to other lending platforms to access an even larger pool of liquidity 169 | The beauty of a permissionless blockchain protocol like Ethereum is that we can tap into the liquidity of other already established lending platforms such as Maker or Compound, in order to increase InstantDXs ability to provide instant liquidity to even more DutchX users. This will be achieved by a third major contract called Platform Manager, which serves the following functionalities: 170 | 1) Comparing interest rates and maximum borrow amount on pre-selected lending protocols, in order to select the most economical option. 171 | 2) Depositing collateral at chosen lending protocol. 172 | 3) Borrowing the required asset being purchased by the DutchX seller. 173 | 4) Transferring the funds to the Pool Contract. 174 | 5) Receiving the acquired tokens after dutch auction has been settled from the Pool Contract. 175 | 6) Wiping the loans debt. 176 | 7) Sending the freed up collateral back to the Pool Contract. 177 | 178 | The platform manager contract will be customized for each lending protocol and autonomously manages the credit positions of the liquidity pool. At first we will most likely only use stable DAI as collateral for acquiring loans on these platforms, in order to mitigate collateral liquidation risks. As soon as more complex derivatives gain the necessary liquidity on Ethereum, such collateral types can be used, and their risk can be managed accordingly by the Platform Manager smart contracts. 179 | 180 | #### Tools and frameworks: 181 | - Smart contracts: Solidity 182 | - Documentation: Web3, Javascript 183 | - Testing & Deployment: Truffle 184 | - Libraries: SafeMath.sol, SafeToken.sol 185 | 186 | ------ 187 | ### Team description 188 | #### Who are we? 189 | Luis & Hilmar have been working together on projects since 2016, founded two companies along the way and led software development projects using Ethereum for multiple Fortune500 companies. 190 | #### Hilmar Orth aka HilmarX 191 | - Full Stack Developer (Solidity, Javascript, Python, C, Ruby) 192 | - Hooked on DAOs - first ever [tweet](https://twitter.com/hilmarxo/status/735567875793137664) was about “The DAO” 193 | - Co-founded and led energy blockchain startup DEEP (d33p.org) 194 | - Participant of ETHSingapore & Prize Winner at ETHParis 195 | 196 | #### Luis Schliesske aka Bytezantium 197 | - Full Stack Developer (Python, Solidity, C, JavaScript) 198 | - Political Economy graduate at King's College London 199 | - Enjoys to theorize about games 200 | - Co-Founded and headed Konfid.io Contract Solutions. Led project developing private blockchain MVP at European Fortune100 company. 201 | 202 | #### Latest collaborative Projects: 203 | - [Collateralized](https://github.com/hilmarx/collateralized) - Decentralized Interest Rate Swaps on Ethereum. Allows borrowers and lenders to refinance their loans between multiple lending platforms like Maker and ETHLend. 204 | 205 | - [IPFSWAP](https://github.com/hilmarx/ipfswap) - Enables ERC20 token swaps using Kyber Networks liquidity hosted on IPFS. 206 | 207 | ------- 208 | ### Timeline, Milestones and Deliverables 209 | 210 | #### Overall Deliverables: 211 | 212 | The overall goal will be the deployment of InstantDXs v0.1.0 on Ethereum mainnet, in order to test our idea out in the wild with a preselected set of liquidity contributors. Version 0.1.0 encompasses the aforementioned steps 1 & 2 plus the creation of developer documentation. Step 3 would be a natural next step after this phase to increase the number of token pairs supported by InstantDX. 213 | In the scope of the project, the more specific deliverables are: 214 | 1) Development and deployment of Escrow and Pool smart contracts facilitating the escrow, token transfers, pooling, borrowing, interest payment, lending and fee calculation operations 215 | 2) Creation of developer documentation outlining how to integrate the InstantDX feature in user facing applications like slow.trade and other developer targeted applications 216 | 3) Creation of a liquidity pool of at least one asset (e.g. DAI) that can kickstart the liquidity provision. 217 | 218 | #### Detailed description of your timeline milestones and the corresponding payouts 219 | #### Phase I - Development of Escrow.sol + deployment & testing on Rinkeby 220 | **Goal:** 221 | 222 | Deployment of escrow contracts to act as a secure interface between a simulated future pool contract and the DutchX. 223 | 224 | **Deliverables:** 225 | - Development Escrow.sol 226 | - Deployment Rinkeby 227 | - Unit & integration testing 228 | - Gas optimization 229 | 230 | **Time and Price Estimate** 231 | - **Time:** 1.5 months 232 | - **Deadline:** 15.06.2019 233 | - **Price Estimate:** 6k 234 | 235 | #### Phase II Development of DaiPool.sol + deployment & testing on Rinkeby 236 | **Goal:** 237 | 238 | Deployment of pool contract, accepting e.g. Dai as collateral, interacting directly with deployed escrow contracts and transfering funds to the seller. 239 | 240 | **Deliverables** 241 | - Development DaiPool.sol 242 | - Price oracle selection and integration 243 | - Deployment Rinkeby 244 | - Unit & integration testing 245 | - Gas optimization 246 | 247 | **Time and Price Estimate** 248 | - **Time:** 2.5 months 249 | - **Deadline:** 30.08.2019 250 | - **Price Estimate:** 10k 251 | 252 | #### Phase III Iterations on both Escrow and Pool Contracts & mainnet deployment of v0.1.0 + seeding of pool 253 | **Goal:** 254 | 255 | Successful completion of test phase on Rinkeby and mainnet deployment 256 | 257 | **Deliverables** 258 | - Mainnet deployment of InstantDX v0.1.0 259 | - Pool seeding and beta testing with whitelist investors 260 | - Creation of developer documentation 261 | 262 | **Time and Price Estimate** 263 | - **Time:** 1.5 months 264 | - **Deadline:** 15.10.2019 265 | - **Price Estimate:** 6k 266 | 267 | ### Remarks 268 | Our team will be working full time on this project and plans to continue its implementation beyond the scope of this grant. 269 | The other passion our team shares with Gnosis is decentralized governance. Our long term plan would be to create a - or integrate with an existing - DAO which manages the risk parameters of InstantDXs lending activities and makes crowdsourced decisions about what application to integrate next. We would be thrilled to gain & share insights regarding such opportunities from the Gnosis team and start a discussion about how the dxDAO could be a part of that. 270 | 271 | --------------------------------------------------------------------------------