6.6.5 Payments
6.6.5.1 Transfers
Economic activity, both broadly and within network economies specifically, revolves around the exchange of values within a community. The simplest form of exchange is the transfer of received funds from one account to another, known as transferring. To facilitate this, the following conditions must be met:
Sender's Account Funds: The sender (User A) must have funds in their account, which could have been received from another user or a consortium.
Recipient's Correct Address: The sender must know the correct address of the recipient (User B).
Transaction Signature: User A must be able to correctly sign the transaction. This requires a key pair - a private and a public key (technically, the private key is sufficient as the public key can be derived from it).
Network Rules Compliance: The transaction must adhere to the network's rules. Specifically, within the DEC network, accounts are by default limited in terms of transfer amount and frequency. These limits are set at issuance and apply network-wide within the DEC family.
The command format for transferring funds from User A to User B is as follows:
dec send <FROM A: Public Key, Address, FILE> <TO B: Public Key, Address, FILE> <SIGNATURE: PRIVATE KEY OR FILE WITH PRIVATE KEY>
For example, to transfer 10 DEC from account A (to which we previously transferred 100 DEC from the consortium account) to account B (which previously had a balance of 50 DEC), the command would be:
To verify the balance, use the following commands:
The result:
This process underscores the foundational aspects of network economics - facilitating the secure and rule-compliant transfer of value between participants, reinforcing the trust and utility within the digital ecosystem.
A money transfer transaction is a write operation and must be signed by the sender. You should also keep in mind the asymmetrical nature of such operations: sending an operation to the network does not lead to its immediate recording, the status of the operation is Commitment. Only after the operation has been verified by the arbitrator nodes, the record reaches the registry and is distributed in the network as part of blocks. The following status check shows how successful the operation was.
6.6.5.2 Asset Based Transactions
DEC supports complex types of payments by incorporating the notion of assets. An asset refers to any item or entity involved in transactions such as purchasing, selling, lending, exchanging, or other financial activities. Although the specific properties or methods of assets (if they are contracts) are not directly addressed within the DEC transaction family, the core representation of a wide array of assets is through a unique identifier registered within the system.
This setup facilitates an operation for registering target assets:
dec target <TARGET ID> <TARGET PRICE> <TIPS> <PROTO> <INVOICE> <DID> <SIGNATURE>
The comprehensive argument set allows for establishing a price for the asset and associated behaviors linked to the asset's external properties. Two methods exist for asset registration:
Simplified registration by name, using a unique name for the asset.
Registration through notary nodes, which enables the assignment of a special DID identifier that facilitates the tracking of the asset's existence, its properties, availability, and other attributes.
This structure not only broadens the application scope of blockchain technology to include intricate asset management and trading systems but also enhances the environment for digitizing, trading, and managing a diverse range of assets with unprecedented levels of transparency and security. The DEC framework revolutionizes asset tracking and verification, ownership authentication, and history without central authority reliance, especially beneficial for contexts demanding strict provenance, authenticity, and ownership tracking, such as in art collections and supply chain management.
6.6.5.2.1 Simple Asset Registration
Within the simple registration process, a user must have an idea of a unique asset name. Although there is an option to output asset lists, the capabilities of the command itself for the network (see below) are limited; therefore, it is recommended to choose a name that is sufficiently unique, similar to the address generation approach.
Upon registration, an initial value of the asset is assigned: 10 DEC. Such registration also constitutes a write operation and must be signed:
dec target <ASSET NAME> <VALUE> <SIGNATURE>
Registering asset A1 with a price of 10 DEC to account A:
The command returns the address of the asset, which is recommended to be remembered or stored, because it might be difficult to obtain the address if the object is reused.
Retrieving information about an asset:
dec show <ASSET ADDRESS> -tp targets
For example, after applying the object registration commands above, we get the address of the new object B1: 0x131bc85a7c6636f858c1a1b17902f1608826e82cefd7
We can now view the status of the asset with the show command:
Re-registering an object by the same account results in an error; however, it remains possible to create an object with the same name by another account:
Although nodes support limited functionality for obtaining a list of objects, for testing purposes, you can use the listcommand:
The result is shown in the figure below:
Although currently there is no limit on the number of assets created, the node administrator may limit the number of objects created through the API to protect against spam attacks.
6.6.5.2.2 Adding an Invoice to an Asset
Assets within the DGT ecosystem can change ownership through purchase and sale transactions. To facilitate this, an invoice is generated for the asset, enabling a specified transaction for a new owner to acquire the asset. The process of generating an invoice closely mirrors conventional payment procedures. An invoice can specify the price and may be reissued; however, only the latest invoice remains valid and actionable.
The essence of an invoice in the DGT context is to formalize the offer for an asset sale, specifying the asset targeted for sale, the intended new owner (or buyer), the sale price, and the necessary digital signature for authentication. This process ensures that asset transactions are transparent, secure, and verifiable within the DGT blockchain framework. The general format for invoice command:
dec invoice <TARGET> <New Owner/Customer> <PRICE> <SIGNATURE>
EXAMPLE COMMAND FOR ISSUING AN INVOICE:
To sell a previously registered asset, A1, with the address
This command constructs an invoice for asset A1, setting a sale price of 15 DEC tokens, and designates account B as the potential new owner. The transaction is authenticated using the private key of the current asset owner, ensuring the integrity and authorization of the sale offer.
Outcome:
Upon successful execution, this command generates an invoice within the DGT network, recording the sales offer for asset A1 to account B at the specified price. This invoice is then available for account B to accept and process the purchase, facilitating the transfer of asset ownership upon completion of the transaction. The use of invoices in asset transactions enhances the security and efficiency of ownership transfers, providing a structured and verifiable method for conducting sales within the DGT platform.
6.6.5.2.3 Direct Asset Purchase
In the DGT ecosystem, registered assets with a specified value and an active invoice can be directly purchased from their current owner by paying the full price stated in the invoice. This transaction is facilitated using the dec pay command, which follows this format:
dec pay <New Owner B> <Old Owner A> 100 —target A1 —keyfile <private key of B>
This command structure signifies a transfer of ownership for a specified asset from the old owner (A) to the new owner (B), contingent upon the fulfillment of several critical conditions:
Availability of Funds: The purchasing account (B) must possess sufficient funds to cover the total cost of the asset as specified in the invoice.
Existence of an Active Invoice: An active invoice for the asset must have been previously issued to the new owner (B), outlining the terms of the sale including the price.
Existence of the Asset: The asset being purchased must be registered within the DGT network and identifiable through a unique asset ID.
Signature Verification: The transaction must be properly authenticated using the digital signature of the purchaser (B), ensuring the legitimacy and authorization of the purchase request.
EXAMPLE:
To illustrate, consider a scenario where asset A1, previously offered for sale by owner A and represented by the address 0x5dc9f077efab39324ff1492dce02e3faa1e35cc607ae, is being purchased by account B. The command to execute this purchase, assuming the sale price is 15 DEC tokens, would be:
This command initiates the transfer of asset A1 to the new owner B upon payment of the agreed price. The transaction's integrity is secured by the digital signature of the buyer, represented by their private key.
The result of this transaction can be verified using the dec show command, which displays the asset's status and, importantly, the address of the new owner. The inclusion of the asset ID as part of the command allows for a detailed view of the asset's information post-transaction:
The successful completion of a direct asset purchase marks a significant event in the DGT platform, facilitating the seamless and secure transfer of asset ownership while ensuring compliance with all necessary conditions and verifications. This process underscores the platform's commitment to enabling transparent and trustworthy transactions within its ecosystem.
6.6.5.2.4 Tips Management
In the DGT ecosystem, a low-margin (flat) fee rate is applied to transaction fees. This fee is set during the token issuance process and can be adjusted by the consortium that executed the issuance. Nodes that support processing within the DGT network receive rewards through minting mechanisms and transaction fees.
However, when conducting transactions involving significant expenditures, such as the buying and selling of Real World Assets (RWA), a more flexible approach to managing transaction costs is required. To address this, DGT introduces an additional mechanism known as tips – a one-time extra charge associated with an asset during its purchase. Tips are tied to specific nodes for extra charges related to the buying and selling of an asset.
Tips can be designated for the current node for certain types of operations (e.g., target: buying and selling objects) as well as for specific objects.
QUERYING TIPS:
To inquire about specific tips applicable to the network's nodes, the following command can be used:
dec tips <OPERATION>
For instance, the command:
returns additional charges by nodes (list limited to those nearest in topology) with names AA, AB, AC:
SETTING TIPS FOR AN OBJECT:
Beyond nodes, tips can also be established by sellers when publishing an object. This mechanism promotes competition among nodes, as the markup benefits the node involved in the transaction (or is distributed among cluster nodes).
To set tips for an object, the following command format is used:
dec target <TARGET D> <PRICE> --tips <TIPS VALUE> <SIGNATURE>
EXAMPLE:
To verify the presence of set tips associated with an object, use commands like:
Upon setting a specific additional charge (tip), its amount is added to the purchase price, to be paid by the buyer. This approach not only facilitates flexible management of transaction costs but also incentivizes nodes through competitive practices, enhancing the overall efficiency and effectiveness of asset transactions within the DGT network.
6.6.5.2.5 Asset Management with Notary Nodes and Verifiable Credentials
In the DGT ecosystem, assets are often abstract entities within the DEC family, eligible for transactions such as buying and selling when accompanied by an invoice. However, in practical applications, assets possess intrinsic properties that significantly influence their value and desirability to network participants. These properties may originate from the physical world, as seen with Real World Assets (RWA) like properties defined by their construction value, number of floors, interior finishes, etc., or digital objects represented in external registries.
Given that these properties can be confidential and subject to change over time, traditional blockchain registry mechanisms, which require public access by nodes verifying transactions to the data itself, are not well-suited for managing such properties. DGT addresses this challenge through the implementation of Verifiable Credentials managed by specialized Notary Nodes.
NOTARY NODES FUNCTIONALITY:
Notary Nodes serve as anchors within the DGT network, representing a unique object identifier (DID) to which external properties can be linked. The key features of these nodes include:
Correct Configuration of Notary Nodes: At least two nodes should be operational within a notary ring, including a seal keeper and a regular node.
Proper Account Settings: Accounts should be correctly configured with private and public keys.
Unique DID Representation: The DID must be a unique key, avoiding conflicts with other unique data within the network.
OPERATIONS INVOLVING NOTARY NODES:
To create an object with notary participation and associate it with a DID, the following command is utilized:
notary target <ASSET NAME> <DID FOR ASSET> <ASSET PRICE> [--invoice]
The optional --invoice parameter generates a default invoice, making the object immediately ready for sale after creation. Querying an object created through a notary node in the DGT network will reveal additional attributes, including its DID.
To view a list of objects associated with a specific DID, the command is:
notary goods <DID>
EXAMPLE:
Let's register an object A3 with the DID 000af56798:
This example illustrates how Notary Nodes and Verifiable Credentials facilitate the management of assets with complex and changing properties in the DGT network. By leveraging unique identifiers and ensuring the confidentiality and integrity of asset properties, DGT provides a robust framework for asset management and transactions, enhancing trust and security within its ecosystem.
Last updated
