DGT DOCS
  • 1. INTRODUCTION
    • 1.1 Executive Summary
    • 1.2 Why DGT
    • 1.3 Distributed Ledgers Technology
      • 1.3.1 Decentralization approach
      • 1.3.2 Consensus Mechanism
      • 1.3.3 Transactions
      • 1.3.4 Layered Blockchain Architecture
      • 1.3.5 Tokenomics
      • 1.3.6 Web 3 Paradigm
      • 1.3.7 Common Myths about Blockchain
    • 1.4 The DGT Overview
      • 1.4.1 Platform Approach
      • 1.4.2 DGT Functional Architecture
      • 1.4.3 Technology Roadmap
    • 1.5 How to create a Solution with DGT Networks
    • 1.6 Acknowledgments
  • 2. REAL WORLD APPLICATIONS
    • 2.1 Case-Based Approach
      • 2.1.1 DGT Mission
      • 2.1.2 The Methodology
      • 2.1.3 Case Selection
    • 2.2 Supply Chain and Vertical Integration
      • 2.2.1 Logistics Solution for Spare Parts Delivery
      • 2.2.2 DGT Based Solution for Coffee Chain Products
    • 2.3 Innovative Financial Services
      • 2.3.1 Crowdfunding Platform
      • 2.3.2 Real World Assets Tokenization
      • 2.3.3 Virtual Neobank over DGT Network
      • 2.3.4 DGT based NFT Marketplace
    • 2.4 Decentralized Green Energy Market
      • 2.4.1 Peer To Peer Energy Trading
      • 2.4.2 DGT based Carbon Offset Trading
    • 2.5 B2B2C Ecosystems and Horizontal Integration
      • 2.5.1 KYC and User Scoring
      • 2.5.2 Decentralized Marketing Attribution
      • 2.5.3 Case Decentralized Publishing Platform
      • 2.5.4 Value Ecosystem
    • 2.6 More Cases
  • 3. DGT ARCHITECTURE
    • 3.1 Scalable Architecture Design
      • 3.1.1 High Level Architecture
      • 3.1.2 DGT Approach
      • 3.1.3 Unique contribution
      • 3.1.4 Component Based Architecture
    • 3.2 Performance Metrics
    • 3.3 Network Architecture
      • 3.3.1 Nework Architecture in General
      • 3.3.2 Network Identification
      • 3.3.3 H-Net Architecture
      • 3.3.4 Transport Level
      • 3.3.5 Segments
      • 3.3.6 Static and Dynamic Topologies
      • 3.3.7 Cluster Formation
      • 3.3.8 Node Networking
      • 3.3.9 Permalinks Control Protocol
    • 3.4 Fault-Tolerant Architecture
      • 3.4.1 Introduction to Fault Tolerance
      • 3.4.2 F-BFT: The Hierarchical Consensus Mechanism
      • 3.4.3 Cluster Based Algorithms
      • 3.4.4 Arbitrator Security Scheme
      • 3.4.5 Heartbeat Protocol
      • 3.4.6 Oracles and Notaries
      • 3.4.7 DID & KYC
    • 3.5 Transactions and Performance
      • 3.5.1 Transaction Basics
      • 3.5.2 Transaction Processing
      • 3.5.3 Transaction and block signing
      • 3.5.4 Transaction Families
      • 3.5.5 Transaction Receipts
      • 3.5.6 Smart Transactions
      • 3.5.7 Private Transactions
      • 3.5.8 Multi signature
    • 3.6 Data-Centric Model
      • 3.6.1 Data layer overview
      • 3.6.2 Global State
      • 3.6.3 Genesis Record
      • 3.6.4 Sharding
      • 3.6.5 DAG Synchronization
    • 3.7 Cryptography and Security
      • 3.7.1 Security Architecture Approach
      • 3.7.2 Base Cryptography
      • 3.7.3 Permission Design
      • 3.7.4 Key Management
      • 3.7.5 Encryption and Decryption
      • 3.7.6 Secure Multi Party Computation
      • 3.7.7 Cryptographic Agility
      • DGTTECH_3.8.4 Gateway Nodes
    • 3.8 Interoperability
      • 3.8.1 Interoperability Approach
      • 3.8.2 Relay Chain Pattern
      • 3.8.3 Virtual Machine Compatibility
      • 3.8.4 Gateway Nodes
      • 3.8.5 Token Bridge
    • 3.9 DGT API and Consumer Apps
      • 3.9.1 Presentation Layer
      • 3.9.2 Application Architecture
    • 3.10 Technology Stack
    • REFERENCES
  • 4. TOKENIZATION AND PROCESSING
    • 4.1 Introduction to Tokenization
      • 4.1.1 DGT Universe
      • 4.1.2 Driving Digital Transformation with Tokens
      • 4.1.3 Real-World Tokenization
      • 4.1.4 Key Concepts and Definitions
    • 4.2 Foundations of Tokenization
      • 4.2.1 Definition and Evolution of Tokenization
      • 4.2.2 Tokenization in the Blockchain/DLT Space
      • 4.2.3 The Tokenization Process
      • 4.2.4 Tokenization on the DGT Platform
      • 4.2.5 Regulatory and Legal Aspects of Tokenization
      • 4.2.6 Typical Blockchain-Based Business Models
    • 4.3 The DEC Transaction Family
      • 4.3.1 DEC Transaction Family Overview
      • 4.3.2 DEC Token Features
      • 4.3.3 DEC Token Protocol
      • 4.3.4 DEC Account Design
      • 4.3.5 DEC Transaction Family Flow
      • 4.3.6 DEC Commands
      • 4.3.7 DEC Processing
      • 4.3.8 Payment Gateways
    • 4.4 Understanding Secondary Tokens
      • 4.4.1 The different types of tokens supported by DGT
      • 4.4.2 How secondary tokens are produced
  • 5. EXPLORING TOKENOMICS
    • 5.1 Introduction
      • 5.1.1 What does tokenomics mean?
      • 5.1.2 Goals of Building the Model for DGT Network
      • 5.1.3 Tokens vs Digital Money
      • 5.1.4 The Phenomenon of Cryptocurrency
      • 5.1.5 Basic Principles of Tokenomics
      • 5.1.6 AB2023 Model
    • 5.2 Node & User Growth
      • 5.2.1 Node Ecosystem
      • 5.2.2 User Growth and Retention Modeling
    • 5.3 Transactions
      • 5.3.1 Transaction Amount Components
      • 5.3.2 Shaping the Transaction Profile: A Three-pronged Approach
      • 5.3.3 Calculation of Transaction Number
    • 5.4 Network Performance Simulation
      • 5.4.1 Endogenous Model
      • 5.4.2 Network Entropy
      • 5.4.3 Network Utility
    • 5.5 Token Supply Model
      • 5.5.1 Introduction to Supply and Demand Dynamics
      • 5.5.2 Token distribution
      • 5.5.3 Supply Protocol
      • 5.5.4 Token Balance and Cumulative Supply
    • 5.6 Token Demand Model
      • 5.6.1 Node-Base Demand
      • 5.6.2 Transaction-Based Token Demand
      • 5.6.3 Staking Part Modeling
      • 5.6.4 Total Demand
    • 5.7 Token Price Simulation
      • 5.7.1 Nelson-Siegel-Svensson model
      • 5.7.2 The Price Model
    • 5.8 Decentralization Measurement
      • 5.8.1 Active Node Index
      • 5.8.2 Node Diversity in Hybrid Networks
      • 5.8.3 Token distribution
      • 5.8.4 Integral Calculation of Decentralization Metric
    • 5.9 Aggregated Metrics
      • 5.9.1 Transaction Throughput: Evaluating Network Performance and Scalability
      • 5.9.2 Market Capitalization: A Dimension of Valuation in Cryptocurrency
      • 5.9.3 Total Value Locked (TVL): A Spotlight on Network Engagement and Trust
  • 6. ADMINISTRATOR GUIDE
    • 6.1 Introduction
      • 6.1.1 Administrator Role
      • 6.1.2 Platform sourcing
      • 6.1.3 DGT Virtualization
      • 6.1.4 Using Pre-Built Virtual Machine Images
      • 6.1.5 Server Preparation
      • 6.1.6 OS Setup and initialization
    • 6.2 DGT CORE: Single Node Setup
      • 6.2.1 Launch the First DGT Node
      • 6.2.2 Dashboard setup
      • 6.2.3 Nodes Port Configuration
      • 6.2.4 Single Node Check
    • 6.3 DGT CORE: Setup Private/Public Network
      • 6.3.1 Network launch preparation
      • 6.3.2 A Virtual Cluster
      • 6.3.3 A Physical Network
      • 6.3.4 Attach node to Existing Network
    • 6.4 DGT Dashboard
    • 6.5 DGT CLI and base transaction families
    • 6.6 GARANASKA: Financial Processing
      • 6.6.1 Overview of DGT’s financial subsystem
      • 6.6.2 DEC emission
      • 6.6.3 Consortium account
      • 6.6.4 User accounts
      • 6.6.5 Payments
    • 6.7 Adjust DGT settings
      • 6.7.1 DGT Topology
      • 6.7.2 Manage local settings
    • 6.8 DGT Maintenance
      • 6.8.1 Stopping and Restarting the Platform
      • 6.8.2 Backing up Databases
      • 6.8.3 Network Performance
      • 6.8.4 Log & Monitoring
Powered by GitBook
On this page
  • 6.6.3.1 Creating the Consortium Account
  • 6.6.3.2 Funding the Consortium Account
  • 6.6.3.3 Transferring Funds to Regular Accounts
  • 6.6.3.4 Getting Information about the Consortium Account
  1. 6. ADMINISTRATOR GUIDE
  2. 6.6 GARANASKA: Financial Processing

6.6.3 Consortium account

Previous6.6.2 DEC emissionNext6.6.4 User accounts

Last updated 1 year ago

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

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
  • 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

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

Figure 137 FUND account creation
Figure 138 Corporate Account Details
Figure 139 Applying balanceoff command