6.6.1 Overview of DGT’s financial subsystem

6.6.1.1 Meet Garanaska

Garanaska represents a sophisticated financial subsystem embedded within the DGT platform, dedicated to managing financial transactions and incorporating additional logic. It's important to note that Garanaska is an optional component of DGT, available under a separate AGPL v. 3 license. A key aspect of using Garanaska in an open network is that any modifications to the AGPL protocols necessitate approval from the DGT development team, which can be reached at [e-mail]. The Garanaska ecosystem comprises several critical components:

• DEC Transaction Family: Handles the lifecycle of the native DEC token, from issuance to various operations such as transfers and lending.

• NOTARY Transaction Family: Supports external nodes for off-chain operations, decentralized identification, and confidential data handling.

• SETH Transaction Family: Enables interaction with Ethereum-compatible smart contracts.

Garanaska operates on the same core as the main DGT version, meaning the installation and command-checking procedures previously described are applicable here as well. However, there are notable distinctions:

• DEC Token Emission: Unlike the bgt family, which generates tokens for testing purposes, DEC tokens must be initially issued and then distributed among the nodes and the overseeing consortium. The system maintains a strict integrity check to ensure the circulation of DEC tokens is bounded by the initial issuance volume.

• Parallel Transaction Processing: Although DEC transactions are common on the network, clusters can process other types of transactions in parallel. Issuing tokens is a one-time, multi-signature operation that requires careful planning. Another group of transactions is simple transfer of funds from account to account, payment of invoices, and other financial transactions.

• Transaction Sessions and Address Spaces: Each DGT transaction session operates independently, utilizing its own address spaces. The system facilitates communication between transaction families through protocol-defined bridges, but these do not extend to user-defined transaction families.

• Address System: DEC adopts an Ethereum-compatible address system, supplemented by a UTXO/ACCOUNT hybrid model. This system enriches each address with a set of attributes defining transaction limits and other parameters, collectively referred as account.

• Alias System: Beyond the cumbersome expression of public keys and addresses, users can associate simpler Aliases (Registered Names) with their accounts, acting like DNS within the DGT-DEC ecosystem. Linking multiple aliases to a account involves notary operations or special consortium commands.

• Rewards for Transaction Processing: Nodes receive compensation for processing transactions through various mechanisms, including a share of the pre-issued DEC fund, fixed fees determined at the issuance stage, and additional tips for certain types of transactions.

For a practical guide on interacting with DEC tokens and understanding the operational nuances of Garanaska, refer to the "DEC PROCESSING" chapter. This section is tailored for hands-on use, assuming familiarity with the theoretical foundation provided in earlier segments.

6.6.1.2 DEC Account Structure

The financial system within the DGT platform operates on a foundational basis of accounts. These accounts facilitate crucial operations such as the crediting and sending of funds, which necessitate the verification of account balances. Typically, this process involves the use of an identifier, often represented by the account number itself. The DGT network supports the implementation of various parallel account systems, each grounded in its unique transaction family. This discussion centers around the DEC family, which constitutes the primary financial backbone of the platform. However, within the DEC system, an account is characterized by numerous properties and features that significantly influence its usage. The general structure of a DEC account is outlined below, emphasizing the main account properties of DEC.

Further practical uses of accounts are discussed within this guide, with additional theoretical insights available in the DGT Tokenomic book.

6.6.1.2.1 DEC Account Properties

The DEC account system in DGT is comprehensive, featuring multiple attributes that dictate how each account is managed and interacts within the network.

Figure 128 DEC Account Properties

Below is a table detailing the primary properties of a DEC account:

