Turn the marketplace around. Instead of sellers posting supply and buyers hunting through it, let buyers post what they need and let vendors bid for the work. The hard part of a reverse marketplace was never the bidding — it was trust: the buyer will not pay until the job is done, the vendor will not start until they know the money is real. On VBWD you resolve that standoff by holding funds as token_payment escrow, released only when the booked job is delivered, with a bot_telegram broker running the matches and the nudges. Demand posts first; supply bids; credits become the escrow that makes both sides safe.

Diagram of a reverse marketplace: buyers post requests via marketplace, vendors bid, token_payment holds credits in escrow, booking schedules delivery, bot_telegram brokers matches, discount runs promotions.

Inverting the marketplace

The marketplace plugin gives you vendors, listings, and the multi-party structure a reverse marketplace needs — you simply use it the other way around. A buyer's request-for-work is the object that goes live; vendors respond against it. The commercial and identity plumbing is the same as a forward marketplace, so you are not building a bespoke system; you are pointing an existing one in the opposite direction. That reuse is the reason this is buildable at all: the "demand-first" model looks exotic, but underneath it is the same vendor-and-listing machinery, the same shared invoice, the same event core.

What actually distinguishes a reverse marketplace is the sequence of trust. Someone has to commit first, and it should not be the vulnerable party. So the buyer commits money — but into escrow, not into the vendor's pocket.

Credits as escrow — the non-trivial move

This is where token_payment earns its place. Normally you would think of it as a credit or metered-billing economy: customers hold a balance and spend it. Here it does something more interesting. When a buyer accepts a bid, their credits are held — committed to that job but not yet the vendor's. The vendor can see the funds are real and reserved, which is exactly the assurance they need to start. The buyer's money is protected until delivery, which is exactly the assurance they need to pay up front. The token becomes an escrow instrument, and because it is native to the platform's invoice model, the hold, the release, and the eventual payout are all entries the core understands rather than a side-channel you reconcile by hand.

Release is gated on delivery, and delivery is a scheduled thing — which is where booking comes in. The accepted job is a booked commitment: an appointment, a slot, a delivery window. When the booked job is completed, that completion is the event that authorizes the escrow to release from held credits to the vendor. The point of truth stays the invoice line item, and the event-based contract engine balances what is held against what is owed. Assets versus obligations, settled by an event, not by a support ticket.

The broker lives in Telegram

A reverse marketplace is a coordination problem — new requests, new bids, acceptances, reminders, delivery confirmations — and most of that coordination does not want to live on a web page nobody keeps open. bot_telegram is the broker. It pings vendors when a matching request appears, tells a buyer they have new bids, nudges both parties as a booked delivery approaches, and confirms when a job is marked done. Because the core is event-driven with native signed webhooks, every one of those messages is downstream of a real state change on the invoice or booking — not a cron job guessing at state. The bot is a thin, reliable narrator of a system that already knows the truth.

Add discount to seed the early market: waive fees for the first jobs, run a promo to pull demand onto the platform, or reward vendors who deliver on time. Like every VBWD plugin, it declares its line item against the same invoice and can be toggled on or off live, without a restart.

Why this is more than a clever repurposing

Anyone can build a form where buyers post requests. The reason reverse marketplaces are rare is that escrow, scheduled release, and multi-party payout are genuinely hard to build correctly and safely. VBWD gives you all three as composition: a credit economy that doubles as escrow, a booking system that defines "delivered," a payout path, and an event engine that ties release to completion. You are assembling a trust mechanism out of parts that already reconcile against one invoice, on one self-hosted backend that also serves web and native clients. That is the surprise — the exotic model is the easy build, because the load-bearing parts were already there.

The honest boundary

Escrow mechanics are not the same as dispute resolution. VBWD holds the credits, gates release on a delivery event, and gives you the audit trail — but it cannot decide, when a buyer and vendor disagree about whether the work was actually delivered, who is right. That judgment is your product: the arbitration policy, the evidence you require, the refund rules, the trust and safety model for bad actors on both sides. You also carry the regulatory weight of holding value in escrow and moving it between parties, and the operational job of keeping a two-sided market liquid enough that requests get bids. VBWD removes the engineering of safe money-holding. It does not remove the human judgment of adjudicating a dispute, or the market-making of getting both sides to show up.

The public SDK is at github.com/VBWD-platform/vbwd-sdk-public, the plugin docs are at vbwd.cc/docs, and the team is at vbwd.cc/contact. If you have wanted to flip the marketplace and let demand lead, the escrow was always the blocker — and the escrow is already built.

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.