In this edition of ICON Weekly, ICON partners with Band Protocol, ICX fees go through the roof, and RHIZOME deploys a new citizen node endpoint for ICON dApps and services.

ICON Partners with Band Protocol

Earlier this week, ICON announced a new partnership with Band Protocol, a newcomer in the decentralized oracle space. Band is the second oracle project that ICON has announced an integration with. Back in February, ICON revealed that it was working with Chainlink, the undisputed leader in the decentralized oracle space, to add oracle support to ICON. As far as I know, there is still no publicly-available Chainlink integration for ICON dApps and services.

Thankfully, that’s not the case with Band – ICON’s press release included a link to documentation on how to use Band oracles to link real-world data to ICON dApps. According to ICON, “using Band Protocol, ICON developers are able to tap into various built-in price feeds or create a customized oracle script fine-tuned to their needs”. Let’s talk about why decentralized oracles for price feeds are important for blockchain networks and decentralized applications.

Imagine if you have a dApp that lets you bet on ICX price. Where does the dApp get the price from? There are a lot of different price feeds out there – Binance, Kraken, Coin Market Cap, etc. What would happen if the dApp developer chose to use Coin Market Cap’s ICX price as the single source of truth? Coin Market Cap is a centralized entity, which means it can easily manipulate the price of ICX for its own financial gain – I’m not saying CMC would do this, I’m just saying it’s possible. With a decentralized price feed, this kind of manipulation is much more difficult because of two major reasons.

  1. Decentralized oracle networks utilize multiple price feeds, and those price feeds are typiclly backed by different people with different interests.
  2. Node operators on decentralized oracle networks like Band and Chainlink have money at stake. Node operators are economically motivated to be honest and provide accurate data.

Band is still a very new project – it’s ICO took place just two months ago. Having access to multiple decentralized oracles ultimately makes ICON into a safer and more reliable blockchain platform. As we enter into the next phase of blockchain adoption where smart contract logic will execute in response to real-world data, decentralized oracles will play a very important role.

100x Fees on the ICON Network

In crypto, we’re always talking about 100x, but most of us are not referring to transaction fees going up 100x. Unfortunately, that’s exactly what happened earlier today following ICON Foundation’s network proposal to increase fees.

The original intention was to make the change below – a 25% increase.

Before: 10000000000 loops
After:  12500000000 loops

What ended up happening was this - a 12,484% increase.

Before: 10000000000 loops
After:  1258425417728 loops

It was later discovered that the Governance SCORE interpreted 12500000000 as a hex value (0x12500000000). The equivalent decimal value of this hex value is 1258425417728, which explains the transaction fee spike. To fix the issue, the ICON team edited the SCORE to take a human-readable decimal value instead. After the fix was deployed, ICON Foundation submitted a second network proposal to restore step price to the desired 12500000000 loops.

At this time, the new proposal is still being voted on, but I’m glad that the situation is on its way to being resolved. With that said, what happened today is very concerning and truly makes me question the technical competency of the ICON team. I am saying this as an ICON supporter of three years. This is not FUD. ICON has some explaining to do, but let me explain my perspective first.

ICON prides itself on being an enterprise-focused project. Over the past few years, Min Kim has consistently pushed ICON’s ICONLOOP’s enterprise connections as a positive development for the ICON public chain. Imagine what would’ve happened if large-scale enterprises had actually been using ICON’s public chain today. They’d probably be looking at migrating to another chain already. The fact that this “bug” was allowed to happen tells me that ICON is not an enterprise-ready project – not even close.

Quite a few things went wrong today. Here’s how we can improve.

Think About the Humans

The ICON team needs to take human readability into account. Input fields for key network metrics should not require someone to input a number as a hex-encoded string. The team should perform an audit on the whole codebase to ensure something like this never happens again.

Review the Codebase

The ICON team needs to get more familiar with their own codebase. In Scott Smiley’s original proposal. he noted that “there is a maximum increase in Step Price of 30% so it will take some time to reach the goal of 10x growth”. Now that we know this safeguard was not in place, steps should be taken to ensure similar misunderstandings don’t happen again.

