Blockchain needs predictable pricing more than anything

Before real companies endorse real blockchain solutions, they’ll need to see a real price tag. This should be obvious.

Nate Simantov
The Orbs Blog
3 min readDec 17, 2018

--

Image by Rachel Skiba

If you’re ever had to purchase an internet data package in recent years ­– traveling abroad, at a hotel or airport, for example — you’ve been starkly reminded of why you hate paying for traffic used, instead of a fixed price. Even if you don’t believe you can possibly surpass the data allocated in your package. After all, you just need it for emails and Google Maps, right? Maybe a couple of WhatsApp messages from family, you’d just be careful not to download any of the photos. In the end however, you wish you could just pay for unlimited usage EVEN if it puts you at risk of ultimately paying for more than you’ve used.

There is a reason you prefer unlimited: As Dan Ariely points out, there’s peace of mind that comes with not thinking about your usage at all. You don’t plan to watch any videos during your trip to Barcelona, but what if you suddenly want or need to? Calculating the size of the video and its impact on your data package is extremely difficult if even possible: Do you lower the video resolution and hope you’re being frugal? Do you independently shut down apps in the background via your settings?

We can see that an inherent problem with estimating a 3g usage pattern is due in part to the difficulty in calculating the size of online traffic. In my early 20’s I worked for a large cell phone provider and we would give clients a three-month average of their 3g use to help them select a better data package. It made sense in the internet’s earlier days when web pages and photos had relatively predictable sizes and you could ballpark your usage pattern, but today, a low traffic user can throw their entire data plan out of whack by viewing a single lecture on YouTube. The unpredictability of cellphone use makes paying per use a frustrating model that we were all happy to abandon the moment “unlimited” data packages became feasible, as they did for home internet access a bit over a decade ago.

Blockchain makes this problem worse. Much worse.

Presently, the inability to forecast monthly expenses poses a major hurdle for any company seeking to implement blockchain solutions. If you’re using blockchain today, you are probably paying for your transactions using pricing mechanisms like EOS RAM or Ethereum Gas which make it virtually impossible to predict your expenses. Of course no large communications company with a proper accounting department can reasonably opt for tools that can’t be priced: A month with few transactions would cost a tiny fraction of that with a high volume of transactions, which leaves the company’s checkbook at the mercy of complete strangers and unpredictable circumstances (viral releases, for example).

And similarly, as dApp developers pay for transactions on their apps and essentially compete with other dApps over computing resources and validations, they cannot plan their budget accordingly or effectively work out what to charge a client.

The Orbs solution: Tier based subscriptions

As expanded on by Ido Zilberberg in June, a major priority of Orbs is to offer subscription style services for transactions on the blockchain. Under a subscription model with Orbs, each dApp gets its own virtual chain; while the app sits on the Orbs shared physical network, it feels like is is on its own dedicated blockchain with guaranteed resources, app isolation etc. The dApp developer then selects the service tier which suits their needs. For example, each tier has its own monthly price, allowing the developer to plan a budget based on expected usage and payment to be made for the nodes operating the virtual chain. With tiers such as 1,000 transactions per second (tps) or 2,000 tps, we can see how the subscription model enables a company like Orbs to do what most blockchain companies can still only dream of doing, namely, offer a binding service level agreement (SLA) to its clients. That is huge.

--

--