#	Account Property	Description	Example
1	BALANCE	A Double-type number reflecting the account's balance in DEC currency, with decimal precision set at issuance. While DEC is the default currency, accounts may also be linked to other tokens with their respective balances.	1000.50 DEC
2	OBJECTS	Similar to how physical wallets store cards and SIM cards, an account can be linked to various objects characterized by unique identifiers, such as NFTs, RWAs, or abstract objects. These, along with the currency balances, represent the account's stored value.	NFT ID: 1234
3	Private Key	A substantial alphanumeric identifier, randomly chosen within the system's defined value space, selected asymmetrically and can even be generated off-line. This key is confidential, essential for account access, and must not be disclosed.	5JpD...w1X
4	Public Key	A special value extracted via a specific cryptographic algorithm from the private key. DGT utilizes a single cryptographic system network-wide, defaulting to ECDSA over the Secp256k1 curve. This sets the parameters by which the public key is computed from the private key. The conversion from public to private key is computationally infeasible.	1BoatSLRHtKNngkdXE… eobR76b53LETtpyT
5	Address	To condense information and include additional verifications, real operations use an address derived from the public key, reducing its size but maintaining uniqueness across the system. This process employs the Kessak-256 hash function, aligning with the EIP-55 standard. The address essentially serves as the account number.	0x...
6	Attributes	Accounts may be assigned to a set of attributes that define restrictions. The absence of specific attributes implies default settings apply, with key restrictions on transferable amounts and transaction frequency. Attributes can only be modified through notary nodes following identity verification (IDD).	Transfer limit: 1000 DEC/day
7	Role	Roles denote account groupings, allowing for the inheritance of properties set for the group upon creation. This functionality enables features such as credit options and the support for negative balances, among other properties.	Lender
8	IDD	A decentralized identifier linking the account to an identity within a decentralized identification system, enabling advanced operations and simplified KYC processes.	ID: DID:example:123
9	Aliases	To facilitate easier transactions, aliases serve as synonyms for addresses, allowing transfers using identifiers like emails instead of cumbersome public addresses. Managed by consortia or notary nodes, aliases ensure transactional convenience.	Email: [e-mail]

6.6.1.2.2 Key Account Types in the DEC Ecosystem

The DGT platform operates on a sophisticated financial infrastructure presented by DEC Family, centered around a dynamic account ecosystem that underpins the network's economic activities. This ecosystem is designed to facilitate a broad range of transactions, from standard fund transfers to complex, shielded operations, all within a secure and decentralized framework.

At the core of the DGT DEC system is an innovative tokenomics model, which strategically manages the creation, distribution, and expenditure of funds to sustain the network's growth and stability. This model ensures that transaction fees and SLA-based minting processes incentivize participants, maintain liquidity, and fund network development. Exploring the principles behind this model reveals how the DGT network balances economic incentives with operational costs, driving engagement and investment. Key Account Types in the DGT DEC Ecosystem:

• DEC_EMISSION_KEY: This virtual account, replenished during the initial coin offering (ICO), serves as the network's financial reservoir. The emission process is transparent, allowing network participants to view fund availability and utilization. However, only specific transactions, such as disbursements for ecosystem support and rewards for nodes based on their transaction volume, are permitted. As funds deplete over time, reflecting the cost of network transactions, ownership transitions to the community, fostering a self-sustaining economy driven by transaction fees and auxiliary mechanisms.

• FUND: Established during the initial phase, this consortium-managed account is pivotal for early-stage network support. It has the unique ability to conduct transactions within predefined limits, channeling funds to support projects and users. The consortium's management of the FUND account is public and aligns with the network's white paper declarations, ensuring transparency and trust. This mechanism not only kickstarts the network's economy but also ensures ongoing support until the ecosystem becomes self-reliant.

• REGULAR ACCOUNTS: Owned by users and nodes, these accounts are the bedrock of daily network operations. They support a vast array of transactions, including innovative shielded transactions that ensure privacy and security. The flexibility of REGULAR ACCOUNTS, combined with their ability to hold unique attributes, aliases, and roles, showcases the network's adaptability to diverse economic activities.

Consider a scenario where a new project seeks funding from the FUND account. The consortium reviews the project, assessing its potential contribution to the ecosystem. Upon approval, funds are transferred to the project's account, illustrating the FUND's role in ecosystem development. This example demonstrates the fund's strategic use to foster innovation within the DGT DEC network.

6.6.1.2.3 Security and Regulatory Compliance

The DGT DEC system hosts a distinct ecosystem of accounts that support the network's economic infrastructure, including DEC_EMISSION_KEY, FUND, and REGULAR ACCOUNTS, each playing a specific role in maintaining and fostering the network's economic activities. Just as with conventional blockchain systems, the DGT platform allows for a range of account operations, including standard transfers, object payments, invoice settlements, and credit operations. All accounts, aside from the system account, are independently created by users through specific commands.

The DGT DEC ecosystem places a strong emphasis on security and regulatory compliance. Advanced cryptographic techniques protect account transactions, ensuring confidentiality, integrity, and non-repudiation. The system's adherence to KYC and AML standards is facilitated using decentralized identifiers (IDDs), which provide a balance between privacy and regulatory requirements. These measures instill confidence among users and regulators alike, promoting a secure and compliant financial environment.

