First off, apologies for missing last week’s update. After nearly four months of not being able to return home to Japan, we were finally able to find a direct flight. Thus, I was very busy with packing and preparing for the trip home. Anyhow, in this edition of ICON Weekly, we’ll take a look at the IRC-3 and IRC-16 token standards and ICON’s recent mainnet update.

IRC-3 and IRC-6 Token Standards

As the ICON project continues to pick up steam with regard to adoption, there are now two new token standards in the pipeline – IRC-3 and IRC-16. IRC-3 is an NFT (non-fungible token) token standard that lets users deploy non-fungible tokens on the ICON blockchain. IRC-16 is a security token standard that can be used to tokenize real-world and traditionally illiquid assets on ICON.

IRC-3 - Blockchain NFTs

Let’s start with IRC-3 first. A fungible asset is one where individual units of the asset are equal and interchangeable. The most obvious example of a fungible asset is the cash we use everyday. If you go to the store and pay with a five dollar bill, it doesn’t matter which five dollar bill you give to the cashier. With that in mind, a non-fungible asset is one that isn’t interchangeable. For example, a first edition Blue Eyes White Dragon is more scarce than a regular edition Blue Eyes White Dragon. Even though both cards are the same, they are not really the same in the context of fungibility.

An NFT token standard lets users create cryptographically-verifiable UNIQUE tokens on a blockchain. Buzzwords aside, it’s a pretty big deal because – unlike many things in the crypto sphere – NFTs have real and easy to understand use cases. In recent history, the most infamous implementation of NFT technology was undoubtedly CryptoKitties on Ethereum. In CryptoKitties, collectible cats are represented by ERC-721 NFT tokens. Each NFT token has slightly different characteristics, which translate to visual differences in the game’s frontend. At first glance, CryptoKitties may seem silly, but it’s not silly at all. The game is a perfect example of how blockchain can be used to power a desirable product – someone actually paid $170,000 for a CryptoKitty.

In the context of the ICON ecosystem, I think the IRC-3 NFT token standard is an extremely positive development. ICON has three unique strengths that many other blockchains don’t have – fast block time, native interoperability, and high profile business connections in South Korea. An NFT use case I’ve been thinking about lately is in-game collectibles represented by NFT tokens.

For example, imagine if you could trade a special sword in Game 1 for some in-game currency on Game B. Building a cross-game ecosystem like this is totally feasible on ICON. The fast 2 second block time allows for near-realtime settlement for in-game economic exchanges, and BTP interoperability allows for game-specific blockchains to interact with one another. Lastly, ICONLOOP already has a history of forming alliances and consortiums, so I think convincing a few South Korean gave development companies to pilot this kind of system is in the realm of possibility as long as the incentive structure makes sense.

IRC-16 - Liquidity for Illiquid Assets

Tokenization is another strong and obvious use case for blockchain. In life, not everything is liquid and divisible. An example of an illiquid and non-divisible asset is real estate. Buying a skyscraper is a relatively expensive proposition, and such a market is really only available to high net worth buyers.

For better or for worse, the societal structures that exist in the world don’t allow for “average people” to participate in these exclusive markets. A skyscraper is also non-divisible for the most part. You can’t exactly cut the skyscraper into a hundred pieces without making the building worthless. This is where security tokens come into play. Security tokens inject liquidity into illiquid assets by making them divisible and technically easier to access.

Let’s take the skyscraper example again. As a seller, with a security token standard like IRC-16, you can mint a specific number of tokens to represents “shares” of the skyscraper. You can then transfer ownership of shares to a buyer by sending the corresponding number of tokens to the buyer’s public key. Since the IRC-16 standard lives on a public blockchain, the number of shares and their respective owners are easily verifiable by anyone at anytime.

When it comes to tokenization of real-world assets on blockchain, there are already a number of established players. Over the past few years, various companies have tokenized billions of dollars worth of real estate assets on the Tezos blockchain. If you’re interested in learning more about real estate tokenization, check out this podcast episode I recorded with William McKenzie for Tezos Commons. While Tezos does have a significant first-mover advantage, I don’t think entering the STO market is a bad idea for ICON at all.

The asset tokenization sector is still very young, and many countries haven’t even explored this use case of a blockchain from a regulatory perspective yet. Lastly, I think integrating MyID to link ownership of an IRC-16 security token with BTP interoperability is a huge plus for ICON – this has the potential to open up automation of property taxes, legal paperwork, and other administrative processes via smart contracts.

