Tixl Whitepaper

Legal Disclaimer

The Whitepaper and the information contained within both this document and the website in no way constitutes, nor implies, a prospectus of any kind. No wording contained herein should be construed as a solicitation for investment and this document does not constitute, in any way, an offering of securities in any jurisdiction worldwide whatsoever.The content is for information purposes only, you should not construe any such information or other material as legal, tax, investment, financial, or any other advice.Please note that the information in this Whitepaper may be changed or updated without notice, at any time.


This document describes the process of how the Tixl ecosystem and its products have been built, launched and developed over time.

What is Tixl

Backed by well-known investors, the German Tixl Organization consists of an experienced team currently building the interoperable Tixl Ecosystem for Decentralized Finance (DeFi) and any other type of transaction.Our vision is to have all tokens on a single, high-performance network - for a new era of DeFi, payment and banking.At the core of Tixl's ecosystem is the interoperable layer 1 Autobahn network with instant & minimal-fee-transactions for any transfer of data, not just digital assets or tokens. Its business model is based on its token TXL.The first chains integrated are BTC and ERC20, integrated as pegged tokens. The decentralized Custody is done via Threshold Signatures. On the Autobahn, everything is interoperable between the Mainnets.Developers will be able to create interoperable dApps and Smart Contracts that can be called from any connected platform, i.e. Bitcoin, Ethereum, BSC or Polkadot. E.g. for NFTs, Voting & Election, Gaming, etc.If Tixl had cross-chain liquidity pools for its interoperable Autobahn Network, integrated in DEXs, users would be able to swap tokens in a decentralized way with super-low fees. Once interoperable Smart Contracts & dApps for Tixl’s low-fee, instant transaction Autobahn Network are live, smart payment solutions can be offered, from PoS Payments using NFC, Metamask integration to Auto-Swap into (Fiat) Stablecoins.

The Motivation for Developing a new DeFi Ecosystem

You’ve probably noticed that DeFi is having some problems right now. The scalability of Ethereum has been leaving people stuck and looking for alternatives. Paired with interoperability, this is exactly what Tixl is aiming to fix.
The Autobahn Network is Tixl’s proprietary and interoperable network (open-sourced soon) which is designed to provide instant transactions with negligible fees (and the ability for authorized service providers to send private transactions if the regulator allows that in the future). These features could have huge benefits on the current DeFi ecosystem.
Tixl’s Autobahn Network will have a SDK which DeFi products can use to easily access the Autobahn Network and the advantages it provides. This means that any protocol will be able to tap into the network and significantly improve its service level.

The deflationary Tixl Token (TXL) and its business model

The supply of TXL is limited and pre-mined and had a maximum supply of 900,000,000 (900 million TXL). This number is reduced over time as a result of token-burns. The first token burns happened already bringing the current total supply to 600,000,000 TXL.The business model for Tixl's Autobahn Network is based on its Tixl Token TXL. It is used for covering transaction & trading fees, as a utility in our partner's data platform Tixl Finance and in any other own or 3rd party product.Fiat revenues collected from partner projects (Tixl Finance or the Social Mining Club) will be utilized for buy-backs or token burns.
During the development of the Tixl ecosystem, the token is mainly used for fundraising and marketing purposes. The Tixl token will ultimately exist solely on Ethereum and TXL is already available on the Ethereum blockchain. The smart contract for TXL can be viewed on Etherscan. The Autobahn Network will support the ERC-20 TXL token as the native token and allow its transfer with no fees.
Part of the TXL supply (including the Founders Tokens) will be time-locked. The ratio has yet to be finalized, but there will never be more than 600,000,000 TXL in total (before further token burns).

Product Overview

The Tixl project has been creating an ecosystem for applications in the space of DeFi and beyond. That means multiple projects can be built on top. The following sub-chapters give an overview of our core and add-on products.

The Autobahn Network

The Autobahn Network serves as the core layer of the Tixl ecosystem. It is a layer 1 network with integrated layer 2 capabilities. It was named after the German Autobahn due to the speed that elements (cars) or transactions, respectively, can move along it.In other networks, transactions are either expensive, slow or not interoperable. Tixl’s Autobahn solves all of those pain points. It is built as a special Directed, Acyclical Graph (DAG) working with the Stellar Consensus Protocol (SCP):A unique feature of the Autobahn Network is that it supports bridging assets from other chains - such as BTC, ETH, ERC-20 or any other tokens of connected networks - into the Network. These other assets can be transferred into the Autobahn Network and are treated like pegged assets. More details about this implementation can be found in the technology chapter.Most cryptocurrencies in general, and especially BTC and ETH, cannot be sent back and forth efficiently. Transactions are either slow, expensive and/or not interoperable. Solutions like the Bitcoin Lightning Network have not yet gained traction due to weaknesses in their conceptual and technical design. On Ethereum, Gas Fees can rise sharply.By employing the most sophisticated technologies that have emerged from the blockchain world over recent years, the German-engineered Autobahn Network has been designed from the ground up to specifically address these current challenges. Users of a digital asset want to swap to any other token independent of the originating chain and pay the lowest transaction fees possible - the higher the fee, the lower the potential for widespread adoption. Plus, if a future digital asset is slow in terms of transaction speed, it is not a future asset.

Interoperable Smart Contracts & dApps

Having a scalable Autobahn Network technology is the base. Adoption, however, is only coming through opening up the technology to developers who can build dApps on top of it. That’s why we are currently working on offering fully interoperable Smart Contracts.The interoperable dApps & Smart Contracts can be called from any connected platform (i.e. Bitcoin, Ethereum, BSC or Polkadot). Example use cases can be found in all areas: DeFi, NFTs, Voting & Election, Gaming, etc.

Tixl Wallet

Apart from in the interoperable Smart Contracts offered to third party developers, a usable wallet is an efficient and effective way to increase adoption of Tixl, and the use of the Autobahn Network. That’s why we built a Tixl Wallet ourselves.The Tixl wallet is available in the form of both a web and mobile browser wallet. A native application for iOS and Android is already in development. Users of the Tixl Wallet benefit from zero fees for TXL transactions and low fees for transactions using other assets on the Autobahn Network.Once people have the wallet loaded on their devices there are a number of enhancements that can easily be rolled out. Every wallet user becomes a potential advocate of the system simply by experiencing (and sharing) the benefits of Bitcoin and other tokens in the fast lane.



Tixl raises funds by way of token sales. Over the course of an Initial Coin Offering (ICO) conducted in 2019, the Tixl organization sold tokens in the amount of USD 1,350,000 to raise capital. Following the ICO, the Tixl team switched to the sale of tokens through OTC deals -where investors could purchase higher amounts of tokens in combination with lockup periods.
Some projects state they do not conduct ICO’s and claim this as a strength compared to other projects. This, in most cases, does not make sense as these same projects actively sell tokens through exchanges and offer them on the regular order books. In effect, this is similar to carrying out an ICO.

Why have further Token Sales been carried out?

Funding for the running costs of the Tixl organization is currently generated by issuing TXL through token sales.These can be OTC trades or public market sales.Public market sales will only be considered during periods of high market activity/high sales volumes to ensure they do not adversely affect the price.The development of Tixl is laborious. A software development team is needed to implement the Tixl ledger and other parts of the technology in a step by step process.Apart from development, accounting, legal, tax and security audit costs, here’s a list of example costs the Tixl Organization currently needs to cover:1. Exchange Listings.Along with the combined developments, marketing and admin costs, there is the (often large) cost to list on an exchange (only a few exchanges accept Tixl without a financial contribution, or in exchange for an amount of TXL itself). We are working hard that Tixl will be accepted more and more as a cryptocurrency and that Tixl will be offered by major exchanges. Unfortunately, just listing on the tier 1 exchanges for free is not possible - as this frequently requires payments of six to seven-figure sums for listings and we rather have the best products with the best marketing and that listings will come automatically over time.2. Node Hosting.The hosting of Tixl nodes will be decentralized over time. However, in the early days, the Tixl organization will have to provide nodes and must bear the corresponding monthly costs for computing infrastructure.3. Marketing.Tixl can only succeed if as many people as possible use the Tixl Autobahn Network. There will be a number of marketing campaigns to achieve this. Here we face the same challenges as with exchange listings - for some marketing campaigns e.g., influencers or B2B partnerships, TXL may be issued as payment, but others will require payments in BTC, USD, EUR or other currencies.

