Back to FAQ

Back to FAQ

How Does The DGLD Blockchain Work?

01 Aug 2019

The DGLD blockchain is publicly accessible and verifiable along with the Mainstay commitments to the Bitcoin blockchain.

To run a fully validating DGLD node and connect to the network, you can download the Ocean blockchain client from the CommerceBlock Github here: https://github.com/commerceblock/ocean/releases

The client must be run with the configuration for the DGLD blockchain, which can be downloaded from the GTSA Github here: https://github.com/goldtokensa/config

The ocean.conf file along with the network terms-and-conditions (latest.txt) file determine the genesis block and permissions for the DGLD blockchain.

The hash of genesis block of the DGLD blockchain is: c66cb6eb7cd585788b294be28c8dcd6be4e37a0a6d238236b11c0beb25833bb9

The configuration file (ocean.conf) specifies the consensus public keys which are used to define permissions and verify the DGLD blockchain.


Description of the DGLD genesis configuration:

signblockscript: This script defines the signatures required to generate a new valid block. There are 5 public keys in total (in 5 separate block signing nodes), and at least 3 federation nodes must sign the block for it to be valid. The private keys for block signing were generated within 5 FIPS 140-2 Level 3 certified Hardware Security Module partitions owned by GTSA and located in Switzerland.

con_mandatorycoinbase: This specified the address to which transaction fees are paid (controlled by GTSA)

issuecontrolscript: This script defines the signatures required to issue a new asset. There are 3 public keys, and two of them are required to create an issuance transaction. The corresponding 3 private keys were generated on 3 separate air-gapped devices, which are controlled by separate entities within GTSA and located in 3 separate countries. To sign issuance transactions requires following a 2FA issuance procedure authorised by the controllers with signatures generated on the airgapped devices.

freezelistcoinsdestination: This specifies the public key that can be used to freeze user addresses (i.e. preventing them from transacting). The private key is controlled by GTSA.

burnlistcoinsdestination: This specified the public key used to allow frozen assets to be 'burnt' (i.e. destroyed) as part of the redemption process.

whitelistcoinsdestination: This specifies the public key used to onboard users and whitelist user addresses. The private key is controlled by GTSA.

challengecoinsdestination: This specifies the public key used to interact with CommerceBlock's Guardnode system. The private key is controlled by GTSA.

attestationhash: This specifies the transaction ID of the Mainstay staychan base on the Bitcoin blockchain. It uniquely binds the DGLD blockchain to a single history via the Mainstay protocol.

The mapping of individual bars of specified fine mass (identified via serial number, manufacturer and year of manufacture) to the issued tokens on the DGLD blockchain can be retrieved from here: s3.eu-west-1.amazonaws.com/gtsa-mapping/map.json

This mapping object is signed by 2 of the 3 public keys specified in the issuecontrolscript, and is also timestamped with epoch time and the last issuance blockheight.

The mapping can be verified and cross referenced with the on-chain issuances via an RPC connection to a full node using the token report tool for the asset-mapping package (https://github.com/commerceblock/asset-mapping).

The immutability of the DGLD blockchain via the Bitcoin blockchain can be fully and independently verified via the Mainstay daemon which requires RPC connections to both a DGLD (Ocean) node and a full Bitcoin node. This can be downloaded, along with full instructions, from the CommerceBlock Github here: https://github.com/commerceblock/mainstay

Prefer to talk to a team member?

Get in touch