ICON Mainnet Update

This past week, P-Reps voted on and approved the Revision 9 proposal on the ICON network – RHIZOME voted yes. The update included a number of important changes to the ICON network.

P-Rep Key Dualization

One of my biggest concerns since ICON’s initial decentralization is the lackluster security protocol around key management for P-Reps. Unlike other blockchains that provide native support for hardware keys (e.g. Ledger, Trezor, etc.), an ICON P-Rep node stores its keystore directly on the server. Even worse, the keystore password is stored as plain text in the node software’s docker-compose.yml file, and it’s not even hashed. Even though I am obviously a fan of the ICON project, there’s just no way to spin this in a positive manner. Passwords should never be stored in plain text – this is Computer Science 101.

With the new key dualization feature, P-Reps can now designate a secondary “node address” to store on the server. The node address is designated by a P-Rep’s governance address using preptools, so this adds a much-needed layer of security to ICON’s network design. With this new model, a P-Reps governance key no longer needs to be exposed to the public Internet, and it also allows for routine rotation of on-server keys.

I really appreciate the key dualization feature, and I’ve already set up a node address for RHIZOME. With that said, I still think the ICON team needs to take security more seriously. Passwords should never be stored in plain text, and first class support for hardware modules is important.

SCORE-Based Staking and Delegation

The second new feature that was enabled with the Revision 9 proposal is SCORE-based staking and delegation. To put it simply, this feature enables smart contracts to stake and delegate on your behalf. It’ll be interesting to see what kind of tools and services will be built with this feature. For me, the most obvious use case is automating staking and delegation to different P-Reps based on various conditions. I’m sure that ICONists who want to see less vote stagnation would be interested in a service like this.

I-Rep Network Proposal

I-Rep is no longer a stake-weighted average of individual P-Rep submissions. Instead, I-Rep is now a global variable that can only be changed via a network proposal. I’m not a fan of this new I-Rep implementation at all. The previous I-Rep calculation system (stake-weighted average) allowed individual P-Reps to have a direct voice and direct impact on ICON’s economic incentive generation model. If a team felt I-Rep should be higher, it could directly impact the metric without asking for permission from other teams - it was permissionless.

In the new system, I-Rep has become yet another political structure to take direct economic influence away from P-Reps. By adding another layer of social consensus to something as simple as changing I-Rep, P-Reps will be socially influenced to lean towards a certain direction (down) when it comes to proposing I-Rep changes. Why risk getting castrated and crucified on Twitter for being “greedy” by putting out a proposal to raise I-Rep?

By changing the I-Rep implementation to a network proposal model, ICON has effectively taken another step towards minimizing rewards for P-Reps. With this new system, the chance of I-Rep going up in the future is severely lower than the opposite. From ICON’s perspective, this makes perfect sense in the context of other upcoming economic-related changes like the CPF (Contribution Proposal Fund) – minimize P-Rep rewards to node operation costs and offload funding for other contributions to grants and the CPF.

I don’t know if moving I-Rep to a network proposal is a good thing or a bad thing. What I do know is that this model injects an additional layer of social consensus where it isn’t necessarily needed, and skews bias and behavior to one direction. With that in mind, I think ICONists need to reevaluate what a P-Rep is. From my perspective, ICON is evolving into a more traditional PoS network where “P-Reps” will primarily just be node operators. For P-Reps who want to contribute more, that’s where grants and the CPF come in. In other words, “proof-of-contribution” was an interesting idea in the past, but I don’t think “contribution” needs to be a focal point of being a P-Rep anymore – at least not as much as in the past.

Lastly, I want to express some frustration into how the new I-Rep model was just casually thrown into the basket of feature updates in the Revision 9 proposal. A network-wide economic change like this one should’ve been an individual proposal. It doesn’t make sense to include an economic change (not a feature) with other actual features like P-Rep key dualization and SCORE-based staking and delegation. I’ve spoken to members of several P-Rep teams who were onboard with the new features, but not onboard with the new I-Rep implementation (RHIZOME included). Unfortunately, there isn’t a way to vote for certain aspects of network proposals only, so we all voted yes.

Miscellaneous Updates

The Revision 9 proposal also included a few other feature updates.

• It’s now possible to vote for up to 100 teams. The current limit is 10.
• It’s now possible to submit multiple unstaking requests.

That’s it for today. What are your thoughts on NFTs and security tokens? Let me know on Twitter or send me an email.