Proposals for Streamr governance Q4/2022

It’s time for another round of Streamr governance voting!

This post attempts to collect all proposals shared by Streamr contributors and and community members on #governance channel and elsewhere on Discord, and assign SIP (Streamr Improvement Proposal) codes to them to help refer to them in the discussions that follow. So please note that this post may update over the next few days until the voting begins.

The authors will upload their proposals to the project’s Snapshot governance tool on Wed Nov 23rd and the voting will commence right away.

Thanks to a recent upgrade, it’s now possible to vote using staked DATA tokens.

For those new to voting on Snapshot, Matthew has you covered with this tutorial.

A foreword from Henri, the author of four proposals this time around:

“There are two previous decisions made in 2021 during better market conditions, which in my opinion need to be revisited and modified to fit the changed conditions everyone in crypto is now living in. I have two proposals related to that, while my other two proposals are smaller housekeeping items, with their own pros and cons too.

None of the decisions are easy or obvious; that’s why the ability to decide together is so important and powerful.”

Find the proposals below:

SIP-9: Create a project treasury for post-roadmap expenses from the 100M DATA allocated in SIP-6

Proposed by: @henri#1016

Background

In the SIP-6 proposal, passed in May 2021, a supply of 100M DATA tokens was approved to be minted to raise further funding for the Streamr project to cover post-roadmap expenses. The initial project funding will last at least until late 2023, beyond the Tatum milestone, and is held safely in fiat. Arranging the post-roadmap funding is not particularly urgent but the plan needs to be revisited due to changed market conditions.

According to the SIP-6 decision, the tokens were to be sold to crypto VCs at a maximum of -20% discount from market rates, in exchange for a 12-24 month lockup period. At the time of the proposal, DATA price was around $0.10-$0.15, meaning that this supply of tokens had the potential to raise around $8M-12M (factoring in the discount), should the price level stay stable. The idea was also to generate stable yields for the project by depositing the raised funds into DeFi pools, yielding around 10-15% at the time for stablecoin pools.

Clearly this was an opportunistic proposal based on assumptions that did not hold beyond the favourable market conditions at the time:

• The market price of DATA has since then crashed along with the rest of the crypto market
• The stablecoin DeFi pools now yield 0-3% instead of 10-15%

The market, as it is now, is very different. As a result, none of the 100M DATA has been minted yet, and it’s not particularly attractive to lock in the current prices or give any discounts to the already depressed market price.

The project expenses are currently around $3.0-3.5M per year. Post-Tatum, as all the main tech building blocks will have been built, spending on development and maintenance can be decreased, while the spending allocated to growth efforts and ecosystem development can be increased. In all cases, the spending must be adjusted to the available project funding.

Proposal

I propose that the 100M DATA (already approved to be minted) will be used to seed a project treasury which can (only) be spent over time on project expenses from late 2023 onwards (once the initial funding runs out), instead of raising funding in advance and locking in the currently prevailing low rates.

In practice:

• The tokens can be spent over time to pay project contributors or entities that host those contributors
• The tokens can be sold over time to maintain a stablecoin/fiat buffer in advance of upcoming stablecoin/fiat expenses

As a result, the tokens will gradually float to open and efficient markets little by little through project contributors that have earned them by working on the project, not all-at-once via VCs seeking to speculate on the token. This way, the tokens are sold gradually over time, with negligible market impact.

As the downside, it’s not possible to predict how long that supply of 100M DATA will last, as it will depend on market conditions in late 2023 and beyond. In our view, it doesn’t make sense to try and draft a long-term plan instead right now. The current market conditions offer limited visibility, price levels are unattractive for fundraising, and the project still has a major milestone to reach.

I propose this course of action as a bridge/medium-term funding plan to get the project safely into 2024, and then see where the project and the whole crypto space are at the time. I expect that a further decision should be made in 2024. By that time, the current turmoil will hopefully have passed and the DATA community will be able to make longer-term decisions in more stable market conditions. In addition, post-Tatum milestone, there is an opportunity to cover maintenance and growth costs from protocol fees.

