Skip to main content

Fee structure

Service fee​

The service fee is a fee rate that is paid by the Subscriber for receiving data from the Publisher. It is the price of data that the Publisher wants to earn per some standard amount of data delivered to each Client. This standard pricing unit is fixed at 1 gigabyte (GB) to match the standard units of VPS network costs. The service fee is the price of 1 GB in Synternet tokens set by the Publisher in the on-chain service corresponding to the actual data stream.

The rewards for the Publisher are calculated as a function of the length of the data stream delivered to the Client in gigabytes.

note

The service fee can be zero. That makes perfect sense, if the Publisher is, for example, an official full node by a newcomer blockchain project that self-promotes by making its data available on Synternet Data Layer. The cost of running a full node in this case will be covered by attracting more new users to this incumbent blockchain and collecting more gas fees there.

Network fee​

Brokers and Observers receive rewards based on the network fee, which is a static protocol parameter defined per 1 gigabyte of data relayed. The value of this parameter is likely to remain fixed in the tokenomics v1 but will change in the future versions.

The selection of the static network fee, as compared to the dynamic that would allow Brokers to set their own rates, is a deliberate tokenomics v1 design decision made with simplicity and transparency in mind.

Static fee rate results in every data stream being exactly the same from the Broker's perspective. There are no preferences in terms of resource optimization. This means that within the Broker network, all data is treated equally.

Static network fee also means that Brokers with higher network costs will be worse off. However, this should be partially mitigated by the flexibility each Broker entity has in setting up nodes at more lucrative geographical locations without additional crediting per every new node.

Total subscription price​

Subscribers simply pay the sum of the service fee and network fee, which is called the total subscription price.

For example, in mainnet, the network fee is 200 tokens per 1 GB of data. For its service, the Publisher has listed the subscription fee of 100 tokens per 1 GB of data. The accounting round has finished with 250 megabytes:

  • Total subscription price is 300 tokens = 200 tokens + 100 tokens.
  • Total cost of the data is 75 tokens = 300 tokens * 0.25 GB.

Observer attestation share​

The larger share of the network fee goes to the Broker node since it actually dedicated a lot of its networking resources to deliver that data. A smaller share of the network fee is split between all Observers who have attested the Proof of Delivery.

For example, in mainnet the Observer attestation share is set to 16%, and the quorum of Observers required for each attestation is 8. Therefore, if the network fee collected within the Proof of Delivery is 100 tokens, then:

  • Brokers receive 84 tokens = 100 tokens * (1 - 0.16).
  • Each of the eight Observers receives 2 tokens = (100 tokens * 0.16) / 8.

Broker reward distribution​

There are cases when multiple Broker nodes and/or entities are delivering the data to the Client. This may be the case when one of them has a node close to the Publisher, and another closer to the client; it is possible that from the networking perspective, the pathfinding algorithm decides that it is more optimal to route data through these two hops instead of any of them separately. The reward is then split equally by the number of Broker entities participating in the delivery process.

For instance, following the example from above, 84 tokens were accumulated as a Broker reward within PoD. Let’s assume, there were 2 Broker nodes by Broker entity A and 1 node by Broker entity B involved in the process of delivery:

  • Each Broker entity receives 42 tokens = 84 tokens / 2.
  • The earning rate for Broker entity A is 21 tokens per Broker node, so it is worse off.
  • The earning rate for Broker entity B is 42 tokens per Broker node, so it is better off.

This approach is the simplest, and to some extent, topology agnostic, where we need to only account for the cases where node ownership has changed. At the same time, Brokers are motivated to deliver messages on the shortest path, which may potentially increase the performance of the network.

However, in a theoretical scenario where multi-hop is allowed, a malicious Broker could try to set up multiple nodes with different ownership addresses, inject them on the path in order to increase his path participation and receive a higher reward. This behavior can only be limited by increasing the cost of Broker entity registration.

Figure: Fee structure for N Broker entities that have participated in the delivery and M Observers. In the case shown here, N=2 and M=3.