メインコンテンツまでスキップ

WalletConnect と dApp

BitTool Signer が dApp に接続することはありません。ネットワーク機能がないからです。WalletConnect のセッションはウォレット側が保持します。dApp が BitTool Signer のアカウントに署名を求めると、ウォレットはそのリクエストを署名用 QR コードに変換し、レスポンスを待って dApp に応答します。BitTool Wallet はこの方式で動作しています。

ウォレットアプリWalletConnect セッションを保持
BitTool Signerオフライン
  1. 1dApp からセッションリクエストを受け取ります(例:eip155:1 での personal_sign)。
  2. 2リクエストをユーザーに表示し、必要に応じて不足分(nonce、ガス、手数料)を補って、署名するバイト列を確定します。
  3. ur:eth-sign-request · ur:sol-sign-request · ur:tron-sign-request ▶
  4. 3デコードして確認画面を表示し、ユーザーがウォレットパスワードを入力したら署名します。
  5. ◀ ur:eth-signature · ur:sol-signature · ur:tron-signature
  6. 4署名を検証し、メソッドが必要とする場合はブロードキャストして、JSON-RPC の結果を dApp に返します。

WalletConnect のセッションにはタイムアウトがあり、dApp が待ちきれずに諦めることもあります。QR コードはすぐに表示し、ユーザーがキャンセルできるようにしてください。ユーザーがキャンセルした場合は、ユーザー拒否のエラー(EVM チェーンでは 4001)で dApp に応答します。

メソッドの対応表​

名前空間dApp のメソッドBitTool Signer へのリクエストdApp に返す結果
eip155personal_sign [message, address]eth-sign-request、data-type 3、メッセージのバイト列0x 署名、65 バイト、v = 27/28
eip155eth_signTypedData_v4 [address, typedData]data-type 2、型付きデータの JSON0x 署名、65 バイト、v = 27/28
eip155eth_sendTransaction [tx]nonce、ガス、手数料を補い、data-type 4(EIP-1559)または 1(レガシー)ブロードキャスト後のトランザクションハッシュ
eip155eth_signTransaction [tx]上と同じ署名済みの生トランザクション(ブロードキャストしない)
eip155eth_sign非対応:BitTool Signer は生の 32 バイトハッシュには署名しませんリクエストを拒否する
solanasolana_signMessage {message, pubkey}sol-sign-request、sign-type 2、デコードしたメッセージのバイト列Base58 の { signature }
solanasolana_signTransaction {transaction}sign-type 1、トランザクションの メッセージ のバイト列Base58 の { signature }
solanasolana_signAndSendTransaction {transaction}sign-type 1ブロードキャスト後の { signature }
trontron_signMessage {address, message}tron-sign-request、data-type 2、メッセージのバイト列v = 27/28 の 0x 署名
trontron_signTransaction {address, transaction}data-type 1、raw_data_hex のバイト列signature を追加したトランザクションオブジェクト

セッションで提示するチェーン ID(CAIP-2):

チェーンCAIP-2
EVMeip155:1, eip155:56, eip155:42161, eip155:8453, eip155:10, eip155:137, eip155:100, eip155:43114
Solana メインネットsolana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
TRON メインネットtron:0x2b6653dc

提示するのは、ユーザーがペアリングしたアカウントと、BitTool Signer が署名できるネットワークだけにしてください。それ以外のチェーン ID での eth_sendTransaction は、署名デバイスに拒否されます。

つまずきやすいポイント​

  • personal_sign のパラメーター順序。 仕様では [message, address] ですが、[address, message] の順で送ってくる dApp もあります。20 バイトのアドレスを検出して判別してください。バイト列のメッセージは 16 進(0x…)で届きます。sign-data にはデコードしたバイト列を渡し、16 進テキストを渡してはいけません。
  • 型付きデータは文字列で届く。 eth_signTypedData_v4 は通常 JSON を文字列として送ってきます。再シリアライズせずにそのまま UTF-8 バイト列として渡し、整数やアドレスの表記が dApp の記述どおりに保たれるようにしてください。どうしても再シリアライズする場合は、大きな整数を文字列のまま保持してください。
  • Solana:トランザクションではなくメッセージを送る。 solana_signTransaction は、署名スロットが空の、Base64 でシリアライズされたトランザクションを渡してきます。これをデシリアライズし、メッセージのバイト列だけを送ってください。dApp がアドレスルックアップテーブルを使う v0 トランザクションを作成した場合、BitTool Signer は署名できません。
  • Solana のメッセージのエンコード。 solana_signMessage はメッセージを Base58 で送ってきます。まずバイト列にデコードしてください。
  • TRON トランザクションの形。 dApp によってトランザクションの包み方が異なり、params.transaction.transaction、params.transaction、または params そのものの場合があります。raw_data_hex を持つオブジェクトを取り出し、txID = SHA-256(raw_data) を確認したうえで、raw_data_hex のバイト列に署名してください。
  • TRON のメッセージ署名。 署名デバイスはリカバリーバイトを 0/1 で返しますが、TronWeb を使う dApp は 27/28 を想定しています。末尾のバイトに 27 を加えてください。