How do the Tixl Tokenomics look like?

The maximum number of TXL was 900,000,000 (900 million) before token burns (for the current amount, please see below). The initial total supply was also set to 900,000,000 TXL. The model is deflationary. After the first token burns, the total supply is currently decreased to 600,000,000 TXL. In addition to the maximum and total supply, we also have to take a look at the circulating supply. Let’s first look at the definitions:

Maximum supply

The maximum supply of TXL ever in circulation.

Circulating Supply

The circulating supply can be defined as all tokens that are in hands of investors/holders and are free to transfer and trade. For example, tokens that are locked in smart contracts or are kept in the cold wallets of the Tixl organization do not belong to the circulating supply.

Total supply

The total supply can be defined as the maximum supply less the tokens which have been permanently burned.
So what do the exact numbers look like for Tixl? TXL currently has a circulating supply of {{circulatingSupply}} TXL and a total supply of {{totalSupply}} TXL. Of this circulating supply, {{hodlersClubTokens}} TXL are assigned to a staking program called Tixl Hodlers Club. In this staking program, tokens are not locked by smart contracts but instead, if a hodler has moved tokens from his address, they will be removed from the staking program. The staking program ends on the 13th of October 2022. If all holders in this program would keep their tokens until the end date, that would result in {{hodlersClubTokensReward}} TXL joining circulation.
The following pie chart shows further details about the circulating supply and which tokens are assigned to which slices:

Tokenomics Pie Chart

The following pie chart shows the detailed TXL tokenomics. Use the dropdown to switch between different modes:

Loading Tokenomics...

Organizational Form

Tixl is a company of elbstack GmbH, meaning the Tixl gGmbH can utilise the services of the elbstack GmbH when needed. In the past, various team members of elbstack have assisted Tixl with feedback, code reviews and design improvements.


The core team behind the Tixl project have already enjoyed success in related fields. As Managing Directors, Christian Eichinger and Sebastian Gronewold bring with them the experience gained in forming and running a successful software development and design company. Bernd Strehl as CTO and Dr. Max Muelke as CMO complete the Executive Team and, between them, they have real-world experience combined with Masters level qualifications in Software Engineering Leadership, Information Systems, Finance, Product and Marketing.The Executive team is complemented by a range of talented Product Designers, Consultants, Engineers and Community Support Managers.In addition, the team is supported by a distinguished Board of Technical Advisors - all respected in their fields. As the project has continued to grow it has welcomed further personnel in the form of Market and Marketing experts to help drive Tixl to even greater heights.Below you can find links to further details about the team.

Founder Tokens

The founders are dedicated to the long-term performance of Tixl and are heavily invested in its success. Their remuneration/investment is wholly by way of holdings in Tixl. All of the TXL owned by the founders have a lock-up period of 24 months. After the lock-up period, these TXL will be released for a potential sale, in instalments, from June 2021. From this date, the founders will be limited to selling just 1% of their token supply each month. The final 1% will not be unlocked until September 2029.

Legal Form

When choosing a suitable legal form, many factors were taken into consideration. The most important goal was ensuring the long-term decentralization and independence of the Tixl token to separate it from individual interests. To achieve this, Tixl was founded as a German non-profit limited liability company - the Tixl gGmbH. A transfer to a foundation in the future is conceivable, but not mandatory.
Further to this, a German non-profit company was chosen to ensure that Tixl is recognized as a fully legitimate project. A more detailed explanation for choosing this company type can be found on the Tixl Medium blog.

Trademark and Patent Rights

The term Tixl is already registered as a wordmark. The trademark application is designed to prevent competing products from using (or misusing) the name Tixl for their own purposes.There are currently no patent registrations. However, patent filings are not ruled out in the future. The basis for a patent could be, for example, specific concepts in cryptography that distinguish Tixl from established digital assets. Importantly for Tixl investors, patents protect as they prevent cloning of the Tixl system.The Tixl team recognizes the problem of centralized patents management and will therefore work on a solution during, or after, the full launch of the Tixl ecosystem.

Technical Solution of the Autobahn Network

The technical solution is one of the main factors which provides superiority over other existing digital asset platforms. A combination of different approaches puts the Autobahn Network in this position. The most important components are the data structure, technology enabling the second layer, and its chosen consensus algorithm.

General overview

Following, we will present the concepts of the Autobahn Network. First in a general and then comprehensive way and in the following sub-chapters the building blocks are described in more detail.

Important Definitions

The following definitions are used often in this whitepaper and other articles about the Tixl ecosystem:
Autobahn Network
The Autobahn Network is defined as all nodes participating in the Consensus mechanism.
The term Testnet refers to all test releases of the software run by a distinct set of Autobahn Network test nodes.
The term Mainnet refers to all releases of the software run by a distinct set of Autobahn Network production nodes.
The Autobahn Network releases are named after the districts of Hamburg, the hometown of the Tixl project.

Data Structure Overview

Tixl uses a Directed Acyclic Graph (DAG), as opposed to a single blockchain. The chains are built differently depending on whether the use is for private or non-private transactions (we need to see whether we can use the “privacy” feature; depends on regulation). The first block of the chain for non-private transactions is called public root, it is an open block. After this block, only asset blocks are written on this chain. Each asset block represents the root of a branched chain that contains the send and receive blocks for a different asset.
More information about the data structure in the dedicated chapter about the Autobahn Network’s Data Structure.


The most important piece of the architecture are the validator nodes or validators. They store the transactions in instances of the ledger, validate transactions, and determine the global state of the Autobahn Network ledger using the Stellar Consensus Protocol (SCP). All running instances of validators will be called the validator network.
A transaction that, for example, is generated by the wallet software, is sent to the gateway and the gateway broadcasts this transaction to all known validator nodes. If the transaction is valid, all validators should vote to include it in the next slot whereas a slot is defined as a round of the consensus protocol. Invalid transactions should be rejected by all correct validators. If one validator is approving invalid transactions, regardless of this happening out of malicious intent or due to a program error, the whole network should still reject the transaction because no quorum for the invalid transaction is reached.
SCP makes use of a concept called quorum slices. Each validator that runs SCP, which can be any person or organisation, can define which sets of other validators it deems sufficient to be convinced by a statement. This implicitly leads to a ranking of trust in validators. Validators that are run by trustful organisations and don’t vote for invalid transactions will gain trust, over time, by being included in the quorum slices of evermore other validators. Opposingly, those validators that vote for invalid transactions will be considered untrustworthy.

Transaction lifecycle

wants to send 10 TXL to
- the full lifecycle from creation to network acceptance would look as follows:
How do transactions work?
has an asset block for the asset
on this branched chain. At least one receive block must be present to provide the value for the transaction.
creates a send block which contains the amount (the new balance after subtracting the value), the address of the receiver (as destination), the reference to the previous block and its signature. The send block is then sent to the validator network where it will be approved by the validators and stored into their ledgers.
can now create a receive block on a branched chain for the asset
and reference the send block that was created by
. Once the block has been confirmed by the validators the transfer of funds is complete.

Data Structure

The data structure is an essential basis for the Autobahn Network to achieve the desired properties, particularly the high transaction speed.

Which Data Structure does the Autobahn Network use to Persist Transactions?

The Autobahn Network ledger is a special implementation of a Directed Acyclic Graph (DAG). The specific implementation is similar to the block-lattice architecture of Nano. A special feature here is that every user has their own blockchain and only the owner of a blockchain can write new blocks. In the case of private transactions, the user may even have multiple blockchains (Stealthchains). See the graphic below for a visual representation of how the chains are formed.
The graphic shows the accounts for User A and User B. Both accounts start with the account OPEN block. For each different asset (e.g. BTC, ETH, Tixl) an asset block is created, which marks the beginning of a branched-chain, that contains all receive and send transactions for that asset type. The black arrows denote the DAG structure (block reference). Send blocks additionally contain the address of the receiver (blue arrow to OPEN of User A), and receive blocks reference the send block that provides the value (blue arrow from RECV of User A to SEND of User B).The graphic below shows the account for one user, it starts at the OPEN ACCOUNT block. For every asset and for each correspondence with a different address a stealth chain is created (denoted by the OPEN block with the blue lock). To manage all these stealth chains, for each of them an OPEN block containing the keys (encrypted) will be created on the Account chain (Blue dotted arrow shows the relation). The black arrows denote the blockchain structure (block references).

Block Structure

