A token-curated registry (TCR) for storing StandardBounties data collection opportunities. Forked from Mike Goldin's TCR implementation (Owner's Manual available).
Although you can deploy this TCR on any Ethereum network, a quick and easy development environment can be setup and run locally using Truffle's Ganache. Download the latest version from the Ganache website, install and open.
Once Ganache is running, you'll need a secrets.json file with the funded Ganache mnemonic on the m/44'/60'/0'/0/0 HD path in the root of the repo to deploy. Your secrets.json should look like this:
{
"mnemonic": "my good mnemonic ..."
}If you prefer to use an environment variable, your .bashrc or .bash_profile should look something like:
export MNEMONIC='my good mnemonic ...'Clone the Bounties Network's StandardBounties repo locally:
git clone https://github.com/Bounties-Network/StandardBounties.git
Install and deploy the contracts locally:
npm install
truffle migrate --network ganache
Finally, update the StandardBounties contract address in the init() function of this repo's Registry contract, it should be:
standardBountiesAddress = /* address of newly deployed StandardBounties contract from above */;
The only environmental dependency you need is Node. Presently we can guarantee this all works with Node 8. Install all dependancies and deploy the factory contracts:
npm install
npm run deploy-ganache
Next, you'll need to call the deployed factory contracts:
npm run deploy-proxies:ganache
The Parameterizer, Registry and Token contracts are now deployed locally.
If you don't want to use Web3 to directly interact with contract functions, you can easily run the contracts' functions using the contracts tab in MyEtherWallet. Simply switch to the local Ganache network in MyEtherWallet, then copy the deployment address of the contract you would like to run and the corresponding ABI from the /build/contracts JSON directory.
The below diagram shows the different smart-contract calls from the dapp frontend.
The Registry contract manages the list (array) of bounties. The contract's public listing array is accessed by the frontend map to display the avaliable bounties, while the submit() and assessFulfillment() functions are used to create new bounties and trigger bounty fulfillment evaluations, respectively.
After bounties are created by the Registry contract, bounties are funded using the contribute() function of the StandardBounties contract. Once the bounty is sufficiently funded (the total contributed token is greater than or equal to the Registry contract's stakingPoolSize parameter), the StandardBounties's activateBounty() function may be call to activate the bounty.
Fulfillments may then be submitted using the StandardBounties's fulfillBounty() function. Note that bounty fulfillment evaluation (via the PLCRVoting mechanism) will occur when the accessFulfillment function of the Registry contract is called (to be implemented).
When the Registry is deployed a ERC-20 token is also deployed (as defined in the conf/config.json file). Obviously, before token can be sent to a bounty using the StandardBounties's contribute() function, the token contracts's approve() function must be called in order to give the bounties contract access to the desired amount of token to stake.
The submit function takes a JSON string as its only argument. This string must obey the following format (derived from the StandardBounties bounty data issuance schema):
{
payload: {
title: // A string representing the title of the bounty
description: // A string representing the description of the bounty, including all requirements
issuer: [
// Persona for the issuer of the bounty
// See: bounty persona schema here: https://github.com/Bounties-Network/StandardBounties/blob/master/docs/standardSchemas.md#version-01
],
funders: [
// Array of personas of those who funded the issue.
// See: bounty persona schema here: https://github.com/Bounties-Network/StandardBounties/blob/master/docs/standardSchemas.md#version-01
],
categories: // An array of strings, representing the categories of tasks which are being requested
created: // The timestamp in seconds when the bounty was created
tokenSymbol: // the symbol for the token which the bounty pays out (NTN)
tokenAddress: // the address for the NTN token which the bounty pays out
// ------- Flyingcarpet Specific Options Below -------
geohashes: // An array of geohash strings representing the points making up a polygon covering the location of the opportunity
useType: // A string representing the type of the data being collected, one of: rooftop, forest, land
collectionType: // A string representing the type of data collection required, one of: drone, satellite
radiusOfCollection: // The radius, in meters, of the required data collection area
resolution: // A string representing the required resolution of the data collection (for both drone and satellite data collection)
fileFormat: // A string representing the required type of output file format (for both drone and satellite data collection)
droneType: // (drone only) A string representing the required type of drone for the data collection (e.g. "thermal")
}
}
Example of data for issuance of satellite land bounty:
{
"payload": {
"title": "Satellite Land Data Collection @ 40.7079934, -74.0110538",
"description": "This is a request for aerial land data collection using a satellite. ...",
"issuer": [
{"address": "0x667880b4c9378ec4963c046a7e6c582e295ab86c"}
],
"funders":[],
"categories": ["Data Collection", "Satellite", "Land"],
"created": 1536957876,
"tokenSymbol": "NTN",
"tokenAddress": "0xd298284b06ab7e873c5406823609c179ed5d2cf4",
"geohashes": ["gcpvh9p6jp9p", "gcpvh733jjc5", "gcpvjgdcvh95"],
"useType": "rooftop",
"collectionType": "satellite",
"radiusOfCollection": 100,
"resolution": "0.41 meters",
fileFormat: "JPEG"
}
}
Governance of the TCR is handled by the Parameterizer contract. This contract enables token holders to vote on changes to the Registry parameters (currently only the stakingPoolSize parameter) as well as the parameters of the Parameterizer contract itself (that defines how the governance mechanism works). Currently, there is no UI implemented to interact with these Parameterizer methods; however, a governance dialog will be implemented in the web app in the near future.
The repo is composed as a Truffle project, and is largely idiomatic to Truffle's conventions. The tests are in the test directory (need to be updated), the contracts are in the contracts directory and the migrations (deployment scripts) are in the migrations directory. Furthermore there is a conf directory containing JSON files where deployments can be parameterized.
The repo consumes several EPM packages. dll and attrstore are libraries used in PLCRVoting's doubly-linked list abstraction. tokens provides an ERC20-comaptible token implementation. plcr-revival features batched executions for some transactions. All packages are installed automatically when running npm install.