Frequently asked questions

No. PayTP defines no coin and no blockchain of its own. It carries payments over rails that already exist — stablecoins, on-chain crypto, Lightning, instant bank rails. Value-Slices are accounting entries, not a currency, and actual funds move over whatever rail the two sides accept. There is nothing to buy to use PayTP.

No; it is a compatible superset. PayTP's one-shot payment is a real x402 request with a signed paytp extension, so a merchant keeps its existing x402 setup. On top of that, PayTP adds three things the x402 core leaves to the surrounding market: a fixed on-wire meed, payment channels for recurring use, and a stricter exchange (a signed quote binding the resource, a single-use nonce, and the fee schedule, with delivery gated on that nonce being recorded once). Plain x402 and PayTP offers can coexist; a payment is a PayTP payment only when PayTP-aware software selects one.

It is a protocol-defined meed taken from the merchant's side; the buyer pays the listed price and nothing more. The meed is exactly 1% (100 basis points), divided Interaction Layer 0.50%, Wallet 0.30%, Operating System 0.10%, Development Fund 0.10%. (Separately, a merchant may add opt-in in-protocol services — escrow, dispute resolution — that cost up to a further 0.5% and never touch the 1% base.) It pays the payer-side software that makes a payment possible — software that otherwise has no customer to bill. A merchant keeps 99%, compared with 97–98% plus fixed fees on card rails.

The meed is fixed by the protocol at a flat 1% and is identical on every payment; no single participant can change it. A planned PayTP Foundation would maintain the schedule and an operating-system registry, but the rules remove its incentive to misuse that: an absent or denied operating system's share goes to an independent fund the Foundation does not control, so gatekeeping the registry earns it nothing. Denials can be appealed externally, changing a share is hard and rare — it takes broad ecosystem consensus under the charter, with the 100 bp base and 150 bp cap binding every version — and any wire-compatible implementation can fork the governance. The one-shot split is enforced by construction, not trust; the governance properties are designed to be hard to abuse rather than cryptographically guaranteed.

The total is fixed and the key destinations are pinned, so no one can redirect the meed to themselves. Every payment carries exactly 100 basis points from the merchant's side — the buyer pays the listed price regardless — and the shares a participant can't verify in-line, the operating-system and Development-Fund shares, are pinned by the registry and the schema: a false claim can only route a share to its fallback, never to whoever made the claim. The interaction-layer and wallet shares go to whoever actually performs those roles, so supplying your own earns them for the work the meed pays for — not at anyone else's expense.

PayTP bounds loss; it is not insurance. One-shot buyers settle before delivery. For a two-part payment, the meed is finalised first, so an interruption strands at most the 1% meed, which the payer can reclaim — loss returns to near zero (the reclaim is in the baseline asset), at the cost of a short delay. “No chargeback” is a benefit to the merchant (no card-style fraud liability), not buyer protection. Paying a large amount to an unknown counterparty is the weakest case; the spec routes strangers to Tier 0's settle-before-deliver flow, with an off-protocol arrangement — or an opt-in dispute-resolution service — for anything more. Buyer-protection mechanisms are noted as future work.

Both. The same protocol settles a payment from a few cents to a large amount; the one-shot demonstration runs both. Small payments are what channels and the low fee floor make practical; large payments benefit from the fixed 1% compared with 2–3% plus fixed fees, with no card-style chargeback liability for the merchant.

Because it defines a payment they earn from. Earlier open payment standards had no revenue for the software that would carry them. PayTP assigns a fixed share to that software, earned by making payments possible and without negotiating with each merchant. Agent frameworks are a clear case, and demand for machine payments is growing as software agents pay for services by the call.

No. Support is advertised in standard HTTP headers, and payment objects travel in the existing TLS connection — no new ports, and no changes to routers or middleboxes. The profile is HTTP-first (a QUIC transport embedding is anticipated as future work — Chapter 13 §13.2). A site that does not support PayTP falls back to its normal checkout.

No. The protocol is specified (a review-draft whitepaper and a formal interoperability specification), and a reference implementation exists and passes its conformance vectors. Nothing is deployed, in production, or handling real money. The material is published to establish prior art and to invite review before any launch.