6.6.2 DEC emission

6.6.2.1 Emission configuration

When you install the Garanaska sub-version, you unlock additional functionalities within the DGT framework. This includes financial features and notary operations. It is assumed that you have not only selected the GARANASKA package but also compiled and tested the availability of at least one DGT node. Most functions are available even for a single node, along with two notaries: one acting as a key custodian and the other as a regular notary connected to the network.

To engage with the DEC financial ecosystem, an initial step is required: the emission of native DEC tokens. These tokens are digital entries in a central registry, earmarking specific token amounts to distinct addresses, akin to account numbers. DEC tokens embody the network's value, primarily compensating nodes for transaction processing, application support, and balancing the network's economy.

There are some key points to consider before emission:

Consortium-Based Launch: The network's initiation is planned by a consortium of independent entities. They agree on the maximum DEC token supply, reflecting a mutual understanding of the network's goals, configurations, and revenue opportunities. The total agreed-upon token amount is issued at once but distributed over time based on predetermined parameters.
Token Distribution Mechanism: The distribution model is straightforward. A portion is allocated to the consortium, which manages a public account through a multi-signature mechanism by key consortium members. This wallet faces time-bound and amount-specific restrictions.
Emission Parameters: In addition to distribution speed parameters, the emission includes basic information like the token name (default DEC), granularity (fractional parts, like cents), and the primary keys accessing the corporate wallet. These details, along with the issued amount, are recorded in the registry, becoming immutable parts of the DGT protocol.
Operational Protocol: The emission record features a virtual key, _DEC_EMISSION_KEY (virtual account), with protocol-limited actions. This ensures that, despite a majority consensus potentially rewriting the registry, the original emission record remains unchanged and singular. The network can process commands before this emission; however, subsequent DEC commands rely on the existence of _DEC_EMISSION_KEY.
Network Value Circulation: Most tokens are distributed among nodes in exchange for transaction processing, regulated by network temperature parameters (via the Heartbeat protocol). Network users acquire tokens by purchasing or exchanging them with nodes or the consortium. Except for shielded transactions, all operations are transparent and community-regulated within the DGT platform.

The process of emission requires considerable planning as it is a one-time, irreversible action. Below are the steps to ensure a successful DEC token emission:

6.6.2.1.1 STEP 1: Emission Keys Configuration

The process of emission is a one-time event that requires not just meticulous planning but also a robust level of security. This ensures the immutable emission parameters remain protected under any circumstances, and that all parties involved in the emission have indeed agreed to and are authorized to proceed. In blockchain systems, this security is typically achieved using private and public keys, with a pair for each participant.

KEY CREATION BASICS:

Complexity of Keys: The keys are complex combinations of letters and numbers, making memorization and subsequent use challenging without specialized software, such as wallets or password managers.
Privacy and Transparency: While the private key must remain confidential (known only to the owner), the public key is openly shared and verifies ownership of the corresponding private key. The public key is generated from the private key, making reverse engineering impractically time-consuming.
Standardization within DGT: Assuming the DGT platform is operational and at least one node is accessible, standard node software is used for key generation. This standardization is crucial for maintaining a unified cryptographic system.
Consortium Participants' Independence: It's assumed that consortium participants issuing the emission can independently generate key pairs using tools and instructions provided, securely store the private key, and share the public key within the consortium. Emission setup is a flexible process with many adjustable parameters.

STANDARD PARTICIPANTS:

Emission Keys (eKeys): Directly approve parameters and initiate the emission process. At least three consortium members (directly executing the emission) are chosen, with their keys named eKey1, eKey2, eKey3. These can be stored in text files with extensions ‘.pub’ for the public key and ‘.priv’ for the private key.
Consortium Keys: Authorize transfers from the consortium account. Managing the consortium's fund (distributed at the time of emission, about 10% of the issued token amount) requires at least three representatives, with their keys named CorpKey1, CorpKey2, CorpKey3, also located in text files with .pub and .priv extensions.
Emission Administrator Key: Acts as a third-party observer to the emission process, assisting in modifying certain parameters (among those allowed for changes) such as fees, tips, and token burn rates.

GENERATING YOUR OWN EMISSION KEYS:

To create your emission keys, execute the key generator command for each key type:

dgt keygen --key-dir /project/peer/keys <KEY_NAME>