The information that a block contains is different for private and non-private transactions. Non-private blocks are much simpler, and use less disk space, than private ones.Send and receive blocks for non-private transactions contain the following data, of which none is encrypted:The asset is implicitly determined by the branch opened with an asset block.
The metadata contains data relevant to the block. These include a reference to the previous block, the block type and the asset symbol (e.g. TXL or BTC).


The Autobahn Network’s data structure is a good prerequisite for scalability. In terms of the required storage space for the full ledger, the Autobahn Network scales similar to Bitcoin, and other networks, except that it has encryption overhead for private transactions (if the privacy add-on can be utilized; depending on regulation). Regarding transaction speed - the data structure itself supports instant transactions because only senders and receivers are involved instead of the whole network.

Is a Tixl Transaction Instant?

Essentially, the Autobahn Network’s data structure allows instant transactions. Senders and receivers can write transactions on their blockchains without having to wait for other transactions on the network. Nano also advertises these Instant Transactions. However, it should be noted that a recipient must be online if a transaction is to be written to the recipient’s blockchain immediately after submission.In practice, however, more aspects must be considered. As a TXL receiver, one cannot always rely on a TXL transmitter not being an attacker trying to manipulate the system. Consequently, as a TXL receiver, one needs a decentralized validation system whereby one can ask if a transaction is correct. This validation takes time because the decentralized entity must decide on a consensus relevant to the validity of a transaction. Even if this executes within a few seconds, the Autobahn Network envisions additional mechanisms of trust to further accelerate transactions.Transaction speed can generally be traded for trust, this results in multiple theoretical levels of transaction speed and trust:
Peer to peer transaction
A transaction can be directly sent from peer to peer and the receiver validates the transaction and accepts it. The acceptance of the transaction happens asynchronously to the sending of the transaction to the validator network. This peer to peer transaction type is especially suited for payments without direct exchanges of real-world goods, for example, a friend paying back the money for lunch he/she laid out. The estimated speed for this type of transaction is below 500ms.
Single stop validation
The sender can send a transaction to a single validator and the receiver confirms the transaction when the validator deems the transaction valid before it is confirmed by the full validator network. This method is relatively secure especially when the validator is highly trusted by the receiver. A good usage scenario is a point of sale transaction of a retailer. The retailer could run its own validator and the payer sends the transaction to that validator. If it’s considered valid by the validator the transaction can be accepted by the retailer because it is very unlikely that the validator network will reject it.
The estimated speed for this type of transaction is below 1s.
Full validation (No Trust - Medium Speed Transaction)
The transaction is sent to the validator network and is only accepted when the validator network confirms the transaction. When the transaction is confirmed by the validator network it can not be revoked, so there is no need for trust between the payer and the payee. This is the standard mode of any transaction and should be used in most cases. The estimated speed for this type of transaction is 5-10s.


The Autobahn Network consensus algorithm holds decentralized voting on transactions to always make sure only valid transactions are included and all participants of the consensus algorithm will confirm the same transactions.

What are Autobahn Network Nodes?

An Autobahn Network node, validator node or short validator is a computer running the Autobahn Network server software. Since the Autobahn Network server software will be available as open-source in the mid-term, a node can be executed by any natural or legal person without permission. Together all nodes form the Autobahn Network or validator network.Nodes are needed to perform transactions in general. They save the history of all Autobahn Network transactions in the ledger and thus make payments and other features possible. Otherwise, transactions would only be stored on the sender and receiver devices and would be lost if these devices were lost.An additional essential task of the nodes is the validation of transactions. A transaction may only be written into the global transaction ledger if it is valid. A transaction may be invalid due to software errors (e.g. in a wallet app) or sent by malicious users in the network. In this case, the transaction will be rejected by the validator network.

How do Tixl Nodes Reach Consensus?

Many of the existing consensus algorithms, like Proof of Work (PoW) or Proof of Stake (PoS), are not suitable for use within Autobahn Network. Proof of Work uses too much energy and is too slow. Proof of Stake makes no sense without having inflation or rather high transaction fees. So instead the Autobahn Network nodes reach consensus by utilizing the Stellar Consensus Protocol (SCP).
SCP is ”a federated Byzantine agreement system that allows decentralized, leaderless computing networks efficiently to reach a consensus outcome on some decision” ( Bob Clickstein ). An explanation is given in the following sub-chapters starting with the root issue, the Byzantine generals problem, as a result of which SCP was created.
The Byzantine Generals Problem & Byzantine Agreement
The name of the Byzantine generals problem comes from a paper from 1982, written by Leslie Lamport. Together with two co-authors, Lamport described the following allegory for the problem of decentralized decision making: The night before a possible battle, a group of Byzantine generals tried to decide whether to attack together or retreat. Messengers exchange the messages between the generals. Now there is a problem: Some of the generals, and also the messengers, could be traitors. These traitors would be interested in sabotaging the generals’ plans. Accordingly, the loyal generals must find a way to reach consensus.
If the Byzantine generals problem is now transferred to a network of servers that should agree on the validity of transactions, the servers can be defined as Byzantine nodes. Finding consensus within a group of Byzantine nodes can be defined as Byzantine agreement.
Federated Byzantine Agreement (FBA)
Federated Byzantine agreement (FBA) expands the traditional Byzantine Agreement by open membership, meaning that the participants can change. Majority based Byzantine agreement systems are vulnerable to so-called Sybil attacks. That is an attack where the attacker tries to control a peer network by creating or stealing a large number of fake identities. The goal of this attack can be, for example, to sabotage majority decisions. The idea of FBA is to defeat those attacks by introducing decentralized quorum selections. SCP is a certain kind of FBA system.
Stellar Consensus Protocol (SCP)
David Mazières introduced SCP in a whitepaper in 2015. Even though SCP is not tied to financial transactions, this explanation uses financial transactions as an example as they are most relevant for the Autobahn Network.
SCP uses federated voting to discover whether a network of (Byzantine) nodes can agree on a set of transactions. In a round of federated voting, each node must accept one or more possibly valid transactions as an outcome of that round. It can only do so if it’s sure that other nodes in the network will not accept different transactions. That can be ensured by exchanging different types of messages with other nodes in the network. But what does “other nodes in the network” actually mean? To understand that, two main terms of SCP are introduced: Quorum slices and quorums.
Each node
selects its own quorum slices
, which are sets of other nodes. Each of these sets is sufficient to convince
of a statement if all nodes of the slice agree. A quorum slice must also contain the node
itself. As by definition of SCP ”a quorum slice represents a large or important enough set of peers that the node selecting the quorum slice believes the slice collectively speaks for the whole network” (
David Mazières ).
A quorum can be defined as a non-empty set of nodes containing at least one quorum slice of each of its members. For example, given the nodes
have the following quorum slices
S(n1) = {{n1,n2,n3}}
S(n2) = {{n2,n3,n4}}
S(n3) = {{n2,n3,n4}}
S(n4) = {{n2,n3,n4}}
Note, that this is a set of sets, which means that each node can have multiple quorum slices.In this case
would form a quorum because it contains a quorum slice for each of its members. If a quorum also containing
should be formed, this would have to include all nodes
, because
will not agree on a statement without
agreeing as well.
Back to the federated voting and to an example: Given one payment transaction is sent to a network of nodes and those nodes want to find agreement on whether this transaction will be included or not. Now, a node receiving the transaction, that was elected as a leader for the slot (one round of the consensus algorithm), begins by casting a vote for the transaction to be included. It broadcasts the vote itself, its quorum slices and also its identifier within one message to the network. A node receiving broadcasted messages from other nodes can traverse the quorum slices. If it finds a quorum of nodes that vote for the same outcome, it can now accept that outcome and broadcast this information to the network as well. To finish the federated voting process for one transaction, a node must wait for a quorum of nodes to all accept it and can then confirmthe outcome.
Some situations can arise where it is not immediately possible to find a quorum for a decision. In order to be able to perform federated voting nevertheless, the network must fulfill the quorum intersection property. In a network which fulfills this property, any two quorums overlap in at least one node. This property and some other edge cases are explained in detail in the SCP whitepaper. Furthermore, the Autobahn Network consensus algorithm, based on SCP, will be made available open-source, so code examples for handling such cases will follow.

Does every Autobahn Network Node need to know All Transactions?

