What is Herdius?

Exploring what Herdius is and why we are different.

What is Herdius? — that’s a question I get asked on a daily basis and the answer I give usually goes something along the following lines: “Mainly it’s a decentralized exchange, but at the same time it’s a lot more than that”. The next questions to follow are “How is it different from other DEXs?”, “How is it different than anything that’s already out there?”. After hearing the same questions over and over again from both technical and non-technical people — it became clear that our current messaging is flawed. On top of all of this neither the technical paper or the whitepaper cover the topic of what Herdius really is and how it’s different. It’s only when I have a discussion with people and they take a closer look at the technical paper when they realize the core of what we are building.

Last week I had the chance to sit down with someone from one of the most reputable VCs. Naturally, during such meetings we end up talking about Herdius and I always explain everything in a more detailed way while making sure that the substance of Herdius comes through. Usually people are surprised when they realize that Herdius is not just a decentralized exchange but much more than that. The meeting ended with something along the lines of: “This is great, but you are not communicating any of this, and you should.” Since then I started thinking and working on this post to fix this. After all, the Introducing Herdius post is somewhat vague and does not really explain all the aspects of what we are working on.

Backstory on the creation of Herdius

After pivoting away from the original idea of Herdius , on which you can read more on here, it was clear to me that I still wanted to create an exchange. The only thing that changed was the fact that it would be a decentralized one. This was towards the end of August / beginning of September and right about the time the 0x Protocol was the new craze.

I wanted to create something that is a step forward rather than a simple lateral step. You already had simple smart contracts for ERC20 tokens so there was nothing to innovate there. In other words I wanted to create something that can work seamlessly with any blockchain without the need for the Herdius team to implement communication channels with each individual chain. Each blockchain shares a common property, they all use public-key cryptography. Sure, the cryptographic curves & algorithms might differ, but from the user perspective your private and public keys are your identifiers inside a blockchain. Using it you identify yourself, sign transactions, encrypt your data and access all you crypto assets.

This got me thinking. If I can somehow solve everything on the private key level and have a decentralized exchange utilizing such architecture then I could split up ownership of a wallet and the assets that are within. Herdius DEX v0.1 was fairly primitive. It would have worked the following way: when Alice sends funds to Bob inside the Herdius chain she would also reassign her private key to Bob and thereby allow Bob to claim ownership of the funds. Inside a transaction the newly assigned private key was included. This raises three major issues (let’s not touch on the minor ones):

  1. Transmitting sensitive information, such as a private key, efficiently through public & untrusted nodes is really hard. Emphasis on efficiency since you could use a routing network that encrypts the information contained inside the transaction packet layer-by-layer with each node’s public key, but this would be painfully slow. TenX does this with COMIT and pretends everything will scale and work fine — it won’t. (it’s very easy to understand how such routing networks work. If A wants to send a message to E, then A proceeds to encrypt his / her message with the public keys of B,C,D then sends the now encrypted message to B. B receives the message and decrypts it using his / her private key and finds inside the public key of C — who is the next step in the route and who the message has to be forwarded to. At every single stop each node only knows who the message came from and who to forward it to. When E receives the message and decrypts the final layer of ecnryption, the contents of the message are revealed to him)
  2. Key management becomes an issues and things will get messy. Imagine Bob from the example above sending funds to Charlie. Then the key Alice to Bob has already been revealed to him so now it has to be reassigned again.
  3. As mentioned above it would have been a mess and a nightmare.

So all of the above was scraped eventually. You might think it is pointless to write this failure down, but I believe it is important to explain the thought process behind how Herdius was built up following it. What followed was weeks of reading research from others that are much smarter than me. The great thing about blockchains next to learning together is the fact that you can bring so many ideas from the outside that others might not have though of. That is kind of what happened here.

Herdius today

I pointed out the flaws of the first version of Herdius for a reason. It provides clarity on why the Herdius out there today was designed the way it is. Once the flaws were clear, it was somewhat easy to find a solution for them. Actually, the easiest way to guide everyone through the whole thought process I will outline how a simple trade happens in the Herdius chain:

There are three (3) users: Alice, Bob and Charlie. Both Alice and Bob have a Herdius compatible wallet and own an address inside the Herdius network. Charlie does not have a Herdius network compatible wallet but instead he has a regular Bitcoin address and wallet.

Alice sends funds to a wallet of her choice that is compatible with the Herdius network. When she creates the wallet, two private keys are created and an address is assigned to Alice inside Herdius. One private key is the counterpart to her Herdius address (public key), while the other private key (the private key corresponding to the Bitcoin address’ public key where Alice sent the 10 BTC) is deposited into a “box” (hashed database) which is encrypted using another private key — let’s call it box key. This box key is a Schnorr signature and is sliced up into parts, for easy math let’s make it 10. Each of these parts is then distributed to nodes within the network.

Alice sends 5 BTC to Bob’s Herdius address. The balance is updated inside the Herdius state and Bob gains the “right” (similar to UTXOs inside Bitcoin) to reassemble the private key of Alice up to 5 BTC.

