How to Build a Data Union and Sell Data for Crypto

A data union is a group of people who pool their data, license the combined dataset to buyers as one party and share the revenue under rules agreed in advance. The pooling matters because one person's browsing history, fitness readings or location trail is worth very little on its own, while a large, consistent, well-described dataset can be useful for analytics, research or machine learning.

Most data unions share the same moving parts:

• Members, who contribute data and receive a share of income.
• A data source, such as a browser extension, a mobile app, a sensor feed or a manual upload.
• An aggregation layer, which cleans, anonymises or formats contributions so they can be sold as a product.
• A payout mechanism, usually a smart contract that holds buyer payments and splits them among member wallets.
• Governance, meaning who sets prices, approves buyers and changes the rules.

The idea is collective bargaining. Instead of platforms collecting data for free and monetising it themselves, members own a stake in the revenue and have a say in how the data is used.

Several projects have built tooling for this model. Streamr offered a Data Union framework for real-time data, and Swash built a consumer app around browsing data. Ocean Protocol focused on data marketplaces and compute-to-data, which lets buyers run analysis without receiving the raw files. The status of each of these changes over time, so check the project's own documentation and recent on-chain activity before building on any of them.

A data union is a business and legal structure as much as a technical one. The code is often the easy part.

A data union earns when someone pays to access the pooled data. The payment model you choose shapes everything else, so settle it early.

Common revenue models

• Subscription access: buyers pay a recurring fee for a live or regularly updated feed.
• One-off dataset sale: a fixed price for a snapshot, often used for research.
• Pay-per-query or per-record: buyers pay as they consume, which suits APIs.
• Compute-to-data: buyers pay to run approved analysis on data that never leaves a controlled environment.
• Bounties: a buyer requests specific data and the union recruits members to supply it.

How revenue is split

Buyer payments typically arrive in a stablecoin or the platform's token, then flow through a contract that deducts fees and divides the rest. Decide these items in writing before launch:

1. The percentage kept by the union's operator or treasury for running costs.
2. Whether members are paid equally per active member or in proportion to the amount, quality or recency of their data.
3. How often payouts run and what minimum balance triggers one, since small transfers can cost more in network fees than they are worth.
4. What happens to members who leave: do they keep earned revenue and does their past data remain in the product?

Equal splits are simple and resist gaming, but they can feel unfair if contributions vary widely. Weighted splits are fairer but need measurement, and any measurement can be manipulated. A common compromise is an equal split among members who passed an activity threshold in the period.

Always model the numbers with conservative buyer demand. Many unions have plenty of members and few buyers.

Most failed data projects had willing contributors and no buyer. Start from demand, not from technology.

Questions to answer first

• Who would pay for this data, and what decision or product does it support?
• Is the data hard to obtain elsewhere? Data that is freely scrapable has little value.
• Can you collect it consistently, with the same fields and format from every member?
• How many members do you need before the dataset becomes useful, and can you realistically recruit that many?
• Does the data stay fresh, or does it lose value quickly?

Data types that commonly suit unions

• Browsing and app-usage patterns, collected with consent through an extension.
• Sensor and device readings, such as environmental or mobility data.
• Survey and preference data from a defined community.
• Wallet-linked or on-chain behaviour that members choose to label, such as which dApps they use and why.
• Niche professional data, such as freelancer rates or creator earnings, shared anonymously.

Validate before you build

Write a one-page data sheet describing fields, expected volume, update frequency and collection method. Show it to five to ten potential buyers and ask what they would pay and what they would need to see, such as a sample, quality checks or proof of consent. If nobody engages, change the dataset rather than writing contracts.

Also test supply. A short waiting list or pilot group of real members tells you more than a large social following. Community platforms and social wallets can help you reach an audience, but a following is not the same as contributors who will connect data sources and keep them running.

Personal data is regulated in many places, and putting a token payout on top does not change that. Get these foundations right before collecting anything. This is general information, not legal advice, so involve a qualified lawyer in each jurisdiction where you have members or buyers.

Core principles to build in