An Autobahn Network node can be operated with different configurations. Either a node stores the whole ledger (historical node) or a pruned history that contains only the necessary information to validate transactions (light node).The reason for having two different types of nodes lies in the massive storage requirements as the number of transactions increase. For example, if the consumption for one transaction were 1 kilobyte, the entire ledger would be 100 gigabytes with 100 million transactions.

How are Autobahn Network Nodes Incentivised?

The node incentivisation differs for two types of transactions: TXL transactions and transactions with other (pegged) assets on the Tixl network.
TXL transactions will not attract any fees, so nodes will not get a direct reward for processing TXL transactions. However, every investor who has a stake in TXL - and every organization/project making use of the Autobahn Network - should be interested in running an Autobahn Network node. This concept is not unusual, and it is already applied by Stellar.
Whereas TXL transactions are free of charge for Autobahn Network users, transactions using other assets will cost the user a small fee. The fee can be paid in the asset transferred but will then, indirectly, be transferred into TXL and paid to the validators. The exact algorithm of fee distribution will be defined with the Mainnet launch.In addition to the network fees, the Tixl organization has reserved 10% of the total token supply (90,000,000 TXL) for node hosters. These tokens will be distributed as rewards for very early hosters and initial setup partners of the network. The reserve is designed to last for several years (and possibly decades) to help ensure there is not a build-up of sell pressure for node hosters.

Will Tixl be 100% Decentralized from the Start?

Tixl’s primary focus is on usability, widespread usage and protection of investors. To achieve these goals the system does not have to be completely decentralized from the very beginning. In no way do we want to diminish the importance of decentralization with this approach. However, achieving key goals is more crucial to the project than decentralizing right from the initial launch. It remains one of Tixl’s top priorities to become a 100% decentralized digital asset as soon as possible.


As SCP is known to establish consensus within a few seconds, even if there are some conflicting transactions, nodes will still be able to reach consensus quickly. It is also known that SCP can deal with high transaction volumes. Although there is no verified statement from the Stellar Foundation, there are rumors that SCP can handle 10,000 transactions per second in certain network constellations.
The Tixl team plans to focus on boosting the number of transactions per second after the Mainnet launch to cater for increased demand as adoption grows.


This chapter describes the general architecture and how the different modules are orchestrated. Note, that the architecture is mainly designed for the Mainnet v0.1 so far, some aspects may be changed later during the development of the Mainnet 1.0.


The figure below provides a general overview of the architecture and shows how the different components - explorer, wallet, gateway, validator node and witness node - communicate.
Validator Node
The validator nodes are also called Autobahn Network nodes and provide the essential functionality of the Autobahn Network. In the next section, the architecture of the validator nodes is described in more detail. All validator nodes communicate with each other in the validator network. Ideally, the validator nodes will use a broadcast to communicate their information to all the other nodes. There is no confidential information communicated in this network, so it is desirable that anyone can join and listen to messages sent. The basic function of the validator nodes is to validate transactions, find a consensus with all other nodes on which transactions to include and then store those in the ledger.
Transactions need to be sent to at least one validator to be processed by the network, but sending transactions to only one validator will lead to long processing times because each validator is only eligible with a certain probability to propose transactions to the network. The gateway provides a similar HTTP-Interface as the validators and also accepts transactions. Validators can register at the gateway and will receive incoming transactions from the gateway, this results in a distribution of transactions to the validator network, hence, wallets and other components that issue transactions should send transactions to a gateway, and not directly to validator nodes. Possibly later, the gateway should be replaced by a layer for the validator nodes that distributes transactions through the validator network, so that transactions can be sent to validator nodes directly, for more decentralization.
Witness Node
Witness nodes are similar to validator nodes, but instead of actively participating in the consensus they just listen to externalized transactions and store them. They can be used by other components to get the state of the network, e.g. get the latest transactions or subscribe to transactions. This functionality could also be included in the validator nodes but this would introduce even more network traffic and processing to them and it is better to reserve those capacities for participation in the consensus.
The wallet component could be a native mobile wallet or a web wallet. Its main purpose is the display of transactions for a certain user and the issuing of transactions for that user. Transactions will be sent to the gateway and the state will be obtained from witness nodes.
The explorer shows the latest transactions and slots with additional information.The current one is very basic. But a new Explorer is coming soon.

Validator Nodes in Detail

A validator node, or validator, consists of three main components: consensus, ledger and intermediate storage, it also has two interfaces: one exposes an HTTP API and the other is reserved for communication with other validators.When the validator receives a transaction via the HTTP API (most likely from the gateway), the following steps will occur:The micro proof-of-work of the transaction will be validated. If the micro proof of work is invalid, the request will fail immediately. If the micro proof of work is valid, the transaction will be stored until the next slot of the consensus begins.When the new slot of the consensus begins, and the transactions from the slot before have been written to the ledger, the transactions are sent to the ledger for validation.The ledger does an in-memory fork of the state for the current slot to validate all transactions successively. With the usage of the crypto component, the signature and range proofs are validated, to make sure that the transaction is valid in terms of authenticity and balance.Invalid transactions will be discarded and valid transactions will be stored until the consensus requires the information of validity. In the case that the validator becomes a consensus leader for the slot, it will propose all valid transactions to the network. When the consensus receives a vote for transactions it will also vote for those that it considers valid.At the end of the consensus slot, a list of transactions will be externalized. Those are forwarded to the ledger module to be persisted.
Validator State
When a node starts initially or loses synchronization, for example by missing messages from the consensus, because of an unreliable network, it will set its state to synchronizing. In the synchronizing state, the node will reach out to one of its peers to request the transactions that it missed. Whenever a transaction is stored, a master hash is calculated that depends on the prior master hash and the new transaction. Upon receiving all transactions, the node requests the master hash from its other peers and compares that hash to its own calculated master hash to determine if the node received all of, and the correct, transactions. After the validation of the master hash, the node switches its state back to participating. In the participating state, the node actively participates in the consensus.

Autobahn Network for Other Assets

The Autobahn Network delivers a novel way to move other assets on the network. It offers speed, cost-efficiency (and, if possible from the regulators, privacy). In contrast to existing solutions, we do not rely on peer-to-peer payment channels, nor centralized solutions, to swap tokens.The basic idea involves sending the native tokens (we will use Bitcoin as the example for all assets in the following section) to the address of a decentralized committee that stores the Bitcoin safely until they are withdrawn from the Autobahn Network. This is achieved by giving a subset of all validators, called “the committee” (that makes sure every transaction is legitimate), key shares to a Bitcoin account.With these key shares, the committee can sign Bitcoin transactions in a decentralized way, without any single validator being able to move Bitcoin out of the fund. For every Bitcoin deposited into the Autobahn Network, an equivalent TBTC on the Autobahn Network is created which is later burned in the case where the Bitcoin is withdrawn. The following illustration shows how the Bitcoin Ledger is connected to the Autobahn Network via a "BTC / TBTC Gateway":


One of the central concerns for the interoperability solution is to enable the transfer of other assets while maintaining decentralization. This is trivial for the transactions in the network itself as it uses the mechanisms of the existing Tixl solution - which achieves consensus using the Stellar Consensus Protocol. However, the more challenging task is to guarantee decentralization for the transactions that bring assets into the Autobahn Network (deposit), and those that return themto their native chain (withdrawal).
The native asset can never leave the native chain, as no entity in the Autobahn Network has the authority to mint or burn native assets. Instead, the solution is to transfer the ownership of the native tokens to the Autobahn Network on deposit and to transfer this ownership back on withdrawal. Assets from other chains deposited to the Autobahn Network can be described as “pegged” assets.To achieve this in a decentralized way, the Autobahn Network uses a Multi-Party Threshold Signature Scheme (TSS).A subset of the validator nodes (the committee) will be chosen using criteria like global network trust and decentralization. Every member of the committee participates in the three algorithms of the TSS: key generation, key re-sharing and signing.From the global public key, the address (e.g. the bitcoin address) can be calculated, which is the pool address. When enough members of the committee work together they can produce a valid signature for the corresponding global private key, thus allowing the committee to spend the funds that have been transferred to the pool address.It should be noted that no committee member reveals their key share or can produce signatures alone. The key re-sharing algorithm allows the committee to generate new key shares without changing the underlying global private key, and even allows for new committee members to enter and old ones to leave.

Threshold Signature Scheme (TSS)

