暗号資産ウォレット QRコード作成
100%プライベート、ローカル処理 — データがブラウザの外に出ることはありません。これらのQRコードは恒久的で、期限切れになることはありません。
暗号資産ウォレットの設定
デザイン
中央にロゴを追加
画像はこのページ内で読み込まれ、data: URLとしてコードに埋め込まれます。アップロードはされず、ダウンロードするファイルの中に留まります。
その他のデザイン設定
コードの暗いほうの半分です。背景より明度を十分低く保ってください。
モジュール同士の隙間だけでなく、クワイエットゾーンも塗ります。背景を透過にするとファイルから省かれるので、この色では何も描画されません。
モジュールと背景のコントラストは11.5:1です。
PNGとWebPはアルファチャンネルを保持し、SVGは背景の矩形をそのまま省きます。コードを置いた面が、コントラストの明るいほうの半分になります。
グラデーションは暗いモジュールだけを塗ります。明るいほうの端がスキャナーの実際に得るコントラストを決めるので、両端とも暗いままにする必要があります。
2色目で、グラデーションを選んでいる間だけ使われます。1色目と並べてコントラストが測定されます。
左から右への向きを起点とした時計回りの角度です。放射グラデーションは中心から外へ広がるため、角度が効くのは線形のときだけです。
丸い形はセルを覆う面積が小さくなります。デコーダーが標本を取る中心は覆われたままですが、密度の高いコードを小さく印刷する場合は四角のほうが安定して読み取れます。
3つの位置検出パターンの外枠です。
各位置検出パターンの中にある目にあたる部分です。
コードの周囲の余白で、モジュール単位で測ります。規格上の最小値は4です。
復元レベルが高いほど多くの損傷に耐えられますが容量を消費するため、同じ内容でもシンボルが密になります。
中央にロゴがあり、レベルをHに固定しています。幅の上限はシンボルに応じて変わり、最小のコードで14%、密なコードで30%です。
ライブプレビューと書き出し
Paste the Bitcoin receiving address from your wallet's receive screen.
書き出し
ラスター、画面向け
フォームを入力するとダウンロードが有効になります。
書き出しサイズとエンコードされたテキスト
- ペイロード
- まだ何もエンコードされていません
- シンボル
- まだ生成されていません
- 復元レベル
- H
入力待ち
5つのネットワークに対応した受け取り用のコードを、任意の金額とメモを添えて作成します。アドレスは入力されたとおりに使われ、どこにも送信されません。
スキャンしたときの動作
ウォレットアプリがURIを読み取って受取先を自動入力し、金額とメモは編集可能な支払いリクエストとして表示され、支払う側が自分のウォレットで承認するまで署名も送金も行われません。
各ネットワークのURIの形
Bitcoin、Litecoin、DogecoinはいずれもBIP-21の形を使います。スキーム名、コロン、アドレス、そして任意のクエリパラメータです。金額はコイン単位の小数で書かれ、amount=0.005 はビットコインの1000分の5を意味します。ラベルとメッセージはパーセントエンコードされます。
EthereumはEIP-681を使い、valueパラメータの単位はetherではなくweiです。仕様は指数表記を推奨しているので、0.25 ETHは value=2.5e17 と書きます。EIP-681にはラベルとメッセージのパラメータがなく、Ethereumを選ぶとその2つの欄が消えるのはそのためです。
Solana Payは独自の送金リクエストを定義しています。solana: に続けてbase58の受取先の鍵、金額はSOL単位、ラベルとメッセージは任意です。仕様は金額の小数を9桁までに制限していて、これはSOLの精度にあたり、それを超える桁を運ぶURIをウォレットが拒否することを求めています。
アドレスは大文字小文字を含め、入力されたとおりにエンコードされます。Bech32のビットコインアドレスは大文字小文字を区別しないので、QRの英数字モードに収めてシンボルを小さくするために大文字化することもできますが、旧来のbase58のアドレスは大文字小文字を区別するため、大文字化すればそれを壊します。その最適化を場合によってだけ適用するのは、誰も試さなかった1つのケースで壊れたコードを生む種類の条件分岐なので、まったく適用していません。
- bitcoin:bc1q…?amount=0.005&label=Riverside%20Bookshop
- ethereum:0x…?value=2.5e17
- solana:7xKX…?amount=1.5&label=Riverside%20Bookshop
金額は依頼であって、約束ではありません
ここにあるどのスキームでも、金額は送金する側のウォレットへの提案として扱われます。多くのウォレットは欄を初期値で埋め、署名の前に支払う側が編集できるようにします。パラメータを完全に無視して、金額が空のまま開くウォレットもあります。どれにも金額を守る義務はなく、QRコードの中に、それを守らせられる仕組みは存在しません。
BIP-21には、ウォレットが理解できなければ拒否しなければならないパラメータのための req- という接頭辞が定義されていますが、それが決めるのはウォレットがURIを解釈するかどうかであって、人がその金額を支払うかどうかではありません。印刷された金額は入力の手間を省く便宜だと考え、実際に届いた額を、依頼した額と突き合わせてください。
金額は請求の参照番号も運びません。メッセージの欄は支払う側に見せる表示用の文字で、トランザクションには書き込まれず、資金と一緒にあなたのところへ届くこともありません。入金を注文に対応づけるには注文ごとに新しいアドレスを使うしかなく、印刷した1つのコードに、それはできません。
コードが画面を離れる前に、アドレスを検証してください
このサイトはアドレスを検証できません。確認しているのは、入力された文字列が、選んだネットワークの文字種とおおよその長さに合っているかだけで、明らかな貼り付けミスは捕まえられますが、それ以上のことはできません。そのアドレスがあなたのものか、そのウォレットがまだ存在するか、あなたのウォレットとこの欄の間で文字列がすり替えられていないかは、判断できません。問い合わせる先がないからです。このページには、そもそもネットワークへのリクエストが1つもありません。
アドレスのすり替えは、現実にありふれた脅威です。クリップボードを乗っ取るマルウェアは、コピーされたウォレットアドレスを見張り、攻撃者のものに置き換えます。すり替えられたアドレスは形式として正しいので、どの形式チェックも通過し、できあがるコードは完全に有効です。ただし、別の誰かにとって有効なのです。これらのネットワークの送金は取り消せません。チャージバックもなく、どのサポート窓口も資金を取り戻すことはできません。
防ぎ方は短く、そして譲れません。コードが描画されたら、支払いに使うのと同じスマートフォンでそれを読み取り、ウォレットが表示するアドレスを、自分のウォレットの受け取り画面と1文字ずつ突き合わせてください。最初と最後の6文字ですり替えのほとんどは捕まえられ、全部を照合すれば残りも捕まえられます。そのうえで、コードを大量に印刷する前に、自分あてに少額のテスト送金をしてください。保存したファイルから刷り直したときも、これをもう一度行ってください。
よくある質問
コードには秘密鍵やシードフレーズが入りますか?
入りませんし、どちらもどんなWebページにも決して入力しないでください。このツールが受け取るのは受け取り用のアドレスで、これは共有するためにある公開情報です。秘密鍵やリカバリーフレーズは、ウォレットそのものの支配権を渡してしまうもので、まっとうな生成ツール、取引所、サポート担当者に、それを尋ねる理由はありません。
印刷したコードが傷んだり汚れたりすると、間違ったアドレスに送金されることはありますか?
ありません。QRコードはリード・ソロモンの誤り訂正を備えていて、デコーダーは元の文字列をそのまま復元するか、そうでなければ完全に失敗します。もっともらしいけれど違うアドレスを返すことはありません。復元能力を超える損傷は読み取りの失敗になり、それは安全な結果です。本当の危険は、そもそも間違ったアドレスが正しくエンコードされていることです。
Ethereumを選ぶとラベルとメッセージの欄が消えるのはなぜですか?
EIP-681がそれらを定義していないからです。仕様が記述していないパラメータを足すと、ウォレットはそれを無視するか、URIを不正なものとして扱います。不正なURIは、ラベルがないことよりも悪い結果です。BIP-21とSolana Payはどちらもラベルとメッセージを定義しているので、その4つのネットワークでは欄が表示されます。
ネイティブのコインではなく、トークンにも使えますか?
このページからはできません。EIP-681でERC-20を送るにはURIの中にコントラクトアドレスと関数の呼び出しが必要で、Solana Payにはspl-tokenのミントのパラメータが必要です。どちらも、資金を失う形で微妙に間違えやすいものです。トークンの小数桁とコントラクトを把握している、ご自身のウォレットの請求機能を使ってください。
静的QRコードの仕組み
このサイトのコードはすべて静的です。ペイロードは白黒のモジュールそのものに書き込まれています。読み取り時に何かを参照することはなく、当サイトのサーバーが関与することもなく、印刷されたコードをサブスクリプションが支えているわけでもありません。同じ性質が限界でもあります。一度印刷すると、中身は変更できません。
印刷したコードが読めるかどうかを決めるのは3つです。ペイロードが何バイトになったか、どの復元レベルが損傷を吸収するか、そして紙の上で1モジュールがどれだけの幅になるか。以下のガイドは、そのそれぞれを数字とともに扱います。