すべての投稿
ガイド

Solanaの多対多送金|ウォレットを一対一で組む

対にしたウォレット送金の仕組み。一行につき一トランザクション、送金ごとに0.001 SOL、そして金額を削らず行を飛ばすrentの規則。

18 分で読めます J Tools Editorial
ほぼ黒い地に赤い点の縦列が二つ並び、左の各点が細い直線でちょうど一つの右の点とつながっている図

Solanaで多くの支払いを一度に動かすやり方は三つあり、いつも取り違えられます。マルチセンダーは一覧へ払い、一括回収ツールは多くのウォレットを一つに寄せます。

そして、どちらでも書き表せない場合が残ります。それが多対多送金で、送るウォレットそれぞれに自分の受取先を持たせます。ウォレット1はアドレス1へ、ウォレット40はアドレス40へ払い、二つの行は互いに触れません。

細かい違いに聞こえます。実際には、資金の出どころが一つであることと、独立した四十の出どころがあることの差です。

  • 一行が一トランザクションです。その行の送るウォレットが、その行の費用をすべて払います。
  • プラットフォーム手数料は送金ごとに0.001 SOL、ネットワーク手数料は0.000005 SOLです。
  • そのトークンを一度も持ったことのない受取先には、0.00149 SOLのrent預託が足されます。
  • 条件を満たさない行は金額を削られるのではなく、行ごと飛ばされます。

一括送金の三つのかたち

マルチセンダーは一対多です。ウォレット一つ、受取先の一覧、支払う側は一つ。エアドロップに合うのはこのかたちです。

一括回収ツールは多対一です。ウォレット四十、宛先は一つ、終われば全部が一か所に収まります。

多対多ツールが三つめで、組(ペア)を扱える唯一のかたちです。二つのアドレス列と金額を読み、その行に書かれたウォレットで署名します。多対多送金では、一行目には一行目の出どころ、二行目には別の出どころがあります。共通の資金はなく、行が互いを埋め合わせることもありません。

左では明るい点がひとつ、扇のように十個の点の列へ広がり、右では直線が二つの列を一対一で結んでいる図

一行あたりの費用

多対多送金では一行に項目が三つまで載り、その行の送るウォレットが三つとも負担します。共通の資金口座はないので、自分の行をまかなえないウォレットが上の行から借りることもありません。ネットワークの項目は署名ごとに5000 lamportの基本手数料で、Solana自身の手数料ドキュメントが定めています。

項目SOLモードトークンモード
プラットフォーム手数料0.001 SOL0.001 SOL
ネットワーク手数料0.000005 SOL0.000005 SOL
受取先のトークン口座該当なし0.00149 SOL、ただしその受取先がこのトークンを一度も持ったことがない場合だけ

三行目は二度読む価値があります。人がつまずくのはここだからです。SPLトークンに一度も触れたことのないアドレスへ送るとは、それを入れる口座を新しく作るということで、Solanaはその口座にrent預託を求めます。預託はネットワーク手数料よりはるかに大きな額です。

新しい受取先が百件なら、預託だけで請求のうち0.149 SOLほどを占めます。同じ条件でプラットフォーム手数料は0.1 SOLです。預託はバーンされません。受取先のトークン口座に残り、あとでその口座を閉じた人へ戻ります。署名の前に、ツールは百件の宛先口座を一回の呼び出しでまとめて調べるので、画面に出る見積もりがそのまま請求額になります。

飛ばされる行

多対多送金は署名の前に検査を二回走らせ、どちらも行を書き換えるのではなく止めます。

一つめはただの算数です。送るウォレットが自分の金額と手数料、そして開ける必要があるかもしれないトークン口座までまかなえなければ、その行に印が付き、そのまま残ります。半分だけ出ていくことはありません。

二つめは少し変わっていて、初めて見るとバグに見えます。Solanaは、残高が0より多くrent免除の下限より少ない口座を残すことを許しません。ふつうのウォレットならその下限は0.00065 SOLで、Solanaの口座ドキュメントにある式から出ます。

口座を空にし切るのは許されます。0.00005 SOLを残すのは許されません。ウォレットをその隙間へ押し込む行にはrent dustの印が付き、送られないまま残ります。

横軸の図。ゼロに灯った点がひとつ、次に二本の棒で閉じた赤い帯の中に暗い点がひとつ、その先に灯った点が二つ

金額を削らない理由

多対多送金が金額を削らないのは、削るほうが悪いからです。金額はあなたが入力した数字です。黙って別の数字を送るツールは、そのあとどんな表とも突き合わせられません。

残高を全部送るか、残りが下限を超えるまで金額を下げるかです。プレビューが、どの行が引っかかるかを先に知らせます。

一行に一トランザクション、その意味

