Some time ago, a twitter thread made the community react about the amount of $6600 of communications consumption on the Helium network. This thread was full of approximations in order to present negatively the growth of the Helium network. But it is also an opportunity to take stock of the development of the use of the network. We will see in this article who operates the Helium decentralized network, what are the current data volumes and what are the associated financial metrics.
In short, we cannot talk about Nova Labs’ revenue with respect to direct communication costs because these costs are associated with different third parties offering the packet routing service. We cannot rely on this cost to estimate an associated business volume because there are many indirect costs as I have already specified in my blog post analyzing the running costs of a Helium router/console. Finally, regarding a long period where gamers found a way to earn a few dollars on the back of Nova Labs, involving many ancillary costs, distorted the data for June. You will understand all this in the rest of the article.
Disclaimer: I’m the owner of the public helium console helium-iot.eu (oui 6) – no need to makes comment like “he have written this because he own … blablabla”
What is an Helium console, who own them ?
As Helium is a web3 LPWAN network, it runs in a decentralized way, there is no central point (as much as possible) and anyone is free to contribute and expend the network. As part of these contributions, anyone can create a LoRaWan Network Server and connect it to the network to manage a fleet of devices. This is a big difference compared to other LoRaWan networks. Usually the owner of the network and the network server is the same company and you have a one-to-one relation. On Helium network, for the same global network, you have multiple network servers operated by different companies. For this you need to acquire and run your own router and console, corresponding to the LoRaWan Network Server. I wrote a post, previously, that fully detail the way to create your own Helium console.
You have an interest to have your own Helium console if you manage a big fleet of devices, if you want to make sure your data are fully private or if you want to offer a connectivity service based on Helium. This is why I have created the Helium-IoT.eu public console with no restrictions. (I also create/manage private console for enterprises on demand).
So currently, we have 39 routers already created, with 23 connected and 21 processing devices data in July 2022. Advantage of a blockchain, everything is public and after some investigation, I arrived to the following list:
|1||Helium||free public console with restriction|
|6||Helium-iot.eu||public console not restricted|
|9||Created by Helium||unknown usage|
|10||futuredecisions.net||air quality, energy use-case|
|12||Created by Helium||unknown usage|
|15||Created by Helium||unknown usage|
|16||Created by Helium||unknown usage|
|23||Brdots||public console in Brezil|
|24||Semtech||localization service demo|
|25||not clearly identified||unknown|
|32||lithium-app.com||monitoring & alerting services|
|33||Rak wireless||rak devices|
|36||unknown||unknown, located in spain|
|37||quivo.net||unknown, in bulgaria apparently|
|38||poged.pl||unknwon, in poland apparently|
The non listed OUIs are the one that are offline or not completely setup.
We see on this list 3 type of owners:
- device maker (sensecap, rak, bobcat)
- service providers (handonsystems.com, lithium-app.com, futuredecisions.net…)
- connectivity provider (helium, helium-iot.eu, brdots …)
Where the June 2022’s $6600 of communications comes ?
From an ETL (a database with all the blockchain information), we can access the information about the traffic through the token transaction performed.
SELECT sum(packets.num_dcs) from packets where "time" >= 1654041600 AND "time" < 1656633600; 663567876
In June, 663M of DCs have been consumed for purchasing paquets on the different routers. As the price for 100.000 DCs is $1, it means $6.630k have been distributed to the hotspot owners for receiving these communications.
The twitter feed I mentioned above was indicating these $6.6K as NovaLabs revenue, this is totally wrong as this is a cost for the router owner, so it is a cost for NovaLabs and other router owners. This is a revenue for the hotspot owners. So in June, 6.6K$ has been distributed, that way between the different hotspot owners being part of packet transfer.
Now we can take a look to the router data transfer for this month to see how it is distributed ( lets take the main routers)
|OUI||Who||Data Transfer cost|
|1||Helium public console||$5588|
|16||Helium unknown usage||$416|
|9||Helium unknown usage||$325|
|12||Helium unknown usage||$244|
|24||Semtech localization demo||$17|
|6||Helium-IoT.eu public console||$13|
We see that most of the traffic is passing through thee different NovaLabs services. The public console and some other console, may be, as part of it the B2B console.
What can we think about these $6600 ?
This value has no real economic meaning, we will see that a bit later. But we can take a look at it in regard of the evolution of it. But at first we need to mention Helium has changed, in June, the number of free DCs for opening an account on the console. As announced, it was related to some bad people using robots to create account, fake device, to get paid in DCs for fake communications. This has been stopped by June. July is a reference of legit traffic as a consequence. So let’s take a look at the historical traffic:
|Month||Total $ equivalent DCs used for packet transfer|
Wee see that gamers started to attack the Helium console on January at scale and Helium has started to block them May. The total of DCs stolen than way can be estimated around $55.000. By making investigation, I’ve identified about 136 data-only hotspot (I assume they are pure software based on gateway-rs), not positioned participating to this in June. I did not investigate more to see the attached wallet and so on. You can get this list with a such request on the ETL database:
SELECT actor,sum(amount) s from dc_burns where "type" = 'state_channel' AND "time" >= 1654041600 AND "time" < 1656547200 AND amount > 50000 GROUP BY "actor" ORDER BY s;
As a consequence, the $6600 is a wrong estimation of the growth of the network and the hotspot owner revenue as most of it has been sent to gamers playing with the Helium’s router wallet. The current, real volume of data is around $2199 and this is about 220M packets transferred (equivalent 24 bytes). The growth compared to December is not significant but gamers may have already been here at the period of time.
Can we consider that $6600 is the overall economics around data transfer ?
Considering thee $6600 as the data transfer economics is a big mistake. The data transfer, as I described it in my post on the overall helium router economics, is only a part of the different transactions around data transfer. This is the part going to the hotspot owners. When you run a helium router/console, you have many different costs related to the blockchain transactions. As part of these transactions, you have the State Channel maintenance and the XOR filter update.
The state channel cost is related to the duration, volume of data and number of actors in a certain way. The XOR filter update is related to the device addition in the console. If we take a look at historical data on the last 3 months, here is what we have:
|Month||Packet Transfer||State Channel Maintenance||Xor Filters||Ratio|
The ratio is the multiplier, from the packet transfer cost, to obtain the global blockchain cost. This ratio does not includes the initial investments, the server cost and the man power. It depends on each router/console configuration, volume of device … Here you see the overall value to illustrate that in June, the global economics was not $6.6k but is was 8.5x.
This has been reduced drastically in July for two reasons:
- The first one is the end of gaming, reducing the number of device creation (to get the $4000 overhead in packet transfer, they had to create at least 40000 accounts with 10.000 DCs in it, it also means registering a minimum of 40k devices).
- The second one is related to the XOR filter update cost formula. It has been changed to stay stable and not exponential with the growth of registered devices. Each device registration was, for Helium console, about $1 in June.
My analysis conduct me to estimate that NovaLabs has lost about $200k related to the XOR filters updates, on top of the $55k given to gamers. Definitely, the $6.6K are not Helium revenue but a large cost over $250k spent. In the same thread there was a parallel between investor cash and the mentioned $6.6k … but don’t be afraid, as Helium and investor are getting 35% of the distributed token… and DCs are burned token, so… there is no investor money directly spent here, just free token, that will potentially miss later for something else but no money.
The money question is more for the other console owner having to buy HNT to make their router running.
What is the current status of the data transfer economics ?
Now let’s complete this blog post with the current situation of the different router/console to see what we can learn from July 2022 (number are rounded to $, ratio computed on DCs):
|OUI||Owner||Packet Transfer||State Channel||Xor Filters||Ratio|
|1||Helium public console||$1438||$471||$392||1,6|
|6||Helium-Iot.eu public console||$10||$7||$24||3,9|
What can we learn from this ?
- Helium public console is the main console running data-transfer, this is an historical situation, most of the community is using it for the device already commissioned. User are only paying for the packet transfer DCs, the other costs are taken by NovaLabs. Efficient.
- Helium private console 2, 9 and 16 are not growing but running large fleets of devices, I don’t know what are the applications, it can be dedicated for certain customers.
- Helium console 12 seems to be the growing one for certain customers ; we see a ratio of 2.16, this is interesting to notice as Helium seems to propose a running cost with a ratio of 1 for customers, it means, every communication is a loss for NovaLabs.
- Sensecap and RAK console setup are bad, they overspend a lot due to the State Channel management cost. Ubidots is not better.
- The different service providers with a private console also need to improve their setting, they are overspending a lot. They are not big numbers and marginal over the server costs but it’s a loss that can be avoided for the same service at the end.
These information will help to later see the growth of the network use, this is the first reason why I decided to share it in this post, with all that level of details.
If $6600 is not revenue but cost, what are the data transfer revenue ?
It’s not easy to estimate the revenue, the revenue is what the customer pay for it current and future communication, it makes sense when it is payed with fiat or eventually when customer tokens are burned for this purpose. The burning part can be followed in the router wallet DC balance and related activities. I did not investigate this as it is incomplete. These payment and the growth of the payment is important as it is a good indicator of the trust of the user in the network in long term perspective. Even if the volume is still low on what I can see, the trend is good and the volume is largely higher than the volume indicated above. As an indication, I can tell you that the volume of revenue for my router/console have a factor of 10x compared to the cost indicated above. This is not margin but communication pre-ordered for the future.
How can I verify these numbers ?
I used the following ETL PLSQL script to obtain these numbers …
CREATE OR REPLACE FUNCTION LoopOuisTable() RETURNS SETOF RECORD AS $$ DECLARE _nonce BIGINT; _oui BIGINT; _addr TEXT; _dcs BIGINT; _xors BIGINT; _scs BIGINT; ret RECORD; _startEpoch BIGINT; _stopEpoch BIGINT; _dcs_dol BIGINT; _xors_dol BIGINT; _scs_dol BIGINT; _dcratio REAL; BEGIN _startEpoch := 1654041600; _stopEpoch := 1656633600; FOR _oui, _nonce, _addr IN SELECT distinct on (oui) oui _oui, nonce _nonce, addresses _addr FROM ouis ORDER BY oui, nonce DESC LOOP IF ( _addr IS NOT NULL ) THEN -- GET Sum of Dcs from State Channel Close WITH alldcs AS ( SELECT jsonb_array_elements(fields->'state_channel'->'summaries') AS dcs FROM transactions WHERE "type" = 'state_channel_close_v1' AND CAST ( fields->'state_channel'->'owner' AS TEXT ) = CONCAT ( '"',_addr,'"' ) AND "time" >= _startEpoch AND "time" < _stopEpoch ) SELECT SUM(CAST (dcs->>'num_dcs' AS INTEGER)) INTO _dcs FROM alldcs; IF ( _dcs IS NULL ) THEN _dcs := 0; END IF; _dcs_dol := _dcs / 100000; -- RAISE NOTICE 'DCS: %', _dcs; -- Get XOR costs SELECT sum(amount) INTO _xors FROM dc_burns WHERE "time" >= _startEpoch AND "time" < _stopEpoch AND actor = _addr AND "type" = 'fee' AND (amount != 35000 AND amount != 70000); IF ( _xors IS NULL ) THEN _xors := 0; END IF; _xors_dol := _xors / 100000; -- Get State Channel Open Cost SELECT sum(amount) INTO _scs FROM dc_burns WHERE "time" >= _startEpoch AND "time" < _stopEpoch AND actor = _addr AND "type" = 'fee' AND (amount = 35000 OR amount = 70000 OR amount = 105000); IF ( _scs IS NULL ) THEN _scs := 0; END IF; _scs_dol := _scs / 100000; -- Get the ratio packet DC vs Total DCs IF ( _dcs > 0 ) THEN _dcratio := (_dcs + _xors + _scs) / _dcs; ELSE _dcratio := 0; END IF; SELECT _oui, _addr, _dcs, _dcs_dol, _xors, _xors_dol, _scs, _scs_dol, _dcratio INTO ret; RETURN next ret; END IF; END LOOP; END; $$ LANGUAGE plpgsql; SELECT * from LoopOuisTable() as (oui BIGINT, address TEXT, DCs BIGINT, DCs_DOL BIGINT, XORs BIGINT, XORs_DOL BIGINT, SCs BIGINT, SCs_DOL BIGINT, DCRatio REAL);