実例​

各例では、ウォレットが dApp から受け取るリクエスト、BitTool Signer との QR の往復、dApp に返す結果を示します。すべてテストフレーズを使っています。チェーンごとの詳細は EVM、Solana、TRON の各ページにあります。

Sign-In with Ethereum によるログインです。

dApp のリクエスト(chainId eip155:1)
{
"method": "personal_sign",
"params": [
"0x6170702e6578616d706c652e6f72672077616e747320796f7520746f207369676e20696e207769746820796f757220457468657265756d206163636f756e743a0a3078393835384566464432333242343033334534376439303030334434314543333445636145646139340a0a5369676e20696e20746f204578616d706c65204170702e0a0a5552493a2068747470733a2f2f6170702e6578616d706c652e6f72670a56657273696f6e3a20310a436861696e2049443a20310a4e6f6e63653a203866336b326d39710a4973737565642041743a20323032362d31302d31385430393a33303a30302e3030305a",
"0x9858EfFD232B4033E47d90003D41EC34EcaEda94"
]
}

リクエスト(ウォレット → BitTool Signer)

eth-sign-request2 フレーム
UR:ETH-SIGN-REQUEST/1-2/LPADAOCFADFDCYCMDSCMFHHDOXOSADTPDAGDHECKNDDWKIFTGLJLLEBDCEDPFMGWHTAMAOHDWEHSJOJODMIHKSHSJNJOJZIHDMJLJPIOCXKTHSJTJYJKCXKKJLKPCXJYJLCXJKINIOJTCXINJTCXKTINJYISCXKKJLKPJPCXFEJYISIHJPIHKPJNCXHSIAIAJLKPJTJYFTBKDYKSESETECETFEIYFGFYEYEOEYFWEEDYEOEOFEEEEMIEESDYDYDYEOFYEEEHFEFXEOEEFEIAHSFEIEHSESEEBKBKGUINIOJTCXINJTCXJYJLCXFEKSHSJNJOJZIHCXFPJOJODMBKBKGOGMGAFTCXISCPDEGMOY
1 / 2
CBOR フィールド
{
"1 request-id": {
"uuid (tag 37)": "5f1e9b2c7d3a4e6f8a0b1c2d3e4f5a06"
},
"2 sign-data": "6170702e6578616d706c652e6f72672077616e747320796f7520746f207369676e20696e207769746820796f757220457468657265756d206163636f756e743a0a3078393835384566464432333242343033334534376439303030334434314543333445636145646139340a0a5369676e20696e20746f204578616d706c65204170702e0a0a5552493a2068747470733a2f2f6170702e6578616d706c652e6f72670a56657273696f6e3a20310a436861696e2049443a20310a4e6f6e63653a203866336b326d39710a4973737565642041743a20323032362d31302d31385430393a33303a30302e3030305a",
"3 data-type": 3,
"4 chain-id": 1,
"5 derivation-path": {
"crypto-keypath (tag 304)": {
"1 components": [
44,
true,
60,
true,
0,
true,
0,
false,
0,
false
],
"2 source-fingerprint": 1942346250
}
},
"6 address": "9858effd232b4033e47d90003d41ec34ecaeda94",
"7 origin": "BitTool Wallet"
}
QR テキストと生の CBOR を表示
QR テキスト · ur:eth-sign-request
UR:ETH-SIGN-REQUEST/1-2/LPADAOCFADFDCYCMDSCMFHHDOXOSADTPDAGDHECKNDDWKIFTGLJLLEBDCEDPFMGWHTAMAOHDWEHSJOJODMIHKSHSJNJOJZIHDMJLJPIOCXKTHSJTJYJKCXKKJLKPCXJYJLCXJKINIOJTCXINJTCXKTINJYISCXKKJLKPJPCXFEJYISIHJPIHKPJNCXHSIAIAJLKPJTJYFTBKDYKSESETECETFEIYFGFYEYEOEYFWEEDYEOEOFEEEEMIEESDYDYDYEOFYEEEHFEFXEOEEFEIAHSFEIEHSESEEBKBKGUINIOJTCXINJTCXJYJLCXFEKSHSJNJOJZIHCXFPJOJODMBKBKGOGMGAFTCXISCPDEGMOY
UR:ETH-SIGN-REQUEST/2-2/LPAOAOCFADFDCYCMDSCMFHHDOXJYJYJOJKFTDLDLHSJOJODMIHKSHSJNJOJZIHDMJLJPIOBKHFIHJPJKINJLJTFTCXEHBKFXISHSINJTCXGAFYFTCXEHBKGLJLJTIAIHFTCXETIYEOJEEYJNESJSBKGAJKJKKPIHIECXFPJYFTCXEYDYEYENDPEHDYDPEHETGHDYESFTEODYFTDYDYDMDYDYDYHTAXAXAAADAHTAADDYOEADLECSDWYKCSFNYKAEYKAEWKAEWKAOCYJKSKTNBKAMGHMKHDWSZCCNDNFZEOVEKIMHAEFSFPWPEEWPPLTNMWATJTFWINJYGHJLJLJZCXHGHSJZJZIHJYCWTTFYJT
UR CBOR(16 進)
a701d825505f1e9b2c7d3a4e6f8a0b1c2d3e4f5a060258ed6170702e6578616d706c652e6f72672077616e747320796f7520746f207369676e20696e207769746820796f757220457468657265756d206163636f756e743a0a3078393835384566464432333242343033334534376439303030334434314543333445636145646139340a0a5369676e20696e20746f204578616d706c65204170702e0a0a5552493a2068747470733a2f2f6170702e6578616d706c652e6f72670a56657273696f6e3a20310a436861696e2049443a20310a4e6f6e63653a203866336b326d39710a4973737565642041743a20323032362d31302d31385430393a33303a30302e3030305a0303040105d90130a2018a182cf5183cf500f500f400f4021a73c5da0a06549858effd232b4033e47d90003d41ec34ecaeda94076e426974546f6f6c2057616c6c6574