• Informed consent: members must understand what is collected, who may buy it and for what purposes. Pre-ticked boxes and vague wording are weak foundations.
• Purpose limitation: only collect what the stated dataset needs.
• Data minimisation: drop fields buyers do not need, especially direct identifiers such as names, emails and exact locations.
• Withdrawal: give members a way to leave and stop future collection. Be clear about what happens to data already sold.
• Transparency about buyers: publish categories of permitted buyers and prohibited uses.
• Security: encrypt data in storage and transit, restrict internal access and keep logs.

Blockchain-specific cautions

Never put raw personal data on a public chain. It is permanent and public, and it conflicts with deletion rights. Store only hashes, membership records and payment flows on-chain, and keep data in access-controlled storage.

Anonymisation is harder than it looks. Combined fields such as postcode, birth year and device type can re-identify people. If you claim data is anonymous, test that claim, and consider aggregation or compute-to-data so buyers never see row-level records.

Finally, consider taxes and reporting. Members receiving crypto payouts may have income to report in their own country, and the union itself may have obligations. Tell members plainly that they are responsible for their own tax position.

This sequence works for most projects, whichever framework you choose.

1. Define the product. Write the data sheet: fields, format, volume, update frequency, intended buyers and prohibited uses.
2. Draft the member agreement. Plain-language terms covering consent, revenue split, fees, withdrawal and buyer rules. Have a lawyer review it.
3. Build or choose the collection method. Options include an extension, an app, an API connection to a device or a manual upload form. Keep permissions minimal.
4. Add a processing layer. Validate formats, remove direct identifiers, deduplicate and flag suspicious submissions such as bots or copied data.
5. Choose storage and access control. Keep raw data off-chain with encryption, and give buyers access through an API, signed download or a compute environment.
6. Set up the payout contract. Use an audited template where possible. Decide the token for payments, the fee wallet and the distribution rules.
7. Create governance. Decide who can change prices, approve buyers and update terms. Start with a small multisig of trusted stewards, then add member voting as the union matures.
8. Run a closed pilot. Recruit a small group, test collection, quality checks and a test payout using small amounts.
9. Sign the first buyer. Offer a trial or sample, a clear license and an invoice or on-chain payment route.
10. Publish transparency reports. Show member counts, revenue received and payouts made.

Keep the first version small. A narrow dataset with ten real members and one paying buyer teaches more than a broad launch with thousands of silent sign-ups.

You can assemble a data union from a framework, a data marketplace or custom contracts. Each trades speed against control.