Now Bob proceeds to send 3 BTC to Charlie, Charlie being a non-Herdius user. In the process Bob triggers the key reassembly process of the “box key” with his Herdius signature this is followed by each node submitting their private key to the “assembler node” (explained later). Since Herdius uses a threshold signature scheme, only 7 out of 10 keys are necessary to unlock the “box”. The assembler node is the one who puts together these individual key pieces and unlocks the “box” that holds the Bitcoin private key of Alice. Using encrypted computation, the assembler node creates a transaction that he signs using Alice’s Bitcoin private key and the funds are finally moved back on the Bitcoin chain.

Sounds complex but it really isn’t.

It sounds really complex and complicated, but I promise you that it really isn’t. Whether you are sending a transaction to a Herdius user or to someone outside of the Herdius network, the process looks the same to you. All the cryptographic magic happens in the background.

Now that we got the example out of the way it’s easy to understand why our DIVIWA — Distributed Virtual Wallet Network approach was needed. Here are some other arguments as well:

  1. Why is Alice’s Bitcoin private key hidden from her, encrypted & put into this “box” thing?
  • The whole point of putting the key into the “box” and hiding it from Alice is that if someone were to possess the private key of the wallet, they could freely move funds of it. Imagine that Alice puts in 10 BTC in the wallet and then proceeds to send 2 BTC each to 4 other people. And each of those 4 people proceeds to send 0.1 BTC to another 20 people. That means that now you have 81 (80 + Alice) users that own funds inside Alice’s wallet. If Alice, or anyone else, were to know the private key they could move funds freely and while one user will be very happy, the other 80 won’t :)

2. Why use a “box” instead of just slicing the private key up directly?

  • As I mentioned above we use a threshold signature scheme. This is a half answer to this question. Take the case of having a Bitcoin private key that you split up and slice into parts. Now when you are doing the key reassembly process and some nodes are not online then you can not reassemble the key and it the funds will be stuck.
  • If you split up the key directly and you have the nodes transmit it for reassembly then the final assembler node that does the reassembly can see the keys and later on could put it together himself to move the funds. If you only give nodes the keys to the box and this is what the assembler node gets then he can only use it one-time to open the box and do encrypted computation on it.

3. What is this assembler node?

  • The assembler node is the final piece in the process of transmitting a transaction out of the Herdius network. This is the node that signs a transaction and transmits it to the mainchain. If you have a simple wallet on your desktop that you use to send Bitcoin with, then you are the equivalent of an assembler node inside the Herdius network.

4. What is encrypted computation? Why is it needed?

  • Ecnrypted computation or homomorphic encryption allows someone to perform computational work on encrypted text / data. In our case this text is the private key. We do not want the assembler node to actually see inside the box and see what the private key is. All we want him to do is to sign off on the transaction with the catch that he / she is not allowed to and does not see the private key that is used to sign the message. The following is the information the assembler node gets: “Hey, here is this container that holds the key parts, do computation on them and then do computation on the box & sign the transaction in the value of 3 BTC to Charlie who has a Bitcoin address”

5. Why use a threshold signature scheme?

  • We use a threshold signature scheme for security and uptime reasons. As a user you want to be able to transmit transactions back to the main chain at all times. To achieve this, all the different nodes that hold keys have to be online. It is better to plan ahead and expect that at least 30% of all nodes are offline. This is why you need 70% to be online so that if you have a key sliced into 10 different parts, at each key reassembly process we only need any 7 of these keys to compute the key

6. What happens if some of the nodes holding the 7 keys go offline?

  • There is redundancy built into the system. Initially we plan on creating the key storage in a way that each individual key part is backed up by 20 additional nodes. In the event that the first contacted node is not online, there are fallback options. Storing a private key is inexpensive if you are a node as each key is less than 10 bytes in size.

Herdius is an identity bridge between blockchains

This is exactly what Herdius is! Not a cryptocurrency platform, nor a decentralized exchange. In the example above I focused on a simple trade order that happens within the chain but having an architecture which can do distributed key storage and reassembly enables much more than that!

As mentioned above: your public key is your identifier in a blockchain while your private key is the counterpart to it that allows you to access whatever asset is stored under that identity. You could sign transaction on one chain and have the Herdius chain act as a middleman where all data & transactions are stored and then have that data converted and transmitted to the other chain.

The good thing about performing what has been described above is the fact that there is no need for any kind of communication channel whatsoever with the different main chains. This is due to the fact that the key that is used to sign and route the transaction back to the main chain is the chain’s native key and is thereby seamlessly recognized. In my view this is what chain interoperability is about.


It’s kind of interesting how the DIVIWA network introduces privacy. For a long time I didn’t even realize this myself. It was a suprise, to be sure, but a welcome one.

Before going further I advise everyone to read this short summary by Monero on what ring signatures are. It’s here. For the lazy: users are part of groups that have a bunch of public keys and each user in the group has a private key they can sign messages with. When the user sends a transaction he / she signs the transaction with one of the groups identity. The other participants of the network can easily verify that this is a signed message from that particular group, but they do not know which user made the transaction.

