6.6.3 Consortium account

6.6.3.1 Creating the Consortium Account

The establishment of a consortium account is a critical step following the emission process, during which the consortium is identified as one of the recipients of the formed fund. The DEC protocol inherently supports two types of recipients by default:

  • Nodes, which operate based on transaction verification. Nodes earn funds by exchanging their Service Level Agreements (SLA), which represent the number of transactions processed over a unit of time, for a certain number of tokens. Validator nodes, arbitrator nodes, and notary nodes support the network and distribute the received tokens to their users and specific applications. Depending on the settings, nodes receive the majority of tokens over a designated period (80–90% of all issued tokens). Subsequently, the network's economy is sustained through commissions intended to be kept as low as possible.

  • The Consortium that launched the network also receives a portion of the tokens (about 20%), which are spent according to a published protocol to support the initial phase of the network's operation.

DEC tokens thus represent the network and do not promise a share of any property other than the value embedded in the network itself. Any node or segment that joins and processes transactions is entitled to a portion of the network's value, though the terms of joining are controlled by the consortium and subsequent segment owners.

During the Emission process, the public key associated with the consortium, which is responsible for the consortium account, is specified. This key is verified when funds are transferred to the consortium account from the issued pool. To create an actual account, a series of actions must be undertaken.

For example, a key pair associated with the consortium, FUND.pub and FUND.priv, is created and located in the directory ‘/project/peer/keys’. While these keys are handled in plain text for demonstration purposes, it's advised against storing these files openly. Typically, they should be converted into a secure PEM format or removed from the system for enhanced security. These keys are then utilized to create a corporate account using commands common to account management:

dec account --keyfile /project/peer/keys/FUND.priv
Figure 137 FUND account creation

After it is created, you can replenish your account within the amount assigned during the issuance process.

6.6.3.2 Funding the Consortium Account

In the realm of blockchain, the secure and transparent management of financial transactions is paramount. This is especially true when establishing the foundational financial structure of a network, such as the consortium account in the DGT DEC system. Traditional blockchain networks often face the challenge of balancing transparency with security, particularly during the critical phase of funding initial accounts. The DGT DEC network addresses this challenge by implementing a robust protocol for the consortium account's funding process, ensuring both transparency and security are maintained.

Before nodes begin receiving rewards for processing transactions, the consortium account stands as the sole source of DEC within the system. This is because specific rules have been set to allow the transfer of funds from the virtual emission account (_DEC_EMISSION_KEY) within a designated amount and time frame. The consortium account's funding can commence no earlier than the specified limit (Wait to date in the emission configuration) and may occur in several batches but must not exceed the emission reduction to the Minting share (a parameter set during emission).

KEY STEPS FOR CONSORTIUM ACCOUNT FUNDING

  • STEP 1: Verify that the emission has been completed and the total supply is positive.

dec totalsupply

  • STEP 2: The transfer is executed with the standard send command but, due to the critical nature of this funding, is performed using multi-signature based on keys specified as emission attributes. The basic steps are as follows:

dec send _DEC_EMISSION_KEY_ [PUBLIC KEY OF CORP ACCOUNT] 
--keyfile [key signer 1] -tid [INVOICE_ID]

Parameters used here:

o _DEC_EMISSION_KEY_: The sender's reference (emission pool).

o [PUBLIC KEY OF CORP ACCOUNT]: The public key of the corporate account - recipient. It can be specified through a file set during emission /project/peer/keys/FUND.pub.

o [key signer 1]: The signing agent (one of the issuers). Multiple signatures are required, defined at emission along with the threshold /project/peer/keys/eKey1.pub.

o [INVOICE_ID]: The transfer ID parameter, which must match for each signature. Can be a secret word agreed upon by consortium participants CORP001.

Thus, the first signature is applied:

dec send _DEC_EMISSION_KEY_ /project/peer/keys/FUND.pub 10000 
--keyfile /project/peer/keys/ekey1.priv -tid CORP001

Additional signatures are required until the threshold is met:

dec send _DEC_EMISSION_KEY_ /project/peer/keys/FUND.pub 10000 
--keyfile /project/peer/keys/ekey2.priv -tid CORP001

Here, instead of directly using private keys, we reference corresponding files created for demonstration during the emission. In actual scenarios, such files should be securely formed, or keys should be directly provided. Storing private keys in plain text on a single node is not advisable.

  • STEP 3: A simple command to check the corporate account following the transfer:

dec corpaccount
Figure 138 Corporate Account Details

  • STEP 4: To verify the remaining token balances in the system after the transfer to the consortium account, the following command is used:

dec show _DEC_EMISSION_KEY_

The secure funding of the consortium account is a cornerstone for launching and sustaining the network's economy. Through a meticulously designed process involving multi-signature verification and transparent operations, the DGT DEC network ensures that the initial distribution of DEC tokens to the consortium account is executed with the highest security standards.

6.6.3.3 Transferring Funds to Regular Accounts

In a blockchain ecosystem, especially within networks like DGT DEC, the process of transferring funds from foundational accounts such as those controlled by the Consortium to regular user and node accounts is of paramount importance. It epitomizes the network's commitment to secure, transparent, and efficient economic activities. This capability not only propels the network's economy forward but also ensures that the principles of decentralization are upheld, allowing for the equitable distribution of resources across the network.

