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.3 Transactions

5.3.2 Shaping the Transaction Profile: A Three-pronged Approach

Previous5.3.1 Transaction Amount ComponentsNext5.3.3 Calculation of Transaction Number

Last updated 1 year ago

The transaction profile of a platform isn't solely a reflection of its user count or its marketed potential (Clegg et al. 2009). It's a nuanced picture painted by myriad factors, each contributing uniquely to the overall transactional behavior. Our model distills this complexity into three primary components (Shi et al. 2021), each capturing a pivotal aspect of the transaction landscape:

  • Emerging Effect (Rogers, Singhal, and Quinlan 2019):

    o Description: This component captures the initial fervor surrounding a new platform. Think of it as the honeymoon phase, where the platform's novelty and distinctive features lead to a surge in transactions. However, like all good things, this phase has expired. As the platform matures and the initial excitement simmers down, the transactional fervor wanes, leading to a decline in transaction numbers.

    o Modeling Approach: The emerging effect is encapsulated using an exponential decay function. Here, stands for the initial transactional burst, denotes the decay rate capturing how quickly the initial enthusiasm diminishes, and models the platform's initial positioning in the market. , a constant, signifies the steady-state transaction rate, the new normal after the initial hype has settled.

EmergingEffect(t)=ce+ke×exp⁡(−be×t)×exp⁡(−le×C(−be×t))       (13)EmergingEffect(t)=c_e+k_e×exp⁡(-b_e×t)×exp⁡(-l_e×C(-b_e×t))\ \ \ \ \ \ \ \tag{13}EmergingEffect(t)=ce​+ke​×exp⁡(−be​×t)×exp⁡(−le​×C(−be​×t))       (13)
  • Market Share (Cooper 1993):

    o Description: As the platform carves its niche in the market and gains traction, its transactional activity is influenced by its market share. Essentially, a larger slice of the market pie translates to more transactions.

    o Modeling Approach: The market share's impact on transactions is represented by a logistic function. In this function, is the apex of market share the platform can achieve, characterizes the pace of market share accretion, and is the inflection point, the moment when the market share's growth rate is at its zenith.

MarketShare(t)=Bm1+exp⁡(−bc×(t−t0))       (14)MarketShare(t)= \frac{B_m}{1+exp⁡(-b_c×(t-t_0 )) } \ \ \ \ \ \ \ \tag{14}MarketShare(t)=1+exp⁡(−bc​×(t−t0​))Bm​​       (14)
  • Usefulness:

    o Description: Beyond initial hype and market share, the platform's inherent value proposition, its usability, plays a pivotal role in shaping transactional behavior. A platform that seamlessly addresses user needs and offers tangible value will naturally see more transactions than one that's cumbersome or misaligned with user expectations.

    o Modeling Approach: The usefulness factor is captured by a logistic decay function. In this representation, is the baseline usability level, represents the decline rate in usability, and indicates the shift in the adoption curve.

Usefulness(t)=Cu×11+exp⁡(au×(t−ku)))       (15)Usefulness(t)=C_u×\frac{1}{1+exp⁡(a_u×(t-k_u )))} \ \ \ \ \ \ \ \tag{15}Usefulness(t)=Cu​×1+exp⁡(au​×(t−ku​)))1​       (15)

As observed, this model closely aligns with Gartner's methodology for analyzing technological hype in the sector (Dedehayir and Steinert 2016). We posit that transaction volumes within a specific network predominantly adhere to similar principles. While a more sophisticated strategy can incorporate deep learning techniques for data analysis, it demands a comprehensive model that considers an array of influential factors (Shi et al. 2021)

Combining these components, the overall transaction profile can be expressed as:

KTX=EmergingEffect(t)+MarketShare(t)−Usefulness(t)       (16)K_{TX}=EmergingEffect(t)+MarketShare(t)-Usefulness(t) \ \ \ \ \ \ \ \tag{16}KTX​=EmergingEffect(t)+MarketShare(t)−Usefulness(t)       (16)

From our simulation, the transactional profile of the environment is depicted in the subsequent figure. It's crucial to approach this model with caution as it's grounded in logical assumptions rather than empirical data. This methodology is suitable for initial tokenomics models tailored for nascent networks. In our upcoming iteration, we will juxtapose the constructed model with insights derived from ML algorithms. Nonetheless, it's essential to understand that even when leveraging actual data, every unique scenario will possess distinct factors that significantly shape the transaction profile.

Figure 74. Transaction Profile K_TX over time