If you run an OEM instance of a platform, you usually monetize in a single direction. Either you sell access to your own software, or you sit in the middle of other people's transactions and take a cut. Picking one and hard-wiring your whole billing stack around it is the default, and it quietly caps what your business can become.
VBWD is built as a source-available, self-hosted platform (Python/Flask, PostgreSQL, Vue 3, all containerized with Docker) with an agnostic core and a plugin layer that carries the domain logic. That separation is the whole point: because the core does not care what you sell, one instance can run two revenue rails at the same time. Rail one is entitlement licensing. Rail two is Connect-style partner payouts. This piece walks through what each rail is, how they share a single instance, the business shape that results, and where the honest limits are. Some of this is shipping and some is still being built, and I will be clear about which is which.
A hub is a single VBWD instance configured to be the commercial center of a network rather than just a product you log into. It still has the normal machinery: tariff plans, invoices, subscriptions, a user directory, an admin backoffice. The difference is that a hub also carries authority. It can issue signed proof that a downstream customer is entitled to something, and it can be the ledger that decides who gets paid when a referred sale closes.
Nothing about that requires a second server, a second database, or a second billing engine. It is the same instance wearing two hats. The architecture keeps the core generic and pushes the money-shaped behavior into plugins, which is what makes running both rails on one box tractable instead of a fork-and-pray exercise.
The first rail sells access to capabilities. A customer buys a license tariff plan the same way they would buy any subscription, and in exchange the hub issues a license token. The hub acts as a license authority: it holds an Ed25519 signing key and signs each token so that a downstream instance can verify it offline without phoning home on every request. Ed25519 gives you short keys, fast verification, and signatures you can hand to a customer's own deployment without exposing your private key.
The token is not a boolean "paid / not paid." It carries a features list, and that list is what gates capability. A plan can unlock a set of features; a higher plan can unlock more; an expired or downgraded plan narrows the set. The gate lives in the core security layer, so the enforcement point is generic and the meaning of each feature flag is defined by whatever plugin owns that capability.
The business logic reads simply:
customer buys license tariff plan
-> hub (license authority) signs a token with Ed25519
-> token embeds { features: [...], expiry, subject }
-> downstream verifies signature offline
-> features list gates which capabilities are liveFor an operator this is the clean rail. You are selling your own thing, the compliance surface is ordinary subscription billing, and the cryptography means a leaked token cannot be forged into a higher tier because the signature would not verify. If you want to see which capabilities are packaged as plugins and therefore gateable this way, the plugin catalog is the place to look.
The second rail points outward. Instead of selling to a customer, you enable partners to sell on your behalf and you pay them a commission. This is the Stripe-Connect-style pattern: partners onboard as connected accounts, referred sales are attributed back to the partner who sent them, and commission accrues through a defined lifecycle before any money moves.
The lifecycle is idempotent by design, because commission accounting punishes sloppiness. A referred sale moves through four states:
Idempotency matters here because the same webhook or settlement event can arrive twice, and you must never let a retry double-pay a partner or double-count a reversal. Each transition is keyed so that replaying it is a no-op.
The payout itself flows through a provider-agnostic port, IConnectProvider, so the accrual ledger does not hard-depend on any single processor. Stripe is the first implementation, but the seam exists so a second provider can be added without rewriting the commission engine:
referred sale -> accrual (pending)
-> settlement -> confirmed
-> refund/chargeback -> reversed (no payout)
-> payout run -> IConnectProvider.pay(partner_account) -> paidThis rail is where the hub stops being a product and starts being a marketplace ledger. It is also the rail with the heavier obligations, which I will get to.
The reason both rails fit on one instance is that they touch different parts of the same generic spine. Licensing rides the tariff-plan and token-signing path. Payouts ride the sale-attribution and settlement path. Neither owns the core; both are plugin-shaped extensions over it, so enabling one does not entangle the other.
Concretely, a single sale can feed both rails at once. A partner refers a customer who buys a license plan. The license rail issues the signed token and gates the customer's features. The payout rail attributes that same sale to the referring partner, accrues commission in pending, and only advances it to confirmed once the sale settles. If the customer refunds inside the window, the license entitlement lapses on the licensing side and the commission moves to reversed on the payout side. Two rails, one event, consistent outcome.
Because everything lives on one Postgres instance and one admin surface, the operator gets one place to reconcile: which licenses are live, which commissions are owed, which were reversed, and which have been paid. The documentation covers how the plugin layer wires these paths into the core without the core ever learning what a "license" or a "commission" is.
Two rails on one hub gives you two complementary income shapes from the same infrastructure spend. Licensing is recurring, predictable, and high-margin because you are selling capability you already built. Partner payouts are volume-driven and expand your distribution: partners bring sales you would not have closed yourself, and you keep the spread between the sale and the commission.
Run together, they reinforce each other. Partners have a reason to sell because they get paid. Customers have a reason to buy because the license unlocks real capability. And you sit at the center holding the authority to issue entitlements and the ledger that decides payouts. That is a defensible position that a single-rail business does not have.
It also changes your cost story. You are not standing up two systems with two ops burdens. You run one VBWD instance, one database, one deploy pipeline, and you turn on the rails you want. On the cost side, VBWD is source-available under BSL 1.1: commercial use is free while annual VBWD-attributable sales stay under the value of 6.7 BTC per year, and above that you need a commercial license. It is source-available, not public-domain, and it is never CC0 — the source being open does not mean the licensing obligation disappears. The pricing page spells out the threshold and what crossing it means.
The payout rail is powerful and it is also the one that will get you in trouble if you treat it as pure software. Running partner payouts means you inherit your payment processor's onboarding and KYC requirements for every connected account, and you step into money-transmission and compliance territory. That is a legal and regulatory posture, not a config flag. VBWD gives you the mechanism — attribution, an idempotent accrual lifecycle, and a provider port to move money — but it does not give you the license to move that money or the compliance program around it. That layer is yours.
The reversed state is a deliberate defense, not a nicety. It exists so you never pay commission on money that later got refunded or charged back. Without it, a wave of refunds after a payout run turns into commissions you already sent and now have to claw back by hand. The state machine makes that failure mode structural instead of manual, but it cannot recover funds that already left — it only prevents paying on money that has not truly settled.
And to be straight about status: this is VBWD's designed monetization architecture. The licensing rail's signing authority and the Connect-style payout lifecycle are the intended shape of the platform. Parts of it are shipping and parts are still being built. Treat this as the direction and the seams that already exist, not a promise that every state transition is production-hardened today.
An OEM operator does not have to choose between selling their software and sitting in the middle of other people's sales. On a VBWD hub, entitlement licensing and Connect-style partner payouts run as two rails on one instance, sharing a database, an admin surface, and a generic core. Licensing gives you recurring high-margin income backed by Ed25519-signed entitlements. Payouts give you distribution through partners, with an idempotent pending-confirmed-reversed-paid lifecycle that keeps you from paying on refunded money. The software supplies the mechanism; the compliance and money-transmission obligations remain your job.
If you are weighing this for your own instance, start with the architecture overview to see how the agnostic core keeps both rails independent, then check the pricing terms before you turn either one on.