As the goal is to stay decentralized, no single validator should be able to spend Bitcoin from the shared pool where the Bitcoins are deposited. Therefore, a process such as using a threshold signature scheme (TSS) is needed.A “(t,n)” TSS is a group of “n” parties sharing a secret in such a way that only “≥ t” parties can reconstruct the secret respectively to produce a signature in a decentralized way, without revealing their shares. Additionally, there is a decentralized algorithm to create secret shares without any party knowing more than its share.The Autobahn Network "BTC / TBTC Gateway" relies on the implementation of Binance written in Go, which has been security audited and offers all the features required.The library offers three algorithms:
This algorithm lets “n” parties create keys with a threshold of “t”, which can be used for the other two algorithms.
This algorithm creates a signature and requires at least “t” parties to participate.
To make the storage of the secrets more secure, the secret shares can be regenerated with the underlying secret, thus allowing the Bitcoin address to remain the same. This is yet to be implemented in our Testnet.

Deposits into the Autobahn Network

The transferring of assets to the Autobahn Network is relatively simple: The user sends the amount they wish to deposit to the pool address and creates a Deposit Block, which contains a reference to the transaction of the native token, on the Autobahn Network.To prevent any others from claiming that transaction a claim proof must be provided. Currently, two different claim proofs are implemented.The first method to proof that the user can use the transaction for the deposit block is to sign the public key of the stealth chain the deposit block is going to be placed on with the asset private key and then supply this signature to the block. The second method is to send any amount to a second address, which is deterministically generated from the public key of the stealth chain. The general handling of this mechanism can also be conducted by a proxy to make it as easy as possible for users to deposit. The development of the proxy is already underway.In addition, the following criteria must be fulfilled by a deposit block to be accepted by the validators: The asset transaction must not have been used in any other deposit block before, the transaction must be confirmed (e.g. 6 times for bitcoin), the asset symbol of the deposit block must match the asset transaction, and the amount of the deposit block must match the amount that was transferred to the pool.The deposit block mints the respective asset tokens on the Autobahn Network. Thus, when the deposit block is accepted by the validator network, the token - in an amount equal to the transaction in the pool - can then be moved on the Autobahn Network, while the committee holds access to the native tokens in the pool.

Withdrawals from the Autobahn Network

To withdraw tokens of an asset from the Autobahn Network, to receive native tokens, a withdrawal block must be created. The withdrawal block has an additional field where the address on the native chain the token should be transferred to is stored, and the amount is public.When the address is validated, and the block itself is valid, the acceptance of the block results in a token burn of that asset. The committee witnesses the externalisation of the withdrawal block and creates a transaction of the asset type, e.g. a native Bitcoin transaction, and executes the distributed signing algorithm.When enough committee members participate in the signing, a signature is eventually produced which is used to complete the transaction. The transaction is then sent to the native networks, e.g. Bitcoin Network, and the transaction reference is made public so that the user can retrieve it.Note that the transaction fee of the native asset is paid from the amount withdrawn. The balance of the pool can never drop below zero because only tokens that have been deposited can be withdrawn.

Securing the Autobahn Network by Bitcoin

To increase the decentralization of Autobahn Network, a hash representing the current state of the Autobahn Network ledger will be written onto the Bitcoin blockchain regularly. In doing so, the Autobahn Network will increase its trust by leveraging the most secure blockchain in the world.

Support of Other Tokens

The goal is to provide as many bridges to other networks as possible. Interoperability is one of the key goals of the Autobahn Network. Some networks, like the Ethereum network for example, not only have their native tokens but also custom tokens issued on them. For these tokens, a process is planned that will allow the Autobahn Network validators to vote if a token may be transferred and accepted by the Autobahn Network gateway or not. It is planned that a small fee in TXL must be paid by projects applying for bridge support. The fee will be spam protection to avoid questionable tokens on the network.


The risks listed below represent those considered material at the time this document was prepared. All risks presented may occur in isolation but could potentially happen at the same time, and in varying degrees of severity. The threat of these risks could have a negative effect on the Tixl project and cause doubts for prospective buyers. International incidents such as a global financial currency and/or economic crises may also occur and exacerbate the risks outlined below.Personal and economic circumstances unique to a buyer cannot be quantified but may amplify the effects of the risks listed.No definitive statement can be made as to the probability that the risks described below will occur, nor is the order of the risks presented a measure of their probability of occurrence, or the extent of their potential impact. For the sake of clarity, the following presentation is thematically structured, whereby it should be noted that the risks mentioned may also have cross-thematic relevance and/or may affect the occurrence and severity of other risks.Irrespective of the risks described here, developments that are unknown and/or unforeseeable today may also have a negative impact on the Tixl Project.The risks described below may not only affect the immediate value of the Tixl Token (TXL), but may also cause the Tixl platform to develop negatively and lead to a partial, or complete, loss of the capital invested by the buyers.

Technology Risks

The implementation of Tixl and it’s underlying Autobahn Network is based on existing technologies.Which, amongst others, include: programming languages, frameworks, network protocols, cryptographic systems and consensus algorithms. The risks cannot be ruled out that there may be security gaps or other errors in the applied technologies used, or faulty compilations thereof. Whilst these risks may be offset by the implementation of security audits, for example, there is never one hundred percent certainty in computer science and cryptography. Two scenarios in particular would have a drastic effect on the price of Tixl.Scenario 1 would be a breakup of the cryptographic system. In the worst case, an attacker could gain complete access to any number of Tixl (TXL).This would more than likely make the currency worthless, or at least lead to a long-term price collapse.Scenario 2 would be a long-lasting “DDoS attack” paralyzing the Tixl servers for an extended period for which no immediate solution can be found.Again, a long-term price collapse would result.Advanced technical precautions are employed to safeguard against both these scenarios, thereby limiting the chances of them occurring.

Marketing Dissemination

The success of any product, including digital assets, depends on their dissemination. Theoretically, it could transpire that none of the marketing measures implemented has any effect and no further users or B2B partnerships can be generated. In this case, the corporate capital would eventually run out, thus rendering Tixl marketing financially untenable. This could lead to a long-term decrease in price.


Governments and state institutions, whether in Germany or elsewhere in Europe or the world, will focus more on digital assets over the coming years. This will lead to more regulation in what is currently a relatively unregulated market. The founding team is very open to cooperation with the German state, as well as other states. Tixl will not look to become an underground currency but instead seeks to comply with the regulations outlined in prevailing public policy (provided these do not completely block the Tixl core concept). The worst scenario would be that states prohibit the use of Tixl as a means of payment. Depending on which state(s) is/are concerned, a ban may lead to a short-term, or long-term, dip in price.


Currently, various teams worldwide are working on the implementation of a new generation of digital assets. Some startups have recognized that the digital assets of 2019/2020 need to be more usable and that distribution is of utmost importance. There is no denying that competition is strong and that throughout 2019/2020 at least 100 new digital assets will hit the market.
Other competition comes from improvement in the usability of existing digital assets, and their distribution will increase. The key currency is likely to remain Bitcoin. As seen in the past, the next crypto bull marketwill favor the competitive drive and growth of new digital assets. However, developing and launching a new digital asset gets more difficult with each passing year.

Key Individuals Risk

The development and economic success of the Tixl project depends, to a large extent, on the experience and competence/skills of a small group of people, in particular Christian Eichinger, Sebastian Gronewold and other key people. There is a risk that these key persons may not be available, or not perform their tasks (fully or properly), and that the development and economic success of the Tixl project may deteriorate, or even cease, as a result. There is also the risk that a successor cannot be found in the event of the loss of a key person.

The Risk from Conflicts of Interest

There are personnel and capital links between the partners involved in this project. Participating partners and consultants are not subject to a non-competition clause. Therefore, it cannot be ruled out that the partners involved (as well as persons associated with them) could launch projects which compete with Tixl in the future. Irrespective of this, there is a risk that the participating partners will take measures, or refrain from necessary actions due to their own, or external, interests and/or those decision-making situations will be resolved to the detriment of the Tixl project.

Insolvency Risk / Lack of Deposit Protection / No Capital Guarantee

The business activities of Tixl gGmbH represent an entrepreneurial commitment which exposes it to all of the common risks associated with business transactions. A company always has the potential of becoming insolvent. Under no circumstances does Tixl gGmbH offer a capital guarantee. Due to lower-income and/or higher expenses, Tixl gGmbH may become insolvent or over-indebted. Tixl gGmbH does not belong to any deposit insurance scheme. In the event of insolvency, the project’s success cannot be realized.