The case against the proposal

• This proposal doesn’t solve the long-term funding needs of the project
• By spending tokens on expenses instead of selling them to VCs, the project won’t get additional validation and support of such VCs
• If the crypto market further depreciates by late 2023, the supply won’t last very long

The case for the proposal

• This gets the project well into 2024 and potentially way beyond if the markets recover
• With the current market turmoil, a medium-term decision feels like a better strategy than trying to predict the future or lock in the current rates
• Releasing tokens to the market gradually and at a rate equalling project expenses (or slower, as some recipients will keep them) avoids negative impact on the markets
• This proposal doesn’t introduce new inflation; a 100M DATA supply increase has already been approved earlier by token holders in SIP-6, and this proposal just recycles that

SIP-10: Reduce DATA holders’ allocation of Data Union spin-off tokens from 40% to 15%

Proposed by: @henri#1016

Background

Another proposal, SIP-3 from May 2021, was approved to spin off the Data Union Framework product into a separate project called the Data Union DAO, aiming to launch its own token, UNION. As the Data Union Framework was initially built with Streamr funding, SIP-3 directed the spin-off to allocate 40% of UNION tokens to DATA token holders.

At the time, the crypto market was doing well and funding was more easily available. As of now, raising funding for new projects is extremely challenging and anything that seems “off” in the eyes of early backers may block progress.

We’ve been observing the Data Union DAO being pitched to crypto VCs. While they typically like the idea, they often have questions about the 40% allocation to DATA holders. The allocation seems to be too large, leaving too few tokens into the project treasury to incentivize growth.

Looking back at what was decided, the VC’s are probably right. There are not many examples of spin-offs or demergers in the crypto space, but there have been a few similar cases to reflect on in the Gnosis ecosystem:

• CowSwap is a spin-off from Gnosis. 10% of COW tokens were allocated to Gnosis.
• Safe is a spin-off from Gnosis. 15% of SAFE tokens were allocated to Gnosis.

While there aren’t enough data points to compile a statistic here, 10-15% of the token allocation seems to be an acceptable amount to ‘give back’ to the origin community.

Proposal

I propose that the DATA community settles for 15% of the tokens to be launched by the Data Union spin-off. The goal is to make the spin-off project more attractive to fund and to eliminate any concerns related to the allocation to DATA holders.

It should be noted, should the proposal be approved, that the Data Union spin-off would then have more tokens in its treasury as a result. The additional tokens could then potentially be allocated to early builders and early users. By participating in the Data Union ecosystem, Streamr community members can increase their chances of getting allocation through other means in addition to the 15% share.

The case against the proposal

• DATA holders will be allocated less tokens
• In the current market conditions, the spin-off may still struggle to raise funding despite this change

The case for the proposal

• The 40% allocation may be a blocker in fundraising
• It’s better to get 15% of something valuable than 40% of zero

SIP-11: Increase staking cap per node to 20k DATA

Proposed by: @henri#1016

Background

Since the Brubeck mainnet launched with incentives to run Broker nodes, there has been a maximum amount of 10,000 DATA that can be staked per node. The amount is a balance between:

• Maximising the number of nodes in the network: more nodes is better for proving protocol reliability and scalability, and bigger numbers are always better for marketing 🙂
• On the other hand, each node comes with fixed operating costs, so a low limit means higher fixed costs for node operators that run several nodes and therefore less profit margin

With the DATA token value hurt by the overall crypto market crash, the profitability of running Broker nodes has decreased. At current market prices, 10k DATA equals around $240 in value. With roughly 50% APR, roughly $10 will be earned per month per node. If running a node costs, say, $5 per month, half of the earnings are spent on operating costs.

Proposal

Increase the staking maximum per node to 20,000 DATA.

To repeat the above example calculation with the new cap, this would allow $480 worth of DATA to be staked per node, earning roughly $20 per month – and with the same $5 example operating cost, this means that only 25% of earnings is spent on operating costs.

The case against the proposal

