Ethereum Usecase: Identity Management – Part 2

Identity verification is one of the hottest usecases for the blockchain. I already wrote on this topic few months ago with the idea of a fictive government binding hashed identity data to citizen’s ethereum address.

Recently, I ran into ShoCard, a mobile app which is able to locally store user’s identities (driver’s license, passport, tickets, credits cards, online accounts, …) on the mobile phone and seal this data by putting the hashes via the BlockCypher API on the blockchain. Furthermore, institutions, like banks for instance, can verify user’s identities and store this fact on blockchain too, effectively confirming that the sealed id record is correct.

I did the experiment of implementing ShoCard’s concept on the Ethereum blockchain. A very interesting point is that we only need one simple contract for the implementation of the concept. It simply binds a hash value to an address:

contract DataSeal {
address owner;
uint256 dataHash;
function DataSeal(uint256 _dataHash) {
owner = msg.sender;
dataHash = _dataHash;

First, for every user’s identity record of the form

idRecord = {idData_1, ..., idData_n, randomValue} 

we create in Ethereum a DataSeal instance storing idRecord‘s hash value.

idRecordSeal = new DataSeal(<idRecord hash>)

From now on, idRecord can not be modified without breaking idRecordSeal.

If we want to prove to X that our idRecord has been sealed by us, we will send to X the idRecordSeal address and idRecord signed with the private key of the Ethereum account used to instantiate idRecordSeal. Having this informaton, X can verify that idRecord matches the hash value in idRecordSeal contract and that the signature matches its owner.

So far, we have the proof that idRecord was created and sealed by us, but we have no proof yet that idRecord matches our real identity as documented on our id card. For instance, we could steal the id card from someone else and  seal it on the blockchain. In order to make the idRecord trustworthy, we need a trustworthy witness verifying our idRecord and committing the proof to the blockchain.

The most direct witness for this proof would be the public authority issuing the id cards to the citizens. The next best instance, could be a commonly accepted institution like the mailing company (see POSTIDENT solution of Deutsche Post AG) or a bank.

If the user has been successfully authenticated, the witness will produce

witnessRecord = {idRecordSeal, secretKey}

and create a new instance of the DataSeal contract with the hash of it:

witnessRecordSeal = new DataSeal(<witnessRecord hash>)

Finally the witness shares the following record with the user:

{witnessPublicAddress, witnessRecordSeal, secretKey}

Assuming that X is trusting W, and that we already were authenticated by W, we can pass to X

  1. the witness data {witnessPublicAddress, witnessRecordSeal, secretKey}
  2. our idRecord signed with the corresponding private key
  3. our idRecordSeal address

Now X, can check that idRecord hasn’t been modified, that we’re the owner of the record and it’s blockchain seal, and that we already were successfully authenticated by W. If X trusts W, then he doesn’t need any further verification of our identity and he can do business with us.

BitBond – the future of Loans

Last week the P2P lending platform BitBond got a license from the German BaFinBitBond is a fine little platform with lot of nice features. It’s unique selling point is that it is completely bitcoin based. You can get loans and invest on a USD and BTC base, but the complete backend is based on bitcoins. This will simplify the backend processes for all participants in a radical way and it can be used by unbanked population from undeveloped regions all over the planet. 

The internal account will be managed only in BTC. Yes, this radical bitcoin p2p implementation will be a barrier for anyone who is not familiar with BTC, but it shows how easy this complicated business can become in the future.

The amount of loans is still rising and the platform has good chances for the disruptive network effect. It also has an open API to integrate the functionality into the own business or application and it gives us an idea about the connected business processe for small business.

Another nice feature is “AutoInvest” for all lazy investors, which are not interested in studying the loans on their own.

Ok, lets look on the other side of the coin. The interest rates are pretty high, up to 30% and the credit risk is also really high. On the platform you can look on the credit portfolios of the investors, they diversify their capital to a lot of loans and do not win in every case. Over all they earn money, but it’s not the holy grail. 

BitBond Team, good luck with your platform, thumb up for your platform implementation and ideas !

KW 39 – Weekly Blockchainers Recap

The kind of blockchain news are rapidly changing these days.

  • Two years ago: Bitcoin is some dirty stuff for anarchists and criminals. 
  • One year ago: Hmm, the blockchain behind Bitcoin, it sounds interesting, lets have a look on it.
  • Half year ago: Let’s start some prototyping to find out how to use it for us, if we can’t stop the technical progress let it work in our direction.  
  • And today? I see more and more commercial projects or productive systems using the BC, DLT how ever they call it. It’s really inspiring to be a part of the development of this disruptive technology, let us have a look on some brand new examples: 

Static Type Safety for DApps without JavaScript

DApps, starting professionally…

You might not be aware, but despite its similarities to JavaScript, Solidity is actually a statically, strongly typed language, more similar to Java than to JavaScript.

static type check in browsersolidity

…and ending in frontend-chaos

Sadly, for a long time, there has only be one interface to Ethereum nodes, web3.js (besides JSON/RPC), which is, as its name implies, written in JavaScript.

Though providing this API in a web-native language is really a brilliant idea in terms of fast development, seperation of concerns and ease of use, it is a nightmare for professional, multi-developer, multi-year, enterprise products.

You may not agree with me here, but as there are currently no 10 year old 1.000.000 LoC enterprise projects in node.js/JavaScript out there, you should at least consider that such projects are nearly impossible to maintain with a dynamically, weakly typed language like JavaScript (JS).

So, we have this situation, where JS defines the lowest common denominator (dynamically, weakly typed

JavaScript_1 (2)

when we really would like to have this situation, where Java (C#, Haskell) defines the lowest common denominator (statically, strongly typed)

JavaScript_2 (2)

Removing chaos

The problem is was, that up to now only web3.js existed. However, today there is also a (which is Python and therefore at least strongly typed, but still dynamically) and, brandnew, web3j.

With the latter, we can easily model the call chain above, where we only use statically, strongly typed Java and omit JavaScript altogether. Welcome to hassle-free integration into existing Java/JEE-environments without workarounds. Finally: using the Ethereum Blockchain with Java.

If you want to actually get deeper and use Java with no RPC at all, you can also switch to EthereumJ, which is a Ethereum Node implemented in Java, like Eth (C++), Geth (Go), PyEthApp (Python) or Parity (Rust). It is crucial to understand the difference between web3j and EthereumJ. If you just want to use some Ethereum Node from a Java application, web3j is your choice, you are limited to the Web DApp API then, which should be enough for all “Ethereum user” use cases.

We will not explain in detail how to use web3j, it should be familiar to any Java developer how this library can be used just by adding Maven-dependencies to your project.

Fixing the front-end

We could stop here, since using JavaScript for the frontend is not really problematic and a common use today.

However, if you use JavaScript in your frontend, it might really make more sense to stay with web3.js. So, we want to go further: how are we going to create the GUI if we want to have no JavaScript at all?

This is just a PoC, but if you think of any other client to the Ethereum Blockchain other than a web site (let’s say: Batchjobs, Web Services, Message Queues, Databases, other proprietary software with Java adapters (there are some!)), this should make sense to you – you really wouldn’t want to use them from web3.js (hopefully).

Using templates: Thymeleaf and Spring Boot for slim enterprisy software

We will do a step-by-step guide for creating a No-JS-Dapp. Even without any Java experience, you will be able to follow without problems. Java is not that complicated anymore!

  • Get an account and key, so you don’t have to mess around with starting your own Ethereum node
  • Clone this repo:
  • Install Maven
  • Edit these files:

    pom.xml (add these dependency to section dependencies and add the repo, beware that web3j is a fast moving target, check for new versions)




src/main/resources/templates/hello.html (change name to balance.html)

<!DOCTYPE html>
<html lang="en" xmlns:th="">
<meta charset="UTF-8"/>
<title>Your Static Strongly Typed Wallet</title>
<p th:text="'The balance of account ' + ${address} + ' is ' + ${balance}" />

src/main/java/com/hellokoding/springboot/ (change name to

public class EthereumController {

public String balance(Model model, @RequestParam(value="address", required=false, defaultValue="0xe1f0a3D696031E1F8ae7823581BB38C600aFF2BE") String address) throws IOException {
Web3j web3 = HttpService("{YOUR_INFURA_KEY}"));
EthGetBalance web3ClientVersion = web3.ethGetBalance(address, DefaultBlockParameter.valueOf("latest")).send();
String balance = web3ClientVersion.getBalance().toString();
model.addAttribute("address", address);
model.addAttribute("balance", balance);
return "balance";


…that’s it. Start with mvn spring-boot:run

If you encounter an connection/handshake error, you may have to import the infura certificate into your local Java keystore (I didn’t have to)

$JAVA_HOME/Contents/Home/jre/bin/keytool -import -noprompt -trustcacerts -alias -file ~/Downloads/ -keystore $JAVA_HOME/Contents/Home/jre/lib/security/cacerts -storepass changeit

Look Ma! Displaying the wallet balance with no JavaScript!

You can call the spring-boot web application with http://localhost:8080/balance (then the defined default argument is used) or with your address (in the consensys testnet) as parameter address= 

walletOf course, you can change the Ethereum net like you want in file EthereumController to morden or mainnet, just read the welcome mail from Or you can just use a local Ethereum node like geth with RPC enabled (geth –rpc) and http://localhost:8545 as the constructor for HttpService of the Web3j-Factory in EthereumController.

Have fun, with or without JavaScript!

Steem – community building and social interaction with cryptocurrency rewards

This week I came across Steem and I instantly got sucked into it. In this post am trying to summarize what I learned about it so far. 

You can think of Steem as a Facebook-like platform where authors and curators can earn cryptocurrency rewards by writing posts, up-voting posts, commenting on posts and up-voting comments.

To understand how this process works, first of all we need to understand the currencies circulating in this process. According to the whitepaper we have:

Steem – the fundamental unit of account on the Steem blockchain. All other tokens derive their value from the value of STEEM. Generally speaking STEEM should be held for short periods of time when liquidity is needed. Someone looking to enter or exit the Steem platform will have to buy or sell STEEM. Once STEEM has been purchased it should be converted into Steem Power (SP) or Steem Dollar (SMD) to mitigate the impact of dilution over the long-term (100% inflation annually). 

Steem Power (SP) – Steem can be instantly converted to Steem Power. It is a long-term investment and can only be converted back to Steem via 104 weekly payments over a period of 2 years. This long-term commitment gives the owner two advantages:

  1. the user can participate on the platform by voting or posting articles/comments. This is rewarded by more Steem Power (SP) and Steem Dollars (SMD). How much everyone gets, depends on his Steem Power and the voting algorithm.
  2. The inflation is not 100% anymore like with Steem, but only ~10% per year because for every 1 Steem generated as reward, 9 new Steem are distributed among Steem Power holders. If the platform grows faster than the inflation, investors make a win, otherwise they’ll be losing money.

Steem Dollar (SMD) – represents a number of Steem tokens having a value of ~1 USD. It can be used to trade goods/services with the stability of the USD. SMD pays holders interest (currently 10% per year). The interest rate is set by the same people who publish the price feed so that it can adapt to changing market conditions.

The two main reward mechanisms in Steem are curation and author rewards. Both are equally important in Steem.

Author Rewards are gained by posting articles that are upvoted by others. Curation Awards are gained by early upvoting articles that grow popular later. The rewards are payed out in Steem Power and Steem Dollars. In general the more Steem Power someone holds, the more weight his vote has. If one of developers is upvoting a post, it can instantly bring more than $100 value to the post. A new account on the other side with ~3 Steem Power will only bring a fraction of a cent. The final value of a post is distributed among the author and curators depending on how early they participated in the voting process and how much Steem Power their accounts hold.

The money for the reward pool is coming from the inflation. Instead of taking a tax on existing accounts for generating the reward pools, the protocol generates continuously new Steem where 1 is going to the reward pool and  9 are redistributed to Steem Power holders. This basically results in a ~10% inflation annually.

Lot of people are asking the question if this model is sustainable. One could expect that the model can only be profitable as long as more investors are jumping in. At the moment where supply gets greater than demand the whole system could break together like a Ponzi-Schema. This could be very painful for late-adoptors because of the 2 year payout mechanism. One of the main critical voices claiming that Steem is actually scam is Tone Vays.

My personal impression so far is that this could be the first DLT application with good user experience and the potential to go viral. It reminds me a little bit on 2007 and the gold rush with the AppStore. At the time of writing this post, the platform has around 70k accounts.

Try it yourself at or read more about it at Currently every new account gets Steem Power worth ~$4 for free.

Further reading:


KW 33 – Weekly Blockchainers Recap

The number of blockchain news post is growing exponentially. Nearly every company or government does some research projects based on blockchain and DLT technologies. Let’s try to filter the stuff wich could be interesting for us blockchainers.  

Last year I saw a well written paper from the world economy forum about fintechs. This year they published “The future of financial infrastructure” witch focused on blockchain. The paper describes in detail a set of financial use  cases and how they can be improved using blockchain tech. It’s one of the best papers we have seen so far. 

The next big thing is Raiden from Heiko Hees. See also International Business Timer. Every time you discuss the opportunities of blockchain and smart contracts with business people, very soon they come up with the scalability issue. Based on my IT project experience, I can tell that there is always a solution for every performance issue. Heiko’s Raiden is the solution for Ethereum.

Finally we have to mention Steem – a blockchain database that supports community building and social interaction with cryptocurrency rewards. You can think of it as Facebook/Reddit like Plattform where content contributors and content curators are monetary rewarded for their work. It is questionable if the model is sustainable or not, anyway it’s the first application of the DLT tech with a nice front-end and with the potential to go viral. 

Create your own Oracle with Ethereum Studio and

This is a follow-up post to Gambling with Oracles and describes the technical part for the implementation of an Oracle with

People told us last time that we had not really created an binary option. This might be true and to not confuse the reader and also to introduce just another cool use case and link to current events, we are going to bet on the winner of the EURO 2016 soccer championship.

As you see from the posting date, the championship is already finished and the winner is well known, it is Portugal.

So we can just create a static Oracle to make things easier, we will define the Oracle call in our betting contract and on calling update(), the winner will be determined, which is the static json {“winner”: “portugal”}.

You can call bet(winner) with exactly 1 ETH and on calling claim() you will get nothing or (loseBets + winBets) / (numberOfParticipantsWhoBetOnWinner), eg. 3+2/2 = 2.5



You will need to sign up for the Studio and check out the corresponding github project in the terminal, follow the instructions in the README.

Starting the Oracle

After starting the web server, you can access the “Oracle” with which redirects to the file web/eu2016winner.json in your project.

You can test the data retrieval in the Studio, just choose the Oraclize tab, Test query, “URL” and put json(…).winner around the URL.


That’s it, by clicking “Test” you should get the result “portugal”. So now the Oracle Smart Contract can call your Oracle datasource and submit the result via callback to your contract.

oraclizeObviously, a real Oracle should be a little more dynamic, but for testing purposes this Oracle is enough. You can change the answer by stopping the web server, changing the file manually and restarting the server.

To avoid duplicating information here, please consult the documentation for the Studio IDE for actual usage of the sandbox. Remember to give enough value (at least 0.1 Ether in Wei: 100000000000000000) for the update() call, but also 1 Ether in Wei (1000000000000000000) for the bet()-calls, otherwise it will not work.

Deploying the betting contract to Morden

The contract.sol contains the complete contract, it imports some helper classes and the oraclize-API, which, depending on the deployed environment, is instantiated with the corresponding contract address.

In the README you will see the local environment sample, but also the Morden example. To deploy the contract to the testnet Morden, you will have to get Ether first, which is really simple in Morden

Note: you have to set the networkID to Morden in the constructor of the contract before deploying:

 function FinalWinner() {


After deploying, you can click on the Transaction-Hash in the Transaction-Tab, which automatically opens the deployed contract in

To be able to invoke the contract in, you will have to upload the sources of the contract, however, there is a problem with inline assembly at the time of writing this post. Therefore we added a special file (for-upload-to-ether-camp-morden-as-source-only.sol-not.executable) for uploading in the root of the github-project, this contract is just for this purpose and is not executable.

In Morden, each call should be done with value 1 Ether, the bet-calls will throw; otherwise and the update call needs some for the call of Oraclize, which costs Ether for each call (consult pricing on

Distributing Business Processes using Finite State Machines in the Blockchain

Having disctinct, even competing organisations with a common goal and no shared technical infrastructure represent a perfect use case pattern for blockchain usage.

The quest for the holy business use case

As many blockchain enthusiasts we are constantly searching for use cases for establishing Distributed Ledger Technology (DLT) or even real blockchain technology in enterprises as solutions for common business problems.

[Business *]

This turns out to be difficult, since each single aspect of this technology is already solved by several – established and well known – products. 

In this post we will present a use case, or even a use case pattern, which we think is ubiquitous and can best be solved by blockchain technology.

For these type of use cases the other technologies, even though being more mature, seem themselves like workarounds for the natural technological solution, which is blockchain-based.

Our definition is the use case pattern is:

Several distinct, competing organisations have a common goal and don't share technical infrastructure.

distinct, even competing organisations

Distinct organisations are not related to each other and therefore have no existing technical or organisational processes. To pursue a common goal, these processes would have to be established first, which is costly and time-consuming.

[Competing teams *]

The second aspect, competition, implies that there is no mutual trust. Obviously, this aspect is a crucial one. Blockchain technology might even make sense if just the other aspects of the pattern match, but it only is a perfect fit if this aspect is important, since the blockchain itself is inherently trust-less.

common goal

This is the fundamental requirement, if there is no common goal, there is no need to establish any collaboration. It is important to note, that the common goal is most likely not related to the core competence of the organisations, but to some crosscutting concerns, which have to be addressed by all organisations, but are just cost factors.

no existing shared technical infrastructure

To put it contrary: if there already exists a shared technical infrastructure, also organisational processes exist to establish new technology. Given this, there are several great technology products which implement each aspect of the blockchain technology (namely distributed data storage, immutability, security), and most likely even more performant, more mature, with less maintenance and evident responsibilities.

Ok, this is quite abstract and complex, let’s find an easy example.

…want a securities account with your new account?

There is one universal retail bank, FriendlyBank, which wants people to open accounts. And there are three deposit banks, FriendlyDeposit, EasyDeposit and NiceDeposit. There is also the Regulator, who must be able to audit all transactions between the parties.


common goal: make money

The common goal of universal and deposit banks is to open accounts. The universal bank can be intermediary to deposit account opening, so you can open a securities account at one of the three deposit banks with your new account at FriendlyBank. This way, it is a win-win-situation for both parties, the intermediary gets commissions, the deposit banks get new customers.

FriendlyBank and FriendlyDeposit are related to each other, they have the same ownership structure, but are separated entities. Since the deposit banks are in competition with each other, the other deposit banks besides FriendlyBank want to be sure that not very valuable customers are transferred to FriendlyDeposit or the deposit account opening is “accidentally forgotten”, if not FriendlyDeposit is chosen.
Since the parties do not really trust each other, a trust-less (ie. no trust necessary) solution is needed.

the wonderful world of finance IT today

As we said, the depicted scenario exists quite often. Also, technical “solutions” for these scenarios exist.

They look similar to this one:


We wan’t go in detail what all this means, but to become trust-less, as well as assure that the data is in sync in each organisation, a lot has to be implemented and still, shortcomings of these solutions are quite common:

  • reconciliation processes are always necessary, but still, due to missing transaction support in flat file exchange, which is almost always chosen as the “simplest” integration pattern, errors occur.
  • adapters have to be built for each party, so there will soon exist a many-to-many problem.
  • special adapters have to be built for regulators.
  • crosscutting concerns have to be implemented: security, authentication, auditing, transaction support

Compared to a natural solution in the blockchain

Below is the blockchain solution, it fits naturally and implements all requirements.bcsample

Abstracting from the use case

Why is this solution matching so well, what is the pattern “behind”?

Different actors change the state of a business process on some event in a transactional way.

[Old cigarette machine *]

You certainly know this pattern, it is describing a finite state machine, more exactly a distributed, secured by cryptoeconomics finite state machine, which events are transactions.

After all, the blockchain itself is a state transition system, it somes quite naturally to implement a simple state machine on the Ethereum EVM, it even is mentioned as a common pattern in the Solidity docs.


Approaching the finite state machine

How would the organisations collaborate? This could look like this informally:



or like this (more) formally:


so we actually can built this state machine and its transitions really easy using the blockchain, here in pseudo-Solidity, derived from the common pattern in the Solidity docs:

contract AccountDepositStateMachine {
enum Stages { Init, AccountOpened, DepositOpened, DepositConfirmed, AccountConfirmed } Stages public stage = Stages.Init; modifier atStage(Stages _stage) { if (stage != _stage) throw; _ } function nextStage() internal { stage = Stages(uint(stage) + 1); } // Order of the modifiers matters here! function openAccount() atStage(Stages.Init)
{ if (msg.sender != FRIENDLY_BANK) throw; } function openDeposit() atStage(Stages.AccountOpened)
if (msg.sender != FRIENDLY_BANK) throw;
function confirmDeposit()
if (msg.sender != DEPOSIT_BANK) throw;
modifier transitionNext() { _ nextStage(); } }

Great, so that’s it, we can build any business process using the blockchain, QED.

Leaving the ivory tower

As you might guess, it is not that simple. Let’s review the actual process:

  1. Account is opened 
  2. Deposit Account is opened
  3. Deposit Confirmed
  4. Account Confirmed

Ever saw an IT-process in real life? Exactly, it’s not like this, not even close. Let’s see a more real life example:

  1. Account is opened
  2. An Email is send to whoever feels responsible
  3. The Product Owner’s Excel has to be updated
  4. The new reporting engine must have its data updated, it is runnig with MongoDB, which has to be updated
  5. Revision wants to have it’s auditing data in their Oracle DB (must use 2PC)
  6. … (ok, you got it already…)

None of the tasks in bold red can be accomplished from the Ethereum blockchain, since calls from “inside” to “outside” are prohibited. Let’s hope this will never change, the separation of “inside” and “outside” is essential for the stability and security of the Ethereum blockchain

We could use Oracles for this, but it would be a kind of usage which is highly inappropriate for this type of external information retrieval.

Teaser: “Mastering the Flow: Blending Reality with the Blockchain”

This post is way too long already, so here comes a teaser for two posts next to come: “Mastering the Flow: Blending Reality with the Blockchain”

The idea is really simple: let’s just recentralize the business process (we are in eager anticipation for the comments to come…)

But we think this can make sense. Look at the sample above, illustrated as a flow:


The flow was created with Node-RED, an excellent and highly undervalued tool of IBM Emerging Technologies for flows in IoT. It could be very easily adapted to Ethereum with smart contract access by usage of web3.js, which itself can be integrated in node.js, which is the basis of Node-RED, hence the name.

We make the following assertion:

More than 80% of all use cases can be realized by a centralized business process engine as a first layer, eg. implemented in Node-RED, and a state machine implemented in the blockchain as a second layer

The business process engine is the glue between the transactional blockchain state transitions and the secondary business processes.

What do you think of it? Please let us know in the comments, we really appreciate feedback, positive or negative.

And stay tuned for the next episode, we will get to the nitty-gritty there.

[Business] Business by Christophe BENOIT under CC
[Competing teams] Competing teams by Denis De Mesmaeker under CC
[Old cigarette machine] Old cigarette machine by Walter Baxter under CC

The Golden Private Blockchain Use Case 

During the last months we have seen a lot of press releases about blockchain projects everywhere, but only few of them are more then just experiments. We also saw many notes about private blockchains as a solution for enterprises. Private blockchains are a good story for consultant companies and their skin deep powerpoint writers with expensive cufflinks. However, we haven’t seen good use cases yet in all these power point slides, just repeating arguments and sales stories. So where is the real private blockchain killer application? More or less every problem addressed by private blockchains can be solved with already existing technologies and software architecture patterns. 
Most IT system in enterprises follow the centralized architecture paradigm, e.g.: 
a) MDM (Master Data Management), data from different sources will be collected and consolidated in central databases, then the data will be processed, checked etc. with some algorithms or human interactions and at the end the data will be distributed to different target business applications.
b) Central BPM (Business Process Management) systems will be triggered by an event, it pulls some data from other sources, process them, generate reports, trigger new events etc. 


We can continue and continue to all the different other centralized systems and architecture pattern. We build centralized solutions, because we learned centralized architectures are good, however, in decentralized or silo organizations it is difficult to establish such structures. In this kind of organizational structure, we find very often poorly organized data exchanged via Excel and emails. BPM solutions perform poorly too due to the fact that it is difficult to establish and enforce exactly specified business processes. 
Central systems also ignore circumstances of local data aspects, not all data has the same importance for all business applications, very often you need individual data and data rules for single data consuming business app. 
How DLT (distributed ledger technologies) and smart contracts instead could help to integrate applications in a decentralized/silo organization where centralized architectures break on the organizational structure?
In a DLT-based solution there is no central system. Every business application is equal and can participate in the P2P network by contributing or consuming data from the distributed ledger. How an application contributes or how it consumes data is a local decision of the application itself. For instance, if it needs a specific frontend, it can be implemented in the context of the specific application in need of it.  
central systems2.002
This is a new software architecture paradigm which could lead to better scalability, less redundancies and lightweight integration of applications in technologically and organizationally decentralized environments. 
Relevant Articles:

KW 25 – Weekly Blockchainers Recap

Swenden Land Registry
One of the first serious ideas to use blockchains and smart contracts was the land registry use case. We heard about projects in Greece and Honduras. Now Sweden do some research, it has high potential to show the applicability of this approach. 

more projects
During the last weeks we saw more and more interesting Blockchain activities.
Polish Gouvernance 
Dutch Central Bank 
Kazakhstan Central Bank 
– ……
It seems more or less every institution works on this technology.