How ZulHub Trades Work: From Listing to Release
The full lifecycle of a marketplace trade, and what protects each side at every step.
A ZulHub trade is not a chat thread with a payment attached. It is a state machine with frozen terms, an append-only evidence log and independent payment verification. This guide walks through every stage and explains what each one guarantees.
The terms snapshot
The moment a trade is created, ZulHub captures a complete snapshot of what was agreed: the listing title and description, the unit price, the quantity, the total amount, the platform fee, the seller payout, the delivery terms, the listing attributes and the deadline rules in force. That snapshot is hashed with SHA-256 and stored alongside the trade.
This matters more than it sounds. If a seller edits the listing afterwards — changes the price, rewrites the description, alters the stated account power — none of it touches your trade. The trade references its own snapshot, not the live listing. You can see the hash on the trade page, and it will not change.
The state machine
Every trade moves through a fixed set of states, and the transitions between them are enforced on the server:
- Draft — created, terms frozen, waiting for both sides to accept
- Awaiting payment — terms accepted, payment configuration locked
- Funded — payment independently verified on-chain
- Seller working — the seller has been notified and can begin
- Delivery in progress — the seller has started work
- Buyer review — delivery submitted, the confirmation window is open
- Completed — released to the seller
- Disputed / In arbitration — a dispute is open and normal release is paused
- Refunded, Cancelled, Expired — terminal outcomes
A transition that is not in the table cannot happen. A completed trade cannot go back to funded. A cancelled trade cannot become funded. A disputed trade cannot auto-release. These are not UI restrictions that a modified client could bypass; the server rejects the transition regardless of what is asked of it.
How funding is confirmed
This is the part most marketplaces get wrong. On ZulHub, no user action marks a trade as paid. There is no "I have sent the payment" button that changes the trade state.
Instead the platform queries the blockchain itself and checks, independently:
- the transaction exists and did not revert
- it went to this specific trade destination
- it was the configured token, on the configured network
- the amount matches what the trade expects
- it has reached the confirmation threshold for that network
Only when all of those hold does the trade become funded. A screenshot proves nothing here, and neither does a transaction hash pasted into chat — the platform looks the transaction up for itself.
Wrong network, wrong token, wrong amount
Three mistakes account for most lost crypto payments, and each is handled explicitly.
Wrong network. Sending a token on a different chain than the trade expects means the funds never arrive at the destination the platform is watching. ZulHub shows the network prominently before you send anything, and the payment instructions for a trade never change once shown.
Wrong token. Only the exact configured token contract counts as payment. If a different token arrives at the trade destination, the platform records it as an anomaly and tells you plainly that it did not fund the trade, rather than silently showing nothing.
Wrong amount. An underpayment does not fund the trade. A small shortfall inside a configured tolerance is accepted, which covers exchange withdrawal fees shaving a few units off a transfer. Anything more is reported as underpaid. An overpayment does fund the trade, but the surplus is surfaced so it can be returned deliberately instead of quietly absorbed.
Address locking
Before funding, the buyer sets a refund address and the seller sets a payout address. Both are validated against the network's real checksum algorithm, so a mistyped address is rejected rather than accepted and later unrecoverable.
Once the trade is funded, both addresses become immutable. Changing one afterwards requires an explicit change request that is reviewed, logged as a security event and flagged for attention — because a payout address changing immediately after funding is exactly what a hijacked account looks like.
Auto-release
When the seller marks delivery complete, the trade enters buyer review and a confirmation deadline is set. If the buyer confirms, the trade completes immediately. If the buyer does nothing until the deadline passes, the trade may auto-release to the seller.
Auto-release is blocked entirely while a dispute is open. Opening a dispute stops the clock. That is enforced by the state machine guard, not by a UI check.
Disputes and arbitration
Either party can open a dispute with a reason and a description. Both sides can then submit evidence: text, transaction hashes, and references to messages already in the trade log.
The trade conversation is append-only. Messages cannot be edited or deleted by anyone, including staff. Each message carries a sequence number, a snapshot of who sent it, a timestamp and a SHA-256 hash of its content. If a message has to be withheld for legal reasons, it is marked redacted — its slot, ordering and hash remain, so the evidentiary record survives.
An arbitrator reviews the evidence and records a decision with a written reason and a list of the evidence considered. Only then can the trade be settled. A buyer or seller can never trigger a settlement themselves, and an arbitrator cannot settle without the decision record existing first.
What the fee is, and when it applies
The platform fee is a percentage of the trade amount, charged by default to the seller. The buyer funds the trade amount; the seller receives that amount minus the fee. The exact figures are computed when the trade is created and written into the terms snapshot, so they cannot drift afterwards.
The trade amount, the platform fee, the seller payout and any refund are tracked as four separate integer values throughout. They are never merged into a single number, and no floating-point arithmetic is used anywhere in settlement.
What is not live yet
ZulHub is honest about the state of its own infrastructure. On-chain escrow settlement — the 2-of-3 mechanism that would let a release move funds automatically — requires a deployed, audited contract on each supported network. That does not exist yet.
Until it does, trades run in a manually arbitrated mode: funding verification is fully real and automatic, and settlement is performed by an authorised operator against the recorded decision. The platform reports this state plainly on every trade rather than showing a settlement that did not happen. You can see the exact readiness of each network, including what is blocking it, on the networks page.