• This is likely to decrease the number of nodes in the network by up to 50%, as people will need to run half as many nodes to stake a given amount of tokens.
• While the Network is enjoying constant organic growth of nodes, the total number of nodes will drop at least temporarily.

The case for the proposal

• This will increase the profitability of running Broker nodes.
• Better operating margin will attract more nodes to compensate in the initial reduction in node count.

SIP-12: Drop the old XDATA token from governance

Proposed by: @henri#1016

Background

The DATA token migrated to a new smart contract from July 2021 onwards. The old token was renamed to XDATA, while the new token adopted the symbol DATA. Any remaining XDATA tokens can be migrated 1:1 to DATA at any time and forever by interacting with the migration smart contract. 80% of token holders have already migrated to the new DATA token.

Since the migration started, both XDATA and DATA have had voting power in governance decisions on Snapshot.

Proposal

Drop XDATA from governance voting. If this proposal passes, those who still hold XDATA will no longer be able to vote on future proposals or submit new proposals.

The case against the proposal

• XDATA holders are still Streamr supporters, even though they haven’t bothered to migrate

The case for the proposal

• Passive token holders are unlikely to vote anyway
• This is a final nudge to encourage XDATA holders to migrate
• Cleaning up old stuff is good

SIP-13: Streamr Log Store Proposal

Proposed by: Ryan | Usher#2802

Please note, some of the details of the proposal have been omitted in this blog for brevity. Please see the full proposal here.

Context

Streamr currently does not support indefinite and/or decentralised storage for data streams.

Storage Nodes are Streamr’s current solution for delivering data persistence.

While a good solution for ephemeral data, it:

• lacks controlled and/or indefinite persistence
• is centralised with a capacity for semi-decentralisation
• requires the development of the same value propositions offered by existing & maintained decentralised storage platforms like Arweave and IPFS/Filecoin.

To decentralise persistence, incorporating existing decentralised storage platforms is an inevitable step forward for the Streamr platform.

Usher, is proposing to solve decentralised storage for Streamr by delivering integration between Streamr and existing decentralised storage/data technologies.

Solution

This solution is comprised of leveraging four technologies:

1. Streamr—Necessary for transporting data anywhere.

2. Kyve—To securely coordinate a decentralised network of nodes, aka. validators, responsible for performing and validating the movement of data from Streamr data streams to a storage blockchain.

These validators form a Kyve Pool (example). Each validator can be an independent entity securely participating by staking via Kyve’s platform.

Data archived with Kyve is also indexed, such that data can be queried through a GraphQL interface.

3. Arweave—A blockchain for permanent, accessible and decentralised file storage.

4. EVM Smart Contract—logstore.sol—A decentralised authority over which data streams are stored by the validator nodes.

A value-based stake (in ETH, MATIC, DATA, etc.) is required to be included in the parameterised Log Store to finance the compute and storage costs.

By integrating these technologies, we form a decentralised data pipeline governed by an EVM Smart Contract, such that Streamr data is moved to Arweave for permanent and decentralised storage by a Kyve Pool (a decentralised network of nodes).

Scopes & Objectives

The development of this solution will be separated into milestones.

Each milestone will begin with a proposal submitted to Streamr’s Snapshot.

This allows the Streamr Community to vote on whether the given milestone proceeds and if it should be funded.

If the milestone is approved to be funded and funding terms & amounts have not been explicitly detailed within the given milestone proposal, a subsequent proposal to approve funding terms & amounts will be shared for open governance.

The purpose of this proposal (SIP) is to determine whether to start the first milestone.

Approval of this proposal (SIP) will set the first milestone’s scope of work in motion.

The scope for each milestone is as follows:

Milestone 1: Proof of Concept

This phase includes developing just enough of the solution to demonstrate that it can work within production parameters such that ingestion of data into the node network represents Streamr’s live environment.

Milestone 2: Production

This phase includes the development of optimisations, integrations and compatibility mechanisms that further improve UX.

What is Kyve?

It’s important to establish what Kyve does before diving into our approach to development.

The Kyve Blockchain is a Cosmos-based Blockchain responsible for drawing consensus on votes submitted by Validators within a “Pool”.

