ARTIS: the genesis

In August, we reported how the cancelled ICO and the discovery of the Plasma design pattern would impact the roadmap of ARTIS. It’s time to give an update.

In the 2 months since, we have made the first steps into the new direction and achieved a clearer picture of the road ahead.

This is being written on the way back from Devcon4, the yearly Ethereum conference. What we experienced there has reinforced our believe that Ethereum is the right ecosystem for us to be part of. Its open and collaborative mindset have created a very powerful community which never fails to amaze with new achievements and which provides us with a large set of tools for working on our vision of a more decentralized and interoperable — a more human-friendly Internet.

lab10 members at Devcon4

We recently decided that we can and will launch the ARTIS mainnet earlier than expected: on November 14th 2018.

ARTIS is envisioned as a piece of infrastructure which evolves based on the requirements of applications and services built on top of it, taking advantage of the rich toolset of the quickly evolving decentralization ecosystem.
We try to make pragmatic instead of dogmatic choices, based on the understanding about requirements we gathered in conversations with various organizations and project teams.


ARTIS will use a combination of Proof-of-Stake (PoS) and Proof-of-Authority (PoA) consensus.
This makes ARTIS ecologically sustainable from the start — avoiding the excessive electricity consumption of Proof-of-Work as used by Bitcoin, Ethereum (for now) and many other blockchain networks.

Electricity consumption of Bitcoin. Source:

As is common for networks with BFT-style consensus, there will be a defined set of network nodes which participate in consensus finding.
In pure PoS systems, such nodes can be anonymous — referenced only by a public key. Sybil resistance is achieved by the requirement of a (large) economic deposit denominated in the network-native crypto-asset.
In pure PoA systems, operators of validator nodes are publicly known. There’s no economic deposit, but the reputation of the node operators is at stake.

The consensus protocol initially used by ARTIS is Aura, a simple and proven PoA protocol with higher dependency on synchronous clocks than typical BFT protocols.
We have extended the consensus protocol with a stake component. In order to join the validator set, a fixed amount of ATS (the ARTIS-native crypto-asset) needs to be provided to the consensus contract. Once locked in that contract, the on-chain governance mechanism gains exclusive control over that collateral.

Plans to deploy the Tendermint protocol had to be given up, because the Tendermint implementation of Parity we intended to use turned out to be unproven and unmaintained — as we figured out on our visit to RustFest Paris where we had the opportunity to talk to and drink beer with Parity core developers.

Nevertheless, we expect the use of the Aura consensus protocol to be temporary. From today’s perspective, a switch to the Honey Badger protocol is most likely. Its core feature is the ability to quickly adapt the performance to the network conditions. This leads to higher availability than even Tendermint offers, without compromising on consistency.
Honey Badger is currently being implemented in Rust and intended to be made available for Parity (as a Pluggable Consensus module) — as the developers have told us at Devcon4.


In ARTIS, nodes actively participating in the consensus protocol are named trustnodes and the individuals or entities operating them trustnode operators.
The network will start with a set of 5 trustnet operators. In the first 12 months, trustnode operators can run 1 or 2 trustnodes each, afterwards only 1 trustnode per operator is allowed.
Trustnode operators will be publicly known and are required to deposit a collateral of 4.5M ATS per trustnode. Collateral can be partially confiscated in response to trustnode misbehaviour. They thus have both reputation and economic assets at stake.

Operations like locking/unlocking/confiscation of collateral, changes to the set of trustnodes and upgrades of governance contracts are all governed through on-chain voting.

This are the initial rules for trustnodes:

  • good performance and high availability
  • responsiveness of the operator
  • must be physically separated from each other (cannot run on a virtual machine on the same server)
  • must be physically located in a country belonging to the European Economic Area (EEA) which is not part of the Five Eyes alliance
  • no cloud service provider (e.g. Amazon AWS) shall host more than 5 trustnodes
  • 6 months after the network launch, there must be at least 12 trustnodes
  • 12 months after the network launch, not more than 50% of the trustnode operators shall be residents (based on tax residency) of the same country

It is tempting to codify such rules as (smart) contracts, but there’s a problem: contracts cannot verify facts outside the system (e.g. the physical location of a trustnode or the residency of a trustnode operator).
What we can and will however do is using on-chain voting for transparently enforcing the rules. This can be done by creating binary ballots about individual rules.
Each trustnode has one vote, the majority determines what’s the truth. The consequences determined by the results of a ballot (e.g. reduction of block reward) are then automatically applied by the voting contracts.

Screenshot of the voting DApp interfacing with the governance contracts

In order to make lying expensive, we consider combining such ballots with a simple prediction market element: voting against the majority on binary ballots about the state of rule application would then incur an economic cost.

