ZPAYSPECIFICATION / 0.1
A terminal for ZEC.
Product behavior, access mechanics, accounting boundaries, and launch dependencies.
Overview
ZPAY turns a ZEC balance into familiar card and checkout interfaces. Live financial services begin after partner approval.
Extension
Connect a compatible wallet, mint a partner-issued virtual card, reveal or copy card credentials, autofill checkout, and freeze access. Live issuance requires contracts and a BIN sponsor.
Merchant store key
Burn the current fixed amount of $ZPAY once. Fifty percent is destroyed; fifty percent enters treasury for rail costs. The resulting key is wallet-bound and non-transferable.
Pay with ZEC
A merchant embeds the checkout control. A shopper approves in wallet or extension. Settlement targets ZEC while processors and card rails may require conversion.
Holder accounting
Ten percent of processing earnings—spread plus merchant take, not gross merchandise volume—is allocated to holders in ZEC. Pair rewards may also enter the distribution pool.
Webhook model
Store-key holders will receive signed event notifications for authorizations, settlements, declines, disputes, and refunds. Live endpoints begin with partner activation.
Risk
Issuance is partner-dependent. Cards can decline. FX, processor costs, fraud, chargebacks, contract risk, and asset volatility can cause losses. Nothing here is financial advice.