Tixl Whitepaper

Table of Contents

Legal Disclaimer


Product Overview


Organizational Form

Technical Solution


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 interoperable DeFi (Decentralized Finance) ecosystem, Tixl, will be 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).

Our vision is the mainstream adoption of cryptocurrencies and blockchain technology for everything DeFi related. At the core of the Tixl Ecosystem is a layer 1 platform called “Autobahn Network” which serves as a base platform allowing the transfer of any digital asset instantly, with almost zero fees and with full AML-compliant privacy for authorized service providers.

Following the launch of the Tixl Wallet, the first major DeFi product using the Autobahn Network and its Autobahn SDK will be the Tixl Exchange, a scalable Swap DEX for BTC, ETH and other assets launched by Tixl in December 2020.

Tixl's Autobahn technology can be utilized for any other DeFi product. The ability to provide instant, fully interoperable transactions with minimal costs and optional privacy is equally essential for payment and lending solutions, liquidity programming, yield farming, decentralized insurance and many other activities.

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. This is exactly what Tixl is aiming to fix.


Autobahn Network

 is Tixl’s proprietary network which is designed to provide instant transactions with negligible fees and the ability for authorized service providers to send private transactions. These features could have huge benefits on the current DeFi ecosystem.

Tixl’s Autobahn Network will have an 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 their service level.

In addition, Tixl’s DeFi ecosystem will be interoperable, so any blockchains can get involved.

The Tixl Token: TXL

TXL will be the native token of the Tixl ecosystem and is a digital asset itself. The TXL supply is limited and pre-mined. There will be 900,000,000 TXL (900 million TXL) and the supply can never be increased.

As the Tixl ecosystem is still under development but a token was needed for fundraising and marketing purposes, TXL is already available on the Ethereum blockchain. The smart contract for TXL can be viewed

on Etherscan


50% of the TXL supply will be time-locked until December 31, because a part of the token supply is issued on Binance Chain. The ratio will be re-evaluated at the end of the year but there will never be more than 900,000,000 TXL in total. See the

chapter below

 for more details.

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.


 would only ever be 900,000 MTXLT in existence, and the reason for this number was that – especially during the first years of marketing – it was envisaged that this number would mean that one MTXLT could have the same value as one BTC, while only having a fraction of its market cap.

In time, the goal was that MTXLT would eventually be broken down into smaller parts (TXL) to enable it to be used as a more efficient means of payment, and the plan at the time was that one MTXLT would split into 1,000,000 TXL. This would have resulted in a 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 = 1,000 TXL, the resultant TXL price becomes more meaningful.

MTXLT was listed on Binance DEX (Binance DEX is a decentralized exchange built on top of Binance Chain), in August of 2019. It runs on Binance Chain as a BEP-2 token. MTXLT also began trading on ProBit Exchange on November 11, 2019. This was followed by a decision to list on Uniswap in September 2020.

We had originally planned to make the change from MTXLT to TXL at the time of the Mainnet release but, a combination of a very positive token price increase and great strides being made in overall project development meant that we decided to change to TXL earlier than scheduled. We decided to make the move from MTXLT to TXL to coincide with the Uniswap listing – where TXL would exist as an Ethereum ERC-20 token. The change from MTXLT to TXL occurred on the ProBit Exchange at the same time TXL was listed on Uniswap.

While the initial plan was that the change from MTXLT to TXL would occur simultaneously on every exchange (effectively making MTXLT redundant), the mechanics behind a token split on Binance involves a greater degree of preparation (including the issuing of a new BEP-2 token). A combination of a more complicated delisting/relisting procedure on Binance Chain and feedback from a substantial number of community members and investors meant the decision was made to keep MTXLT on Binance DEX for the time being, where it also remains tradable.

As at September 30, 2020 – 50% of the original MTXLT supply remains as a BEP-2 token on Binance Chain (in a time-lock) and 50% of the original MTXLT will be transferred into a smart contract on Binance Smart Chain until December 31, 2020. We will then re-evaluate the ratio of tokens on Ethereum and Binance Chain. The same will happen on the Ethereum network, where 50% of all TXL will be moved into a time-lock smart contract with the same release date.

One MTXLT on Binance Chain is always able to be swapped to 1,000 TXL on Ethereum via the

Token Bridge


How was the Total Supply Determined

The total supply of TXL will be capped at 900,000,000.

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





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.

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 amount

. 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 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


 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




 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).

Product Overview

