Whitepaper

dApp Builder Whitepaper

The purpose of dApp Builder is to bring smart contract technology to the business users who do not necessarily have the technical know-how to create smart contract.

You can think of dApp Builder as WIX.com for smart contracts.

User Authentication

For the purposes of dApp Builder we will need to have a strong user identity. This is especially necessary in a corporate/enterprise environment.

We are not going to develop our own authentication system but instead we will integrate with identity providers such as

1. Google.com (OAUTH)
2. Civic.com (JWT Token)
3. Others will become added if requested by users

The user will authenticate with our system using one of the above identity providers.

Interaction of authenticated users with the system:

Once the user has logged into our system, she can do one of the two things:

1. Customize a UI/UX of one of the standard dApps developed by dApps Builder. The description of these dApps is available below. In this case we provide to the users something like WIX.com for smart contracts.

   The UI/UX of dApp created using such a constructor is accessible from:

   1. a regular webpage which can be looked at by a regular desktop browser. In this case for integration with methods of smart contract the user has to use MetaMask or a similar solution.
   2. a mobile device where dApp is integrated as a widget. In this case connection to Blockchain, signing of the transactions, saving of the accounts happens by means of Ethereum Mobile Wallet built into the widget.

2. Provide us with an address of user smart contract already published in Ethereum blockchain. In this case we will:

   1. Inspect the address of this smart contract pulling out Contract Metadata and Application binary Interface.

   2. Automatically create WEBAPI methods under https://dapps.ibuildapp.com accessing the methods of user smart contract

   3. Let user create and publish desktop and mobile widgets and templates a-la https://www.ibuildapp.com/ accessing the user's smart contract through our WEBAPI (underneath this WEBAPI will be using Ethereum Web3 package.). These widgets and templates will be published on IBuildapp Marketplace in a special category of smart contracts with sub-categories for

      TODO: insert here the slide with categories

   In the process of such publishing the user will be able to add a description to her smart contracts, give them a name, an identity and so on.

Description of standard dApps:

The following smart contracts will be initially available on dApps Builder platform

Voting

1. in dApp Builder the owner customizes:
   1. the list of options/candidates to vote for, giving them
      1. a name/description
      2. a picture (optionally)
   2. whether or not the voting is "blind"
2. the module widget shows:
   1. a list of configured candidates with pictures and click on a candidate image/name to record his/her vote
      1. The vote of the user gets recorded in Ethereum blockchain through a WEBAPI call to a method of dApp Builder voting smart contract;
   2. Also shown are:
      1. If the voting is "blind" - how many votes are given for which candidate
      2. if the voting is not "blind" - how many votes are given for which candidate and by whom

Escrow

1. in dApp Builder the owner customizes
   1. a list of options for betting, giving them:
      1. a name/description
      2. a picture (optionally)
   2. the maximum and minimum amount of bid;
   3. the time after which the bids are no longer accepted
   4. the Ethereum address of the "oracle" (could be his/her own address)
   5. A small amount of Ether that "bet oracle" gets for his fair choosing of the winning bet
2. The mobule widget shows:
   1. For those who are not "bet oracle"
      1. an option to let user to bet a certain amount of ether on each bid option (provided that the time has not expired);
         1. the bet of the user gets recorded in the blockchain through a WEBAPI call to a method of "dApp Builder" Betting smart contract. The amount of bet is transferred to "dApp Builder" Betting smart contract
      2. An option to see the bid and (potentially) re-call unless it is too late
      3. An option to see who won the bet (one it is decided)
   2. For the "bet oracle"
      1. before the end of bidding the widget just shows a message saying "The bidding is not yet over till [date]"
      2. after the end of bidding the widget shows the list of bids and let the "bet oracle" choose the winning bet.
         1. The choice of winning bet is recorded by a WEBAPI call to "dApp Builder" smart contract. At this point the money accumulated in the smart contract get re-distributed to the users who made the right bet (minus the small pre-configured amount that goes to the Ethereum address of the "bet oracle" for his fair choosing of the winning bet/bid)

Betting

1. in dApp Builder the owner customizes
   1. a list of options for betting, giving them:
      1. a name/description
      2. a picture (optionally)
   2. the maximum and minimum amount of bid;
   3. the time after which the bids are no longer accepted
   4. the Ethereum address of the "oracle" (could be his/her own address)
   5. A small amount of Ether that "bet oracle" gets for his fair choosing of the winning bet
2. The mobule widget shows:
   1. For those who are not "bet oracle"
      1. an option to let user to bet a certain amount of ether on each bid option (provided that the time has not expired);
         1. the bet of the user gets recorded in the blockchain through a WEBAPI call to a method of "dApp Builder" Betting smart contract. The amount of bet is transferred to "dApp Builder" Betting smart contract
      2. An option to see the bid and (potentially) re-call unless it is too late
      3. An option to see who won the bet (one it is decided)
   2. For the "bet oracle"
      1. before the end of bidding the widget just shows a message saying "The bidding is not yet over till [date]"
      2. after the end of bidding the widget shows the list of bids and let the "bet oracle" choose the winning bet.
         1. The choice of winning bet is recorded by a WEBAPI call to "dApp Builder" smart contract. At this point the money accumulated in the smart contract get evenly re-distributed to the users who made the right bet (minus the small pre-configured amount that goes to the Ethereum address of the "bet oracle" for his fair choosing of the winning bet/bid)

Multisig Wallet

1. the owner
   1. configures amount of ether to send;
   2. configures the address to send the ether to;
   3. funds the smart contract with the necessary amount of ether;
   4. configured 1 or more Ether addresses that need to approve the sending of Ether.
2. the user of the widget
   1. if the desktop or mobile device has the Ethereum address of the destination then we just show if the ether was already sent or we are still waiting for the signatures (we can list who are awaiting the signatures from). Or we show that all the signatures were collected and such and such time and the ether was transferred;
   2. if the desktop or mobile device has the Ethereum address of the one of the approvers of the transaction then we show them the button or approve (unless they have already done so);
   3. if the desktop or mobile device has none of these addresses then we show an ad for dApps IBuilder (or whatever the name of the new company).

Customization and deployment of smart contracts

Using a smart contract specific web form, the user picks customizable values in the contract, for example, she may choose the list of candidates for Voting. When the user presses "Submit" button, we initialize a user record in a pre-deployed dApp Builder smart contract in Ethereum blockchain. The user pays for Gas required by this transaction, the gas can be paid through integration with MetaMask.

It is responsibility of the user to at all times retain control of the Ethereum identity used for this initializing transaction. Only this identity will be allowed to make changes in the smart contract user record.

The frontend

While the transaction creating the user record in the smart contract is being mined, the user sees a progress bar or a spificator. Once the transaction has completed, we open a form to customize the look and feel of the dApp frontend.

Meanwhile, the frontend is already accessible at a location like https://ibuildapp.com/dapps/{dapp_id}/. The frontend is an HTML page with CSS styles and scripts including the script responsible for interaction with our smart contract.

The user can customize the frontend of dApp: change the color of button and/or test, background image. The user changes get saved in database and used in HTML template when the dApp is shown by the browser.