ICON Republic

There are a number of moving technical pieces involved in a system this complex. Accordingly, I will take a moment to describe them, and then try to explain how they interact together. In order to do so, I am going to utilize the analogy that was included in Chapter 1 of this series, so please keep it in the back of your mind as you continue to read:

“Imagine a student at a university requires surgery. On the day of her operation, she checks into the hospital. In doing so, she presents her digital identity — recorded on blockchain via ICON — and provides permission to the hospital to share her medical records, stored on the hospital’s blockchain, with her insurance company. Now, the insurance company can immediately — and automatically — process the claim, since the records are tamper-proof on the blockchain and do not require an additional party to verify them. Just through this process alone, we’ve reduced time (the process is virtually instant), resources (no paperwork to fax or mail), and labor cost (by eliminating the need for a 3rd party).”

To make it flow a bit easier, let’s give the student in this example a name: Ashley.

Community

In a practical sense, a “community” within the ICON world could be a collection of hospitals, banks, or schools. This is not simply theoretical, as ICONLOOP has deployed loopchain technology in the following communities:

Capital Markets

“Their first project launches in September, allowing a consortium of securities brokerages to share client identification directly with each other on the blockchain so that their clients can open new accounts easily between the brokerages and skip the “know-your-customer” process.”

Hospitals

“Korea University Hospital is also applying the blockchain technology to help with data integrity, a cross-border digital signing system, and a health coin. Its first project, in cooperation with the government and other hospitals, is a cloud-based precision medicine hospital information system that will help with synchronizing databases between hospitals, according to Sangheon Lee, a professor at the hospital.”

Universities

“Meanwhile, Korea’s top-tier Sogang University is using the blockchain to create a university currency for students to pay through QR codes for the first time in Korea at on-campus stores, shopping malls and vending machines, as well as lending to classmates and paying tuition, and it is expected to benefit students overseas.”

(Source: Forbes)

Based on how these have been described in the Forbes article and other areas, these entities will share a blockchain among themselves. For instance, when Ashley checks into the hospital (Hospital A) for her surgery, they are able to pull her medical records from her prior hospital from her hometown (Hospital B). Both hospitals would be utilizing the same intra-community blockchain network developed with loopchain, and they would be considered part of the same “community” in the context of the ICON Network.

C-Node

First, let’s make sure we have a basic definition of “node.” Here is a helpful definition from the LISK Academy:

“A node can be any active electronic device, including a computer, phone or even a printer, as long as it is connected to the internet and as such has an IP address. The role of a node is to support the network by maintaining a copy of a blockchain and, in some cases, to process transactions. … Nodes are the individual parts of the larger data structure that is a blockchain. As the owners of nodes willingly contribute their computing resources to store and validate transactions they have the chance to collect the transaction fees and earn a reward in the underlying cryptocurrency for doing so.”

Within the context of the ICON Network, a C-Node “is the building block of a Community that affects the consensus or decision-making process of Community governance,” according to the whitepaper.

For instance, in our community of hospitals described immediately above, each hospital (let’s pretend there are 10) can function as a C-Node. The 10 C-Nodes work together to operate and govern the blockchain network that the hospital community operates on.

C-Rep

According to the whitepaper, “C-Rep (Community Representative) is a representative unit of Community and a unit that comprises ICON Republic governance at the same time. It has the right to vote on transaction verifications and its governance in ICON Republic. C-Rep is selected according to the decision of each community, and C-Rep can be changed from one node to another. In other words, C-Reps are subject to change depending on the situation and purpose of each governance. Furthermore, C-Rep will receive incentives for its maintenance and activation of ICON Republic.”

In simplified terms, the C-Rep, which can be operated by a single individual, a group of individuals, or an entire hospital, serves as a “portal” between the “mini-ICON” network that the community runs on, and the “big-ICON” public network. Circling back to our example, let’s say among the community of hospitals, “Hospital A” is chosen by the other 9 to serve as the C-Rep for the hospital community.

This means Hospital A’s node is in charge of verifying the transactions being sent to and from the “mini-ICON” hospital network to the “big-ICON” public network. It also has a vote when it comes to governance decisions of the “big-ICON” network as it relates to how communities are governed.

