How Tagion works: step-by-step
Written by Decard - the initial stewardship company of the Tagion platform.
This is an advanced draft (last edit June 3rd 2025), final improvements of details and descriptions are pending. Once complete, this message will be removed.
All technical terms will here be written in italics. Some of them are explained at the beginning, some first appear "in inverted commas" in the text and are explained there.
If not mentioned specifically, links in the text go to the technical documentation pages of the Tagion project. There, full technical details and codes are provided but - in contrast to this introductory text - a high level of technical understanding is assumed.
There is also a complementary Glossary for terms which are here not touched upon.
Up first: a bit of terminology
User: anybody making use of Tagion software, without being a node operator
Node: instance of main Tagion software (for Tagion Mainnet and Subsystems). Several nodes can run on one computer, but in a "distributed" system they will be on different computers connected via the internet
Subsystem: a bespoke network of nodes for a particular use-case, independent of the Tagion Mainnet in terms of rules and settings. It hosts its own database and sends regular hashed/encrypted status updates to the Mainnet (for validation and notary functions, further explained below). Because of this, Subsystems are here called "federated" with the Tagion Mainnet.
Database: structured system to store, manage and retrieve data. Akin to a filing cabinet with labeled drawers - rather than the records in those drawers.
"DART" is the name of Tagion's custom-designed database system (further explained below) maintained in/by the Tagion node software
App: user-interface to make changes to the database, it sends info about intended changes to a node
Transaction: unit of database-changes (add, edit, delete), including but not limited to currency related transactions
... that much said, we now have enough words to begin ...
Starting from a general use-case
A user (see above) wants to enter some new pieces of information to the system. Let's assume that this information is about a particular use-case for which a federate Subsystem (see above) has been set up.
The user submits the information via an app (see above), e.g. on their mobile phone. This information can be new (it will be added to the database - see above), or it can be a change to (or deletion of) existing data. Along with the information itself, the user submits their electronic signature which will be linked to submitted information as a way to manage and authenticate access rights to the data.
The app they use for this is built upon - and sometimes still called - a "wallet application", a term inherited from the Tagion Mainnet with its principle use-cases centered around financial transactions ("JustPay" is such a wallet application, more information about it on the Decard website). The application packages the information to be entered into the database. Next to the basic data-input and additional required information (timestamp, user identity, references to other data, required permissions) this might also contain conditional instructions for the node to "execute". This is why the whole information package is here called a (smart) "contract" -a term inherited from "blockchain" and "DLT" concepts, which will be explained below.
These contracts are sent to a node (see above, or here for all details) via the internet or local communication networks. To enable swift transmission under most bandwidth conditions, contracts are structured/written according to our custom "HiRPC" communication format, which in turn is based on our general data format called "HiBON". We felt compelled to design those new formats to achieve the highest level of security and flexibility for control of data at the record level. At the same time, these formats allow for the utmost efficiency in terms of storage and computing requirements for the network.
Distribution: from one node to many
The receiving node checks the information sent in the contract against the information already existing in its locally stored database (e.g. if user identities and permissions are valid and other data is referenced correctly). Results are preliminarily stored in the memory of the node's "virtual machine" - the computation and execution software interpreting the operations specified in a contract. The Tagion Virtual Machine (TVM) is built on the popular open WebAssembly standard. Since those operations can be much more complex than simply "add this information to the database", contracts in such advanced distributed systems are called "smart", which sometimes also implies "self-executing".
However, for the moment none of the results of executing a contract is committed to the database. Because in a "distributed" system without central control, all nodes need to make sure they maintain their individual copies of the database in accurate synchronisation and don't make changes to it without coordination. Thus, the nodes will first notify other nodes in the network about the receipt of any new contract and their contents.
This continuous communication between nodes does not only concern contracts they received individually, but also contracts submitted to other nodes which they consequently heard about. This propagation of information is here called "gossip about gossip". And in this way, all nodes will eventually know of all recent submissions to the whole network - at least up to a certain point in the (not-so-distant) past.
For everything before that point, a network-wide agreement about a correct and complete new version of the database will have been reached, thanks to the gossiping between nodes. For distributed systems, this is called reaching "consensus", and the time-span from one moment of consensus to the next is called an "epoch". Now, only for contracts submitted within a concluded epoch will nodes in the Tagino network commit the new information to their database(s). Submissions which at this moment have not been shared across the whole network yet will be dealt with in the next epoch.
This way the information in the network is synchronised up to the recent moment of consensus, and the resulting shared version of all individual database(s) is called the "state" of the network (as in "state of play" or "the current situation").
How consensus on the state of the network is achieved is different from one distributed network to the next. So called "blockchains" offered the first popular solution for consensus without a central authority. And when the practical limitations of blockchains became obvious and new solutions were sought, the collective term "DLTs" was introduced - which stands for "distributed ledger technologies" . The "ledger" part of that term was again inherited from the early use-cases of DLTs in currency transactions and accounting.
Tagion, as a network of distributed databases, has utility far beyond ledger based accounting. But to understand the concept and implementation of its consensus mechanism it remains useful to consider its heritage.
Consensus: how nodes know what other know
Common to all consensus mechanisms is that nodes constantly communicate with each other about how their local versions of their shared database have evolved or should evolve. The scenario in which some nodes fail to do so (be it deliberate/maliciously, or because of lost connectivity), is described as the so-called "Byzantine Generals Problem". Consequently, DLTs that solve that problem and can deal with a certain number of divergent nodes are called "byzantine fault tolerant".
For Decard's platform two innovative "protocols" (meaning sets of rules about the communication between different software entities) enable a fast, secure, reliable consensus (which is also most efficient in terms of required storage capacity, internet bandwidth and energy consumption). This consensus is highly byzantine fault tolerant, as it still functions with up to 1/3 of all nodes being out of sync or not playing by the rules.
The first of those two protocols, developed and patented by Decard, is called the "Wavefront" protocol and it manages the gossip-about-gossip as introduced above. It swiftly conveys how many new contracts each of the two nodes have received (directly or indirectly) since the last epoch, and then enables them to efficiently synchronise their local knowledge. This includes contracts/transactions that were submitted to the communicating nodes since the last epoch, but also the contracts/transactions submitted to other nodes which either of the communicating nodes has already heard about.
The second protocol then establishes consensus not by comparing the databases themselves (or counting the number of blocks in a chain) but by tracking the level of shared knowledge that nodes have communicated about in the wavefront protocol. This consensus protocol was originally developed by Leemon Baird (co-founder of the "Hedera" project), under the now well established term "Hashgraph consensus algorithm".
Together, the two protocols ensure that the communication between nodes relates directly to the state of their shared database. From the network-wide communication history, each node can reconstruct by and for itself, and with mathematical certainty, what other nodes in the network know. Once information about new contracts/transactions (since the last epoch) has spread to enough nodes in the network (namely to 2/3+1 of all nodes), consensus about those contracts is established and the database is updated up to that point.
DART: Smarter than blockchains
Everything before that recent epoch is then fixed in the database and no competing versions (in blockchain systems those are called "forks") can occur. That is what is called "finality" in DLTs and while traditionally blockchains rely on "probabilistic finality" (because there is always a slight chance that a fork can gain consensus), Tagion features the absolute certainty called "deterministic finality".
Again, this finality concerns the consensus about the database, not the information in the database itself. As explained at the beginning, a given contract can stipulate the change or deletion of existing data - as long as all nodes in the network agree upon the validity (permissions and credentials granted) of the contract and reach consensus about the resulting state of the amended database.
Another effect of the way Tagion achieves consensus is that the order of changes to the database is determined by the time in which most nodes have received knowledge about contracts affecting that change. We call this "fair ordering", as it cannot be manipulated by individual node operators or distorted by the amount of fees offered by users (as in many popular blockchain systems).
As a last step, each node calculates a signet of the complete new version of their database. These signets are mathematical fingerprints (called "hashes") of the database. For Decard's specially designed database called "DART" (which stands for "Distributed Archive of Random Transactions"), this fingerprint is called the "bullseye" (of the DART-board). And thanks to the patented architecture of the DART database, the calculation, sharing and storage of a bullseye requires only minimal computing resources. Comparing the bullseyes of a given epoch across the network will quickly flag up nodes that had fallen out of sync. For a Subsystem the bullseyes are of additional importance because they get submitted to the Tagion Mainnet where they are recorded to form a continuous audit trail of the Subsystem's accurate operation.
Tagion: best of two worlds
Talking about accountability: another unique design feature of the DART database is that all entries and edits have an "owner", typically the user specified in the contract that created the data entry. Access rights to each data point can be managed like the file permissions in a conventional computer system (e.g. read, write, own). In this regard, rules concerning privacy, anonymity and security can be determined individually for each (type of) entry, or for each Subsystem database, depending on its particular use-case. Only for contracts/transactions of "TGN", the native utility token on the Tagion Mainnet, the rules are fixed: the amounts of the transactions are revealed, along with the identifiers of the payer and payee. But their actual identities are protected because, different from most blockchains, only the resulting balances of a transaction/contract are stored in the new state of the database, not the contracts with the actors' information themselves.
In a Subsystem, the actors can be made visible (only to the participants of that Subsystem or more widely), while the content kept in the Subsystem's own database can be protected as appropriate for the use-case or industry. The level of data-protection available can be configured to be compliant with any privacy and data-protection regulation or even up to government agency levels of classification - including but not limited to access-control, authentication and sharing services, and multi-signature requirements.
Each Subsystem thus benefits from having its own distributed database, shared and synchronized across a freely defined set of participants (e.g in a "permissioned" network) while also freely determining its own rules and governance as needed. The only mandatory information shared with the Tagion Mainnet is the regularly calculated bullseye-signet.
This is why the Mainnet is said to fulfill the function of a "public notary" to its federated Subsystems. But public here goes beyond any nation state's public institutions and power. The governance rules and protocols being developed for the Tagion Mainnet make it "decentralised", meaning no entity owns or controls the network and anybody can participate. This is achieved by our "proof of community" requirements for becoming a node operator on the Mainnet, and the randomised rotation of validator nodes that participated in the hashgraph consensus. Thus, the trust and reliability provided by the Tagion platform extends beyond the classical boundaries between public and private, or nation states and industries.
This move away from central authority to an infrastructure that is run and governed by its users and stakeholders had been one of the impulses for the development of blockchain technologies. However, the particular way in which DLTs manage data and achieve consensus has been riddled with inefficiencies from the beginning. No DLT solution has achieved scalability without compromising on security or decentralization. This is why Tagion as a database system that functions in a distributed manner and designed to be decentralized is such a novelty.
Built from the ground up with efficiency as its foundational design principle, it achieves the speed, safety and energy efficiencies of traditional server based databases - while staying true to the promises of DLTs and providing the cooperative data infrastructure needed for multi-stakeholder industries and use-cases.
If you are now inspired to deploy Tagion for your business, project or community but do not have the expertise to set-up a node and Subsystem for yourself, contact Decard: the stewardship entity to drive the development and adoption of Tagion.