The Tixl project is about to create an ecosystem for applications in the space of DeFi. That means multiple projects can be built on top. The following sub-chapters give an overview of planned products.

The Autobahn Network

The Autobahn Network serves as the core layer of the Tixl ecosystem.

It was named after the German Autobahn due to the speed that transactions can move along it. The Autobahn


 allows very fast transactions at a low cost. In comparison to Ethereum, for example, the Autobahn Network does not include a smart contract engine as it is designed to focus purely on the transfer of value. As most DeFi applications rely on the ability to execute individual code in a decentralized way, the Tixl team is currently evaluating concepts for off-chain smart contract execution.

A unique feature of the Autobahn Network is that it supports bridging assets from other chains - such as BTC, ETH or ERC-20 tokens - 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 transparent to the public. 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 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.

The Autobahn Network is a L1 platform that serves as a base layer for tokenizing assets, increasing the exchangeability of existing assets and can be used for any scalable DeFi app that would benefit from low transaction fees, high speed, interoperability and privacy.

Tixl Exchange (Swap DEX)


ecentralized Exchanges or DEXs have continued to increase in popularity  - having many advantages over centralized exchanges. However, what most decentralized exchanges are currently struggling with is that transactions (or swaps) and liquidity adds/withdrawals come with some disadvantages. They they cost high network/gas fees, they take a long time to be fully executed and often they cannot be cross-chain.

Tixl’s Autobahn Network offers solutions to all the disadvantages above, by default. The Tixl Exchange (Swap DEX) is the first product due to be launched on the Autobahn Network. It does not rely on generic smart contracts but, instead, comes with an additional sub-network of validators managing the liquidity pools in a decentralized way.

The technology behind the Tixl Exchange will be explained in more detail in the near future, but, in summary, the Tixl Exchange (Swap DEX) will be a fully interoperable Swap DEX with liquidity pools and liquidity mining. It will have almost zero network/gas fees along with instant transactions and pay rewards for both liquidity providers and swapping users.

To gain a better understanding of the way in which a Swap DEX works, you can read more in

this article


Tixl Wallet

The Tixl wallet will be available in the form of both a web and mobile wallet. It will work not only for assets within the Autobahn Network, but will also provide wallet functionality for larger networks - such as Bitcoin or Ethereum networks. Users of the Tixl wallet will benefit from zero fees for TXL transactions and low fees for transactions using other assets on the Autobahn Network.

A usable wallet is an efficient and effective way to increase adoption of Tixl, and the use of 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 in the fast lane.

Other Use Cases for the Autobahn Network

As the Autobahn Network increases its flexibility in the future, with off-chain smart contracts and interoperability to other networks, it can serve as a base layer for unlimited applications in the DeFi space. The list below highlights just a few examples of the categories of products that could be launched based on the Autobahn Network.

Yield Farming

Algorithm-supported strategies allowing users to generate returns from putting their crypto holdings to work.

Social Mining

Social media activities for community members to support a project in return for rewards.

Liquidity Programming

New technology used by the Tixl Exchange to be announced soon.


Borderless transactions without middlemen charging high fees.


Borrowing or lending crypto assets to other network participants according to rules set in smart contracts that are executed decentralized.


Decentralized systems that bring real-world information like price-feeds into blockchains.

Decentralized Insurance

Utilizing the blockchain technology and oracles to share risks amongst members with automated payouts.


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 $1,350,000 USD 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 was a Token Sale carried out?

The development of Tixl is laborious. A software development team is needed to implement the Tixl ledger in a step by step process. Also, there are a number of associated aspects that need to be commissioned, these include social media, accounting, legal and tax services, as well as security audits.

Along with the combined developments costs, there is the (often large) cost to list on an exchange - some exchanges may accept Tixl without a financial contribution, or in exchange for an amount of TXL itself. To be accepted as a cryptocurrency by the market, Tixl needs to be traded on major exchanges which frequently require payments of six-figure sums for listings.

The hosting of Tixl nodes should 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.

Last but not least, Tixl can only succeed if as many people as possible use the Tixl network for payments. 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.

Token Swap

The Tixl organization will implement a bridge between the Tixl ledger (as soon as it is launched) and the Ethereum Network, and for MTXLT on Binance Chain. With that bridge, it will be possible for a Tixl token owner to swap TXL ERC-20 (or MTXLT BEP-2) tokens to native TXL and vice versa. A tutorial outlining the technical details and requirements regarding the token swap will be published on the