Nexus / ICON Republic

The ICON Nexus is essentially the primary mechanism that serves to “hyperconnect” other blockchains; however, it’s structure is a bit more nuanced than that, so let’s break down what the Nexus is, as well as what makes it (slightly) distinct from the ICON Republic.

Let’s look at the exact definition of the term “nexus”:

“a connection or series of connections linking two or more things.”

That’s exactly what the ICON Nexus does. ICON calls this nexus the “ICON Republic.”

So let’s look at the definition of “republic:”

“a government in which supreme power resides in a body of citizens entitled to vote and is exercised by elected officers and representatives responsible to them and governing according to law”

Moving forward, the simplest way to understand the distinction between the ICON Nexus and the ICON Republic is that the ICON Nexus describes the technology that ICON utilizes to connect blockchain communities, and ICON Republic refers to the conceptual connection between those communities, especially as it relates to governance.

The ICON Republic is comprised of the C-Reps described in the section above. That means the C-Rep for the hospitals is connected to the ICON Republic. So is the C-Rep for insurance companies. So is the C-Rep for universities. As the whitepaper describes, “Governance of ICON Republic is determined by the consensus of C-Reps, with the scope of governance limited to ICON Republic.”

To understand how all this works, let’s take a visual approach.

Imagine a large, one-story building that is designed as a loop. This is the nexus. Now, surrounding the nexus are several smaller loop-shaped buildings, each with hallways connecting to the nexus. One of these smaller buildings could be labeled “Hospitals,” another “Insurance,” and another as “Universities.”

Remember our friend Ashley from the example described above? Let’s take the step where she gives permission to the hospital to share her medical records with the insurance company.

In the Hospital “building,” her records are carried to the door of the hallway connecting to the nexus. Standing at the door is a metaphorical individual with a computer. This is the C-Rep. They review the information, verify it, and allow it to pass through the door.

The medical records travel into the larger loop building, where they move down the hallway until the insurance company is reached. Another individual is standing at that door — the C-Rep for the insurance community. They, too, review the information to verify it and allow it into the insurance building.

Meanwhile, every once in a while, the C-Reps gather together to vote on decisions that have to be addressed involving the network. This is when they function as the ICON Republic.

Easy enough?

Well it does get a bit more complicated.

Remember the section above where I mentioned the “multi-channel” features of the loopchain technology? Remember, the ICON Nexus is part of the loopchain architecture, so the multi-channel element is featured here too.

So what exactly are the channels?

Pretend that larger-loop building isn’t just one giant hallway, but rather multiple hallways running adjacent to one another. They are labeled as:

1. Representation Channel

2. Public Treasury

3. Notary Channel

4. Public Channel

Let’s examine closer what each of those does.

Representation Channel

This is the “hallway” where decisions about governance are made, as described above. This is where the C-Reps “meet” to decide such issues. Here is how it’s described in the whitepaper: “in a Representation channel, one can manage node policies regarding node addition and removal in Nexus, adjust ICX transaction fee, manage node selection and removal.”

How much say in these decisions does each community C-Rep have? Again, the whitepaper: “The voting rights are distributed to the community based on I_score, which is the contribution level of corresponding community towards the invigoration of ICON Network.”

We will go into the details of I_score at a different time, but for now just know it is a mechanism for objectively determining the level of contribution being made to the network based on community size and transaction scale.

Public Treasury

According to the whitepaper, “Any ICX newly issued, as well as ICX allocated to be distributed as transaction fees, is first held in the Public Treasury. The Public Treasury is the account from which Incentives are distributed. Any ICX not allocated or distributed to a particular party due to reasons including but not limited to the elimination of incumbent C-Reps will be held in the Public Treasury and held as source of incentives to be distributed at a later date.”

Imagine this hallway as simply holding piles of currency— in this case, ICX — like a vault, to be distributed to participating nodes as an incentive for validating transactions, as described in the whitepaper: “the transaction fees generated from transactions will be distributed only to those who have contributed directly. As a result, a direct incentive to participate in the transaction is generated and the incentives are given out stably.” Like the voting rights described above, the amount of ICX to be distributed is calculated based on I_score.