The integrity and security of financial transactions represent foundational pillars for the trust and functionality of any blockchain network. Traditional blockchain systems often grapple with the challenge of balancing transaction transparency with the need for privacy and security. While the immutable and decentralized nature of blockchain technology offers unparalleled security and transparency, it also poses limitations regarding the confidentiality of financial transactions and account ownership. The DGT DEC network addresses these challenges through innovative mechanisms designed to safeguard user privacy while adhering to regulatory requirements and maintaining the decentralized ethos of the network.

• Decentralized Identifiers (IDD) and Partial Confidentiality. Account ownership within the DGT DEC ecosystem is obscured behind a system of Decentralized Identifiers (IDDs). This approach provides a layer of privacy by decoupling personal identities from account numbers, offering users partial confidentiality. Although indirect information might still allow for the deduction of private data based on additional off-chain information, the use of IDDs strikes a critical balance between meeting regulatory demands and preserving the network's decentralized character. This balance ensures that while transactions and account balances remain transparent and secure, the real-world identities of account holders are protected.

• Shielded (Private) Transactions. To further enhance privacy, the DGT DEC network implements Shielded Transactions, utilizing Zero-Knowledge Proof (ZKP)-based algorithms. These sophisticated cryptographic protocols allow for the transfer of funds between network participants without revealing the transaction amounts or the addresses involved. This feature is particularly crucial for users who require high levels of transaction privacy, whether for personal reasons or to comply with specific financial regulations. By encrypting transaction details, the network ensures that financial activities can be verified as legitimate without exposing sensitive information.

• Payload Security. In addition to protecting the privacy of transactions, the DGT DEC network employs a Payload Security mechanism. This feature enables the transmission of additional encrypted instructions within the transaction processor, safeguarding the subjects behind them. Payload Security is essential for transactions that involve complex contracts or sensitive information, providing an added layer of protection to ensure that only intended parties can access and execute the specified actions.

6.6.1.3 Deployment and Preparation

Preparing a Garanaska deployment in the initial phase is the same as the steps described above when deploying a single node or cluster. Below is a repetition of the basic steps collected in the form of a short cheat sheet in the form of a table.

#	Step	Command	Comment
1	Preparing and Validating the Server	sudo docker version sudo docker-compose -version	Operating System, “Docker”, “Docker Compose” are deployed comply with .
2	DGT Installation	git clone https://github.com/DGT-Network/DGT-Matagami	Installing DGT is as simple as cloning a repository from GitHub to build a Docker image
3	Node Docker Image Build	cd DGT-Matagami/GARANASKA_BETA bash upDecCluster.sh -G -SC -CB openssl 1 1 bash upDecCluster.sh -SC -CB openssl 1 1	The assembly is done with the same commands as for a single node. Unlike the CORE build, you have to run the command from the GARANASKA_BETA directory. Wait for the "done" command to finish.
4	Notary ring (optional)	bash upDgtNotary.sh -CB openssl 1 bash upDgtNotary.sh -CB openssl -NR 2	For the functioning of the full-fledged version (if you are deploying a network), you can also install notary nodes. It is necessary to install separately the Notary Key Keeper and at least one node of the Notary type for regular operations.
5	Dashboard (optional)	bash control.sh dash up -d or bash upDgtDashboard.sh -CB openssl	After launching the DGT Dashboard, the service is available by default through the browser at <SERVER_IP>:8803
6	Check-up	docker exec -it shell-dgt-c1-1 bash dgt peer list bgt set WAL 7777 bgt list exit	Here, the first command runs the host interpreter inside Docker Next, the command displays a list of nodes (apparently one node) Next, the command creates a BGT-wallet and transfers 7777 tokens (test tokens) to it Finally, the command displays a list of bgt-wallets and finishes with the interpreter

Starting with the Matagami version, a new version of the commands using the control.sh script is available: bash control.sh (see also Shell Scripts). In case the node has been previously installed and the server is overloaded and running, but it is necessary to reinitialize the node launch:

cd DGT-Matagami/GARANASKA_BETA
bash upDecCluster.sh -SC -CB openssl 1 1 
bash upDgtNotary.sh -CB openssl 1
bash upDgtNotary.sh -CB openssl -NR 2

To execute node commands, you must also run the container shell, for example:

docker exec -it shell-dgt-c1-1 bash