What if your salary was paid in Libra?

Though Libra has a long way to go before running in production, the Libra testnet was launched on the day of the official announcement of the Libra project
This testnet is experimental, but is supposed to have the same properties as the mainnet, making application migration from testnet to mainnet straightforward.
So it makes sense to look into Libra with this testnet, assuming that the regulatory challenges will settle one day and Libra will launch its mainnet.

As the nitty-gritty regulatory work has just started to begin for Libra to go into production one day, we can see how ambitious this project really is. It is quite possible that it actually will never be launched at all.

So, we moved our use case a little bit into the future, but thanks to the Libra testnet, we can try it right now! (…with worthless Libra testnet coins of course…)

Working for the Wintermute DAO

As we are far into the future, we can be creative about the payment processes then. So our scenario is this:

Henry and his hacker buddies are working for the Wintermute DAO. They are not employed (employment these days is only possible for goverment jobs), but working based on a contract they signed with the Wintermute DAO, an AI representing a decentrally organized corporation and concluding contracts with all kind of external parties. 

We are not really sure why and how, but Excel actually survived the atomic wars, the zombie apocalypse and Ragnarök and is used by the Wintermute DAO to store the obligations to the contractors:

The DAOs payment processor reads these datasets line by line, extracts the amount and Libra address and transfers the amount. Optionally (see below) the signature is verified to make sure the address actually belongs to the contractor.

Starting the Payroll…

  1. Start the java-libra-shell
  2. Create account with mnemonic with command a cwm ‘chaos crash develop error fix laptop logic machine network patch setup void’
  3. Generated account 0 is Wintermute’s sender account. For each hacker account, add the index to the mnemonic, eg. to create Henry’s account, use a cwm ‘chaos crash develop error fix laptop logic machine network patch setup void’ 1
  4. Note the account balances and sequence numbers with command q b INDEX, eg. q b 1 for Henry’s account
  5. Run the java-payment-processor
  6. Note how the balances have now changed, account 0 (the sender account) has 700 Libra less, accounts 1-5 balances have increased with 100, 120, …. and the sequence numbers changed accordingly

Implementing the Payment Process in Java

Using Libra from Java is really simple: we have implemented the application using jlibra and the extension jlibra-spring-boot-starter.

As you can see from the repo, there is not much to do: 

  1. Create a pom.xml or build.gradle for your application
  2. Specify the application.properties for your testnet
  3. Inject the utility classes: JLibra, Peer2PeerTransaction, QueryAccountBalance, etc.
  4. Use the pre-configured classes in your application

We implemented all steps necessary for the payment processor in the Main class, the crucial functionality (coin transfer) is implemented in Main.java

private PeerToPeerTransfer peerToPeerTransfer;

private AccountStateQuery accountStateQuery;

private JLibra jLibra;

