In order to get the Bounties SDK up and running, it needs to be properly configured. This document will go in depth describing each property in the configuration.

Below is an example of what a production configuration object might look like:

{
  "platforms": {
    "example-network": ["example-network", "example-subnetwork"],
    "bounties-network": ["bounties-network"]
  },
  "postingPlatform": "example-network",
  "postingSchema": "standardSchema",
  "postingSchemaVersion": "0.1",
  "categoryPlatform": "main",
  "networkName": "example.network",
  "url": {
    "mainNet": "https://api.bounties.network",
    "rinkeby": "https://api.bounties.network"
  },
  "requiredNetwork": "mainNet",
  "deployments": {
    "StandardBounties": {
      "mainNet": "0x2af47a65da8CD66729b4209C22017d6A5C2d2400",
    }
  }
}

Reference

platforms

The platforms object defines the scope of any requests sent to the Bounties API. The keys are what will be visible to the user (such as in the filter navigation on the Bounty Explorer for example). The value of the key is what is used to query against the API. In the example above, example-network is selected then results from example-network and example-subnetwork will be returned from the API. This allows interoperability so that other platform's bounties can be visible throughout the ecosystem.

postingPlatform

Unlike platforms, the postingPlatform refers to the platform which bounties and fulfillments will be created with. This is one of the keys to creating a new bounty network.

postingSchema

This refers to the format of the JSON object in which the metadata is stored for on-chain events. This allows the Bounties API to correctly read and propagate the bounty.

postingSchemaVersion

As development continues, there will likely be changes in the standardSchema. These changes will be controlled by different versions here.

categoryPlatform

Some platforms have different sets of categories than the main explorer. This requires some work directly with Bounties Network, so main should be used unless told otherwise.

networkName

This value is plugged into many different modals on the site to alert users of which network they are currently using.

url

This object will have a key for each Ethereum network that is supported by the dapp and a url to the server that handles that networks request. In the example above, both Rinkeby and MainNet direct to api.bounties.network. This means that when a user is on Rinkeby they will still see MainNet content.

requiredNetwork

Usually dapps will run on only one network. The required network is used to easily enforce that constraint and alert users if they are trying to perform an action on an incorrect network.

deployments

The deployments object will be a mapping of contract names to another object of all the networks on which the contract has been deployed and their address. In the example above, there is only the StandardBounties contract and it has a corresponding deployment address on MainNet.