Qlyphs Trade
Reserve a token lot for a named buyer, then exchange it for QTC in one purchase transaction.
How do you sell tokens to one person for QTC, without either of you trusting the other?
QLYP-v1 supports bilateral sales: a seller reserves a token lot for one named buyer, at a fixed QTC price and with an expiry height. Another account cannot buy that reservation. There is no partial fill. A market open to any buyer, open listings, is in development.
Current availability
Purchases require a development deployment with two trusted witnesses and a wallet built with their trust policy. Purchases remain disabled on mainnet. The flow below describes that development protocol, not a verified live mainnet market.
Reserve a lot
The seller and buyer first need a native 2-of-2 trading account, set up once per buyer. The seller then signs an offer proposal committing the asset, amount, buyer, payout address, price, 1% fee and expiry. QLYP reserves the tokens after accepting that offer. Reserved tokens cannot be transferred elsewhere. The trading account holds no purchase principal. Native account/proposal costs and network fees may apply; listing has no Qlyphs fee.
- Lot
- 1,000 GLYF
- Price
- 5 QTC
- Status
- Account ready
- Signer
- you
- Signer
- named before signing
- Threshold
- 2
- Proposal ID
- assigned on inclusion
- 01 / 04
Start with a trading account
The seller and named buyer use a native 2-of-2 trading account. Creating this account is separate from proposing an offer, and can have a native cost. It holds no purchase principal.
- 02 / 04
Propose the exact offer
The seller signs an offer proposal for 1,000 GLYF at 5 QTC. Its immutable terms name the buyer, payout, Qlyphs fee and expiry. The seller and buyer are the two signers of the existing trading account.
- 03 / 04
Identify the proposal
The native proposal receives an ID within that trading account. Together with the network and multisig account, this identifies the reservation. The wallet checks that exact proposal before constructing a purchase.
- 04 / 04
Wait for a finalized reservation
QLYP accepts the valid offer and reserves the tokens. The buyer waits for finality, then verifies and approves the exact proposal inside the purchase batch. Cancellation and expiry can release an unsettled reservation.
Buy the reserved lot
The named buyer waits for the reservation to finalize. Their wallet verifies the witness proof, checks the native proposal and builds the purchase from its committed terms.
- Proven by two witnesses
- Still open, checked on chain
- Terms built by your wallet
- 01 / 05
You press Trade
An offer reserves 1,000 GLYF for you at 5 QTC. Only the named buyer can take it. Your app requests a purchase by reservation key; the wallet independently obtains and verifies its terms.
- 02 / 05
The wallet asks for proof
The wallet requires a proof and signatures from two operators allowed by its compiled development trust policy. Both must bind the same state root and finalized checkpoint. Separate code exists for the witnesses; infrastructure independence must be verified by the operator.
- 03 / 05
It checks the chain itself
A proof describes a checkpoint. The wallet also reads the native proposal through its configured node, checking the exact call, membership, approvals and expiry. State can still change before your transaction is included.
- 04 / 05
It builds the payment
The wallet constructs the purchase from the verified offer, then shows the lot, seller payment, 1% Qlyphs fee and network fee. A purchase approves an existing proposal; it does not create a new ticket with a separate fixed ticket fee.
- 05 / 05
One signature, done
Your signature authorizes one atomic batch: approve the proposal, pay the seller and pay Qlyphs. QLYP delivers tokens only for a matching valid purchase. Track its inclusion, native result, QLYP acceptance and finality; a submitted hash alone is not success.
The purchase is one native atomic batch: approve the exact proposal, pay the seller, and pay the Qlyphs fee. QLYP credits the reserved tokens to the buyer only when that canonical batch succeeds with the required events. The buyer pays 1% on top of the price, rounded up to a QTC base unit, plus network fees; the seller receives the full price.
Native atomicity protects the approval and QTC payments. Token delivery is an overlay rule, so it also depends on valid offer data, correct chain ingestion and correct protocol interpretation. A manual QTC transfer is not a protected token purchase.
A successful purchase cannot be paid twice
The named buyer can give their first native approval only once. A second purchase attempt on the same proposal fails before its payments. Network fees can still be charged.
- Approve the existing proposal
- Pay the seller 5 QTC
- Pay Qlyphs 0.05 QTC
- Approve the existing proposal
- Pay the seller 5 QTC
- Pay Qlyphs 0.05 QTC
- 01 / 05
One buyer, two purchase attempts
Imagine the named buyer submits two purchases for the same finalized reservation with different native nonces. This demonstrates the protocol gate; the wallet must not automatically resend an uncertain transaction.
- 02 / 05
The first one runs
The first transaction approves the existing proposal using its exact committed call. The native pallet records the named buyer’s first approval.
- 03 / 05
It goes through
The same atomic batch pays the seller and the 1% Qlyphs fee. A matching valid purchase makes QLYP settle the reservation to the buyer. The token interpretation is separate from native execution.
- 04 / 05
The second one hits the lock
The duplicate tries to approve that proposal again. Native approval fails because this buyer already approved, or because the proposal was removed. The batch cannot proceed to either payment.
- 05 / 05
Cancelled whole
The failed duplicate pays neither the seller nor the Qlyphs sale fee. Network fees can still be charged. Keep the original transaction hash and follow its result instead of retrying a purchase.
This is a duplicate-purchase example for the same buyer, not a race between different buyers. If a submission has an uncertain result, keep its hash and check its status; do not resend it.
Cancel or expire
A seller can cancel a live proposal. If cancellation is processed before a purchase, approval fails and no purchase price is paid. If the purchase succeeds first, later cleanup cannot return the sold tokens to the seller. Expiry releases a still-live reservation at the first block strictly after its expiry height. Network fees can apply to cancellation and failed attempts.