We did it! Data Unions 3.0 is now live.
Data Unions 2.0 was a first step in the direction for members to use, trade, or transfer their earnings without having to bridge them to the expensive Ethereum mainnet. We did this in 2.0 by moving the Data Unions contracts to the Gnosis Chain. This way, the mentioned transactions only cost fractions of a cent.
However, we still bridged transactions like deploying a data union or data purchases on the marketplace over the Ethereum mainnet.
That is what Data Unions 3.0 is improving: Not only are you now able to choose an alternative EVM-compatible sidechain like Polygon, but we also removed the bridging to the Ethereum mainnet contract altogether. Thus, when a data union gets deployed or someone purchases access to the data (for example via the updated Streamr marketplace), the transactions will exclusively happen on the chosen EVM sidechain like Polygon.
Another substantial change is the detachment of the data union functionality from the Streamr client. We did this by providing a separate Data Unions client.
The Data Unions client contains all of the functions required by data union builders, whereas the Streamr client is responsible for the underlying data transport.
The client separation also demonstrates the flexibility of the Data Union framework as revenue sharing infrastructure capable of adapting to any underlying technical stack.
How does this affect developers and admins?
Two main things change in the code.
Prior, one had to use the Streamr client in order to create and interact with a data union. As mentioned we now have a separate Data Unions client instead of the Streamr client.
In addition you can now optionally add your desired EVM sidechain to the client configuration.
Check the following code snippets to see how this looks like.
Before:
After:
The administrator can now withdraw earnings from the admin fee the same way data union members do.
Before, admins had to withdraw their earnings from the mainnet contract with the high transaction fees. Since we don’t bridge from the mainnet to the sidechain anymore, earnings are stored in the chosen sidechain contract.
What changed in the smart contracts?
The Data Union 3.0 smart contracts contain some minor improvements.
With the new contract, you’ll be able to add metadata to your Data Union. The new state variable is called “metadataJsonString”. The owner of the contract will be able to set this variable via a callable function and the initial deployment. Note that it is just callable and purely for off-chain usage. The metadata unlocks endless use cases: you can add a name, a manifesto, or any other information related to your data union.
Data Unions are subject to a protocol fee set and collected by the Data Union DAO. The rate was set to 1% in the DUIP-1 governance proposal. The update makes it easier for the DAO to govern and collect the fee from all Data Unions at once. As a recap, here’s how the revenue in a DU is split:
- Data Union DAO = 1% (set via governance voting)
- Admin fee = x% (set by the DU owner)
- Member share = 100% – x% – 1% (the rest is shared among active members)
Which sidechains are supported?
As of right now we support Polygon and Gnosis chain (formerly known as xDai chain). However, we are going to support more EVM-compatible L1 and L2 chains. Potential next steps could be Binance Smart Chain, Avalanche and Optimism.
Running custom join servers
Join servers are centralized gatekeepers that validate members attempting to join a Data Union. They keep out bots and other fake users, and their functionality can be customized and extended to meet the needs of any Data Union – for example to add a CAPTCHA.
The Data Union DAO continues to host a default join server which validates joins based on a shared application secret. If you wish to customize this functionality or remove your Data Union’s dependance on the centralized join server, the DAO now provides two great open source starting points:
- A ‘vanilla’ join server which you can import as an npm package and inject your own validation logic, or
- The default join server run by the DAO, which builds upon the ‘vanilla’ server, and which you can run as is or fork to customize the functionality.
Migrating second-generation Data Unions to 3.0
As the contracts themselves contain only minor improvements, builders who are already running a 2.x Data Union have no urgent need to migrate to the 3.0 contracts. The new client library is backwards compatible with the Gnosis chain part of 2.x Data Unions. Please don’t hesitate to reach out via our discord if you have questions or run into any issues.
We’re also planning on launching a bug bounty and a user testing challenge to improve our docs and overall developer experience, more details on that soon.