private long transferLibraToReceiver(String receiverAddress, BigDecimal amount) {
long seqNo = fetchLatestSequenceNumber(KeyUtils.toByteArrayLibraAddress(SENDER_PUBLIC_KEY.getEncoded()));
PeerToPeerTransfer.PeerToPeerTransferReceipt receipt =
peerToPeerTransfer.transferFunds(receiverAddress, amount.longValue() * 1_000_000, ExtKeyUtils.publicKeyFromBytes(SENDER_PUBLIC_KEY.getEncoded()), ExtKeyUtils.privateKeyFromBytes(SENDER_PRIVATE_KEY.getEncoded()), jLibra.getGasUnitPrice(), jLibra.getMaxGasAmount());
System.out.println(" (seqNo " + seqNo + ") " + receipt.getStatus());
return seqNo;

That’s all. In our sample application, this works against the testnet with the preconfigured accounts (corresponding to the mnemonic stated in the README).

Real World Use Cases before the year 2525

But how can we use this before the arrival of AI-Hackers and decentralized autonomous organizations? And what if we want to get our salary in EUR and just want to do international payments with Libra?

What did we do here? We connected Libra to an existing Java application. This Java application can do whatever Java applications do our days, most likely some enterprisey stuff. 

So how about connecting the payment processor of your corporate ERP system? Easy. How about integrating in one of those huge EAI products? Peasy. Workflows, BPNM Engines, Data Science frameworks? Yes, just like that. If it’s accessible from Java (or one language of the other adapters like JavaScript, Python, Go, Rust) it can use Libra. 

Bonus: Authorizing Transactions

In the old banking world, just giving your account information to the employer was enough. The banks checked all the regulatory stuff and made sure that the right person got the right money – or reverse the transaction if it was not. In the Libra world, that’s not that easy. 

There is a simple way of making sure that the address given is actually belonging to the person authorized to get the payment: signatures. By signing a pre-defined message like
I am working for Wintermute DAO and own Libra address 0x123 which should retrieve my earnings. Signed, Peter on 12/12/2103. 
It is easy to link the address to the signature, making sure that the address is correct as nobody could have signed the message without access to the private key of the Libra address. 

This way, the payments are arguably more safe than the old way of transfering money, given that “the system” makes sure that the address is checked for AML and is KYCed. This will presumably be true for the “wallet-level” applications in Libra.

jlibra – Connecting Libra to Java

Having learned from other Blockchain implementations, Libra starts with a nice package, a sound framework and concept and several developer goodies which other implementations had to invent first.

Right from the start Libra keeps mass adoption and developer attraction in mind and therefore is designed to be language agnostic. Even though the node is implemented in Rust, a gRPC interface is co-deployed, so other languages and platforms can easily use Libra through gRPC. 

Using Libra 101

Libra did a nice job in creating a usable package for developers. Though Windows is currently not supported, with Mac and Linux installing a Libra node and client is straigthforward and a Testnet is publicly available, so developers can immediately begin to explore the Move language and the patterns of the Libra Blockchain.

With the Rust node a client is included and a gRPC interface is deployed, so accessing the node is possible for a variety of languages and platforms.

Entering the Java Universe

There already exist several libraries for accessing the services directly from the languages without having to deal with gRPC itself. As Libra defined their interfaces with Protobuf, Java is well suited for using the interface, as Protobuf supports a quite sophisticated type system, which can be mapped to respective Java types. In contrast to other languages like JavaScript and Python, Java is statically typed and therefore the Java accessor classes must be generated from the Protobuf definitions in a precompile step.

Schematic Overview of Libra Integration into Java Environment

In Java, this is most often done by some build system, for jlibra a Maven step is executed before the Java class compile step, which generates the Java classes from the Protobuf definitions. An advantage of this precompile step is type-safety: as soon as the Protobuf changes, the library doesn’t compile any more, instead of failing at runtime.

Using Libra from Java Applications

As jlibra still is low-level and meant as a thin library layer above the Libra API, using the library requires some boilerplate code in Java applications which want to access Libra.

To keep this boilerplate to a minimum, two projects have been created on top of jlibra to ease development with Libra from Java: jlibra-spring-boot-starter and java-libra-client.

Structure of jlibra projects

Using jlibra in custom Java applications

With the dependency 


The JLibra project can be injected into any Spring-based project like this:

private JLibra jlibra;

This JLibra object is preconfigured and “ready-to-go” by Spring Boot externalized configuration, eg. you can provide an application.properties file with the configuration:


Currently, the spring starter project creates a gRPC channel, but you are free to provide your own implementation or inject a channel from the existing environment.

Predefined Actions

There are predefined actions in the action package of jlibra-spring-boot-starter:

  • AccountStateQuery
  • PeerToPeerTransfer

These actions can just be @Autowired and are preconfigured as well, so you don’t have to deal with jlibra directly.
This is WIP and other actions will be added soon.

private PeerToPeerTransfer peerToPeerTransfer;

public void transfer(...) {

How the starter project can be used to speed up developement for Libra in Java is demonstrated by the java-libra-client project.

Accessing Libra from a Java based Shell

The showcase provides the same functionality the Rust CLI provides, but is implemented in Java using Spring Shell. Though being usable as a standalone client, the main focus of this project is to show the integration patterns for Libra from Java applications.

You can try the initial release here: https://github.com/ice09/java-libra-client/releases/tag/v0.0-alpha-1

Start it with java -jar java-libra-client-0.0-alpha-1.jar

Sample recording of java-libra-client with account creation, balance query and coin transfer

Brief introduction to ENS

Brief introduction to ENS (Ethereum Name Services)

An Internet without Domain Name Service (DNS) is hardly imaginable. Addressing resources directly on the basis of their IP address would be a difficult and an error-prone undertaking. How nice it is that there is a Domain Name Service (DNS) that makes the mapping between machine-readable IP addresses and easily understandable memorable names for humans. With the help of DNS, we can easily locate resources on the Internet, even if their IP addresses have changed in background.

A similar function as DNS on the Internet, is ENS on the Ethereum blockchain. Resources of the Ethereum blockchain are primarily Smart Contracts. Contracts are addressed via a 20 byte address, represented as a 40-digit hex string.

The core elements of the Ethereum Name Service are specified in EIP-137. These are the core elements:

  •  ENS-Registry
  •  Resolvers
  •  Registrars

The ENS Registry is a contract that is responsible for the administration of domain names. In addition to mapping domain names to a linked resolver contract, the registry is responsible for ensuring that the owner of a domain has the permission to set up new sub-domains for this domain or to change entries in the resolver.

Revolvers are responsible for responding to resource requests to a domain and return, for example, the contract address, the ABI of a contract or the publickey of a wallet. Each domain name has a link to its resolver.

The registrar is the owner of a domain. Only the registrar has the right to register new sub-donains or change resources. Registrars are contracts or owned accounts. Top- and second-level donains are usually managed by a registrar contract. For example, the second-level domain of Mainnet is administered by a registrar which implements an auction procedure for the allocation of new domains.

Analogous to DNS, the namespace is hierarchically subdivided. Individual domains are separated by dots. The DNS structure of top-level, second-level and sub-domains has been adopted. A valid domain name is, for example, ‘earth.planets.eth’. Domain names are mapped to sha3-hashs (keccak_256). The derivation of the hash is defined by the following namehash function:

def namehash(name):
  if name == '':
    return '\0' * 32
    label, _, remainder = name.partition('.')
    return sha3(namehash(remainder) + sha3(label)) 

The hash of ‘earth.planets.eth’ is calculated as follows:

sha3(sha3('eth') + sha3(sha3('planets') + sha3('0x0000000000000000000000000000000000000000000000000000000000000000' + sha3('earth'))))

Reverse Name Resolution

In addition to mapping a domain name to its resources such as address, ABI or publickey, ENS also supports reverse mapping from an address to its domain name. The procedure for this is described in EIP-160. For reverse mapping, the resource address is registered under the reverse domain name ‘address’.addr.reverse. The resolver for the reverse domain name holds the name of the original domain. The registrar of the domain ‘addr.reverse’ provides a function setName(‘domain’) under which a caller registers his domain-name.


The following example shows how to install ENS including a registrar for reverse name resolution. Deploying all contracts requires a working truffle environment and access to an Ethereum node such as Ganache. You find the project repository at GitHub: Ehereum-ENS-Demo

Step 1: Contract Deployment

In the first step all required contracts are deployed. The script ‘2_deploy_ENS.js’ deploys the ENS-Registry (ENS.sol), the registrar for the top-level domain (FIFSRegistrar.sol), the registrar (ReverseRegistrar.sol) for the reverse domain, the resolver (PublicResolver.sol) for answering resource requests. Finally, the domains ‘planets.eth’ and ‘addr.reverse’ are registered.

The script ‘3_deploy_Planets.js’ deploys a demo contract and registers it under the name ‘earth.planets.eth’ and its addresses in the domain ‘addr.reverse’ with the name ‘earth.planets.eth’. The contract ABI is also packed in zlib format and assigned to the domain as a resource.

The entire deployment is started with the command:

truffle migrate --reset

Step 2: Access earth.planets.eth

The command

npm install

installs all necessary libraries. The libraries ethereum-ens and web3 are used for easy access to ENS and resources of a domain. Before start, the address of the ENS registry must be added to the script (see const ensAddr).

The script is started with the command `node scripts\call_Earth.v1.js`. First the script determines the address and ABI of the domain name ‘earth.planet.eth’, then creates a client for contract access. In the second step, the domain name stored for the address is determined and printed.

The library “ethereum-ens” simplifies the access to the ENS registry. Alternatively, the script ‘scripts\call_Earth.v2.js script’ shows access to the ENS registry without using “ethereum-ens”. The script is started with:

truffle exec scripts\call_Earth.v2.js

More Ressources

invite_me: Onboarding to Ethereum chains with keybase.io identity verification and EIP-712

This is not a Blockchain-bullshit-only post. Head to https://github.com/ice09/onboarding-eip712 for a sample implementation of a private Testnet onboarding with Twitter, Reddit or Github Keybase proofs.

The challenge…

Creating a private Ethereum Proof-of-Authority testnet is actually quite easy, just follow the instructions of Parity or, for testing purposes only, cliquebait, and you’re done.

But how do you onboard new users, who want to participate in your testnet, if they don’t have any ETH to start with and you still want to stay as close to your production environment in terms of gas usage as possible and therefore don’t want to enable gasless transactions in your PoA testnet?

…and the public testnet solutions

Kovan PoA

The public (Parity-powered) Kovan PoA solves this problem by providing a “Faucet Service” which is verified by

Rinkeby PoA

The public (Geth-powered) Rinkeby PoA solves this problem by providing a “Faucet Service” which is verified by

However, these methods require trust or establish dependencies on the testnet providers, which you will and can most likely not introduce in your private net. 

Analysing the problem

There are (at least) two different user states which a user can have in your PoA private testnet:

  1. The user has an authorized account in one of the authority node wallets.
  2. The user is connected to the private testnet, but initially has no balance.

In Proof-of-Work (PoW), the non-authorized user could start mining and get ETH for contract development. This is the Ropsten solution. In PoA, mining is not possible, so the user has no possibility to transact on the chain, except for using usd_per_tx=0 or similar for no gas costs on the authority nodes, which is possible, but contradicts the security measures established by having gas usage for transactions to minimize code execution, prevent infinite loops, etc. Even more, the setup on a test stage should always be similar to the production environment.

Recentralizing for “Almost Know Your Customer”

keybase.io does a great job in identifying users without revealing their real life identity if they don’t want to. But they make it quite difficult for attackers to create several identities. So a good enough solution for onboarding otherwise unknown users could be to bind their testnet accounts to their keybase users.

The basic idea and the following approach is inspired by Aragon and one of their great blog posts, which every Ethereum/Solidity dev should take a look at.

In our setup, we changed two crucial factors:

  1. removed dependencies on a product (Aragon) and on the Oracle (oraclize.it) and
  2. introduced a middleware component as a new dependency, but which you control and can (and have to) host on your own server.

keybase allows for publishing files per HTTPS by copying them to KBFS file system. Thereby, someone reading a file from https://KEYBASE_USER.keybase.pub/invite_me.json can be sure that the file invite_me.json was stored by keybase KEYBASE_USER.

But this is just one proof, how can we be sure that the user really has the private key for the address he wants to be registered? We can just sign the message with the private key and ecrecover in a contract. 

Using this mechanism, we can be sure that:

  1. If the URL https://KEYBASE_USER.keybase.pub/invite_me.json gives back the correct JSON, the user is who he pretends to be, since he had to copy invite_me.json to KBFS
  2. The address (private key) belongs to the user, since he signed the message in invite_me.json and the signature is ecrecovered in the invite_me contract.

MetaMask does a great job in helping signing data with your Ethereum’s account private key. However, up to EIP-712 the signed data has been displayed as a non-human-readable Hex string.

This is unacceptable, especially in crypto, a field of very easy and unavoidable fraud attempts. 

Therefore, we are supporting EIP-712 by signing with a MetaMask version supporting the new eth_signTypedData method. EIP-712 is a major step forward and should be the only way users are required to sign data with their Ethereum account’s private key.

The following overview shows the process which let a new user register his keybase user to a new generated address. Afterwards, 10 ETH are sent to this address. The user can only register once. However, the contract owner can manually unregister users if necessary.

For the ETH transfer to happen, the user must

  • have the invite_me.json as generated by the frontend part stored in his KBFS public directory, so that it can be retrieved by the server side process at the keybase.pub domain
  • have at least one of these Keybase proofs: Twitter OR Github OR Reddit

Introducing invite_me

The complete process is implemented in the “DApp” invite_me, which consists of a JavaScript frontend and a web3j-powered Java backend component called verifier.

After completing the steps, you can see the 10 ETH loaded into your account in MetaMask.

Let me try this!

First, checkout this. Then, make sure that you have an understanding how the authorization and verification works and what the Java component verifier does and how they depend on each other.

Last, install it locally and try it out. And, most importantly, please comment here or in the reddit post if it doesn’t work for you or if you have remarks about the approach, obviously this is work in progress.

What comes next?

We’d like to try two different approaches:

  • Using 3box as a more decentralized (but not as mature) keybase alternative
  • Realizing a different use case: “Almost KYC Airdrops” 

Excel2Blockchain with web3j

If you ever come to the conclusion, for whatever reason, that pushing Excel data to the Blockchain is what you need, we are happy to help!

We recently read about the Azure Blockchain Development Kit and had to cringe about the samples. But, who are we to judge those important enterprise business use cases requiring to get data from Excel to the Blockchain? 

Therefore, we took a look at the prerequisites, setup, initialisations and finally the execution of this with the new Microsoft Azure templates. And, to be clear, we love the idea of Microsoft getting involved into Blockchains and Ethereum and pushing Azure as a starter kit, that’s really great.

However, the whole procedure seemed quite long and exhaustive, that’s why we want to show how easy this is with standard development methods. Of course, these are lacking a lot of features and cool stuff you get with Azure then. But, they can help you to understand better what happens under the hood. So, let’s go for it.

No, wait, Excel to Blockchain, honestly? Why?

//TODO: Insert suitable reason here.

Ok then, but how?

Due to web3j it is really easy to connect to an arbitrary Ethereum Node, even Infura and Ganache, as simple as it is with web3.js or web3.py. All the other stuff is common Java dev tools, like Glueing with Maven, Excelling with Apache POI, etc. This is where Java shines, it’s really good at enterprisey integration stuff.

You can start directly and import the sources as a Maven project in your IDE or build it without an IDE and start it from the command line. See the details here.

Show me some code!

private void connectToBlockchain() throws IOException {
Web3j httpWeb3 = Web3j.build(new HttpService("http://localhost:8545"));
log.info("Connected to HTTP/JSON Ethereum client version: " + httpWeb3.web3ClientVersion().send().getWeb3ClientVersion());
// Create credentials from private key.
// Don't use with real (Mainnet) Ethereum accounts.
String privateKeyDeployer = "c87509a1c067bbde78beb793e6fa76530b6382a4c0241e5e4a9ec0a0f44dc0d3";
Credentials credIdentity = Credentials.create(pkDeployer);
BigInteger balance = httpWeb3.ethGetBalance(credIdentity.getAddress(), DefaultBlockParameterName.LATEST).send().getBalance();
log.info("Deployer address " + credIdentity.getAddress() + " has " + balance + " wei.");

private void deployExcelContractToBlockchain() throws Exception {
ExcelStorage excelStorageContractHttp = ExcelStorage.deploy(httpWeb3, credIdentity, ManagedTransaction.GAS_PRICE, Contract.GAS_LIMIT).send();
log.info("Deployed contract at " + excelStorageContractHttp.getContractAddress());

As you can see, ExcelStorage is a class which can used like any other Java class. It has been generated by a Maven plugin (web3j-maven-plugin) during build time. It is statically typed with methods resembling the Solidity functions of the smart contract and with all the nice aspects this has: compile time checks instead of runtime checks and brilliant IDE support (code completion, type checking, static code analysis).

With great IDE and build tool support, you can try this out yourself, you will be surprised how lightweight and easy Ethereum smart contract usage is from Java. Even more, integration with your existing (“legacy”) software and infrastructure is straightforward. 

Have fun!

Addendum: This is a Testsetup only! What about the real Blockchain?

Where does the private key in the current Java sources come from? 
If you start Ganache with the mnemonic mentioned, everytime the same accounts are generated. The first one being 0x627306090abaB3A6e1400e9345bC60c78a8BEf57. This address has one private key which is set into the Java sources to create the Credentials for contract deployment and transactions.

Setup for other test chains

  • Create an account with infura.io
  • Use the Endpoint URL from the dashboard and copy in into the Java sources

  • Create an account with MetaMask
  • Copy the address of your account

  • Copy the private key to the Java source code to use the account for contract deployment and transactions

Identity is the New Money

This post is inspired by the book with the same title, which we found in in this nice summary post by Alex PreukschatIn that blog post and especially in the book you will find all information about Self-Sovereign Identity. We will only refer to the concepts if they are feasible for our samples.

This is not a Blockchain-bullshit-only post. Head to https://github.com/ice09/identity for a sample implementation of the “federated” claim issuer sample.

The Story of Alice, Booze and her local Bank

Alice just turned 18 years old, being in good ol’ Germany she wants to celebrate this with a lot of booze, but her parents refused to buy it for her, since she can do this on her own now.

Currently, she can do this easily by showing her identity card when buying the drinks. The dealer would check her birthdate and verify her age.

This obviously has major shortcomings:

  • The ID could easily be altered, stolen or otherwise not belonging to the person showing it
  • The dealer gets a lot more information than necessary for this transaction, including a lot of sensitive personal data: name, address, height, etc.

So, the dealer would just have to verify that the person is older than 18 years, how could this work with Alice and eg. her local bank?

The book differentiates between identity and statements about this identity (claims), which entitle the person to do things. In our example, the fact that Alice turned 18 years old entitles her to buy and drink alcohol (in certain legislations). However, showing the identity card to the dealer mixes up two aspects very badly: the dealer has to check the identity information to derive the entitlement. This he has to do by himself, if for whatever reason (eg. the dealer not being able to calculate the age) he cannot derive the entitlement, Alice’s intention would be rejected. Also, only information which can be derived from the identity information can be used, if eg. Alice would be incapacitated and therefore not allowed to buy alcohol, the dealer wouldn’t know, since this information is not stated on her identity card.

In the world of cryptography and decentralized data storage (read: DLT), Alice’s bank could easily help her with an identity or better: entitlement verification service. Since Alice participated at the bank’s KYC process, the bank has a lot of information about Alice, one of these being her age. Now, if the local bank is trusted by the shop owner, this information would be enough for the owner: “As your local trusted bank, we verify that this customer is older than 18 years.”

Setup for Ethereum

In Ethereum, the easiest setup would be to use ERC 725/735. These standards (requests) provide all necessary equipment for identity creation and claims/endorse mechanism. Other standards and products are provided by uPort and standard bodies like the W3C DID.

The initial setup Alice has to execute, together with the claim issuers like the bank, a utility provider, an insurance company, etc. consists mainly of three steps which could easily be embedded into a mobile app:

  • Alice creates an identity ERC 725/735 (which might be one of multiple identities she has)
  • As a claim issuer, the bank adds a claim (using ERC 735 addClaim(…)) about Alice being older than 18 years. This claim is signed by the private key of the bank. The claim is stored with a returned ID and must be approved by Alice (1, 2).
  • Alice approves (using ERC 725 approve(claimId)) the bank’s claim on her identity.
  • Now, anyone can verify the claim about the topic she is interested in, eg. the fact that the identity is older than 18 years (4).

After the setup the process of verifying a claim is depicted below:

  • Alice signs a challenge of the shop owner with her private key (3).
  • With the derived public key of Alice, the shop owner can identify the claim in ERC 735 and check the signature of the trusted party, which is Alice’s bank (4), against the publicly available public key of the bank.

This would make a great use case for banks desperately looking for their next Blockchain use case: forget about value transfer, asset creation, settlement and whatnot, you are fighting against proven and established systems which might be embedded in complex processes but have been running stable, reliable and performant for years.

Identity verification on the contrary could be a completely new service offering and banks have the great advantage of having identified thousands of customers in strongly regulated processes, they have valuable data at their hand. The same is true for insurances, mobile providers, utility providers, governmental companies, etc.

But let’s say we want to decentralize even more, how could we go on?

Incentivizing Identity Verification

Couldn’t we incentivize people for doing something only they are able to do right: prove the identities of their social network?

There are some assumptions:

  1. People know their social environment best, especially their direct environment like family, best friends and neighbors.
  2. People want to earn (even few) money with something they – and only they – can do easily following a simple procedure

The process is almost equal to the process above, except that notaries are slashed if they defraud and earn fees if they behave according to the protocol. The slashing is complex and would have to be implemented by some governance mechanism. This step adds complexity, but is solvable and will be very similar to PoS. Most likely there will be a incentivization for detecting and proving fraud included into the protocol.

Incentivization is a great means for getting anonymous parties to agree on a fact. This works great for Blockchains and has also been proven theoretically by eg. game theory and the Nash equilibrium.

Therefore, with incentivization of notaries, their advantage of doing fraud is minimized.

Build a Social Network based on Trust

Trustlines is a decentralized, permissionless, open platform to host currency networks in which money is represented as IOUs issued by its participants. Trustlines implements money as bilateral peer-to-peer issued blockchain-based credit.

In the example above Bob gave Alice a creditline of 20 EUR and Alice Bob of 100 EUR, so they have bilateral creditlines which is a trustline. Bob gave Charly 30 EUR credit and Charly Bob 50 EUR. Now if Alice wants to pay Charly, whom she doesn’t know personally, the system finds a path between Alice and Charly (via Bob) and the creditlines will be used. If Alice pays Charly 10 EUR, Bob afterwards owes Charly 10 EUR and Alice owes Bob 10 EUR. The creditlines have been used and the remaining credit is lower or higher, depending on the direction of the payment.

There is no settlement in the system, if it is necessary or wanted by some party to settle, this is done outside of the system and then reflected in the system by an opposite transaction.

More information about the project is available on trustlines.network, we encourage you to inform yourself about its concepts of people powered money and complementary currencies and its potential to boost cryptocurrencies adoption and enhance accessibility for cryptocurrencies for all people.

Extra Trustlines Benefit: Socially proven Identity

However, for this blog post, a secondary aspect of Trustlines is more important: if you have a social network of trust, you have a social network of identities. This is immediately obvious by the simple fact that if you trust someone with a certain amount of money, you certainly know and trust this person, because you are in risk of losing money if your creditline is used. Depending on the social context this can be family members, good friends, co-workers and the amount of credit you give will mirror your amount of trust in these people.

Given a network with creditlines, people will most likely have creditlines with different people and a identity (and reputation) algorithm could value the amount of credit given and the number of creditlines for a probabilistic identity verification.

This might even be pseudonymous, as someone offering a service for money, I am most interested in a receiver to pay me money, which is related to his trustworthyness and therefore to the amount of creditlines given, not so much who this person actually is. If 10 people who have medium sized networks of creditlines have creditlines with the receiver, I am tending to assume that:

  1. This person actually exists
  2. This person is trustworthy for some amount to other people

For now, this is the only attribute of identity which Trustlines helps solving, but with very high accuracy: if a person actually exists and that this person is trustworthy to some degree.

We won’t have information about other identity attributes like gender, age, wealth, educational degrees and so on.

Let’s fix Identity now!

If you didn’t know a good use case for Blockchain technology, now you have it. This is one of the most natural use cases for a decentral, immutable database accessible by everyone without central control and the possibility to incentivize people.

This is a win for all involved parties, enhancing privacy and security and enabling service providers to make use of their already available data. As there is no “disruption” of any existing business model, but a creation of a completely new one, public identity management can only get better.

Token ERC Comparison for Fungible Tokens

“The good thing about standards is that there are so many to choose from.” Andrew S. Tanenbaum

Current State of Token Standards

The current state of Token standards on the Ethereum platform is surprisingly simple: ERC-20 Token Standard is the only accepted and adopted (as EIP-20) standard for a Token interface.

Proposed in 2015, it has finally been accepted at the end of 2017.

In the meantime, many Ethereum Requests for Comments (ERC) have been proposed which address shortcomings of the ERC-20, which partly were caused by changes in the Ethereum platform itself, eg. the fix for the re-entrancy bug with EIP-150. Other ERC propose enhancements to the ERC-20 Token model. These enhancements were identified by experiences gathered due to the broad adoption of the Ethereum blockchain and the ERC-20 Token standard. The actual usage of the ERC-20 Token interface resulted in new demands and requirements to address non-functional requirements like permissioning and operations.

This blogpost should give a superficial, but complete, overview of all proposals for Token(-like) standards on the Ethereum platform. This comparison tries to be objective but most certainly will fail in doing so.

The Mother of all Token Standards: ERC-20

There are dozens of very good and detailed description of the ERC-20, which will not be repeated here. Just the core concepts relevant for comparing the proposals are mentioned in this post.

The Withdraw Pattern

Users trying to understand the ERC-20 interface and especially the usage pattern for transfering Tokens from one externally owned account (EOA), ie. an end-user (“Alice”), to a smart contract, have a hard time getting the approve/transferFrom pattern right.

From a software engineering perspective, this withdraw pattern is very similar to the Hollywood principle (“Don’t call us, we’ll call you!”). The idea is that the call chain is reversed:  during the ERC-20 Token transfer, the Token doesn’t call the contract, but the contract does the call transferFrom on the Token.

While the Hollywood Principle is often used to implement Separation-of-Concerns (SoC), in Ethereum it is a security pattern to avoid having the Token contract to call an unknown function on an external contract. This behaviour was necessary due to the Call Depth Attack until EIP-150 was activated. After this hard fork, the re-entrancy bug was not possible anymore and the withdraw pattern did not provide any more security than calling the Token directly.

But why should it be a problem now, the usage might be somehow clumsy, but we can fix this in the DApp frontend, right?

So, let’s see what happens if a user used transfer to send Tokens to a smart contract. Alice calls transfer on the Token contract with the contract address 

….aaaaand it’s gone!

That’s right, the Tokens are gone. Most likely, nobody will ever get the Tokens back. But Alice is not alone, as Dexaran, inventor of ERC-223, found out, about $400.000 in tokens (let’s just say a lot due to the high volatility of ETH) are irretrievably lost for all of us due to users accidentally sending Tokens to smart contracts.

Even if the contract developer was extremely user friendly and altruistic, he couldn’t create the contract so that it could react to getting Tokens transferred to it and eg. return them, as the contract will never be notified of this transfer and the event is only emitted on the Token contract.

From a software engineering perspective that’s a severe shortcoming of ERC-20. If an event occurs (and for the sake of simplicity, we are now assuming Ethereum transactions are actually events), there should be a notification to the parties involved. However, there is an event, but it’s triggered in the Token smart contract which the receiving contract cannot know.

Currently, it’s not possible to prevent users sending Tokens to smart contracts and losing them forever using the unintuitive transfer on the ERC-20 Token contract.

The Empire Strikes Back: ERC-223

The first attempt at fixing the problems of ERC-20 was proposed by Dexaran. The main issue solved by this proposal is the different handling of EOA and smart contract accounts.

The compelling strategy is to reverse the calling chain (and with EIP-150 solved this is now possible) and use a pre-defined callback (tokenFallback) on the receiving smart contract. If this callback is not implemented, the transfer will fail (costing all gas for the sender, a common criticism for ERC-223).



  • Establishes a new interface, intentionally being not compliant to ERC-20 with respect to the deprecated functions
  • Allows contract developers to handle incoming tokens (eg. accept/reject) since event pattern is followed
  • Uses one transaction instead of two (transfer vs. approve/transferFrom) and thus saves gas and Blockchain storage


  • If tokenFallback doesn’t exist then the contract fallback function is executed, this might have unintended side-effects
  • If contracts assume that transfer works with Tokens, eg. for sending Tokens to specific contracts like multi-sig wallets, this would fail with ERC-223 Tokens, making it impossible to move them (ie. they are lost)

The Pragmatic Programmer: ERC-677

The ERC-667 transferAndCall Token Standard tries to marriage the ERC-20 and ERC-223. The idea is to introduce a transferAndCall function to the ERC-20, but keep the standard as is. ERC-223 intentionally is not completely backwards compatible, since the approve/allowance pattern is not needed anymore and was therefore removed.

The main goal of ERC-667 is backward compatibility, providing a safe way for new contracts to transfer tokens to external contracts.


  • Easy to adapt for new Tokens
  • Compatible to ERC-20
  • Adapter for ERC-20 to use ERC-20 safely


  • No real innovations. A compromise of ERC-20 and ERC-223
  • Current implementation is not finished

The Reunion: ERC-777

ERC-777 A New Advanced Token Standard was introduced to establish an evolved Token standard which learned from misconceptions like approve() with a value and the aforementioned send-tokens-to-contract-issue.

Additionally, the ERC-777 uses the new standard ERC-820: Pseudo-introspection using a registry contract which allows for registering meta-data for contracts to provide a simple type of introspection. This allows for backwards compatibility and other functionality extensions, depending on the ITokenRecipient returned by a EIP-820 lookup on the to address, and the functions implemented by the target contract.

ERC-777 adds a lot of learnings from using ERC-20 Tokens, eg. white-listed operators, providing Ether-compliant interfaces with send(…), using the ERC-820 to override and adapt functionality for backwards compatibility.


  • Well thought and evolved interface for tokens, learnings from ERC-20 usage
  • Uses the new standard request ERC-820 for introspection, allowing for added functionality
  • White-listed operators are very useful and are more necessary than approve/allowance, which was often left infinite


  • Is just starting, complex construction with dependent contract calls
  • Dependencies raise the probability of security issues: first security issues have been identified (and solved) not in the ERC-777, but in the even newer ERC-820

(Pure Subjective) Conclusion

For now, if you want to go with the “industry standard” you have to choose ERC-20. It is widely supported and well understood. However, it has its flaws, the biggest one being the risk of non-professional users actually losing money due to design and specification issues. ERC-223 is a very good and theoretically founded answer for the issues in ERC-20 and should be considered a good alternative standard. Implementing both interfaces in a new token is not complicated and allows for reduced gas usage.

A pragmatic solution to the event and money loss problem is ERC-677, however it doesn’t offer enough innovation to establish itself as a standard. It could however be a good candidate for an ERC-20 2.0.

ERC-777 is an advanced token standard which should be the legitimate successor to ERC-20, it offers great concepts which are needed on the matured Ethereum platform, like white-listed operators, and allows for extension in an elegant way. Due to its complexity and dependency on other new standards, it will take time till the first ERC-777 tokens will be on the Mainnet.


[1] Security Issues with approve/transferFrom-Pattern in ERC-20: https://drive.google.com/file/d/0ByMtMw2hul0EN3NCaVFHSFdxRzA/view

[2] No Event Handling in ERC-20: https://docs.google.com/document/d/1Feh5sP6oQL1-1NHi-X1dbgT3ch2WdhbXRevDN681Jv4

[3] Statement for ERC-20 failures and history: https://github.com/ethereum/EIPs/issues/223#issuecomment-317979258

[4] List of differences ERC-20/223: https://ethereum.stackexchange.com/questions/17054/erc20-vs-erc223-list-of-differences



Is it a blockchain or is it a DLT?

In various discussions I often hear people saying “But that’s not blockchain! That’s DLT!”. This sounds like blockchain and DLT would be two totally different things, while in fact, blockchain is a specific implementation of a DLT.  What most people actually mean is something like this: “But that’s not public, unpermissioned and egalitarian! That’s private, permissioned and authoritarian!”.

While I’m waiting to see the terminoligy get standardized, I have decided for myself to apply the following three-dimensional categorization:

private / public – connectivity to the network. E.g.: are nodes accesible via Internet or Intranet? Can anyone join or is it limited to a closed user group?

permissioned / unpermissioned – access regulation. Do I need a permission/invitation to join the network?

egalitarian / authoritarian – are all participants (potentially) equal in their rights?

The obvious two categories are the two well known extrems:

Public unpermissioned egalitarian – The participant doesn’t have to ask someone for permission to join. He can create an account (private/public key pair) by himself  and he can immediately start to use the network via Internet. Every participant in the network has the same rights (but not necessarily the same means). Typical representants of this category are Bitcoin and Ethereum.

Private permissioned authoritarian – The participant needs a permission or an invitation to join the network. There are authorities, which grant/revoke the rights. The network is private and/or the connection to it is regulated (firewals, whitelists, VPN, …). Typical representants are Hyperledger Fabric and Corda.

How about the other 6 categories? Of what use could they be? Let me try to describe the public one first, since the private variants are a narrower version of it.

Public permissioned egalitarian -the participant needs a permission to join the network, but as soon as he joined, he has the same rights as other participants. For instance an invite-only social network.

Public permissioned authoritarian – the network is open to everyone, but the onboarding and transaction validation is done by the network authorities. Example for this are RippleTobalaba Test Network, and Infrachain (maybe?). What I also could imagine is to have for instance a Europe-wide Proof of Authority Ethereum network. Let’s call this theoretical construct Eurochain. In Eurochain each government has a sealing node and is onboarding its citizents after checking their identity.

Public unpermissioned authoritarian – Same as above but with the difference that participants can join without asking for a permission.

Private permissioned egalitarian – this seems weird at first, but if you put it in the context of an extranet (see CredNet for example, which is the network connecting all German saving banks (Sparkassen)), it starts to make sense again. However, I have not observed one yet.

Private unpermissioned authoritarian – a narrower variant of the public one. For instance if the theoretical Eurochain is not intended to be used by the citizens but only for the communication between governments themselves.

Private unpermissioned egalitarian – more open variant of the permissioned one.

Das große Mining Abtenteuer ….

… oder der neue Mining Goldrausch mit Crypto – Währungen.

Bitcoin Mining hat sich in den letzten Jahren deutlich verändert. Zuerst experimentiert man mit seiner eigenen CPU, dann nutzte man seine Grafikkarte und zum Schluss begann der Krieg der ASIC Miner. ASIC (Application Specific Integrated Circuit).

Wer mit dem ASICs Mining Geld macht, entschied sich weitgehend anhand der Stromkosten und wer neue effiziente Modelle herstellen konnte. Daher verwundert es nicht, dass nur noch dort wo der Strom billig war, mehr und mehr Miner sich konzentrierten. Die klugen Miner gehen auch noch dahin wo das Klima kälter ist, um die kosten für die Klimatisierung gering zu halten.

Die Preisbewegungen und der Boom der Cryptos in der ersten Jahreshälft 2017 hat die Karten für einen begrenzten Zeitraum neu gemischt. Auf einmal konnte man wieder mit seinem Gaming PC profitabel Minen. Der Ethereum Algorithmus Ethash läuft aktuell am besten auf einer Spielegrafikkarte, die Gewinne reichten aus um auch in Länder mit hohen Stromkosten die laufenden Kosten zu kompensieren.

Der Mining Markt kam in Bewegung, immer mehr private Miner bauten sich Mining Rigs, auf youtube gibt’s eine menge Filme dazu mit sehr spannenden Konstruktionen und die Motherboard und Grafikkarten Hersteller produzieren Gaming Hardware die nur noch für das Minen ausgerichtet ist.

Am besten lässt sich der Minig-Boom am Verlauf der produzierten Hashrate im Ethereum Netz über die Zeit, oder dem Aktienverlauf von Nvidia ablesen.


Stand 7.9.2017 werden ca. 90 tera Hashes im Ethereum Netzwerk fürs Mining erzeugt. Eine Nvidia Geforce 1070 generiert ca. 30 Mega Hashes, d.h. alleine für Ethereum würden aktuell alleine 3 Mio. Grafikkarten verwendet. Die Karte benötigt ca. 100 Watt wenn sie richtig eingestellt ist, also werden mindestens 300 Megawatt für das Ethereum Netzwerk verbraucht. Eine durchschnittliche Windkraftanlage erzeugt 3 MW, d.h. min. 100 Windräder laufen nur für Ethereum.

Die meisten verwendeten Karten erzeugen weniger Hashes und verbrauchen mehr Strom.

Die verwendeten Algorithmen unterscheiden sich stark im Stromverbrauch, So benötigt das Minen der Währung Monero weniger Leistung, Ethereum liegt im Mittelfeld, wohingegen Zcash 10..20 % mehr Energie aufnimmt. Jede Währung hat eine eigne optimale Configuration von Leistung, Speicher- und GPU Taktrate.

Das Minen von Ethereum hat einen weiteren Pferdefuß. Nicht nur die stark wachsende Anzahl der Mining-Grafikkarten reduzieren die Erträge, auch die „difficulty bomb“ im Code sorgt für fallende Erträge. Sie macht das Mining schrittweise unattraktiver bis zum nächsten Release, in dem der Konsen-Algorithmus auf Proof-of-Stake umgestellt wird.

Auf der folgenden Website wird der Effekt deutlich:


Andere Cryptos haben zwar keine „difficulty bomb“ und bleiben beim Proof-of-Work, es ist jedoch zu beobachten, dass der Hashrate Markt sehr effizient ist, Ethereum Miner wechseln zu Zcash, Monero etc. so dass die Mining-Erträge dort analog sinken und sich dem Strompreis nähern.

Welcher Coin welchen Algorthmus verwendet findet man unter anderen auf whattomine.com oder bei der Börse cryptopia.co.nz.

Die Preise für Mining geeignet Grafikkarten ist ebenfalls im Sommer schnell angestiegen um bis zu 50 %, sinkt jetzt jedoch schon wieder, hat aber noch nicht das Mai Niveau erreicht. Glaskungeln gehen davon aus, dass sie Anfang 2018 wieder auf dem Level von vor dem Boom sind.

Wie bei jedem Goldrausch verdienen auch bei diesem die Verkäufer von Schaufeln am meisten Geld. Neben Nvidia und AMD scheinen auch die Entwickler von Miningsoftware das große Geld zu machen. Der weitverbreitete Claymore Mining-Software nutzt 1% der Mining-Zeit für den Entwickler. Das könnte bedeuten, wenn 10% der Miner die Software von Claymore verwenden, jede Grafikkarte 40 $ in Cryptos pro Monat schürft, dann würde der Entwickler 0,40$ pro Grafikkarte und Monat verdienen. Das wären bei 3 Mio. Karten einnahmen von 120.000 $ im Monat. Vermutlich verwenden jedoch mehr Grafikkarten den Claymore Miner.

Ob es sich lohnt einen Rechner fürs Minen zu bauen, muss jeder für sich entscheiden. Einen positiven Business Case auf lange Sicht zu rechnen ist schwierig, in der ersten Hälfte des Jahres 2017 hätte man mehr Geld verdient, wenn man das Kapital für einen Rechner direkt in Ether investiert hätte, jedoch ist der Spaß einen eignen Rechner zusammen zu bauen unbezahlbar.

Blockchain vs. Database

When should I use blockchain and when a database? 

A lot of companies and consultants are looking for meaningful use cases and blockchain implementations, the problem is no one has really experience dealing with the professional blockchain principles, architectures or the technologies. The result of the first considerations could be the transfer of existing concepts to blockchain technologies. This way, consulting companies will make a lot of money, but sustainable solutions will not be produced. The result will be very complex and expensive systems where solutions with a simple database and an standard application server would have been cheaper and better.

What are the parameters you can look for to find the right decision?

Business model: If the business between two partners 1:1, or sell company products or service to many companies 1: many, or sell many marketers something to many customers many: many

Governance of the IT solution and the business model: Is one of the partners responsible for the IT solution and business model?

IT platform: Is the IT platform, e.g. Application Server, etc central or distributed over many participants?

Let’s look at all possible combinations which can work and which are suitable for a blockchain solution:

Business ModellGovernanceIT ArchitectureSolution
many:manysingle/hierarchical centraldatabase - platform use case
single/hierarchical decentralDLT or blockchain

If the transaction only takes place between two parties or a supplier sells a product to many customers, then a blockchain based solution is probably not the appropriate approach in many cases. But it is possible to use it, if the features of a blockchain are helpful, i.e. you want to have journal where you can prove the immutability of electronic contratcs or publication. The functionality of stampery is good example for it.  

Blockchain is more exciting in a market where many suppliers want to sell something to even more customers.

If one chooses a hierarchical governance and a central IT architecture with central databases and application servers, the result will be a classic Silicon Valley platform approach. The money will be made by the platform providers like Uber, Amazon or Ebay.

Theoretically, a solution with cooperative governance and a central IT solution could work. All the projects I have seen so far in the way have failed terribly, it’s not possible for the central solution to fulfill all unspoken requirements from different  stakeholders with more or less equal rights.

There are still two useful scenarios:

Hierarchical professional business and technical control and specifications and decentralized IT architecture. The technical features of the blockchain are in the foreground, transparency, stability, etc. can be the base of an successful and useful IT system. 

When governance is cooperative and the IT system is decentralized, all basics for a sustained system are given. Everyone can define the type of the deployment, features of his front-ends and services. Every participant can decide which services he offers himself and which one can used from someone else. This is the most useful scenario for the blockchain.

But ….. blockchain based application doesn’t mean it’s blockchain only.

If you decide in a business application for a blockchain, however, this does not mean that you are building a blockchain only application. The blockchain remains the right platform for the transaction data; all the others should be stored outside the blockchain, since otherwise you would have to spend a lot of time to encrypt and decrypt data.

It’s a hard job to find the right blockchain architecture principles, everybody enters new territory.