Time to talk about the DATA token economics of the Streamr Network! The token economics will be released in the 2024 milestone (1.0), and actual implementation work will start as soon as this year’s Testnets have completed.
Although the current state of research and planning are at a pretty advanced stage, please bear in mind that what you see here may still be subject to change. Please see the Streamr docs for an up to date understanding of the Streamr Network tokenomics.
Before diving into the roles and mechanisms involved, let’s briefly discuss why token economics are needed in the first place!
Table of Contents
Why the Streamr Network needs token economics
In the Streamr Network, both data publishers and subscribers are nodes in a peer-to-peer network. Nodes involved in a stream of data connect to each other in a certain way – forming the stream’s topology – to perform the main function of the Streamr Network: the dissemination of messages published to that stream.
So every node that joins a stream both consumes data in that stream AND helps relay it onwards to other nodes interested in the stream in a peer-to-peer configuration. Since everyone who uses resources also contributes resources back to the network, can’t the system work without any token incentives, based on reciprocity alone?
Under perfect conditions perhaps, yes, but the real world is far from perfect. In practice, the reliability of message passing is reduced by the following
- Churn – Nodes joining and leaving the stream can add instability to the topology, which could disrupt message flow
- Free riders – In a decentralized network, there’s no way to enforce honest behaviour. Some nodes might selfishly consume messages but refuse to propagate them onwards
- Malicious nodes – Some nodes may intentionally try to disrupt the network
- Node failures – Nodes can crash, run out of memory, get overwhelmed with data, get disconnected, experience packet loss, etc.
So, very roughly, what determines the quality of service in a stream’s topology is the ratio of honest, stable nodes vs. nodes that perform questionably. If your use case needs honest, stable nodes to make your data flows more robust, how do you incentivise good nodes to join? Well, you pay them. This forms the basis of the token economics (tokenomics).
Traditional software products often have freemium and paid plans. Decentralized protocols usually have more of a grayscale spectrum as a result of being subject to true market conditions – you pay more for better service. Gas price on Ethereum is a good example: you bid a higher gas price to incentivise miners to execute your transaction faster. A similar economy is at play on Streamr: you pay less (or even nothing) if you’re happy with best-effort performance, while you can pay to incentivise nodes to make your stream more robust and secure.
For the sake of clarity, the Streamr Network tokenomics should not be confused with the transactions happening on the Streamr Hub. On the Network, people pay for infrastructure costs; for data delivery. On The Hub, people pay for access to data content. Here’s an analogue: when you order an item from an online store, someone (either you or the store) pays the postal service for package delivery. You also pay the online store for the item you ordered, or the package content. Note that you can very well use the Network for data delivery without using The Hub at all, just like you can send and receive packages without ordering stuff from online stores.
The roles in the Streamr tokenomics
Publishers and Subscribers are already familiar roles in the Streamr Network. These roles are only related to the data flows in the network, meaning these roles could be seen as being one layer ‘below’ the tokenomics. In the below diagrams, data flows are shown in blue.
The introduction of token economics defines three new roles: Sponsor, Operator, and Delegator. These roles use DATA tokens to participate in the incentive mechanisms, and those value flows are shown in the diagrams below in orange.
It should be noted that the roles are independent of each other and can be mixed and matched by all actors depending on their goals, for example, the same person could be a Sponsor, Publisher, and a Delegator.
Publisher
A Publisher is simply a node through which certain data enters the network. The data usually originates in an adjacent application that interfaces with the Publisher node, with the goal of delivering that data to Subscribers via the network. Publisher nodes relay the messages to other nodes they are connected to.
Subscriber
A Subscriber is a node in the network that wants to receive messages from a stream. Just like Publishers, they also relay the messages to other nodes they are connected to. Subscribers may have a range of different motivations for joining a stream – there could be an adjacent application that wants the data, they could be Operators who mine the stream by becoming Subscribers (see below), or they may even want to help the stream simply for charitable reasons.
Sponsor
Sponsors pay to secure the operation of a stream. They pay DATA tokens into a smart contract called a Sponsorship. Essentially, the Sponsor says “I want to spend X amount of DATA tokens over a period of time T to improve stream S”. The Sponsorship contract releases the funds over time to Operators who are mining the Sponsorship (see below to learn about Operators). It should be noted that a stream can have many Sponsors, and they could be anyone at all, including the Publisher(s), Subscribers, or a third party.
Streamr Node
Streamr nodes are the miners in the Streamr Network. They are nodes that constantly monitor which Sponsorships are available – Sponsorships are smart contracts on the public blockchain, so they are visible to everyone. Streamr nodes choose the Sponsorships they want to start mining, stake DATA on them, and become Subscribers in the related streams. The promise of the Operator is: “I am an honest and stable node, and I’ll join the stream topologies to help stabilise and secure them”. Operators don’t subscribe to a stream because they’re interested in the data, they join because they want to earn a share of the DATA tokens flowing through a Sponsorship. The Operator can claim their rewards periodically to withdraw earned tokens from the Sponsorship contract.
Operators are expected to be honest, following the protocol rule of properly forwarding messages to other connected nodes. And they are also expected to be stable, with good uptime along with sufficient bandwidth and hardware resources to handle the traffic of the stream. If they fail to meet these standards, they could be kicked out of the Sponsorship and their stake could be slashed.
The amount of DATA tokens the Operator stakes on the Sponsorship determines the size of their share of the token flow. The Operator will generally stake on Sponsorships where they can earn the best available yield for their stake. Other Operators in a Sponsorship are there to share the cake, so overcrowded Sponsorships may not offer the best yields, and some Operators will decide to mine other Sponsorships instead. Like any open market, the market of servicing Sponsorships will always gravitate towards achieving equilibrium between supply and demand.
Delegator
Delegators are DATA token holders who don’t want to do mining themselves, but would rather earn on their tokens by supplying liquidity to Operators. In exchange, they earn a share of the Operator’s rewards. Since Operators need to stake tokens to mine Sponsorships, having access to tokens from Delegators enables them to earn more from Sponsorships, creating a win-win situation.
Delegators select Operators to stake on and deposit tokens into the Operator’s Stake Pool smart contract. The funds in the pool can then be used by the Operator for staking on Sponsorships.
Observability and free riding
While the above processes and roles may seem quite straightforward, one of the key challenges is preventing Operators that don’t actually do the work (of joining the stream’s topology and relaying messages to connected peers) from earning Sponsorships.
Since the Operators place a stake on the Sponsorships, they could be slashed for not doing the work. The problem is proving to the smart contract that a particular Operator did not do the work or otherwise live up to its promises. There’s limited observability in the network, as basically only the peers connected to a node really know what the node is up to. On the other hand, only the tracker knows which nodes are connected to each other. By combining attestations from a Operator’s peers as well as the tracker, it could be shown with reasonable confidence that a Operator did/didn’t fulfill the requirements of servicing the Sponsorship – potentially leading to slashing the Operator or at least kicking them out of the Sponsorship.
To avoid being slashed, Operators will need to ensure that their node is connectable and up to the challenge of distributing data on the sponsored stream. Running redundant nodes is an excellent way to protect yourself against slashing.
Delegators are also at risk of losing value if they delegate to unreliable Operators. Read more on the bigger picture of network incentives.
Nodes regularly spot test each other in Sponsorships, and raise flags if they think another Operator is not online and doing the work. A flag stake is placed to back up the claim. A number of reviewers are selected to validate the flag by also testing the flagged Operator and voting. The flagger loses the flag stake due to a false flag when the majority of flag reviewers vote that the flagged Operator is actually fine, and the flag was therefore deemed invalid. See node inspections for more information on the node flagging process and parameters.
See node inspections for more information on the node flagging process and parameters.
As you probably realise by now, this is pretty complex. As is usually the case with decentralized systems, nothing is foolproof and every such system has some conditions under which it fails or becomes less reliable. Understanding those conditions well is the key to establishing what parameters work in the real world and what guarantees can be given about the system in practice. And indeed, much of the remaining work is exactly in this area.
Finally
As part of the rollout of the 1.0 milestone, we’ll also be exploring a range of new use cases for the Network, such as DePIN, decentralized AI, and video streaming. We’re already seeing some traction on these use cases, and we’re excited to see what you, the community, build with the Streamr protocol.
However, as I mentioned in the beginning of this blog post, there may still be some changes and tweaks to the plans.
What do you think about the current progress and plans? Join the Streamr Discord to chat more!
