From a clear brief
to verifiable delivery.

Deeper detail: The service page is the shared expectation baseline. It prevents an order from beginning as an open-ended DM and gives both sides the same visible package definition.

Buyer sees: The buyer sees what is included, what is excluded, the starting USD price, delivery target, and the exact inputs needed.

Creator sees: The creator receives a request tied to a known package rather than an unbounded custom promise.

Boundary: Browsing and comparing packages requires no wallet connection.

Deeper detail: Profile data can prefill the order, while order-specific name and contact fields remain editable. Submitted requirements are stored with the order off-chain.

Buyer sees: The buyer sees clear Required and Optional labels, field validation, and the final brief before submission.

Creator sees: The creator sees the private context required to perform the paid package after server authorization.

Boundary: Private brief text and contact details are not published in the blockchain transaction.

Deeper detail: The browser displays the quote but cannot choose a different receiver or quietly mark the order paid. An expired quote must be replaced by a fresh server quote.

Buyer sees: The buyer reviews the exact payment route and value before approving a wallet transaction.

Creator sees: The creator receives an order whose expected payment values remain connected to the package and brief.

Boundary: Only payment assets and networks enabled by the server are presented.

Deeper detail: Authentication is only a message signature. Payment is a separate wallet transaction initiated after the buyer confirms the quote. Rejection, wrong network, pending confirmation, and expired quotes remain explicit states.

Buyer sees: The buyer sees transaction progress and a precise verification failure instead of a client-side paid shortcut.

Creator sees: The creator sees paid status only after the server accepts a real transfer matching the locked quote.

Boundary: One transaction hash can prove only one order.

Deeper detail: Current stored states include pending, awaiting payment, paid, reviewing, accepted, in progress, delivered, completed, expired, and cancelled. QuestPay does not invent unsupported revision or late states.

Buyer sees: The buyer follows the current status and keeps the same public order reference from checkout through completion.

Creator sees: The creator reviews paid work and updates the allowed status through the role-gated Studio workflow.

Boundary: After providing the agreed output through the established delivery channel, the creator records delivered status and timestamp.

Deeper detail: Public proof can include chain, asset, amount, transaction hash, and verification state while private contact, brief, references, and sensitive delivery context remain redacted.

Buyer sees: The buyer keeps a shareable record that can be verified without exposing the private request.

Creator sees: The creator keeps payment and completion history connected to the original scoped order.

Boundary: Public receipts are proof views, not a public copy of the private workspace.