"Loyalty points are a per-store gimmick." They don't have to be. The interesting version of loyalty is a single credit that behaves like money across a whole network of independent merchants — earn it buying coffee, spend it on a haircut, top up with a card if you run short — and on VBWD that network is not a fantasy integration project. It is token_payment used as a closed-loop currency, multi-tenant giving each merchant its own storefront, and shop, marketplace, and discount letting them actually sell and promote. The surprising part is that the hardest thing about a shared currency — one balance that clears cleanly across many businesses — is the part you switch on rather than build.

Most loyalty programs are per-store because the plumbing to make a credit portable is genuinely hard: you need one ledger, one settlement model, and clean accounting when a customer earns at merchant A and redeems at merchant B. VBWD already has that ledger in the form of the invoice line item, and it already isolates merchants as tenants. Put those two facts together and a network currency stops being a moonshot.

The token is money, not points

The token_payment plugin is a token/credit economy with metered billing. In most VBWD businesses it powers credits and usage — a customer buys a balance and spends it down. Use it at the level of a whole network instead of a single store, and that same balance becomes a private, closed-loop currency. A customer holds one wallet. They earn credits as a reward, buy credits with real money through the payment core, and redeem credits at checkout anywhere in the network. Because every spend is an invoice line item against the one shared interface the entire platform uses, a redemption is a real, reconciled transaction — not a coupon counter drifting out of sync with the till.

That is the whole trick, and it is worth being precise about why it matters. A gift card is closed-loop but single-merchant. Bank money is open-loop but heavily regulated. A network credit sits between: it moves like money inside your fence and nowhere outside it. VBWD gives you the ledger and the settlement mechanics to run that fence cleanly.

Multi-tenant makes each merchant its own store

A network is only interesting if the members are genuinely independent. VBWD's core is multi-tenant, so each merchant gets its own storefront, its own catalogue, its own orders and stock, its own branding — the coffee shop is not looking at the barber's inventory. The shop plugin gives every tenant products, variants, orders, stock, and shipping; the marketplace plugin lets the network present those tenants as listings and vendors under one roof when you want a directory rather than a set of islands. You get autonomy at the merchant level and coherence at the network level from the same deployment.

This is the combination people don't expect on one stack: fully separate merchants, one shared currency between them. Normally you'd bolt a loyalty vendor onto a dozen unrelated point-of-sale systems and pray the reconciliation holds. Here the merchants and the currency live in the same core, so the credit a customer earns at one tenant is, by construction, spendable and accountable at another.

The cross-merchant clearing problem, solved by the ledger

Ask anyone who has run a coalition loyalty program what breaks, and they'll say settlement. When a customer earns at merchant A and spends at merchant B, someone owes someone money, and that inter-merchant balance has to be tracked without drama. VBWD's design point of truth is the invoice line item, and its core is an event-based contract engine that balances assets against obligations. A credit earned is an obligation on the network; a credit redeemed is that obligation discharged at whichever tenant accepted it. Because it is all one ledger of line items, the network operator can see, at any moment, who is owed what — and, when you want real payouts to participating merchants, the withdraw capability moves settled balances out to them.

The event-driven core with native signed webhooks means every earn and every burn can trigger downstream logic — a fraud check, a tier upgrade, a notification — without polling and without a fragile cron. You are extending behavior through events the core already emits, not patching a monolith.

Discounts and promotions ride on top

A currency is a foundation; a program needs levers. The discount plugin gives you coupons and discounts, so the network can run "earn double this weekend," "20% off when you pay in credits," or merchant-specific promos to pull traffic toward a struggling tenant. Because discounts and token spends are both expressed as line items on the same invoice, a promotion that mixes cash, credit, and a coupon reconciles correctly — the discount carries its own accounting rather than silently distorting the token balance. Add the referral capability and members grow the network for you: refer a friend, both get credits, and the currency's circulation widens on its own.

What the substrate does not do for you

Here is the honest boundary, and it is a real one. VBWD gives you a clean, reconciled, portable credit and the tenants to spend it across. It does not give you a business model for that credit. You decide the earn rate, the burn value, and the float — and a closed-loop currency is a financial instrument, so breakage, liability for outstanding balances, and the regulatory treatment of stored value in your jurisdiction are your responsibility, not the platform's. VBWD keeps the ledger honest; it does not sign off on your economics or your compliance. Bring an accountant and, depending on where you operate, a lawyer.

You also still run the network. Recruiting merchants, setting the rules everyone agrees to, handling disputes, and operating the self-hosted deployment are your job. VBWD is a substrate — it removes the undifferentiated engineering, not the entrepreneurship.

Why this is buildable now, not someday

The reason this constellation is realistic is that none of its pieces are bespoke. token_payment already runs credit economies. multi-tenant already isolates merchants. shop and marketplace already sell. discount and referral already promote and grow. The platform has already carried verticals as different as a tarot app, a dice-market game, a pharmacy shop, and dataset publishing, which is the evidence that its seams are real rather than a slide. Adding a payment gateway to top up credits with a new local rail is roughly 100× less code than on a classic platform, because the payment core is provider-agnostic — card, PayPal, a regional processor, or non-custodial crypto that settles to your own wallet all plug into the same interface.

Clone the public SDK at github.com/VBWD-platform/vbwd-sdk-public, read the token and multi-tenant guides at vbwd.cc/docs, and if you're weighing a coalition program, talk it through with us at vbwd.cc/contact.

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.