This command generates a pair of files with ‘.pub’ and ‘.priv’ extensions. For demonstration purposes, we use a single DGT node console. In real business scenarios, keys are created asynchronously by different platform participants. This can be achieved with specified cryptography parameters (e.g., using OpenSSL with agreed-upon cryptographic parameters) or with DGT utilities available for offline use. After generation, the public key values are stored in a configuration file (see below).

DEMONSTRATION SCENARIO:

A typical scenario for demonstrating emission using a single node console is outlined below. In practice, keys are created asynchronously by various platform participants, potentially using specified cryptographic parameters or DGT utilities for offline use. After key generation, public key values are stored in a configuration file for further use.

Command

Comments

dgt keygen --key-dir /project/peer/keys ekey1

Creating a Key Pair 1 for Emission

dgt keygen --key-dir /project/peer/keys ekey2

Creating a Key Pair 2 for Emission

dgt keygen --key-dir /project/peer/keys ekey3

Creating a Key Pair 3 for Issuance

dgt keygen --key-dir /project/peer/keys FUND

Creating a Consortium Account

dgt keygen --key-dir /project/peer/keys CorpKey1

Pair 1 for key1 consortium

dgt keygen --key-dir /project/peer/keys CorpKey2

Pair 2 for key2 consortium

dgt keygen --key-dir /project/peer/keys CorpKey3

Pair 3 for key3 consortium

dgt keygen --key-dir /project/peer/keys admin

Pairing an Administrative Key

For each command listed in the table above, a pair of keys is created – files with priv and pub extensions. Inside such files are the keys themselves, which can be viewed by commands, for example:

cat /project/peer/keys/ekey1.priv
cat /project/peer/keys/ekey2.pub

6.6.2.1.2 STEP 2: Consortium Agreement

Finalize the maximum token supply and distribution parameters with the consortium. You must agree with the consortium (if you are not experimenting alone) on the main parameters of the emission. It's a good idea to create a contract with key parameters, which can be attached with a list of parameters, as defined in the system:

Parameter

Default Value

Description

Name

DEC

Name of the Currency/Token

Symbol

"Đ" ([Unicode: U+0110])

Currency Symbol

supply_total

Total Amount of

admin_pub_key

123456

Admin key for initial operations (if no signing keys are specified in the multi-sign part)

wait_to_date

123456

Date from which funds can be distributed

Granularity

0.0001

Minimum fractional part in calculations

Passkey

Paraphrase to access modifiable parameters (which include the number of burns – reduction of the amount, commission, and default value of tips).

Link

https://dgt.world/docs/DGT_GARANASKA_TOKENIZATION.pdf

Link to the tokenomics model (please use you own)

Nominal

0.8

The ratio of the issued token to the base currency (e.g., USD)

10.

nominal_name

USD

Name of the base currency

11.

corporate_account

0xcfa9fe46e0873050b6819651d6cf6fd5b57e6db4965b

Address or public key of the account of the consortium that receives a share of tokens in the common pool for the development of the network (corporate_share parameter)

12.

corporate_share

20%

Number of tokens distributed for the purpose of direct support of the network (consortium)

13.

minting_share

80%

A parameter that determines the share of tokens that are used to support the network through nodes (minting)

14.

mint_param

"Umax" : 10, "B2" : 1, "T1" : 1

Minting Parameters That Define the Finance Distribution Model: Umax, 𝛽2, 𝜏1

15.

nBurn

Number of Possible Token Burns (Limited Use)

16.

Fee

Commission for DEC transfer operations (fixed in the network). Subject to change at a later date

17.

Tips

0.01

Additional fee for "expensive" transactions, subject to change later

18.

Account

