We all have heard of Blockchains where, in a network (like Bitcoin) all the transactions are grouped into blocks chronologically (with a cryptographic proof) and chained. The world currently is in a place where billions of transactions happen every second and all these cannot be integrated into a single branch of chained blocks (blockchains).

Hence Transactions Chains are introduced (by Uniris), where each block contains only one transaction and these transactions are chained to form a transaction chain. Every identity (person, device, node, etc) has it’s own transaction chain independent of each other. (This potentially means that an identity will have it’s own blockchain) and there can be billions of Transactions Chains inside Uniris network.

Let us take an example of a Transaction and see how it is integrated in Blockchain vs Transaction Chain

Example: Alice sends Bob 10 Bitcoins

As you can see Alice's transactions is inside a block where there are many transactions in the same block. Hence in Bitcoin the Transaction speed is 7 per second.

Example: Alice sends Bob 10 Uniris Coins (UCO)

Here Alice's transaction is in her own Transaction Chain and is validated instantly. Her transaction chain does not interfere with that of other identities as they have their own transactions chains.

Pending Transaction and Validated Transaction:

Pending Transaction

Pending Transaction is a transaction that does not have proof of network validation. To be processed by the network, this transaction must have the following information (Figure above):

  • @addr : An unused address that corresponds to the hash of the public key of the transaction that will succeed it in the chain.
  • type : A type defining the functional role of the pending transaction.
  • timestamp: The date and time of the transaction generation.
  • DATA : Data zone containing all the operations to be performed (operation on one of the registers, programmed tasks, smart-contracts, operations on an identity, etc.)
  • Prev-PubKey : The public key associated with the previous transaction (the address of the previous transaction being the hash of this public key)
  • PrevKey Sig : Signature from the private key associated with the mentioned public key to prove the possession of the private key, the chaining of transactions and the content of the transaction (address, type, timestamp and data area “DATA”).
  • OriginKey Sig : Signature from the private key associated with the device or software from which the pending transaction was generated. This signature is used for the proof of work of the nodes.
Each transaction also has an additional signature (Figure 1.2) corresponding to the signature of the device that generated the transaction. This signature is used inside the Proof of Work mechanism and can be integrated as a necessary condition for the validation of a transaction (for example, in the context of an electronic vote, this will ensure that a person’s biometric identity is generated only through a recognized device).

Validated Transaction is when a pending transaction is completed with the validation proofs required by the Heuristic Algorithms. These validation proofs are defined as follows:

Validated Transaction

Validation Stamp is the stamp generated by the elected coordinator node and containing

  • Proof of integrity: proving the linkage of the previous transactions
  • PoW: result of the Proof of Work
  • Ledgers Operations: contains all the ledger operations that will be taken into account by the network:
    – the ledger movements mentioned in the pending transaction DATA/Ledgers along with the issuer’s signature.
    – the list of unspent transaction outputs (UTXO) of the sender’s chain on the address of the new transaction.
    – the ledger movements to the nodes that participated in the validation and retrieval of the data (effective payment of the welcome, coordinator, cross-validation nodes and nodes from which the data were downloaded) DATA/Ledgers/Fee – the fees can be mentioned explicitly or not mentioned (if not, the costs will be calculated by the coordinator node).
  • Cryptographic signature of the Validation Stamp of the coordinating node, the public key being already mentioned in the list of beneficiaries of the fees.
  • Cross Validation Stamps To be considered as valid, the Validation Stamp must be joined by as many Cross Validation Stamps as required by the Heuristics Algorithms. Cross Validation Stamps are the signatures of the Validation Stamp by each of the cross-validation nodes (in case of inconsistency or disagreement it will contain the list of inconsistencies noted, all signed by the cross validation node).


Whenever a transaction is created, it is validated by the ARCH Consensus mechanism and added to the Transaction Chain of the respective identity who sent the transaction. The overall flow of the Transaction is shown below

Overall flow of the Transaction