Kickstarting Streamr Governance

*Update 16/02/21, voting has now finished. The Streamr community voted in favour of SIP 1 & 2. See the results.

Holders of DATA, the utility token that powers the Streamr ecosystem, will be able to vote on Streamr protocol governance decisions starting from February 11th, 2021. We are very excited to take this first step in empowering the Streamr community to make important decisions about the future of the project.

Towards decentralized governance

Since the Streamr project launched in 2017, the core team has been making decisions about the project in order to make progress on the roadmap and towards the project vision. While efficient, such a centralized governance model is only appropriate as a temporary placeholder. Decentralized governance allows anyone with a stake in the project to contribute to steering it, enabling the wisdom of the crowd to kick in and push the project towards the best long-term outcomes.

Not too long ago, the governance models of decentralized projects tended to be on the heavy side with lengthy constitutions, on-chain voting with enforceable decisions, and elections of boards and councils. We wrote an extensive governance whitepaper to survey different governance processes, both traditional and digital, to gain insights to best practices in the space.

However, the DeFi boom of 2020 has shown that lightweight, hybrid governance models can engage stakeholders, offer guidance to project teams, and add value to ecosystems, while avoiding the complexities of full-blown decentralized governance. Snapshot, the awesome tool by Balancer Labs, has become the voting booth of many high-profile projects such as SushiSwap, Yearn, and Balancer itself. There is now a Streamr space on Snapshot, enabling the community of DATA holders to signal their opinions about submitted governance proposals.

How will it work?

The governance process will kick off with two Streamr Improvement Proposals, SIP-1 and SIP-2, as introduced below.

To participate in voting, you will need to have your tokens in your own custody (in a wallet for which you control the private key) when Ethereum block 11836300 is mined, which is estimated to occur around 4pm UTC on Thursday February 11th. The voting will open around the same time.

The token balances at this “snapshot block” will determine your voting power, which is proportional to the amount of DATA you hold. If you are holding DATA tokens on an exchange, or providing liquidity on Uniswap or another DEX, you will need to withdraw them into your wallet before the snapshot block occurs. Right after the snapshot block you are free to move your tokens out of your wallet – this won’t affect your ability to vote. The voting will stay open for five days and close at noon UTC on Tuesday February 16th 2021.

Voting on Snapshot will not require any gas. We recommend the ubiquitous MetaMask wallet for interacting with the voting UI. Snapshot also supports WalletConnect, Fortmatic, Coinbase, and Torus.

We encourage you to consider the proposals ahead of time. Here are the first two Streamr Improvement Proposals:

SIP-1: Token migration to enable token economics

In the past year or so, many Ethereum projects have gone through a token migration. While it’s a somewhat cumbersome process that requires a lot of coordination with token holders, exchanges, and information sites, it gives the communities the opportunity to update their token contract to implement new standards (e.g. Golem’s GNT to GLM), change branding and support new features (e.g. Aave’s LEND to AAVE), or raise the supply hard cap to enable inflationary token economics (e.g. OCEAN token migration to double the hard cap, setting it to the originally planned value).

The main reason for the token migration is to double the hard-coded maximum supply from 1 to 2 billion DATA.

It’s very important to understand the following, so please read carefully:

• This proposal does not change the circulating supply or market cap. No new tokens are minted by passing SIP-1.
• For any new tokens to be minted, a separate governance proposal clearly describing the amount and purpose of the tokens must be created, and voted on by the token holders. Tokens can only be minted if such a proposal passes.
• This proposal is about technically enabling such decisions to be taken by token holders in the future. With the current token smart contract, minting tokens is impossible, even if the community wanted to and decided to do so.

The case against the proposal

Minting new tokens in the future will dilute existing token holders accordingly. While none will be minted with this decision, the decision signals that the community wants to explore inflationary reward models in the future.

The case for the proposal

A controlled inflationary pool is a powerful tool to incentivise network participation, as seen in almost all blockchain networks including Bitcoin and Ethereum. In the DeFi space, there are many examples (e.g. UNI, CRV, etc.) where minted tokens have been used to incentivise growth and energise the community, and often the growth has added ecosystem value orders of magnitude beyond the caused dilution. Token holders can also defend against inflation by participating in the related programs – participation being exactly the goal of the incentives.

Subsequent proposals will need to be drafted and voted upon for any tokens to be minted. That said, here are some potential use cases for such tokens:

• Bootstrapping the decentralized Streamr Network. Similar to yield farming in DeFi, minted tokens can act as early-adopter bonuses and help focus the community’s efforts. This would also enable nodes to be rewarded already in the Brubeck phase where the Network’s usage fee mechanisms don’t exist yet.
• Rewarding DATA holders for voting on governance proposals (such as this one)
• Incentivising long-term maintenance and development of the Streamr codebase
• Incentivising long-term ecosystem growth and building of applications beyond the lifespan of the current Data Fund.

Why exactly 2 billion DATA?

Token migrations require a lot of communication, coordination and resources to implement. While we don’t expect the full reserve to ever be needed, the hard limit should be set sufficiently high to avoid ever having to do another migration in the future. Doubling the hard cap seems more than sufficient for all foreseeable incentive programs, even in the very long term. In practice, only a fraction of it may end up being created, but it’s better to overshoot than undershoot here to avoid tying the community’s hands to decide on incentive programs.

Implement ERC-677

The change to the hard cap is the only material change in the token migration. However, it is also an opportunity to do a few technical improvements which have appeared since the token launched in 2017, such as implementing ERC-677.

This technical change will enable smart contracts to be notified via a callback function whenever tokens are transferred to them. This is useful in many situations, including moving tokens across interchain bridges, moving tokens to Data Unions, and so on. ERC-677 is an extension of the ubiquitous ERC-20 standard, 100% backwards compatible, and used by a number of well-known projects, such as Chainlink.

The practicalities of the migration

In the token migration, a new token smart contract will be deployed, and token holders can swap their existing tokens 1:1 for the new token at any time. There will be a simple UI for doing this in a self-service manner. The Streamr team will also notify exchanges and other custodial parties, and encourage them to migrate the tokens in their custody.

The new token will adopt the DATA symbol, while the old token will be renamed DATAv1. A similar approach was used in MakerDAO’s DAI migration, where the new token adopted the symbol DAI, and the old token was renamed from DAI to SAI.

You will be able to migrate your DATAv1 tokens at any time, meaning that there will be no particular urgency to do so, or any particular time when you need to have them in your wallet to qualify for the migration.

SIP-2: Drop Canvas and Dashboard features for now

Streamr Canvases are microservices that consume and act upon real-time data, defined in a visual drag-and-drop editor. Dashboards are collections of visualisation widgets extracted from Canvases. While they have proven to be useful tools in the ecosystem, maintaining and upgrading the tooling in future milestones requires considerable resources and steals focus from more fundamental efforts such as developing the Streamr Network itself.

Canvases have so far been a centralized service hosted by the Streamr core team to offer a cloud-like install-nothing experience. As the whole Streamr ecosystem moves towards decentralization as envisioned, Canvases can hardly continue their centrally hosted existence. In the original 2017 whitepaper, it was envisioned that Canvases could eventually run on decentralized computation frameworks developed by projects tackling that problem (such as Golem), but building such frameworks has proven to be more difficult than many imagined at the time, and none suitable for running Canvases are really available today.

The proposal is to remove the Canvas feature from the Streamr Core application and the associated API. The code will be archived into a fork for safekeeping and potential later use. An example of later use could be to relaunch the Canvas tooling at a later time as a self-hosted version which would connect to the decentralized Streamr Network for data.

The case against the proposal

Canvases have value as a tool to create simple automations and integrations based on data from Streamr streams, including simple centralized oracles that interact with Ethereum smart contracts. If the feature is removed, users will need to find other ways to accomplish what they need. Using alternative approaches may be harder than using Canvases, which are pretty user-friendly and approachable.

The case for the proposal

Dropping Canvases will improve the team’s ability to focus on the essence of the project, the Streamr Network and its token economics, and speed up its delivery by eliminating some baggage that would otherwise need to be migrated to newer Network milestones.

Canvases can be used to build automation, visualisations, and oracles – but it’s unlikely to ever become the best tool for any of these tasks, as better, specialised tools and methods are available to most developers and often being used by them already. For example:

• Node-RED is a popular tool for creating data-driven automation workflows, and it already supports Streamr.
• Grafana is a common and flexible framework for visualisations, and it could easily ingest data from Streamr streams with a suitable plugin.
• Chainlink and API3 are frameworks focusing on connecting data to smart contracts, with capabilities that go well beyond the simple oracles that can be built with Canvases. Chainlink already supports Streamr, and Streamr is a founding partner in API3 with an integration planned.

Where can I go for further information?

There will be a Discord AMA at 15:30pm UTC on Tuesday February 9th, where I’ll happily answer any questions you have on the governance process or the two proposals on the table, ahead of the vote. In the meantime, if you have any questions or comments, feel free to drop them in the #governance channel of the new Streamr Discord server, where you can talk directly with members of the team.