No Guarantee of Tradability

TXL should be tradable on exchanges. Also, there are no restrictions on the transfer or sale of TXL (or MTXLT). It is important to note that it is not possible to return the TXL (or MTXLT) to the Tixl gGmbH. There is a regulated exchange-like market for the sale of the Tixl Token. However, there is no guarantee that a sale will be possible at the desired time or under conditions acceptable to the original purchaser.

No Right to a Say

The Tixl Token is not a security; it does not convey any claims under the law of obligations or company law for co-determination and/or profits concerning the Tixl Project and/or Tixl gGmbH. Therefore, the management may make decisions which do not correspond to the objectives of the individual buyers of the Tixl Tokenand these may negatively affect them.

Contract Performance Risk (Counterparty Risk)

The Tixl project is based on various contractual relationships that have been established or are yet to be established. There is a risk that the contractual partners will not meet the obligations associated with these contracts (intentionally or negligently), or will no longer be in a position to duly fulfil the contract, pay damages due to a deterioration in their creditworthiness or the accumulation of obligations towards a large number of contractual partners, or will terminate their contracts properly or extraordinarily. Any claims for damages against these contractual partners may prove to be economically unenforceable and/or the necessity may arise to conduct time-consuming and costly legal disputes. This can lead to costs in connection with the enforcement of a contract or a replacement of the contractual partner. In addition, the assertion of claims for damages may be made more difficult by limitations of liability in the contracts to the extent customary in the market, and the outcome of legal proceedings and the success of enforcement measures cannot be foreseen. Any claims for damages against contractual partners due to violation of their contractual obligations may for these reasons not be (fully) enforceable. Furthermore, there is the risk that the contractually owed, but not performed, services cannot be procured elsewhere in the market, or procured under conditions which are not as favorable. It must be understood that the proper execution of these contracts is dependent on the economic performance and compliance of the contractual partners, the effectiveness of the individual contractual provisions and, in part, on the interpretation of the contractual provisions, whereby these factors may result in disruptions to the performance of the respective contractual relationships.

Reputational Risk

It is possible that the reputation of FinTechs, digital assets, and ICOs may deteriorate with individual interest groups or with society as a whole, e.g. due to a large number of unrealized projects, fraudulent or other illegal behaviour, or serious technical inadequacies (e.g. security gaps, hacks, data loss). The result of these events - either systemic or at the company level, may adversely affect the reputation of the Tixl gGmbH in terms of performance, competence, integrity and creditworthiness. A deterioration in the company’s reputation would typically have a detrimental effect on the customer base and the company’s business activity.


MTXLT – The Precursor of TXL

When the Tixl Project was launched, it was done so with MTXLT – which has a value equal to 1,000 TXL. Today, TXL is Tixl’s token and MTXLT is not tradeable anymore.A small percentage of tokens remained on Binance Chain, in the form of the original MTXLT token. In February, 2021 a token burn was carried out leaving only enough MTXLT tokens on Binance Chain to cover those that have been sold (and yet to be distributed), and those tokens staked as part of the Hodlers Club.All holders can always swap them into TXL (ERC-20). Once swapped, these amounts are eventually burned on Binance Chain until the Supply of our old MTXLT token will theoretically reach 0. With every swap carried out, or with every MTXLT bridged over to TXL, respectively, we will burn that part of the supply. Why “theoretically 0”? This is due to the fact that some investors have lost their private keys, meaning those MTXLT are now inaccessible and will stay where they are forever with no chance of being accessed.
One MTXLT on Binance Chain is able to be swapped to 1,000 TXL on Ethereum via the Token Bridge.

Token Split MTXLT -> TXL

TXL originally existed in the form of MTXLT. The initial plan was to break down this MTXLT into a larger maximum supply of 900,000,000,000 TXL but – from a psychological point of view – one TXL would then have been worth very little. When the value of a token/coin gets too small (closer to $0), investors tend to see this value is almost “worthless”. By limiting the conversion of MTXLT to 1 MTXLT = 1000 TXL, the resulting TXL price becomes more meaningful.
With the total supply at 900,000,000, there are two main benefits. The value of TXL is not so low as to be seen as worthless, but it is also low enough so that investors can own a number without the cost being prohibitive.

TXL price example:

Assuming a market price of US$150 for one MTXLT, the conversion to TXL is worked out by dividing the price of MTXLT by 1,000. In this case, it would result in a price of 15 cents per TXL (US$0.15). This price-per-token is relatively cheap compared with tokens on CoinMarketCap or CoinGecko.
Multiplying the price of one TXL by the circulating supply provides the market capitalization (market cap) that is displayed on the price trackers listed above.

Market Cap example:

Assuming that there is 20% of the total supply of TXL in circulation = 180,000,000, and one TXL is worth US$0.55, then the “market cap” would be approximately US$100,000,000.180,000,000 x US$0.55 = US$99,000,000.At a price below US$1, the token would be relatively cheap and owning a number will still be seen as achievable.

Appendix: Privacy

Our approach to private transactions

Tixl was originally designed to be fully private.
Fully private transactions mean that the technology behind the token should provide the ability to hide both the transaction receiver and sender, as well as the transaction amounts and account balances. The data structure and consensus algorithm must allow fully private transactions.
Why did we decide to implement private transactions? Bitcoin, as an example, is not entirely anonymous. Each user has a public address that, in theory, can be traced back to an IP address or exchange account. As with many other cryptocurrencies, Bitcoin has the appearance of anonymity but, given enough time and resources dedicated to the investigation, it becomes transparent if an address can be linked to a real-world identity.
Concern has grown within international regulatory bodies that privacy coins could be used for illegal activity and as a way of getting around AML requirements. Within the FATF recommendations, a certain requirement - known as the Travel Rule - is referred to in the media mainly in relation to privacy coins vs. Anti Money Laundering (AML). The Travel Rule requires so-called Virtual Asset Service Providers (VASPs) to transmit certain information about the sender and receiver of a virtual asset with each transaction. In reality, most privacy coins are fully compliant with this rule, allowing VASPs to pass additional information along with each transaction but the fact is, that the threat to the future of privacy coins is real and we have to provision for the potential that they may be outlawed to a greater or lesser degree.
For the reasons above, the first version of Tixl’s technology will only support public transactions for its users. That does not mean that we have decided to stop working toward private transactions, but that we will simply not support privacy at the beginning. In fact, we have already launched our Testnet with private transactions, so certain privacy features can be re-enabled at a later date (after some refactoring).
We’ll then monitor the legal environment and regulation around privacy coins and try to deliver an AML-compliant but private transaction network in the future. The Tixl team is currently looking at protocols like OpenVASP or TRISA to allow private transactions for certain Virtual Asset Service Providers (VASPs - described above).
We still believe that privacy-preserving projects such as Tixl have a bright future - even though they may only be able to provide their privacy features to approved VASPs (like in the TRISA model for example).

Technical Concept of Privacy

Privacy Design

