Future direction

A commerce layer built for sellers and buyers.

Long-term direction, not the MVP. This page exists so the project's intent is public from day one. Nothing on this page is shipped yet. Every section is scoped, labelled and revisable.

FutureDirection, not commitment

1. What we want commerce on Bezant to feel like

Most online stores today force the merchant to choose between two compromises: either accept a custodial payment processor that takes a meaningful cut and reserves the right to freeze funds, or self-host a payment stack that is fragile and unsupported. Bezant's commerce layer is an attempt to give merchants a third option.

Sellers run a store backed by their own Bezant App, on their own hardware. Buyers pay in BZT directly. Optional services - escrow, shipping, fiat rails - are explicit add-ons with disclosed fees, never bundled silently into the protocol.

2. BZT direct payments

Network fee	Goes to miners and pools
Platform fee	0The protocol does not take a cut.
Custody	Buyer-controlled until broadcastSeller-controlled once confirmed.
Confirmation finality	Bezant Proof-of-Work confirmations

BZT direct payments are the simplest case: the buyer's wallet pays the seller's receive address. The transaction is published on chain. Neither Bezant the project nor the seller's hosting provider sits between them.

3. Seller stores

A seller store on Bezant looks like a normal storefront: catalog, product pages, cart, checkout. The backend differs: the store talks to a local Bezant App through a scoped API key. The seller's funds never sit on a Bezant-controlled wallet.

Product catalog with pricing in BZT (and optionally in fiat, via a live rate at checkout).
Receive address per order, generated by the seller's Bezant App.
Webhooks on confirmed credit, so the order moves to "paid" only when the chain confirms.

4. Protected escrow payments

Optional. When the buyer or the seller want extra protection, the payment can be routed through an escrow that releases funds only after delivery confirmation. The escrow operator publishes a fee in advance; Bezant App surfaces that fee clearly at checkout.

Default	No escrow - direct BZT payment
Optional	Escrow with delivery confirmationOperator-published fee, shown at checkout.
Dispute resolution	Operator policy, disclosed before payment

5. Shipping integrations

For physical goods: integrations with major carriers and aggregators so the seller can print a label, get a tracking number, and let Bezant App track the package back to the order.

FedEx, UPS, postal carriers, and aggregators
Label printing from inside Bezant App
Tracking visible to both buyer and seller
Optional integration with delivery-confirmation escrow

For digital goods: secure delivery (download link or unlock key) gated on confirmed payment.

6. Optional fiat rails

Some buyers want to pay in fiat; some sellers want to settle in fiat. Bezant App may offer optional bridges to fiat providers like Stripe or Wise. These bridges are managed services with disclosed fees. They are not on the protocol layer.

Stripe rail	Optional managed bridgeBuyer pays in fiat, seller can receive in BZT or fiat. Provider fee disclosed.
Wise rail	Optional managed bridgeBuyer pays in fiat across borders, seller receives in fiat. Provider fee disclosed.
Pure BZT rail	Zero platform feeAlways available, always the default.

7. Economic model

8. Status today

Legal and compliance details (which jurisdictions, which carriers, which providers, KYC obligations on optional fiat rails) will be disclosed in a follow-up document when those services are ready to launch. This page does not make a legal commitment about any of that.