Preparing your Operator for Streamr 1.0 mainnet

Breaking new ground with decentralized incentivizes in Streamr 1.0

The Streamr 1.0 mainnet launch is getting closer, and now is the time for Operators to prepare by taking a few steps. In summary:

  • Update your nodes to the RC (Release Candidate) version
  • Consider migrating your Operator smart contract to the new version
  • Help validate the RC version by joining the test Sponsorship

All of the above steps will be discussed below in detail:

The RC version

RC (Release Candidate) versions of the Streamr node and Streamr SDK have been released. Release Candidate means that this version has a chance to be promoted to the first official 1.0 mainnet release if no major issues are detected.

There have been some significant changes since the Testnet 3 version, so some surprises can definitely still come up. If issues are discovered in the pre-launch testing, new improved RC versions will be released until we can declare them the official 1.0 mainnet release.

Exactly like we transitioned from one testnet to the next previously, the RC version is incompatible with the Testnet versions. It means that the new version will want to flag/slash any older versions in Sponsorships, and vice versa. For this reason, you should only stake if you’re running the RC version.

The first RC release of the Streamr node is available as follows:

Note that the package and image names have been updated to match the clarified terminology we intend to use going forward! No more ‘broker’ node, it’s simply the Streamr node!

For those of you building use cases and publishing or subscribing to data from your applications, there’s a matching version of the Streamr SDK (note the new package name here too):

NPM package: @streamr/sdk version 100.0.0-rc.0

Migrating your Operator smart contract

As per the SIP-20 governance proposal, a new feature (minimum delegation period) has been added to the Operator smart contract. Newly created Operators automatically support this feature, but Operators created during the Testnets can not receive it retroactively.

The migration is optional and essentially involves recreating your Operator smart contract. For instructions and more information, check out the docs.

While the minimum delegation period sounds like a relatively minor new feature, it was introduced for a good reason, so upgrading is recommended.

In the testnet version of the Operator contract, an abusive pattern is possible whereby a Delegator first delegates, then collects earnings to update the Operator value, then immediately undelegates, creating an instantaneous profit. Repeating this pattern in rapid succession across many Operators allows the abusive Delegator to potentially create excessive earnings compared to delegating normally. Those excessive earnings reduce the earnings of the Operators and other Delegators.

The minimum delegation period prevents Delegators from rapidly cycling through Operators and taking advantage of the above pattern. By disrupting the loop and slowing it down, the abusive pattern becomes less attractive and no longer gives a meaningful advantage.

Test Sponsorship

There’s a new low-paying test Sponsorship active until the official launch. We really appreciate it if you can join it, as it helps validate things. You should only join the Sponsorship if you run the RC version nodes. (Note that you can join regardless of whether you recreated your Operator smart contract or not).

Keeping in mind that there can still be new bugs in the network, and as the test Sponsorship doesn’t pay out much, we recommend to consider joining with only the minimum stake (5000 DATA) to minimize losses just in case you get slashed due to some bug.

As always, if you have any questions or need help, please turn to the #node-operators channel on the project Discord. We have all come so far together! On behalf of the whole Streamr team, a sincere thank you for your continued interest and support!

Stay up to date

Get the latest Streamr news and articles delivered to your inbox