Initially, only trustnodes are involved in the governance process.
At some point in the future, the integration of a system like e.g. Holographic consensus will allow us to extend that to a much larger set of network stakeholders.

Trustnode voting should not be the only pillar of governance, because there’s a risk of collusion between trustnode operators.
That’s why we will look for an independent trustee who has no economic stake in ARTIS, but high reputation stake. This trustee is invited to observe the governance process and publicly report about it, acting as a trust anchor for those who don’t have the technical capability to observe and interpret what happens on the chain.


The native crypto-asset of ARTIS will be the ATS.
Issuance of ATS will take place partly in the genesis block (known as pre-mine or pre-minting) and partly as block reward.

300M ATS will be pre-minted.
The block reward will be 1 ATS per block (target block time: 5 seconds) in the first year. After the first year, 1 additional ATS per block will be minted into a sustainability pool. Usage of that funds is governed by trustnode voting.

Long term ATS supply curve

Initial funding for the ARTIS development was provided by institutional investors.
About 60% of the pre-minted ATS will thus be distributed to this early contributors and to the development team. The remaining 40% will be distributed by the lab10 collective for sustained support of the developement team and for future funding rounds.

DApp projects building on ARTIS will receive up to 10% of the total ATS supply over a maximum period of two years. The goal is to support about 100 DApp projects.


The ATS network is an Ethereum-compatible blockchain. 
ARTIS nodes run the Parity Ethereum client with Aura consensus protocol. The chain will from the start be configured like the Ethereum mainnet, but with the upcoming changes of the Constantinople hard fork already applied.

Also, ARTIS will have ewasm (WebAssembly for Ethereum) support enabled from the start. This allows smart contracts to be developed not only in a limited set of EVM-compatible languages (mostly: Solidity), but in any programming language supported by WebAssembly — there’s a lot of them, including Rust, a language with safety and performance properties making it a great choice for contract code.


ARTIS is envisioned to become a Plasmachain.
Plasma is a design pattern for allowing trustless movement of crypto-assets between blockchain networks.
As we got confirmed on Devcon4, there’s a lot of research and development going on around Plasma. Various specs and implementations of varying levels of maturity exist.
The latest breakthrough was a spec presented as Plasma Prime (initiating here) which claims to have solved all important problem for UTXO-style sidechains.

Plasma is about bridging specific assets / contracts.
For ARTIS, a Plasma flavour for EVM-based side-chains is needed. Such proposals exist and are continually refined, but there’s still some unsolved problems. 
Until such a solution exists, we will use more conventional chain bridging mechanisms in order to make assets transferable between Ethereum and ARTIS. Such bridges consist of contracts on both chains and of chain operators who listen to the changes on one chain and replicate them on the other chain.

Unlike Plasma connections, conventional bridges don’t allow permissionless state transfers based on cryptographic proofs (usually Merkle proofs). Instead they require either a trusted operator or a set of operators coordinating through a consensus protocol.
As we learned in Prague, Paritytech is currently working on tying the validator set running the consensus protocol of their bridge implementation to that of the chain itself. We consider using this implementation for ARTIS.


Last, but not least, there’s Streems, a feature unique to ARTIS.
We have developed a Rust implementation which is currently being finalized.
We have also developed a web-based ARTIS wallet with support for Streems. Currently this acts as a UX testbed for figuring out how to best visualize Streems.

screenshot of the ARTIS web wallet showing open Streems on a testnet

We have decided not to make Streems part of the core blockchain protocol, but convert the built-in contract to an ewasm-based library contract instead. That way, its functionality can be used by any crypto-asset.


In August, we wrote about the importance of identity.
We have since put a lot of focus on that aspect: we have become founding member of the MyData movement, signed an agreement with the Sovrin foundation for becoming a Sovrin Steward (meaning: having the privilege to run a validator node for their PoA blockchain) and attended the recent Internet Identity Workshop in Mountain View, California.

We have also started building the mobile App Minerva Wallet, our interpretation of what a digital wallet for both identity and assets could and should look like.
With Minerva, we want to make the concept of Self-sovereign identity tangible and accessible.
We aim to implement emerging standards (e.g. DIDs) as soon as possible, making Minerva a tool which anybody can easily integrate with — without any fears of getting locked in.

Minerva has evolved into a standalone project which is not tied to, but will closely integrate with, ARTIS.
It will not be the only wallet application for ARTIS — any wallet which supports Ethereum and can be configured for a custom Ethereum network (for example the popular Metamask browser extension) can interact with ARTIS.

Glimpse into the design concept for the Minerva Wallet

If you want to get involved or have a question, don’t hesitate to get in contact.
Your ARTIS team