It is important to understand that the final privacy design is dependent not only on technical aspects but also on potential future regulation. Tixl’s approach for 2020 has based around this and is described in the chapter Our approach to private transactions. An idea about how the Autobahn Network could still offer privacy in a regulated environment which forbids privacy coins as we know them today is described in the chapter Private Transactions.
The following describes how privacy was partially implemented in the first Autobahn Network Testnet versions but is currently disabled for upcoming releases.These privacy features will be activated again in a later version of the Mainnet if they comply with the prevailing regulations.
An account is opened by creating an Accountchain. The first block on the Accountchain is the “account” block and contains an NTRU key pair and a signature key pair. The private keys are encrypted with AES-256 and are also stored on the “open” block. The 256-bit AES key is the access to the account and is short enough to comply with BIP39. Using the NTRU private key as the secret that accesses the account is a problem due to the huge key size and, thus, is not BIP39 compatible. AES-256 encrypted ciphertexts are shorter than NTRU encrypted ciphertexts. A 256-bit AES key requires a seed phrase of 24 words.
The keys needed to access the generated Stealthchains will each be stored on a block of the Accountchain. The access to these chains will also be encrypted with AES-256.
Amounts and balances on “send” and “receive” blocks will be encrypted with AES-256 for the issuer of the block, and with NTRU for the receiver of the block. The blinding factors for the zero-knowledge proofs will be encrypted with NTRU. The amount and balance will be verifiable for third parties by the use of Pedersen Commitments and range proofs. Ownership over the account - or Stealthchain- will be proven by the signing of the blocks with the chain’s private signature key, which is individual for each chain.
The aforementioned mechanisms will ensure private transactions. However, with only these measures in place, it is still possible to infer relations between different Stealthchains by using additional information that may be obtained by being a part of multiple transactions. For example, a big retailer that uses the Autobahn Network for receiving payments could link the Stealthchains of two persons for which it knows the identity -Stealthchainpair - to their employer, if the employer also makes payments to the retailer and pays the employees in Tixl. To break this traceability, Tixl will implement cut-through transactions by using ValueShuffle, if the privacy regulations allow for it.
How do private transactions work?
already has a Stealthchain with 10 or more
as a balance (or more than one Stealthchain with 10 or more TXL in total).
uses the ID of the Accountchain of
as an address for the transaction. The wallet software will look up the necessary keys to create the transaction containing the send block. Specifically, the NTRU public key is used to encrypt the amount, and blinding factor, for
The wallet software sends the transaction to the gateway, and the gateway forwards it to the validators. The validators work to validate the transaction each against their own ledger. The transaction should be recognized as valid by all honest validators, and the validators will include it in the next slot of the consensus protocol.As the send transaction is confirmed by the Autobahn Network,
scans the send blocks and tries to calculate a feasible transaction amount by decrypting the blinding factor and amount with its private NTRU key. If a feasible amount is found, the transaction is addressed to
will create a receive block and send it to the gateway.
The transaction containing the receive block is processed in the same way by the network. If the Autobahn Network confirms the transaction it can be seen as complete.Every account that knows the blinding factor can claim the send block with a receive block. In general, those are the accounts that own the private NTRU key to decrypt the blinding factor, and also the sender itself. A transaction should only be deemed as complete by the receiver when its receive block is confirmed by the Autobahn Network, as that sender could also reclaim the block. This mechanism also allows the ability to restore the transaction when an incorrect address has been used.

Additional transaction data

Data for the receiver (optionally encrypted)
Information that the recipient should receive as transparent information or, under certain circumstances, also encrypted. That includes the amount of the transaction and an optional description.
Data for the sender (optionally encrypted)
The sender would also like to be able to view the amount they have sent. Therefore, the sender encrypts specific data for themselves. In addition to the amount, this also affects the balance on the Stealthchain. In the case where the block is a receive block this part is omitted.
Data for validation (unencrypted)
To verify transactions by consensus, certain data is required. In this part of the block - the block signature - commitments for the zero-knowledge proofs and the micro Proof of Work for spam protection are stored.Encrypting a small amount of data, for both the sender and the recipient, produces duplicate data. This overhead will be accepted in favor of privacy.

Which Cryptosystem does Tixl use?

In a world of technological competition and innovation, we strive to be at the top level of modernization and advancement and provide a product technically strong and secure enough to endure into the future.The cryptographical aspects of the digital asset are no exception to this. Cryptography is a fast-changing science, where new algorithms are discovered, and old ones become obsolete every year. But to anyone even vaguely familiar with the current topics of cryptographic debates, it is clear that a great challenge looms ahead – the advent of quantum computers.The concept of quantum computers has existed for a long time, but in recent years some of the tech giants have started to make practical progress toward making them a reality. And whilst the advent of a practical, usable, functioning, well-programmed quantum computer may be some way off, the potential for their implementation already factors in the minds of the cryptographic community. As always, people’s ideas far proceed their practical implementation, and years before anything related to quantum computers started to become a reality, Peter Shor invented an algorithm (correspondingly named Shor’s algorithm), which uses the theoretical power of a quantum computer to solve the factorization problem (if you have a number, finding its prime factors. Especially hard when the number is the product of the multiplication of two very big prime numbers).Many of the cryptosystems currently used, like the all-prevalent RSA, are directly based on factorization. Many others, like ElGamal and most of the elliptic curve cryptography, can be reduced to a similar problem and can also be solved, theoretically, using Shor’s algorithm. Almost all digital signatures are not secure anymore. And now, as quantum computers are gradually becoming a reality – the world needs to change. It doesn’t matter if the practical implementation of quantum computers is achieved within the next 10 years (in line with the most hopeful predictions), or over the next 15-20 years (a more realistic time-frame), nor does it matter greatly that any change will come slowly, or even that a working, state of the art quantum computer will still take considerable time to decode any particular data - the fact remains that anyone who wants to stay ahead of these developments should act now.Thus we have decided, that in order to provide the highest quality standard of encryption and to create an enduring system, we must use cryptography that retains its strength in the face of quantum computing.

Cryptography and Quantum Security in Tixl

Tixl uses cryptography in various parts of its software. Of course, signing transactions itself and encrypting transaction details requires cryptography. In addition, the consensus algorithm uses signing and encryption methods, for example, to securely communicate with other nodes.


The technology for the encryption of values is only required for private transactions.
NTRU was created in 1996 by Jeffrey Hoffstein, Jill Pipher and Joseph H. Silverman, and patented one year later by NTRU Cryptosystems Inc., a company the three inventors established with Daniel Lieman. The name they gave the new system stands for “N-th degree Truncated polynomial Ring Units” (NTRU). The NTRU cryptosystem consists of two main algorithm categories: NTRU for encryption and NTRU for digital signatures; however, only the encryption part is currently of interest to us. In the beginning, people praised the new cryptosystem for its speed and efficiency. However, there were concerns that, for smaller N (degree of the polynomial), some attacks were effective. With the potential advent of quantum computing, NTRU drew renewed attention and the different forms of attack were studied in greater detail. Greater scrutiny of the possible values of the parameters proved certain rings to be weaker and others to be more robust, and provably secure versions were created as early as 2013. In 2017, NTRU entered the public domain and is free to use by anyone. Currently, NTRU has been entered into the Post-Quantum Standardization Project of the US National Institute of Standards and Technology.
The Advanced Encryption Standard (AES) is a symmetric encryption scheme, which means that the same key is used for encryption and decryption. Due to its nature, it can’t be used to share information between parties on the blockchain (except with a key exchange). AES comes with 3 different security levels: 128, 192 or 256 bits. The Autobahn Network will use AES-256 because it is the most secure. Quantum computers will reduce the effective security to 128-bit, which is still sufficient. We can use AES-256 to encrypt things that need to be private and only accessed by the writer, for example, the keys for Stealthchains or the amount and balance. Note that the amount and balance will also be encrypted with NTRU for the recipient of the transaction. Also, because the keys for NTRU are very large (4411 bits key size for 128-bit security), a seed phrase to create such a key would be huge and would not conform to BIP39, so the NTRU private key would be stored on the Accountchainencrypted with AES-256, with the AES-256 secret key allowing access to the account (and created by a mnemonic seed phrase).


Signatures are necessary to prove the ownership of the Accountchains, Stealthchains and blocks. The owner that has access to the private key creates a signature that is publicly verifiable by the validators or other third parties, thus allowing only the owners to write blocks on their chains and to create new chains. With the launch of Tixl, we will use ECDSA for signatures and later switch to a quantum-resistant system, as it becomes necessary.
The Elliptic Curve Digital Signature Algorithm with the Secp256k1 curve became popular through its use by Bitcoin. Elliptic curve cryptography is known for providing good security in relation to key-size compared to its alternatives - like RSA. However, since the security of this crypto-system is based on the elliptic-curve discrete-logarithm problem, it is also vulnerable to Shor’s Algorithm, which means that it is not quantum resistant.
XMSS - standing for Extended Merkle Signature scheme - is currently one of the best candidates to become the quantum secure digital signature of the future. Its main strength lies in the fact that its security depends purely on the properties of the underlying hash functions, and not on some unsolved mathematical problem, which means that there is no chance someone will discover a solution to that problem which would compromise the security of the signatures. It is quantum secure and no developments in quantum computing will ever challenge it. Hash-based signatures combine a one-time signature scheme with a Merkle tree structure, which adds the hash functions in such a way as to allow a very large, but fixed, number of multiple signings. XMSS is a further development of this concept adding pseudo-random key-generation for every single signature, which needs a different private key. That also makes XMSS forward-secure, which means that even if a secret key is compromised, all previous signatures remain valid and are not compromised.
Note on the transition of ECDSA to a quantum secure signature
We do not see the lack of quantum resistance as a problem for now because we can upgrade the keys of the chains later when the threat to ECDSA due to quantum computers becomes more imminent. Also, the usage of ECDSA will, for now, allow us to keep the block size a little smaller. If we reach this threshold in the cryptographic ecosystem, the validators will be required to only accept transactions that are signed with a new quantum secure signature. Before that, there will be a period where chains will be required to announce a new, quantum-secure, signature key and sign it with their old signature key. We will ensure that there is enough time before the validators stop accepting the old keys and that the official wallet software will do it automatically. However, a failure to upgrade the key could result in the loss of funds.