Approach	Best for	Strengths	Trade-offs
Data union framework (such as Streamr's)	Real-time or streaming data	Ready-made membership and revenue-sharing logic, existing tooling	Depends on the framework staying maintained and on its network
Data marketplace (such as Ocean Protocol's model)	Static datasets and analysis without sharing raw files	Listing, pricing and compute-to-data concepts built in	Buyers must find you, and marketplace direction can change
Custom contracts and your own app	Unusual rules or specific compliance needs	Full control over splits, governance and access	Higher cost, audit needs and maintenance burden
Off-chain operation with crypto payouts	Early validation	Fast and cheap to test	Less transparent, and members must trust the operator

Choosing a chain

Payouts involve many small transfers, so low fees matter. Layer 2 networks and low-cost chains are common choices, but fee levels and ecosystem health change, so check current conditions. Prefer a chain where your members already hold or can easily get a wallet.

Wallets and onboarding

Members need an address to receive payouts. Beginners often struggle with seed phrases, so a social or app-based wallet can reduce friction. Tomo, for example, is a social crypto wallet offered as a Telegram bot, app, browser extension and developer SDK. Whatever you choose, explain self-custody clearly and never ask members to share seed phrases.

Before committing, check the framework's documentation date, repository activity, audit reports and whether other unions are actively running on it.

Governance decides whether members trust the union once real money arrives. Design it before the first payout, not after a dispute.

Decisions to assign

• Who approves buyers and sets prices?
• Who can change the revenue split or fee?
• How are bad actors removed, and can members appeal?
• Who controls the treasury and any admin keys?
• How are terms amended, and how are members notified?

Practical models

• Steward-led: a small team decides, with a published charter. This is fast and fits an early pilot, but it needs trust and transparency.
• Multisig treasury: several signers must approve spending and parameter changes, which reduces single-key risk.
• Token or membership voting: members vote on proposals. It is more democratic, but turnout is often low and large holders can dominate. Weigh one-member-one-vote against stake-weighted voting carefully.
• Hybrid: stewards run day-to-day operations while members vote on fees, buyer categories and changes to terms.

Protecting the union

Anti-abuse rules are essential. If members are paid for data, some will submit fake or duplicated data, run many accounts or script contributions. Use rate limits, quality scoring, one-person verification where lawful and proportionate, and clawback or suspension rules written into the agreement.

Time-lock sensitive contract changes so members can react, and publish admin addresses. An audit of the payout contract is worth the cost, because the contract holds other people's money.

Finding buyers is usually the hardest part. Plan outreach as seriously as development.

Package the product

Buyers need a data sheet, a free or small sample, a description of how consent was obtained, quality metrics and a license that states permitted and prohibited uses. A short methodology note increases credibility, since buyers worry about legal risk as much as data quality.

Where buyers come from

• Academic and market researchers looking for niche or hard-to-collect data.
• Analytics and intelligence companies that already purchase datasets.
• AI and model developers seeking consented, well-labelled data.
• Crypto projects wanting to understand user behaviour or run research panels.
• Existing data marketplaces, where listing puts you in front of people already searching.

Pricing

Do not copy a number from another union. Price from the buyer's value and your costs:

1. Estimate what the data lets the buyer do or save.
2. Look at what comparable datasets sell for in the same industry.
3. Add your operating costs, member share and a margin for compliance.
4. Offer a pilot price in exchange for feedback, then raise it once demand is proven.

Expect negotiations on exclusivity. Selling exclusively to one buyer may raise the price but blocks other income, so treat it as a separate, higher-priced license.

Keep a record of every sale and its terms. Publishing aggregate revenue and payout figures helps members see that income is real, and a track record becomes your strongest sales tool.

If you want to take part rather than build, treat membership as a trade of privacy for a possible payout, and judge it accordingly.

Questions to ask before joining

• What exact data is collected, and can you see it before it is shared?
• Who can buy it, and are there prohibited uses?
• Is the data anonymised or aggregated, and how?
• How is revenue split, and what fee does the operator take?
• Is there a published payout history and a way to verify it on-chain?
• Can you leave, delete your data and stop collection at any time?
• Who runs the project, and are they identifiable?

Sensible habits

• Use a separate wallet for payouts, with no large balances.
• Avoid sharing data that reveals sensitive categories such as health, finances or precise location unless the terms are very clear.
• Review browser extension permissions and remove ones that seem broader than needed.
• Keep a record of payouts for tax purposes.
• Be wary of any project that asks for a deposit, seed phrase or wallet signature unrelated to receiving payouts.

Realistic expectations

Most members earn modest amounts. Rewards often arrive in a project token whose value can fall, and payouts depend on buyer demand that can disappear. Treat earnings as a bonus, not income you can plan around.

Other social platforms treat reputation or opinions as an asset in different ways. Ideamarket, for instance, lets users post ideas and pay ETH to rate them. It is not a data union, but it shows how crypto projects try to price information and credibility.

Data and token payouts attract scammers, and the risks fall on both builders and members.

Red flags

• Promises of guaranteed or passive income from selling data.
• No named team, no terms and no explanation of who buys the data.
• Requests for upfront payment, a deposit or a token purchase to join.
• Unclear permissions, such as a browser extension asking to read all sites with no reason.
• Payouts that depend on recruiting other members rather than on buyer revenue.
• Contracts with unrestricted admin control and no audit.

Defensive steps for members

• Check the contract on a block explorer: who holds admin rights, and does payout history match the claims?
• Never share a seed phrase or private key. A real union only needs a public address.
• Review every wallet signature request and reject anything that grants spending approval for your tokens.
• Use a fresh wallet and a small test amount first.
• Revoke token approvals you no longer need.

Defensive steps for builders

• Audit payout and membership contracts, and use a multisig for admin keys.
• Store raw data encrypted with strict access controls, and prepare a breach response plan.
• Log access and rotate credentials.
• Limit what you collect, since data you do not hold cannot leak.
• Monitor for fake accounts and replayed submissions.

Before launching or joining, confirm the current status of any framework or marketplace on its official documentation and community channels. Projects in this area can pivot, pause or shut down, and a quick check is far cheaper than recovering from a dead platform or a drained contract.