レスポンス(BitTool Signer → ウォレット)

デコードしたレスポンス · ur:eth-signature
{
"request-id": {
"uuid": "5f1e9b2c7d3a4e6f8a0b1c2d3e4f5a06"
},
"signature": "23c5ba3f5d247b4c81d55b7c44a3951a14c82e70f17ef2c19abea893c4e5bef05795a7261ac2bd9da29be2dfef529327e1b0724580fccac106bed3d007854f6b1b"
}
QR テキストと生の CBOR を表示
QR テキスト · ur:eth-signature
UR:ETH-SIGNATURE/OEADTPDAGDHECKNDDWKIFTGLJLLEBDCEDPFMGWHTAMAOHDFPCNSKRDFHHLDKKGGSLYTLHPKEFYOTMDCYBBSPDMJOWNKBWZSENYRNPDMUSSVWRNWTHGMDOSDSCYSARYNTOENDVOURWSGMMUDIVYPFJPFELAZTSGSEAMRNTETIATLPGWJECWWNKEFGEH
UR CBOR(16 進)
a201d825505f1e9b2c7d3a4e6f8a0b1c2d3e4f5a0602584123c5ba3f5d247b4c81d55b7c44a3951a14c82e70f17ef2c19abea893c4e5bef05795a7261ac2bd9da29be2dfef529327e1b0724580fccac106bed3d007854f6b1b

ウォレット側で組み立てた結果

walletConnectResult
0x23c5ba3f5d247b4c81d55b7c44a3951a14c82e70f17ef2c19abea893c4e5bef05795a7261ac2bd9da29be2dfef529327e1b0724580fccac106bed3d007854f6b1b
dApp に返す JSON-RPC の結果
0x23c5ba3f5d247b4c81d55b7c44a3951a14c82e70f17ef2c19abea893c4e5bef05795a7261ac2bd9da29be2dfef529327e1b0724580fccac106bed3d007854f6b1b

リクエストの表示​

ユーザーは 2 回承認します。1 回はウォレットで、もう 1 回は BitTool Signer でです。2 つの画面の内容を一致させてください。dApp の名前と URL、ネットワーク、そして BitTool Signer が表示するのと同じデコード済みの内容(金額、受取人、spender、メッセージの場合は全文)を表示します。未知のコントラクト呼び出しは推測せずに「不明」と表示してください。BitTool Signer も同様に、デコードできなかったものとして表示します。