Notary Channel

Earlier on, I referenced how, once information left the “hospitals” building, it passed through the nexus to reach the “insurance” building.

In that case, the information needs to travel through the notary channel. To better understand just how this happens, let’s again refer to Speculative Rationality:

“A research institute from a Research Institute Community wishes to access the historical records of a Hospital that belongs to a Hospitals Community. The elected C-Nodes within the research Institute Community who have voting rights to the notary channel will authenticate the request before registering it to be processed with the notary channel. The light clients representing each of the blockchains on the Nexus certify the registered blocks according to the LFT Consensus algorithm. Once two thirds or more of the signatures on the block are verified, the block is transmitted to the Hospitals Community through the portal. The Hospitals Community blockchain verifies the transaction block according to the PKI system, to validate the certification issued by the light clients. The transaction is processed, and the Hospital records requested by the research institute are released.”

In other (and simpler) terms, the Notary Channel is, to a certain degree, the “master blockchain” that validates and stores the history of transactions between different communities, and allows them to pass between one another.

Public Channel

Let’s imagine this hallway is the one closest to the outer walls of our large loop building, but with a front door that anyone can walk through.

In this case, those that can utilize the public channel include:

Anyone making ICX transactions (if you’ve sent ICX to someone, you’ve used the public channel)

Creating dApps (decentralized applications)

Using dApps

If you walk through the door of the public channel, you become a “citizen node.” Unfortunately, as explained in the whitepaper, a citizen node “does not hold rights to verify transactions or vote on governance issues. Only allowed to generate new transactions.” However, a “Citizen Node can also be a C-Rep with voting rights if certain conditions are met.” While the whitepaper doesn’t specify how, Speculative Rationality hypothesizes that, as an example, “the provider of a Medical Data Exchange DAPP stakes ICX to gain permission to act as representative for those using his/her DAPP.”

Now that we’ve described the entire Nexus, here’s what it would look like within the context of our building analogy:

(If you weren’t aware, BlueWhale and WeBloc are dApps built on the ICON Network)

Decentralized Exchange (DEX)

One of the more misunderstood elements of the ICON architecture has been the purpose of the decentralized exchange. While some believed it was being built as a way to compete with other exchanges, such as Binance, it actually exists to serve an important purpose within the ICON ecosystem.

Technically speaking, the DEX is a dApp built on the Public Channel, rather than a channel in and of itself.

Here is a description of a DEX from the ICON whitepaper:

“DEX, on the other hand, enables automated transactions without the need to trust a particular exchange, supports completely anonymous transactions, and is free from problems such as server breakdown and hacking. … As a blockchain network that links multiple blockchains with their own unique governance, ICON provides DEX based on ICX. It enables transactions among different cryptocurrencies by determining the exchange rate through Reserve based on the Bancor Protocol.”

Let’s go back to our example featuring Ashley.

After her surgery, Ashley has to pay for her procedure at the hospital. In this example, she does so with Ethereum; however, since her insurance company utilizes the ICON network, it prefers ICX. In this situation, upon payment of Ethereum, the DEX is able to automatically convert the Ethereum to ICX based on exchange rate calculated by the Bancor Protocol.

Here’s how it works according to the ICON whitepaper:

“If one purchases ICX with ETH via DEX, the Reserve Balance composed of ETH increases and the ICX decreases, resulting in an increase in the ICX Price. Conversely, buying ETH with ICX reduces the Reserve Balance and increases the ICX Volume, resulting in a decrease in the ICX Price. … If ICX is listed and traded on another exchange, its value at the corresponding exchange and the value at ICON DEX may be different. In this case, arbitrage transactions which lead to ETH inflow and exchange will take place, thereby resulting in similar price levels of ICX.”

Put another way, the DEX is basically executing the supply and demand curves. If someone buys ICX with Ethereum, the price of ICX will go up, and vice versa. If ICX is more expensive on the DEX than on, say, Binance, then people will sell their ICON on the DEX, driving the price down, and reaching equilibrium with the Binance price.