After the Consortium Board receives funds in the account, it has the authority to distribute them in accordance with the projects selected and announced. Initially, as nodes are yet to receive funds through processed transactions, the DECs distributed by the consortium represent the sole method of supporting the network's economy. Key features of the consortium's operations at this stage include:

  • All funds to be distributed must be declared in white papers before the emission process.

  • All transactions are public, meaning the community can see how funds are spent. A mandatory transaction identifier, set during the transfer, should match the payment's purpose (not explicitly verified, but considered best practice).

  • The execution of transfers also requires multi-signature verification, as stipulated at the time of emission.

  • The presence of regular accounts in the system, created by users, is necessary for executing transfers.

The basic command structure for transferring money from one account to another is as follows:

dec send [FROM_PUBKEY] [TO_ADDR] [AMOUNT] --keyfile [PRIVATE_KEY_FROM]

To demonstrate the transfer of funds from the consortium account to regular accounts, the following steps are executed:

  • STEP 1: Create two regular accounts (for more details, see the section on working with regular accounts). First, generate keys for regular accounts A and B:

dgt keygen KEYA --key-dir /project/peer/keys/
dgt keygen KEYB --key-dir /project/peer/keys/

Next, using the pair of keys, create the accounts:

dec account --keyfile /project/peer/keys/KEYA.priv
dec account --keyfile /project/peer/keys/KEYB.priv

Obtain addresses for accounts A and B:

dec addr /project/peer/keys/KEYA.priv
dec addr /project/peer/keys/KEYB.priv

  • STEP 2: Execute the transfer from the consortium account to regular accounts using the multi-signature mechanism. The first of the defined authorized keys is used:

dec send /project/peer/keys/FUND.pub /project/peer/keys/KEYA.pub 100 
--keyfile /project/peer/keys/CorpKey1.priv -tid PROJ-1

Repeat the procedure with another authorized consortium participant:

dec send /project/peer/keys/FUND.pub /project/peer/keys/KEYA.pub 100 
--keyfile /project/peer/keys/CorpKey2.priv -tid PROJ-1

In this case, within the transfer of funds (100 DEC) for the target project PROJ-1, two authorized keys: CorpKey1 and CorpKey2 are used (in real scenarios, these signatures are applied asynchronously and independently). A real transaction is only completed once the necessary threshold (set during the emission) is reached.

  • STEP 3: Conduct the transfer to account B, also using the multi-signature mechanism:

dec send /project/peer/keys/FUND.pub /project/peer/keys/KEYB.pub 50 
--keyfile /project/peer/keys/CorpKey2.priv -tid PROJ-2

Repeat the procedure with another authorized consortium participant:

dec send /project/peer/keys/FUND.pub /project/peer/keys/KEYB.pub 50 
--keyfile /project/peer/keys/CorpKey3.priv -tid PROJ-2

In this transfer, a different set of consortium representative keys authorizing the transfer: CorpKey2 and CorpKey3, are utilized. For brevity, we again used key files rather than real addresses, but the transfer can be made by substituting real addresses.

  • STEP 4: Verify the balances. According to the terms, the consortium account's balance decreased by 150 DEC, while the balances of the accounts increased. Verification is conducted using the command:

dec balanceof /project/peer/keys/KEYB.pub
Figure 139 Applying balanceoff command

To simplify operations, we use the balanceof command with a reference to the file with the public key. We could also specify an address, alias, or an explicit public key as a parameter

This structured approach to fund transfers from the consortium to regular accounts illustrates the DGT DEC network's dedication to security, transparency, and the democratic distribution of resources. Through multi-signature verification and public transaction records, the network maintains its commitment to an open, decentralized financial system, encouraging community growth and participation.

6.6.3.4 Getting Information about the Consortium Account

Transparency and accessibility of information within a blockchain network are crucial for maintaining trust and integrity among its participants. In the DGT DEC network, every participant can view the consortium account details, which is pivotal for ensuring transparency and fostering a sense of shared responsibility and trust across the network. This accessibility allows users to verify the consortium's activities and balance, contributing to the network's overall accountability.

Below is a table detailing specific commands for obtaining information about the consortium account, enhancing network transparency and participant confidence.

#

Command

Description

Sample

1

dec corpaccount

Retrieves detailed information about the consortium account.

dec corpaccount

2

dec show _DEC_EMISSION_KEY_

Extracts the public key of the consortium account from the emission parameters.

dec show _DEC_EMISSION_KEY_

3

dec addr /project/peer/keys/FUND.pub

Obtains the account address using the public key or a reference to the corresponding file.

dec addr /project/peer/keys/FUND.pub

4

dec show -tp accounts <account_address>

Displays comprehensive account information for a specified account address.

dec show -tp accounts /project/peer/keys/FUND.pub

5

dec balanceof <account_address>

Views the balance of the specified account address.

dec balanceof /project/peer/keys/FUND.pub

Previous6.6.2 DEC emissionNext6.6.4 User accounts

Last updated