TRANSACTION METADATA- API FUNCTIONALITY
For the sake of clarity, any form of data that gets added to a transaction after it has been processed is simply Transaction metadata. Whether a transaction is successful or not, once it is included in a ledger, it has metadata. Of course, software programs, including ours, also have ledgers where transactions are recorded. The transaction metadata essentially gives a detailed description of the transaction. However, the changes described in transaction metadata are in a validated ledger format.
For better understanding, some of the fields that may appear in a transaction metadata are: AFFECTED NODES, CREATED NODES FIELDS, DELETED NODE, and MODIFIED NODES field. They also include the delivered amount, transaction index, and transaction result.
The AFFECTED NODES array is made up of a complete list of objects in the ledger showing that the transaction was modified in some way. Every of the entry in this array is an object with at least one top-level field that indicates what exact type it is. Basically, the CREATED NODES indicate that the transaction has created a new object in the ledger, while DELETED NODES is in charge of indicating that the transaction has removed an object from the ledge. Also, the MODIFIED NODES indicates that an existing transaction has modified the objects in the ledger.
So altogether, the value of these field/nodes is a JSON object that describes the changes made to the ledger object. Now, a breakdown of these functionalities:
The CREATED NODES object regulates the ledger entry type (the type of object created), the ledger index (the identity of the ledger object in the ledgers state tree), NEW fields (the content of the newly created ledger object, which defers according to circumstances).
The DELETED NODES object contains the ledger entry type (the type of ledger object that was deleted), LedgerIndex (as earlier stated in the created nodes field), FinalFields (the content fields of the ledger object right before it was deleted).
The MODIFIED FIELD NODE object contains the ledger entry type (the type of ledger that was deleted), the LedgerIndex(the ID of the ledger object in the states tree), Final Fields (the content fields of the ledger after applying changes to the transaction), PreviousTxnID (although this may be omitted, it is the identifying hash of previous transactions to modify the ledger object), and Previous TxnLgrSeq (this too may be omitted; it contains the ledger index of the ledger version containing the previous transaction to modify the ledger object). However, if the transaction has both PreviousTxnID and Previous TxnLgrSeq, the fields transaction always updates them with the transactions own identifying hash and the index of the ledger version that included the transaction. However, these field’s new value is not listed in the FinalFields of the ModifiedNode Object, and their previous values are listed at the top level of the Modified Node object, rather than in the nested Previous Fields object.
The DELIVERED AMOUNT Is the amount of a payment transaction. It indicates the exact amount to be delivered to the destination. Accordingly, the destination would receive as much as the amount that was stated, and only then would the transaction be recorded as successful. The only exception is the case of partial payment, in which, any positive sum to the amount may have arrived. Instead of doubting the amount field, use the DELIVERED AMOUNT field in the metadata to see how much really reached the destination.
The rippled server provides a DELIVERED AMOUNT field in JSON transaction metadata for all successful payment transactions. It is formatted like a normal currency amount even though the DELIVERED AMOUNT is not available for transactions that meet the criteria of being a partial payment or included in a validated ledger before 20th January 2014.
If both criteria are met, then DELIVERED AMOUNT contains the string value unavailable instead of an actual amount. In this case, you can only figure out the actual delivered amount by reading the AFFECTED NODES in the transaction’s metadata.
It is noteworthy that the DELIVERED AMOUNT is generated on demand for request. It is not included in binary format for metadata, nor is it used when calculating the hash of the transaction metadata. However, the delivered amount field is included in the binary format of partial payment transactions after 20th January 2014.
These are a few basic functions of the API metadata. More specific functions are being developed. These new functionalities, although not yet unveiled, would make our software more interesting and easy to use for developers and other businesses.
Despite fear and reluctance towards the crypto market, this year, it is recovering and making a great comeback. Our company is foreseeing great opportunities for a stable market. Our experts predict that volatility would be considerably lower. So if you want to invest, now would be a good time.