A Validator has two primary processes:

1. Deterministically produce a “bundle” of data from some source.
2. Compare this produced “bundle” to a “bundle” that has been proposed, and then vote on whether the proposed “bundle” of data is valid.

The result is a series of validated datasets stored on Arweave or some other storage blockchain.

The key outcome occurs when these bundles are combined in chronological order. When combined, they produce a fully decentralised append-only event log.

Read more about Kyve here.

Fee Calculation

The stake requirement to facilitate a decentralised log store compensates the Kyve Pool Validators.

Fees are calculated for each log store.

Fees are reallocated after a given dataset/bundle has been stored.

The total fee is the sum of the:

• fees incurred from data stored
• validator rewards for facilitating storage
• treasury fees to fund the maintenance & development of the platform

Validator rewards and treasury fees should & will be governable in a decentralised manner.

While a new governance token offers a breadth of options for scale and purpose, Kyve already offers a governance platform, and therefore, the first version of the Log Store platform will leverage Kyve’s existing governance technology.

This enables validators staking in Kyve’s platform to participate and vote.

Repository

Work on the repository can be found here.

Timeline for Milestone #1

• 4 – 6 weeks
• Log Store Node
• logstore.sol Smart Contract
• Creating Documentation
• Developing security compatibility with Streamr private data streams
• 2 – 3 weeks — additional time for:
• e2e testing
• proposal and governance management across technologies
• validator onboarding and coordination
• in case anything goes astray

Execution

As part of it’s research in merging off-chain & on-chain, Usher has devised the storage solution outlined in this proposal and will be mandated to carry out the delivery and management of the solution.

Deployment

The solution will first be deployed to testnets, such that the entire experience can be tested without real value reallocated to validators.

Deployment to live networks will be proposed to the validator network upon completion of testing.

Upon proposal approval, such that each validator is prepared for the live deployment, the solution will be deployed to appropriate live networks.

Funding

While this proposal establishes a model for monetisation through treasury fees, direct funding provides an additional mark of confidence from Streamr and other interested backers.

With funding delivery of all of the objectives detailed in the given milestone is guaranteed as the requirement for immediate monetisation is alleviated.

Funding for Milestone #1

This proposal (SIP) enables the Streamr Community to vote on funding the given milestone’s scope of work.

Due to the immediate and small nature of the scope, being a proof-of-concept, funding will size similar to a Streamr Network grant. That is up to twenty thousand USD dollars.

Voting

This proposal (SIP) will allow DATA token holders to vote on the most appropriate way forward for the delivery of the Log Store platform:

• Approve & Fund: Prior to project commencement, a new proposal (SIP) will be produced to offer DATA token holders a vote on the funding amount and treasury fee share & terms.
• Approve: Simple approval by DATA token holders to commence the project.
• Reject: Reject the proposal and keep Steamr storage exclusively managed by the Streamr Network.

The case against the proposal

• The Streamr Network has an existing solution for storage and this solution is already being developed to facilitate the value propositions outlined in this proposal, making the Log Store redundant.
• The proposed solution creates too much dependency on third-party technology adding a layer of security risk to Streamr Developers and Data Providers.

The case for the proposal

• Inevitable development: The Streamr Network needs a decentralised & fault tolerant integration with decentralised storage networks for permanent and/or controllable decentralised data persistence.
• Focus: Decentralised Storage of Streamr Data (Log Store) and the Streamr Network are fundamentally different technologies, and deliver different values.
• Empowerment: The Log Store platform becomes a self-sustaining, healthy project powered by Streamr. The Log Store also empowers the Data Union Framework to distribute larger stored & validated datasets to Buyers.
• Retained Vision & Direction: While this new development does set a new precedent for how storage by Streamr will be managed, it does not redirect or change the network’s original vision and purpose, which is to enable a real-time data network.

Thanks (and well done!) for reading the proposals! If you have any questions or feedback, please add them in the #governance channel on Discord and join us for an open AMA on the proposals at 14:00 CET on Thursday 24th November.

See you soon! 🧡