多対多送金は行ごとに自分のトランザクションを作るので、落ちるのはその行だけです。全部を一つのトランザクションに詰め込むやり方なら、三十行目の誤りが手前の二十九行まで道連れにします。

代償はあります。四十組なら署名が四十、プラットフォーム手数料も四十です。かわりに結果は行ごとに読め、やり直すのも失敗した行だけで済みます。トランザクションがどれくらいの速さで入るかは、Solanaの優先手数料の記事に数字を並べてあります。

多対多送金が正しいかたちになるとき

多対多送金がいちばん当てはまるのは、ウォレットの入れ替えです。手放したい履歴の付いたウォレットの一式があり、ウォレットジェネレーターで新しい一式を作り、古いウォレット7から新しいウォレット7にだけ資金を移したい、という場面です。

二つめは、行ごとに支払う側が変わる支払いの一覧です。案件がいくつか、金庫がいくつか、シートは一枚。マルチセンダーでは書き表せません。出どころがちょうど一つだからです。

三つめはスナップショット後の再配分で、保有者ごとにあらかじめ割り当てたウォレットから払います。配る前にその分布を読む手順はトークン保有者の分布の読み方にまとめてあります。

一覧の準備

多対多送金の最初の一回は、二行だけで回してみてください。結果の表が、一行に実際いくらかかったかを、トークン口座の預託まで含めて教えてくれます。一覧をまるごと投入する前に確かめられます。

受取先がすでにそのトークンを持っているかも見ておくと、費用の見通しが変わります。半分が既存の保有者の一覧なら預託の項目は半分になり、百行の規模ではその項目が請求全体のなかでも大きな数字です。

どのウォレットがどの行を払うのかも、始める前に書き留めておくほうがいいです。実行したあとで対応を組み直すのは、思うより面倒です。送る側が作りたてで、見分けるための履歴をまだ持っていない場合はなおさらです。

一覧が大きくなると変わること

一つめは入金です。送るウォレットはどれも、始まる前に自分の金額と手数料を持っている必要があり、ある行が別の行を埋める手はありません。つまり配る前に入金する一回が要り、たいていは一つの金庫から出します。

二つめは終わったあとの突き合わせです。四十行なら表を見れば済みます。二千行なら結果を書き出して元のシートと行ごとに照らし合わせることになります。飛ばされた行はエクスプローラーに一切現れないからです。トランザクションとして存在したことがありません。

三つめは目立ちません。一覧に新しい受取先と既存の受取先が混ざっていると、一行あたりの費用は一定になりません。口座を新しく開く受取先が何件あるかを数え、その数だけを0.00149 SOLに掛けるのが正しいやり方です。

よくある質問

マルチセンダーを何度も回すのと何が違いますか?

マルチセンダーは一回の実行で出どころがちょうど一つです。出どころが四十なら実行が四十回、手でのウォレット切り替えも四十回になります。多対多送金なら実行が一回で行が四十です。

落ちた行にも費用はかかりますか?

署名の前に弾かれた行は、何もネットワークに届かないので費用はかかりません。署名して送信したあとチェーン上で失敗した行は、失敗した他のトランザクションと同じくネットワーク手数料を払います。プラットフォーム手数料は同じトランザクション内の命令なので、送金が成立しなければ決済されません。

送る側と受け取る側が重なってもいいですか?

いいです。一つのウォレットがある行では送り、別の行では受け取れます。行は独立したトランザクションなので、順序は保証されません。行2が行1の届けた分を使うなら、実行を分けてください。

なぜ自分の行にrent dustの印が付いたのですか?

その金額だと、送るウォレットの残りが0と0.00065 SOLのあいだになり、Solanaはその状態の口座を認めないからです。残高を全部送って残りを0にするか、金額を下げて残りが下限を超えるようにしてください。

トークンだけを送るウォレットにもSOLは要りますか?

要ります。動かすものがトークンでも、ネットワーク手数料とプラットフォーム手数料はSOLで払い、受取先が口座を必要とするならその預託もSOLです。

組の数に上限はありますか?

多対多送金に決まった上限はなく、数千組を貼り付けても止められることはありません。百組ずつ署名と送信を行い、最大二百五十六件ずつ確認します。確認の待ち時間は一回あたり最長九十秒なので、長い実行では終わるまで数秒ではなく数分かかります。見守れる実行なら直せる実行でもあるので、とても長い一覧は小さな実行に分けたほうが扱いやすくなります。

一行で決める

シートに支払う側の列があるなら、要るかたちは多対多送金です。全部の行が同じウォレットから出るならマルチセンダーを使えば、四十回ではなく一回の実行で済みます。そして送られなかった行があるときは、バグと決める前にまずrentの下限を見てください。その下限についてはrent不足エラーの解説に続きがあります。

J
著者
J Tools Editorial

J Toolsチームからの投稿

J Tools Editorial のすべての投稿を見る →

関連投稿