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
  1. 5. EXPLORING TOKENOMICS
  2. 5.6 Token Demand Model

5.6.2 Transaction-Based Token Demand

Previous5.6.1 Node-Base DemandNext5.6.3 Staking Part Modeling

Last updated 1 year ago

To properly assess the token demand within a network, it's important to consider various aspects of network activity. This is because different factors can drive the demand for tokens in different ways. The proposed model thus considers two main aspects: users and value transferred, each of which captures different dynamics of the network's operation.

  • User-Based Demand: The approach utilized in this user-based model revolves around the notion that as the average number of transactions per user increases, so will the demand for tokens. This model introduces the concept of a dynamic demand for tokens based on user activity rather than a fixed per-user demand, which is a much more accurate representation of a growing and evolving network. In the modeling process, a sigmoid function is employed to represent the range of alterations in the demand for tokens needed to facilitate a certain number of transactions. Like previous models, the focus is on defining the shape of the function within given limits. These limits are obtained from abstract external sources, such as the analysis of existing cases.

    The token demand per user, in this context, is modeled based on the average number of transactions per user. It is important to note that this model potentially overestimates the token demand, as it aligns with the overall trend of an increasing average number of transactions per active user over time. As the network evolves and user engagement grows, more transactions are likely to occur. This model captures this trend within the set range, providing an upper limit for the token demand per user.

    The mathematical model used to describe user-based demand is:

Duser_basedT=D0T+DmaxT−D0T1+e−kDTUser∗(TXavg−bDTUser)        (34)D_{user\_based}^T = D_0^T + \frac{D_{max}^T - D_0^T} {1 + e^{-k_{DTUser} * (TX_{avg} - b_{DTUser})}} \ \ \ \ \ \ \ \ \tag{34}Duser_basedT​=D0T​+1+e−kDTUser​∗(TXavg​−bDTUser​)DmaxT​−D0T​​        (34)

Where:

o and represent the initial and maximum token requirements per user, respectively. These are defined based on prior knowledge about the network or assumptions about user behavior.

o is the rate of growth of token requirement per user as the number of transactions increases. It determines how rapidly the token demand changes with the change in transactions per user.

o is a corrective factor that can adjust the transition point in the sigmoid function.

o is average transaction number per user

The User-Based Model for token demand, as with any model, does have some limitations. Here are a few of them:

o Simplified Representation: The model operates under the assumption that all users behave similarly and contribute equally to token demand. This simplification overlooks the possibility of variability in user behavior, with some users potentially requiring significantly more or fewer tokens than the average user.

o Overestimation: The model tends to overestimate the token demand, particularly in scenarios where network efficiency increases and the average number of transactions per user grows. This can result in an overly conservative estimation of token requirements.

o Assumption of Constant Engagement: The model assumes that the level of user engagement remains constant over time. In reality, user engagement can fluctuate due to factors such as changing user interests, competition, and shifts in market conditions.

o Exclusion of Inactive Users: While the model focuses on active users, it excludes inactive or less active users from consideration. These users, despite their lower activity levels, may still require tokens for occasional transactions, which this model does not account for.

  • Value-Based Token-Demand Model: The Value-Based Token Demand Model considers the value transferred within the network, often associated with the information entropy of the system. The greater the entropy (or the more complex the information pattern), the greater the value being transferred, and thus, the greater the token demand. As per Metcalfe's law, the value of a network is proportional to the square of the number of connected users in the system. The entropy of the system, being reflective of the network's complexity, is then equated to this network value.

Dvalue_basedT=Anetwork⋅NMAU        (35)D_{value\_based}^T= A_{network} \cdot N_{MAU} \ \ \ \ \ \ \ \ \tag{35}Dvalue_basedT​=Anetwork​⋅NMAU​        (35)

Where:

  • Whole Transaction-based Demand Model: The fusion of two distinct token demand models - the User-Based Model and the Value Transferred Model - delivers a comprehensive estimation of token demand, which is driven by network transactions. This combined model captures both the demand driven by the number of active users (MAU) and the value transfer within the network (inferred from entropy as a measure of complexity or randomness).

    In the User-Based Model, the demand for tokens increases with the average number of transactions per active user. This model essentially mirrors User Engagement, capturing the notion that as more users engage with the network, they would require more tokens to support their activities.

    On the other hand, the Value Transferred Model, anchored in Metcalfe's Law and entropy, represents the network's complexity and the value transfer that happens within it. This model suggests that as the network's complexity increases (higher entropy) and more value is transferred (more transactions), there is a higher demand for tokens.

    By blending these two models, we can better reflect the intricate dynamics of token demand in the network. The aggregate token demand, therefore, arises from both user engagement (transaction frequency per user) and the complexity of value transfer in the network:

DTXT=α⋅Duser_basedT⋅NMAU+(1−α)⋅Dvalue_basedT⋅NMAU        (36)D_{TX}^T= α ⋅ D_{user\_based}^T ⋅ N_{MAU} +(1-α) ⋅ D_{value\_based}^T ⋅ N_{MAU} \ \ \ \ \ \ \ \ \tag{36}DTXT​=α⋅Duser_basedT​⋅NMAU​+(1−α)⋅Dvalue_basedT​⋅NMAU​        (36)

The DT Network represents the total demand for tokens in the network at a given time, accounting for both the demand due to network nodes and the demand due to transactions:

DNetworkT=DnodesT+DtxT        (37)D_{Network}^T = D_{nodes}^T + D_{tx}^T \ \ \ \ \ \ \ \ \tag{37}DNetworkT​=DnodesT​+DtxT​        (37)

The value-based token demand per user is then calculated based on this entropy. However, to bring this in line with the reality of token requirements in a system, the demand is also associated with the inverse of entropy, considering that higher efficiency (more connections, higher entropy) could lead to lower token requirements:

o - Network Value Factor, serves as an attempt to quantify the network's value with respect to its complexity and the number of its active participant

o is the amount of monthly active users (as part of all users).

o is the coefficient of efficiency of the network in the transfer of value (viscosity), traditionally low for decentralized networks.

· It serves to quantify the token requirement dictated purely by operational costs. This includes the resources needed to uphold the network's infrastructure, characterized by the component, and the resources demanded by the active users and value transfer dynamics, as denoted by the component.

· This measure deliberately excludes any influence from speculative activity, i.e., token trading based on price speculation rather than operational necessity. By doing so, the value presents a clearer picture of the genuine functional demand for tokens within the network.

· Additionally, omits the contribution from staking. Staking is the act of setting aside a reserve pool of tokens to support network security, operations, and applications, which can substantially contribute to the Total Value Locked (TVL) in a network. By excluding the staking component, maintains its focus on the transactional and operational aspects of the network.

Figure 86 Token Requirement per User over time (User-Based Model)
Figure 87 Normalized DT value-based over time
Figure 88 Token Demand over time