Private Transactions

For a general statement in regards to private transactions please refer to Our Approach to Private Transactions.
The Autobahn Network can achieve private transactions by combining different approaches. First of all, a TXL owner can be protected so that nobody can see their balance. To achieve this, TXL are not written to the personal blockchain (Accountchain) of a user but instead to unclassifiable blockchains (Stealthchains) only known by recipient and sender. Correspondingly, a TXL sender must also be protected so that their outgoing transactions cannot be seen. The Autobahn Network achieves this by sending TXL directly from Stealthchains that a new recipient cannot relate to other TXL owners.The section about confidential transactions explains how it is possible for the amount of a transaction, as well as account balances, to remain invisible to anyone but the owner whilst still making it possible to be processed and validated by a decentralized consensus algorithm.


The Accountchain represents the user’s main account. It is used to store encrypted references and the keys to the user’s Stealthchains.


A Stealthchain is a separate blockchain that works much like a Monero stealth address. For each sender/receiver combination, the first transaction generates a new Stealthchain. Other blocks of the same sender are written to the same Stealthchainby the receiver.
A third party cannot discover the generated address, even if the third party knows both participants in the Stealthchain transaction.

Confidential Transactions

The goal of confidential transactions is that both the amount transferred, as well as the account balance, remains untraceable to outsiders. That’s made possible by generating commitments for those values. These commitments can perform arithmetic operations (addition and subtraction). So, if a commitment to the number three
and a commitment to the number five
are summed up, that sum is the same as a commitment to the number eight
. Since a commitment to a number always yields the same result, it would be quite easy to recognize the different amounts corresponding to the commitments and the transaction details would no longer be secret. Therefore, the additional use of so-called
blinding factors is necessary.
Blinding factors allow for a variance for each commitment without lifting the arithmetic properties.

Zero-Knowledge Proofs

With zero-knowledge proofs, information can be verified without the information itself being disclosed: Alice proves to Bob that she is indeed in possession of some piece of knowledge without revealing any of that knowledge. The concept has been around since 1985. Zero-knowledge proofs are a general concept and not limited to a specific cryptosystem.
A zero-knowledge proof must satisfy three properties:
If the statement is true (e.g., I have enough balance), the honest verifier will be convinced of this fact by an honest prover.
If the statement is false (e.g., I don’t have enough balance), no cheating prover can convince the honest verifier that it is true, except with some small probability.
If the statement is true, no verifier learns anything other than the fact that the statement is true.
Interactive vs. Non-interactive Zero-Knowledge Proofs
There are two ways in which zero-knowledge proofs can be achieved: Interactive and non- interactive. With interactive proofs, the prover and verifier must exchange information. The outcome of the proof convinces only the prover P1 and the verifier V1. If this check is to be carried out by the prover P1 with another verifier V2 they have to perform the proof again. Therefore, interactive zero-knowledge proofs are limited in transferability, which makes them impractical for a distributed network.
In a distributed network we need a kind of zero-knowledge proof, where the prover can show the result, and another party (the verifier) can verify the proof themselves. These are called non-interactive zero-knowledge proofs.
Non-interactive Zero-Knowledge Range Proofs
Range Proofs are a concrete form of zero-knowledge proofs and allow for proving that a number is within a specific range. With the Autobahn Network, this is used to check that no negative amounts are sent and that no chain on the DAG can have a negative balance.

Pedersen Commitments

A commitment scheme lets you keep a piece of data secret but commit to it so that you cannot change it later. A simple commitment scheme can be constructed creating a cryptographic hash of a piece of data combined with a so-called blinding factor. The blinding factor is like a random value preventing an outsider from revealing the piece of data when knowing the hash.
The Pedersen commitment scheme has the following properties:
A dishonest party cannot discover the honest party’s value.
A dishonest party cannot open its commitment in more than one way.
A dishonest party cannot commit to a value that is in some significant way correlated to the honest party’s value.A Pedersen commitment has an additional property: Commitments can be added. The sum of a set of commitments is the same as a commitment to the sum of the data, with a blinding factor
set as the sum of the blinding factors:
C(BF1, number1) + C(BF2, number2) = C(BF1 +BF2, number1 + number2)
Of course, a Pedersen commitment generated on an elliptic curve is not fully protected against quantum computers if they can solve the Elliptic Curve Discrete Logarithm Problem (ECDLP). Pedersen commitments are perfectly hiding, but computational binding. That means that even if the cryptosystem is broken, the data on which the commitment was given cannot be revealed.

Private Transactions Visualized

Figure 5 shows what the DAG could look like after the first private transactions. It shows an example where Alice receives TXL from the Genesis account (or TXL distribution account), sends TXL to Bob and finally receives some TXL back from Bob.The Genesis account
creates a send transaction
to Alice’s account
. Alice then creates a receive block
on her Stealthchain
. In addition, Alice stores a reference to the created Stealthchain
in her Accountchain
. Alice can send directly from the Stealthchain
to Bob. Therefore Alice creates a send block on the Stealthchain
. Since it is the first transaction Bob receives from Alice, Bob creates a corresponding Stealthchain
and stores the reference on his Accountchain
A Stealthchain cannot be assigned to an Accountchain by an outsider. Since the transactions are received on Stealthchainsand the amounts are never transferred to an Accountchain, the recipient is completely protected. Since the receiver is protected, the sender is also protected because the send block is also saved on the Stealthchain. Only the Genesis account can be identified as the sender because it does not send from a Stealthchain. That is not a problem, and even desirable.
To ensure that only an owner can write a new block on their chain, blocks are verified by signatures. The Autobahn Network considers the use of ECDSA for signatures first and will upgrade to XMSS in the future, to be prepared for the advent of quantum computers.The Autobahn Network aims to provide the highest level of privacy. Therefore, the amounts and balances must be encrypted before they are sent to the network. For amount and balance encryption, NTRU will be used. NTRU is known for its speed and efficiency and has been used in business applications over the last ten years while being protected under patent. A third party will be able to verify transactions by zero-knowledge proofs.For zero-knowledge proofs, the Autobahn Network uses Pedersen commitments which may be replaced by another scheme at a later date. To guarantee maximum privacy, the Autobahn Network offers the possibility of carrying out cut-through transactions by using ValueShuffle, an extension of CoinShuffle++. Cut-through transactions are not implemented yet but are planned for the future.
ValueShuffle is a decentralized protocol, which will be run with the participants wishing to mix their coins and results in a multi-transaction with multiple inputs and outputs, which are unlinkable. We can leverage the concept of quorum slices of the Stellar Consensus Protocol to select the nodes that are most trusted that will function as a bulletin board for the protocol. The downside of this method is that constructing such a multi-transaction consumes extra time. However, we don’t see this as a big problem because the main purpose will be to use ValueShuffle to move funds to fresh Stealthchains and not to use it directly for transactions between two parties. The wallet software could do this automatically in the background so that it doesn’t become time-critical. Quantum security for this protocol is not yet a priority because, even if the used addresses became linkable after breaking the non-quantum cryptosystems, the funds could be moved to new Stealthchainswith an updated protocol version at any stage.


Since signing, encryption and decryption take time, it’s important to keep the performance of the utilized algorithms in mind when building a digital asset that needs to scale up to thousands of transactions per second. As soon as the Autobahn Network reaches a development state which allows the measurement of representative times for encryption, signing, decryption, and validation, this whitepaper may be updated with more information about those impacts on Tixl’s scalability.
Also, consideration must be given to the fact that there are new Stealthchains for every sender/receiver combination. Currently, if an Autobahn Network user wants to send a larger amount of TXL and needs to merge funds of several Stealthchains, this would multiply the regular encryption time per block by the number of Stealthchains. Looking at different solutions, an easy way of solving this, in the beginning, could be to have a clean-up feature implemented by wallets. Wallets would transfer and merge funds to a single Stealthchainwhen idling. This problem only exists for private transactions.
Scroll upScroll up