{"limit" : 10010, "spend_period": 2

Account limits (e.g. amount of one-time spend, minimum period between transactions 2 minutes) – applied in default accounts (can be changed for linked accounts with a notary)

19.

Emission

{"sign_min" : 2,"signers_pub_key" : […]

The minimum number of signatures to be issued, as well as the public keys involved in the signature (the minimum number of keys from the specified number of keys)

Main features of the parameters:

Not only the numerical parameters of the issue have been determined, but also the public keys that will participate in the issuance and subsequent management of the parameters. These keys will be flashed at the time of issuance to the registry and cannot be changed later. However, there is a threshold multi-signature mechanism, where a transaction is signed by all participants, but by a certain minimum number.
The basic parameters are not changeable, while several parameters are changeable (such as commission and reward tips). For this purpose, it is possible to set a special access code (admin_pub_key), if the field is left blank, these values cannot be changed.

Some parameters may overlap during the release, so the new parameter values are set as keys on the command line, so we skip the step of updating the configuration file to demonstrate.

6.6.2.1.3 STEP 3: Crafting Technical Specifications

After the development of the tokenomics model (there is a standard tokenomics model, see DGT's Tokenomic Model), these parameters are recorded in the technical specification, which is presented in the system in the form of a j-son file: etc/dec/emission.json.

The current emission configuration parameters can be viewed with the standard Linux command:

cat etc/dec/emission.json

6.6.2.1.4 STEP 4. Emission Configuration Review and Certification

Once the parameters are saved, the existing configuration and parameters can be checked and certified before the emission is initiated. Viewing is done by the command in the host environment:

dec emission --check

For subsequent certification, it is necessary to make sure that there is no already emission in the system. To do this, run the command:

dec totalsupply

If there is no emission event, the command must return an error (the _DEC_EMISSION_KEY key is missing:

To consolidate the configuration, it is recommended that you certify the existing settings. To do this, you need to use one of the previously created keys, for example, the eKey1 key. The process of certifying, or digitally signing, the emission parameters defined in etc/dec/emission.json involves several steps, utilizing asymmetric keys based on the secp256k1 elliptic curve algorithm. This certification ensures the integrity and authenticity of the emission configuration, making it possible to verify that the file has not been altered since its signing. Here’s how to accomplish this using OpenSSL and keys, such as eKey1, which you've previously generated.

Generating PEM Files from Text Files. First, you need to convert your existing public and private key text files (with ‘.pub’ and ‘.priv’ extensions) into the PEM format recognized by OpenSSL. Assuming you have eKey1.pub and eKey1.priv as your key files:

# Convert the private key to PEM format and protect it with a passphrase
openssl ec -in eKey1.priv -out eKey1_private.pem -aes256 -passout pass:YourPassphrase
# Convert the public key to PEM format
openssl ec -pubout -in eKey1.priv -out eKey1_public.pem

These commands generate eKey1_private.pem for the private key and eKey1_public.pem for the public key, both in PEM format.

Creating a Digital Signature for emission.json. Using the private PEM file (eKey1_private.pem), you can now create a digital signature for your emission.json file. This signature will later be used to verify the file's integrity and authenticity:

openssl dgst -sha256 -sign eKey1_private.pem -passin pass:YourPassphrase -
out emission.json.sig emission.json

This command employs the SHA-256 algorithm to sign the emission.json file, producing a digital signature in emission.json.sig. The -passin option is used to provide the passphrase for accessing the encrypted private key.

Verifying the Signature. The signature of the emission.json file can be verified using the public PEM file (eKey1_public.pem). This verification process can be executed by anyone possessing the public key to confirm the file's unchanged status post-signature:

openssl dgst -sha256 -verify eKey1_public.pem -signature 
emission.json.sig emission.json

A successful verification will prompt OpenSSL to output "Verified OK" signifying the emission.json file's integrity is intact, and it has indeed been signed with the corresponding private key.

6.6.2.2 The Emission Event

6.6.2.2.1 Emission Command

The execution of the emission in distributed ledger technologies, specifically within the Digital Emission Control (DEC) framework, hinges on the deployment of a singular command. This command is replicated asynchronously by multiple participants, each acting independently based on a set of pre-defined parameters. The essence of the emission process is encapsulated in the execution of a specialized command, which looks as follows:

dec emission --<PARAMETERS>

This command is comprehensive, incorporating a substantial array of parameters to fine-tune the emission details precisely. The full command structure, inclusive of all possible parameters, is presented as:

dec emission [-h] [-v] [-y] [--check] [-cb {openssl,bitcoin}] [-U URL] [--wait [WAIT]]
 [--tips TIPS] [--access_token ACCESS_TOKEN] [-V] [--proto PROTO] [--name NAME] 
 [--total_sum TOTAL_SUM] [--granularity GRANULARITY] [--admin_pub_key ADMIN_PUB_KEY] 
 [--passkey PASSKEY] [--link LINK] [--nominal NOMINAL] [--nominal-name NOMINAL_NAME] 
 [--corporate_share CORPORATE_SHARE] [--minting_share MINTING_SHARE] [--mint MINT] 
 [--mint-umax MINT_UMAX] [--mint-t1 MINT_T1] [--mint-b2 MINT_B2] [--num_burn NUM_BURN]
 [--fee FEE] [--corporate_account CORPORATE_ACCOUNT] [--corporate_pub_key 
 CORPORATE_PUB_KEY [CORPORATE_PUB_KEY ...]]  [--emiss_signers EMISS_SIGNERS 
 [EMISS_SIGNERS ...]] [--emiss_sign_min EMISS_SIGN_MIN] [--wait_to_date WAIT_TO_DATE] 
 [--keyfile KEYFILE] [--info]

A detailed explanation of each parameter is provided in the subsequent table, ensuring clarity and ease of understanding for all participants involved in the emission process. This structured approach allows for a flexible yet secure method to manage and execute the emission of DEC tokens, making it an integral part of the broader DGT ecosystem:

Parameter

Description

-h, --help

Display the help message and exit.

-v, --verbose

Enable detailed output for additional information.

-y, --yaml

Produce the output in YAML format.

--check

Preview all parameters for the operation without executing.

-cb {openssl,bitcoin}, --crypto_back {openssl,bitcoin}

Choose the cryptographic backend between OpenSSL and Bitcoin.

-U URL, --url URL

Specify the URL of the REST API.

--wait [WAIT]

Set a duration, in seconds, to wait for the transaction to be confirmed.

--tips TIPS

Assign a tip amount for the transaction (incentive for the accepting peer).

--access_token ACCESS_TOKEN, -atok ACCESS_TOKEN

Provide an access token for authentication.

-V, --version

Show version information of the command or tool.

--proto PROTO

Specify a proto file with emission parameters or input JSON directly.

--name NAME

Define the name of the token.

--total_sum TOTAL_SUM, -ts TOTAL_SUM

Set the total amount of DEC tokens to be emitted.

--granularity GRANULARITY, -gran GRANULARITY

Define the granularity of the DEC token.

--admin_pub_key ADMIN_PUB_KEY, -apk ADMIN_PUB_KEY

Provide the public key of the admin.

--passkey PASSKEY, -pk PASSKEY

Specify a passkey for special operations.

--link LINK

Provide a URL for further description.

--nominal NOMINAL, -nom NOMINAL

Set the nominal value of the DEC token.

--nominal-name NOMINAL_NAME, -nnm NOMINAL_NAME

Specify the nominal name of the DEC token.

--corporate_share CORPORATE_SHARE, -cs CORPORATE_SHARE

Determine the share of tokens allocated to the DGT corporation.

--minting_share MINTING_SHARE, -ms MINTING_SHARE

Set the share of tokens allocated for node minting.

--mint MINT, -m MINT

Configure minting parameters.

--mint-umax MINT_UMAX, -mmax MINT_UMAX

Specify the maximum utility parameter for minting.

--mint-t1 MINT_T1, -mt1 MINT_T1

Define the T1 parameter for minting.

--mint-b2 MINT_B2, -mb2 MINT_B2

Set the B2 parameter for minting.

--num_burn NUM_BURN, -nb NUM_BURN

Specify the total number of tokens to be burned.

--fee FEE

Set the transaction fee.

--corporate_account CORPORATE_ACCOUNT, -ca CORPORATE_ACCOUNT

Specify the DGT corporate account.

--corporate_pub_key CORPORATE_PUB_KEY [CORPORATE_PUB_KEY ...], -ck CORPORATE_PUB_KEY [CORPORATE_PUB_KEY ...]

Provide public keys for managing the corporate account.

--emiss_signers EMISS_SIGNERS [EMISS_SIGNERS ...], -ems EMISS_SIGNERS [EMISS_SIGNERS ...]

List public keys authorized for emission operations.

--emiss_sign_min EMISS_SIGN_MIN, -esm EMISS_SIGN_MIN

Set the minimum number of signers required for emission.

--wait_to_date WAIT_TO_DATE, -wtd WAIT_TO_DATE

Schedule a date for the command to become active: birth, mint, change mint.

--keyfile KEYFILE

Identify the file containing the user's private key.

--info

Display the current status of the emission.

--did DID, -d DID

Specify the DID.

-tp TYPE, --type TYPE

Define the type of operation or data.

Most of the command parameters are optional. For demonstration purposes, we will issue it based on the previously prepared json parameters, overloading only the keys and the most important parameters.

The issuance of native tokens in DGT is a multi-step procedure using multi-signature, which implies the asynchronous execution of steps by the participants of the process to complete the issue

6.6.2.2.2 Demonstration

The emission process in the DGT system is a structured, multi-step procedure that involves the sequential signing of a transaction by all designated keys. This process is performed asynchronously and distributed, with each participant executing the emission command on their side. An emission is only carried out once the predefined threshold (emission parameters) is met, with the parameters being recorded at the first instance of emission initiation by the first participant.

For demonstration purposes, we assume the following:

· The node is set up, and the DGT service is operational.

· Keys have been generated according to the guidelines described in "Emission Generation."

Note. Emission commands can accept either the direct values of keys or relative paths to the key files, making the commands more concise.

After confirming the presence of keys eKey1, eKey2, eKey3, FUND, CorpKey1, CorpKey2, and CorpKey3, we proceed with the emission, assuming an issuance amount of 10,000,000 DEC tokens.

PARTICIPANT 1: INITIATING THE PROCESS AND SIGNING

The first participant initiates the process and signs with eKey1:).

dec emission --total_sum 10000000 -apk /project/peer/keys/admin.priv -ca 
/project/peer/keys/FUND.pub -ck /project/peer/keys/CorpKey1.pub 
/project/peer/keys/CorpKey2.pub /project/peer/keys/CorpKey3.pub 
-ems /project/peer/keys/ekey1.pub /project/peer/keys/ekey2.pub 
/project/peer/keys/ekey3.pub --keyfile /project/peer/keys/ekey1.priv

-apk <ADMIN PRIVATE KEY FILE>

Pointer to the administrative key for executing critical operations

-ca <CORP PUBLIC KEY FILE>

Pointer to the public key for the corporate account (FUND).

-ck <CORP PUB KEY 1> <CORP PUB KEY 2> <CORP PUB KEY 3> …

Pointers to the public key files of the corporation (FOUNDATION): CorpKey1, CorpKey2, CorpKey3.

-ems <EMS PUB KEY 1> <EMS PUB KEY 2> <EMS PUB KEY 3> …

Public keys for multi-signature execution of the emission: eKey1, eKey2, eKey3.

--keyfile <FIRST SIGNER>

The first signer (eKey1); this parameter changes depending on the signer.

--total_sum TOTAL_SUM

Specification of the total amount of issued tokens.

The result of the command execution is shown in the figure below.

Despite the command given, the emission itself was not made, which can be verified by the command:

dec totalsupply

After the first start, the network generates a special DEC_EMISSION_SIG object, the presence of which can be checked using the:

dec show _DEC_EMISSION_SIG_

VERIFICATION AND CONFIRMATION BY PARTICIPANT 2

The second participant (in a real scenario, asymmetrically and independently) repeats the command but signs it with their signature:

dec emission --total_sum 10000000 -apk /project/peer/keys/admin.priv -ca 
/project/peer/keys/FUND.pub -ck /project/peer/keys/CorpKey1.pub 
/project/peer/keys/CorpKey2.pub /project/peer/keys/CorpKey3.pub -ems 
/project/peer/keys/ekey1.pub /project/peer/keys/ekey2.pub 
/project/peer/keys/ekey3.pub --keyfile /project/peer/keys/ekey2.priv

Re-verify the emission execution:

dec totalsupply

The result shows the emission has been executed (reaching the two-signature threshold set in the initial emission example above), with 10,000,000 DEC tokens issued and ready for distribution through other DGT commands and services.

This structured approach ensures transparency and consensus among participants, securing the emission process against unauthorized changes and confirming the collective agreement on the emission parameters.

6.6.2.3 Getting information about emission

Immediately following the emission process, consortium participants and other network observers (all users with access to the commands) can verify the emission data. This includes details such as when the emission took place, the parameters used, and the terms under which it was conducted. The public nature of this information is fundamental and contributes to building trust in the system.

Below are the primary commands for such verification:

Checking the Emitted Amount. To view the total supply of tokens that have been emitted into the system, use:

dec totalsupply

Verifying All Applied Parameters. For a comprehensive view of the emission parameters that were applied during the emission process, execute:

dec show _DEC_EMISSION_KEY_

This command displays all the parameters associated with the specific emission event.

Checking Emission Distribution. To understand how the emitted tokens have been distributed across the system, you can run:

dec distribute

This provides insights into the allocation of the emitted tokens.

Token Information. While the system may host multiple tokens, only one is designated as the native (primary) token. Basic information about this token, as well as others, can be obtained through:

dec tokeninfo --name "DEC"

This command fetches and displays basic details about the specified token, including its name and other relevant data.

The availability of these commands ensures transparency and accountability, allowing all network participants to access detailed information about the emission process. This openness is crucial for maintaining the integrity of the system and fostering trust among its users.

Previous6.6.1 Overview of DGT’s financial subsystem Next6.6.3 Consortium account

Last updated 1 month ago