ICON Needs a Technical Lead

The ICON team needs to review internal technical protocols. From the outside, it really looks like the Governance SCORE that required a hex-encoded input was never tested. This is unacceptable for a project that prides itself as an “enterprise solution”. On a related note, Min is good at business development (obviously), which is very much needed for closing partnership deals. However, I think ICON needs a dedicated “technical lead” to find success in the long term.

At this stage in the game (three years in), ICON’s developer documentation and relations need to be improved significantly. This fact is actually super ironic when you consider that ICON has SDKs for Python, Java, Swift, JavaScript, and more. The tools exist for this project to succeed, but the Foundation hasn’t done much in terms of giving context to the tools.

For a good example on what ICON could be doing to improve the developer experience, just take a look at Apple’s recent sessions from WWDC. Sure, Apple has billions of dollars in the bank, but that doesn’t mean ICON Foundation can’t follow this model with its measly $40 million ICO.

I truly believe that it’s not the community’s responsibility to transform ICON into a more developer-friendly platform – at least not at this time. There’s still a lot of technical knowledge that is siloed within the ICONLOOP organization, and it’s not efficient for P-Reps and other community developers to spend a lot of time digging for information, especially when the Foundation doesn’t have a dedicated developer relations team. For developers who aren’t financially-invested in ICON (or who don’t care about potential ICX appreciation in the future), it would be more efficient to move to a platform with better developer support – and that’s exactly what we are starting to see now.

After today’s ordeal, I would not be surprised to see more P-Reps and dApps exit the ICON ecosystem. In fact, Pocket/Figment just left today, and we recently lost Somesing (ICON’s largest source of transactions) as well. Now is the time for ICON to step up its game and improve technical protocols and developer relations – before it’s too late.

ICON Needs to Take Testnet Seriously

Lastly, and this is really the most important point here, changes should always be tested on a testnet first. If this had been tested, we would’ve caught the bug. Unfortunately, I’m not optimistic. As history as shown us, the ICON team has never taken testnet seriously.

To this day, we still haven’t had the opportunity to do a proper load test in a testnet environment that reflects mainnet conditions. I hope today’s events will encourage ICON to take testnet more seriously. We need an incentivized testnet (especially after ICON’s campaign to lower P-Rep rewards) that simulates mainnet. This is the only way to properly test things out. Deploying to mainnet and hoping for the best is not a viable solution for a healthy ecosystem.

Something “good” did come out of today’s transaction fee situation though. I have renewed confidence in ICON’s P-Reps. Teams like Ibriz, Piconbello, and ICONVIET were already discussing the problem before ICON was even aware of it. It was great to see how quickly P-Reps – many of them community-formed teams scattered all around the world – mobilized to tackle the problem. It was the perfect example of active governance despite the recent funding cuts. P-Reps still care, and P-Reps are doing enough with the resouces they have.

I’m looking forward to reading ICON’s postmortem. Hopefully it contains acknowledgements of the points highlighted above, and presents an actionable plan on how we can improve the network moving forward.

RHIZOME Citizen Node Endpoint

Last week, I wrote about deploying RHIZOME’s new citizen node endpoint to reduce load on ICON’s endpoint. I spent the weekend finalizing the configuration and performing some load testing. In the original post, I mentioned we had node clusters in Iowa, Amsterdam, and Singapore. Over the last few days, I was able to streamline and optimize the configuration even further. As a result, I was able to expand add additional nodes without increasing our monthly server bill significantly.

We now have servers in the following locations.

  • Amsterdam
  • Bangalore
  • Iowa
  • London
  • New York City
  • San Francisco
  • Singapore
  • Tokyo
  • Toronto
  • Sydney

As I specified in the previous post, the endpoint is configured to route requests to the closest geographical location, so you should enjoy low-latency connections no matter where you are in the world.

Earlier today, I worked with nblaze and Sharpn to migrate the FutureICX price prediction dApp to RHIZOME’s citizen node endpoint. Stability and performance are looking good so far! If you would like to use our endpoint for your dApp or service, please get in touch with me via Twitter or Telegram!