Zcash and Monero are risky, but great (disclaimer: Zcash is one of my favorite projects). They use ring signatures and heavy encryption to obfuscate the sender’s identities. The big drawback is that they are slow and in the case of Monero kind of expensive (this is not to bash on them as this is the price of privacy).

The key differentiator of Herdius to other privacy preserving chains is the fact that instead of all the added encryption it is rather that a user can use thousands of identities to send funds from. If a user has ETH and has to send LTC to someone, then he creates a trade order which happens under 1 second and can send the LTC back to the Litecoin main chain after that one second settlement period. The LTC will come from a single address if the order is fulfilling a single order, but if it’s a partial order then the case might as well be that the LTC will come from many different sources. This involuntarily obfuscates the original sender’s identity as Bob does not show up as a source or sender at any time.

As visuals help here is a simple illustration that goes back to the example above.

Trying to solve too many issues at the same time

One of the big misconceptions about us is the fact that we focus on many different issues while also doing a decentralized exchange for the fun of it. At a first glance almost everyone thinks we try to create a DEX, a data marketplace, an identity gateway, a secure place to store private keys and lastly a chain that interconnects all the different blockchains. Luckily, this is not the case.

The decentralized exchange is the main product and first feature, however, the core of Herdius is the blockchain itself that runs everything. A chain that is specifically tailored to be “endlessly” scalable (thanks to BoB). On top of this we create the DIVIWA network which creates the above mentioned identity bridge. This is the core of Herdius, nothing more. Once this is finished or parts of it are functional, as we will do different closed and public beta phases, the decentralized exchange comes on top. At the end of the day all it takes to put a DEX on top of Herdius is to implement the order book and order routing protocol.

“Who would you consider your main competitor?”

I swear there must be a “How to invest and value cryptoassets” guide out there that has this question in there. Towards every single pre sale call this questions comes up. Always worded the same way. It is a fair question to ask and at the same time funny how it is always worded the same way.

Jokes aside. We do NOT want to compete with others (at least for now). The infrastructure we are laying down is so unique that I do not think that at this time we have direct competition. At the same time, we are neutral. The answer to the above question is that we are a mix in-between Polkadot and Stellar. Good thing is that Polkadot and Stellar could make use of our architecture with the first being able to connect chains without communication channels and the second being able to scale their chain and make use of the identity bridge we have.

We also do NOT want to compete for developers with others like Ethereum, Neo, Lisk, IOTA, etc. It would be really stupid to do so. All of these projects have developer communities of their own contributing to their own ecosystem. It would be difficult to start from zero and replicate that.

What we would rather do is position ourselves as back-end infrastructure for decentralized application developers. It doesn’t matter if that dApp is running on Lisk, Ethereum or Neo, as long as our chain and identity bridge can help them in any way then they are more than welcome to use the Herdius infrastructure. Rather than being a competitor I envision Herdius to be as a go-to infrastructure and tool that anyone can freely adopt regardless of what chain they are running on.

It easy to imagine how this would take shape. Since we have BoB (Blocks-on-blocks) and validation inside each block can run in parallel what a dApp could do is reserve blocks inside chain that they use for themselves and have those validated by Herdius validators at least in the beginning, once we are running the talk about hybrid nodes can begin. The cool thing about BoB is that each block is validated independently of another. What this means is that instead of doing serialized transaction execution, like in Ethereum, transactions and orders in different blocks are executed in parallel without any performance downside. Plus this way you also avoid the order bottleneck issue. Simple example: the Herdius DEX, a decentralized game and a service that does supply chain management through the Herdius chain can all run independently of one another. Even transaction surge across all three wouldn’t affect the throughput of the system. All it takes for this to succeed is fair and honest incentives towards the validators.


Since Herdius solves everything on the private key level without communication channels or bridges we are blockchain agnostic. This raises an interesting problem: how do we ban certain tokens from being traded on the exchange?. It is a good problem to have as other DEXs face the exact opposite thing. It wouldn’t be a problem if we are a centralized exchange as we would ban it, but we are not centralized. It is my view that if the team behind a DEX has to do whitelists for certain tokens and subsequently ban other tokens then it is not very decentralized at all.

How do you prevent an asset from being traded on your dex? — the order book. Makes sense. There is even a possible way to do it: self-amending order books. Inside Herdius it is the participants of the Constructor / Queue mechanism who maintain the state and the order books, therefore they are the ones who govern the order book. If there is was a successful vote to ban a token from being traded, then they are the ones who implement it. It all sounds easy, but it’s not.

If you look at the Herdius papers not a lot is mentioned of governance and that was done on purpose. Decentralized governance is such a hard topic to crack that I did not want us to be involved in it for now. I’m sure that by the end of the year we will have a good standard but at this time I leave it to others. What I would prefer in the future is to have an out of the box solution we can simply implement. No need to get into things in which others are better at. Governance is hard. Next to the technical challenges you have this other thing that people have: views. You can cram 150 people into a single room and brainstorm for days but even if a solution comes out people will still be unhappy.

This was a long but necessary post. Next post will be the follow up to the HER token series. Cryptoeconomics is fun!