"A marketplace charges its sellers." Flip that sentence and you get one of the more interesting businesses you can build on VBWD: a member-owned data co-op where the people who supply the goods are paid out, not billed. Members contribute data, subscribers buy access, and contributors receive their share — via payout or non-custodial crypto — pro-rata to what they put in. The dataset plugin plus the withdraw plugin inverts the flow: the "sellers" are your beneficiaries, and the money runs toward them.

Data as a priceable good, not a file dump

The engine is the dataset plugin, and its model is precise: a dataset is priceable, purchase grants an entitlement, and the entitlement unlocks API access. That chain — priceable, then entitlement, then API — is what turns "we have a spreadsheet" into "we have a product." Subscribers do not buy a download; they buy the right to query, metered and governed, through an API the platform controls. That is the difference between giving your data away once and selling access to it continuously.

On the demand side, subscription is the natural fit. Buyers are on tarif plans with recurring billing — a monthly or annual right to access the co-op's data, with add-ons for higher tiers or additional datasets. Recurring revenue in, entitlements granted, API access opened. The buyer side of a data co-op looks like any other subscription business, which is exactly why it is boring in the best sense: it is a solved shape.

The inversion: paying the suppliers

The interesting side is the supply side, and this is where the constellation stops resembling anything off the shelf. In an ordinary marketplace, withdraw moves a vendor's sales proceeds out to them. In a data co-op, you use the same plugin to distribute the subscription revenue to the contributors — the members whose data made the product worth buying. The flow that everyone knows as "pay the sellers" becomes "pay the members," and the mechanics are identical because to the core it is the same thing: money owed, moving out, recorded against the invoice ledger.

Distribution is pro-rata: each contributor's share reflects what they put in, and the split is arithmetic the core can hold because the point of truth is the invoice line item and an event-based contract engine balances assets against obligations. Subscriber revenue is the asset; contributor payouts are the obligation; the engine keeps them in balance. Payouts can settle through the provider-agnostic payment core or via non-custodial crypto — funds moving to the contributor's own wallet, which for a globally distributed set of data contributors is often the only practical rail. The people who built the value get paid where they actually are, in a form they can actually receive.

• Contribute — a member adds data; it becomes part of a priceable dataset.
• Subscribe — buyers pay recurringly for entitlement and API access.
• Distribute — withdraw pays contributors pro-rata, in fiat or crypto.
• Grow — referral compounds both sides at once.

Referral grows a two-sided flywheel

A co-op has a two-sided growth problem: more contributors make the data more valuable, more subscribers make contributing more lucrative, and each pulls the other. The referral plugin lets you reward both sides for bringing more of both. A contributor who recruits another contributor deepens the dataset; a subscriber who brings another subscriber deepens the payout pool that makes contributing worthwhile. Because referral, like every plugin, declares its incentives as line items against the same invoice, the rewards are part of the same ledger that already knows who is owed what — not a separate growth-hacking tool bolted on the side.

And because plugins toggle on and off without a restart, you can launch with contribution and subscription alone, prove there is demand, then switch on payouts and referral as the co-op matures — live, no downtime.

Why this is a genuinely different shape

Most platforms are built to extract from suppliers: list here, and we take a cut. A data co-op built on dataset plus withdraw is built to reward them, and that inversion changes the incentive structure of the whole business. It aligns the platform with the people who create its value, which is a strong story for recruiting contributors who are wary of handing their data to an extractive middleman. The reason almost nobody builds it is that "pay many contributors pro-rata, correctly, across borders, provably" is a hard financial system. Here it is the same withdraw-and-invoice machinery a marketplace uses, run in reverse — and the GDPR-first, self-hosted posture matters enormously when the product literally is people's data.

The honest boundary

VBWD gives you the priceable-entitlement-API pipeline, the subscription billing, the pro-rata payout engine, the crypto settlement, and the referral loop. It does not give you the hardest parts of a data co-op, which are governance and consent. You own the rules for what data may be contributed, the consent and licensing under which members hand it over, the quality control that keeps the dataset worth buying, the pricing of access, and the anti-abuse work of stopping someone from gaming the pro-rata split with junk contributions. Self-hosting personal data is a serious GDPR and stewardship responsibility, and paying contributors is a serious tax and compliance one. VBWD removes the plumbing of collecting, gating, and distributing. It does not remove your duty to run the co-op fairly, lawfully, and with data your members genuinely agreed to share.

The public SDK is at github.com/VBWD-platform/vbwd-sdk-public, the dataset and payout docs are at vbwd.cc/docs, and the team is at vbwd.cc/contact. Dataset publishing already runs on this core as a proven vertical — a co-op that pays its members is that same machinery, pointed at the people who deserve the money.

VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.