Tixl website

 shortly after completion of the technical development.

What do the Tixl Tokenomics look like?

The maximum number of TXL is 900,000,000 (900 million). The initial total supply was also set to 900,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 holders 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.

There are ideas to reduce the total supply in the future through token burns. However, we don’t want to give any guarantee about that right now.

The following pie chart shows further details about the circulating supply and which tokens are assigned to which slices:

Chart coming soon...

Organizational Form

Tixl is a company of the

elbstack GmbH

, meaning the Tixl


 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 and Sebastian bring with them the experience gained in forming and running a successful software development and design company. Bernd completes the Executive Team and, between them, they have real-world experience combined with Masters level qualifications in Software Engineering Leadership and Information Systems.

The Executive team is complimented 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.

Christian EichingerManaging Director
Sebastian GronewoldManaging Director
Bernd StrehlChief Technology Officer
Dr. Max MuelkeBusiness Development
LennartUX & UI Designer
MikeTechnology Consultant
MoeCommunity Manager
Prof. Dr. D. GollmannAdvisor
Dr. jur. C. ConrederAdvisor
Dr. Ralph StuberAdvisor
+many more

Business Model

Tixl will become a decentralized DeFi ecosystem initiated by a non-profit organization, so it is hard to find a classic business model to compare it with.

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 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, with the TXL tokens later being swapped to TXL. At the conclusion of the lock-up period these TXL will be released for potential sale, in installments, 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, a number 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 word mark. 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 provide protection 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 launch of the Tixl ecosystem.

Technical Solution

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, the applied crypto-procedures, a sophisticated privacy concept 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




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


, the hometown of the Tixl project.

Data Structure

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. 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.

For an account with private transactions, the first block is called the private root, which is also an open block. The chain for this account is called

Accountchain, which contains more open blocks that save encrypted information on how to access stealth

chains. Those stealth chains do not reference the account chain, so they cannot be connected by any other person, as the account chain owner.

More information about the data structure in the dedicated chapter about the Autobahn Network’s

Data Structure


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 ch


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.


 account is opened by creating an


. The first block on the



the “account” block and contains a 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


. 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


. 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


 - 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


 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


 of two persons for which it knows the identity -


 pair - 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.


The most important piece of the architecture are the validator nodes or


. 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


 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


 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:

Non-private transactions


 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.

Private transactions

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.

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


 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. Data in a block for private transactions on the Tixl Ledger can be divided into four groups:

Metadata (unencrypted)

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



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.


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. 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 Really 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

of the retailer the transaction is done.

 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.

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 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 not conform to BIP39, so the NTRU private key would be stored on the


 encrypted 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


 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 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. In addition, 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.





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




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


. Other blocks of the same sender are written to the same


 by 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.


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


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.


Pedersen commitment scheme

 has the following properties:


A dishonest party cannot discover the honest party’s value.


A dishonest party cannot open their 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


 and 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, it is crucial that the amounts and balances are 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


, an extension of


. 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


 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 crypto systems, the funds could be moved to new


 with 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


 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


, 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


 when idling. This problem only exists for private transactions.


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)


Proof of Stake


, 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 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


 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


 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


 the outcome.

There are situations that 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


 so far, some aspects may be changed later during the development of the Mainnet.


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 are 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 basically 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 con- sensus 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. It’s 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 information gain is limited because transactions are private and thus there is not much to learn from them but the amount of processed transactions could be seen here.

Validator Nodes in Detail

A validator node, or validator, consists of three main components: consensus, ledger and an intermediate storage, it also has two interfaces: one exposes a 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 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


. 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


. 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 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 validators 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


the Autobahn Network (deposit), and those that

return them

 to 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 are able to reconstruct the secret respectively to produce a signature in a decentralized way, without revealing their shares. Additionally, there is a decentralized algorithm to create the 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 in order 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, in order 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 on a regular basis. 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 shall be a 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 af- fect 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 have an effect on 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 of time 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 have any effect and no further users or B2B partnerships are able to 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 definitely not look to become an underground currency, but instead seeks to comply with the regulations set forth 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 over the period of 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 market

 will 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.

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. In addition, 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 with regard to the Tixl Project and/or Tixl gGmbH. Therefore, it is possible that the management may make decisions which do not correspond to the objectives of the individual buyers of the

Tixl Token

 and these may affect them in a negative way.

Contract Performance Risk (Coutner-party 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.

Made in Hamburg, Germany
© Tixl gGmbH, All Rights Reserved