Zcash-Zahlungslinks und QR-Codes: ZIP 321 erklärt

Ein Zcash-Zahlungslink ist ein Text, der mit zcash: beginnt und eine Adresse sowie optional Betrag, Memo, Label und Nachricht enthält. Wallets machen daraus eine fertig auszufüllende Zahlung, und ein QR-Code ist derselbe Text als Bild. ZIP 321 legt das Format fest und hat den Status Active. Diese Anleitung erklärt jeden Teil und was du vor dem Zahlen oder Annehmen prüfst.

Was ein Zahlungslink enthält

ZIP 321 nennt als Ziel, dass Wallets aus Weblinks oder QR-Codes mit möglichst wenig manueller Eingabe Transaktionen bauen können. Die URI beginnt mit zcash:. Die Adresse kann direkt nach dem Doppelpunkt stehen oder als Parameter address erscheinen; laut ZIP 321 sind beide Formen gleichwertig. Parameter werden mit & verbunden.

Beispielsweise behandelt ZIP 321 50.00, 50 und 050 als denselben Betrag und lehnt 50,000.00, 50. und .5 ab. Prozent-Kodierung ist nur in den Werten von Label, Message und anderen Parametern erlaubt, nie in Adressen, Beträgen oder Parameternamen. Eine URI, die der Grammatik nicht entspricht, darf nicht akzeptiert werden.

Memos in einem Link

Ein Zahlungslink kann das Memo-Feld vorausfüllen, die verschlüsselte 512-Byte-Nachricht einer geschützten Zahlung. Weil das Memo base64url-kodiert ist, kannst du keinen Klartext in die URI schreiben; das übernimmt eine Wallet oder ein Rechnungswerkzeug. ZIP 321 ergänzt eine Sicherheitsregel: Ein Parser muss die gesamte URI als ungültig behandeln, wenn ein Memo an einer transparenten Adresse hängt, weil eine transparente Ausgabe keinen Platz dafür hat. Unser Memo-Feld-Ratgeber erklärt, wer ein Memo lesen kann und was hineinpasst.

Mehrere Zahlungen in einem Link

Parameter mit demselben Index gehören zu einer Zahlung, zum Beispiel address.1, amount.1 und memo.1. Laut ZIP 321 sollen Implementierungen eine einzige Transaktion bauen, die alle aufgeführten Adressen bezahlt, und es nennt eine praktische Grenze: Bei reinen Sapling-Zahlungen könnten mehr als 2.109 verschiedene Zahlungen scheitern. Die meisten Leser brauchen das nie; es betrifft Werkzeuge, die viele Empfänger auf einmal bezahlen.

Das Präfix req-

Ein Parameter, dessen Name mit req- beginnt, ist zwingend. Erkennt eine Wallet einen solchen nicht, muss sie laut ZIP 321 die gesamte URI ablehnen. Unbekannte Parameter ohne das Präfix sollen ignoriert werden. So kann ein Link eine Funktion verlangen, etwa den Parameter für eigene Assets, ohne dass eine ältere Wallet stillschweigend etwas anderes bezahlt.

Welche Adresse in den Link gehört

Nimm den Adresstyp, den deine Wallet zum Empfangen anzeigt. Unser Adresstypen-Ratgeber erklärt transparente, Sapling- und Unified Addresses, und geschützte vs. transparente Transaktionen zeigt, was jede auf der öffentlichen Blockchain hinterlässt. Ein Link auf eine transparente Adresse kann kein Memo tragen und macht die Zahlung öffentlich.

Unterstützen Wallets das?

Wir haben keine Wallets getestet. Der Abschnitt zur Abwärtskompatibilität in ZIP 321 sagt selbst, dass mehrere bestehende Wallets ein ähnliches zcash:-Schema nutzen, typischerweise aber ohne die req--Regel, ohne mehrere Zahlungen, oft ohne die Form address= und teils ohne Memo-Unterstützung oder base64url-Dekodierung. Öffne den Link vor dem Druck eines QR-Codes für Kunden in den Wallets, die deine Kunden nutzen, und prüfe, ob Betrag, Memo und Adresse wie gedacht ankommen. Unser Wallet-Vergleich listet Wallets und ihre Unterstützung für geschützte Adressen.

Bevor du einen Link bezahlst oder einen QR-Code scannst

Ein Link füllt eine Zahlung nur vor; du bestätigst sie selbst. Prüfe Adresse, Betrag und Netzwerk auf dem Bestätigungsbildschirm der Wallet. Kennst du Person oder Firma nicht, vergleiche die Adresse mit einer, die sie dir über einen zweiten Kanal genannt hat. Taucht eine Zahlung danach nicht auf, siehe eine geschützte Transaktion oder ein Guthaben prüfen.

ZEC als Händler annehmen

Es gibt zwei grobe Wege; wir beschreiben, was die Quellen sagen, nicht unsere eigene Erfahrung damit.

1. Eine Adresse oder einen ZIP-321-QR-Code einer Wallet zeigen, die du kontrollierst. Dafür braucht es keinen Server. Du siehst eingehende Zahlungen in deiner Wallet, und bei geschützten Zahlungen können nur die Schlüssel der Wallet sie zeigen. Ein Viewing Key lässt Buchhaltung oder ein Werkzeug eingehende Zahlungen sehen, ohne ausgeben zu können.
2. Einen Zahlungsserver nutzen. Das BTCPay-Server-Plugin für Zcash sagt in seiner README, es „extends BTCPayServer to enable users to receive payments via Zcash". Die README warnt: „This plugin shares a single Zcash wallet across all the stores in the BTCPayServer instance" und rät, es nur zu nutzen, wenn du die Instanz nicht teilst. Sie nennt Daemon-RPC, Wallet-RPC und Wallet-Verzeichnis als zwingende Einstellungen, und die Installationsseite sagt, man solle eine Wallet mit Viewing-Key-Export nutzen, mit YWallet und Zingo als Beispielen. Auf der Repository-Seite waren beim Lesen keine veröffentlichten Releases zu sehen; beurteile die Pflege also selbst. Zur Node-Seite beschreibt unsere Zebra-Node-Anleitung, was der Betrieb eines Nodes bedeutet.

Steuer-, Buchhaltungs- und Rechtsfragen zur Annahme von Krypto hängen von deinem Land ab und liegen außerhalb dieser Anleitung.

Was wir nicht überprüfen konnten

• Welche Wallets ZIP 321 vollständig umsetzen; wir haben keine getestet.
• Wie gut das BTCPay-Plugin heute funktioniert und wie viele Bestätigungen ein Shop abwarten sollte; das entscheidet jeder Händler selbst.
• Ob die Unterstützung für Zahlungslinks je nach Wallet-Version unterschiedlich ist.

Quellen

• ZIP 321: Payment Request URIs, Status Active, Autoren Kris Nuttycombe und Daira-Emma Hopwood.
• BTCPay-Server-Plugin für Zcash und seine Installationsseite.
• ZecHub: eine Community-Anleitung zum BTCPay-Plugin, hier als weiterführende Lektüre genannt, nicht als Quelle der obigen Aussagen.