Kujua holds metadata on every transaction that it processes. All metadata is held in specific data points i.e dictionary keys. Data points that belong to the Kujua blockchain are known as Core data points but these can also be used by a developer. Non-core data points which interact with your dapp (decentralised application) specifically can be created using the 'free_text' core data point which accepts data in dictionary format. Therefore a transaction has a certain number of core data points that hold Core related information needed for the blockchain to operate. Core metadata is passed down from one transaction packet to the next. The reason this is done is because Kujua only cares to find the last transaction of a sender address and would need the most recent of this metadata. To perform this same mechanism for dapp specific data, using 'free_text' as mentioned above Kujua allows developers to append their own non-core metadata to their transactions for their dapps in order to interact with the blockchain.

Metadata State

All metadata can be saved in a state per contract at close of day (see whitepaper on what close-of-day is). A contract pays a fee to save a daily state. The contract saves the state as a hash on the blockchain. Using a default contract argument 'results_readable_obj_proof' one can send the current state readable values (of the hash) and if they match the hash value then the contract will use those values in its processes in future. This means the state readable values are saved externally from the blockchain on the dapp itself. The idea is to be able to save a state of the current contract and be able to use that state for future processes that the contract may need to perform.

Kujua’s metadata is either lineaged such as those data points that can accumulate and are traceable throughout their history such as an amount data point, and non-lineage metadata such as a date data point or an indicator data point e.g a status. Think of this as continuous or quantitative data and categorical data respectively.

An example usage of a lineage metadata is the active_duration_persistence Core data point which is a count in months since the account / address first transacted. This is an accumulated data point which accumulates with time and is needed for the Core system to perform certain functions such as enforce subscription payments every month. This data point could also be useful for a developer who wants to track how long an address has been active for their dapp purposes, perhaps to qualify for a discount. There are quite a number of these Core data points that a developer may find useful and a complete list can be found in the whitepaper. Now if a developer has a dapp that would track a daily active duration, they could create their own data point using the 'free_text' core data point to keep track of such a value and the blockchain will pass it down. Some of these data points are made in anticipation of what most developers may find useful such as the total_sent_amount which is the total Juana sent since the address was active. As you can imagine this can save a lot of lookup time for developers as they do not have to browse the blockchain to find such data for each address when interacting with a dapp.

Note: When using 'free_text', just be aware that should your contract use too many resources, a node may decide against running your contract should it consume unnecessary large amounts of resources. Therefore keep performance in mind when coding your logic and test how long your contract takes to execute fully.