XRPレジャー（XRPL）で4日、トークンの焼却だけを任された口座が、条件によっては新しいトークンを発行できてしまう不具合の修正が有効になった。不具合は、他の口座に操作を任せる権限委任の機能にあった。暗号資産（仮想通貨）XRP（
XRP）は、ソースコード上、この権限による代理の送金に使えない。
XRPレジャーの権限委任、焼却の権限で発行もできた
権限委任は、口座の持ち主（委任元）が別の口座（代理人）に、決められた種類の取引だけを代わりに送らせる機能だ。メインネットでは日本時間10月9日6時29分に有効になった。
権限の一覧を載せた公式文書によると、任せられる権限には、トークンを新たに発行する送金の権限PaymentMintと、発行元に戻して焼却する送金の権限PaymentBurnがある。焼却の権限は、残高がゼロになるところまでに限る。
同文書は、修正前は焼却の権限で、条件によってはトラストラインのトークンとMulti-Purpose Token（MPT）を新たに発行できたとし、修正が有効になるまで委任しないよう勧めていた。ほかの個別の権限は影響を受けないとしている。
修正のソースコードに付いた説明によると、トラストラインのトークンの焼却は保有残高までで終わり、それを超えて送ると、ゼロをまたいで委任元が発行するトークンが生まれる。修正前の判定は残高の向きだけを見て許可し、送る額と残高を比べていなかった。
修正に付いたテストでは、発行元のUSDを50持つ委任元の代理人が、100を発行元に送る。発行元は委任元のUSDを受け入れるトラストラインを持つ。修正前は50が焼却された後、残り50の分だけ委任元の名義で新しいUSDが発行された。
修正後、トラストラインのトークンでは、焼却の権限だけを持つ代理人の送金は保有残高以下に限って通る。
XRPレジャーの修正、支持の一時低下で約12日遅れ
修正は、開発者向けブログが9月16日付で告知したサーバーソフトxrpldの3.4.0に、複数の修正をまとめたアメンドメント（取引処理のルールを変える修正）として入った。名称はfixCleanup3_4_0で、ボールトや融資、自動マーケットメーカー（AMM）の修正も含む。
9月25日に出た3.4.1は、10月9日に開示したXRPを新たに生み出せる脆弱性を直したもので、今回とは別の不具合だ。
公式文書によると、アメンドメントは信頼されたバリデーターの80％超の支持が2週間続いて有効になる。
台帳の記録によると、今回のアメンドメントは日本時間10月9日18時34分に80％超の支持を得た。このまま続けば、10月23日に有効になる計算だった。しかし10月21日21時41分に支持が80％以下に下がって2週間の数え直しになり、同日23時46分に再び80％を超えた。
| 日時（日本時間） | 出来事 |
|---|---|
| 9月16日（ブログの日付） | 修正を含むxrpld 3.4.0を告知 |
| 9月下旬 | 公式文書と規格（XLS-75）に、PaymentBurnを委任しないよう勧める注意書き |
| 10月9日6時29分 | 権限委任の機能（PermissionDelegationV1_1）がメインネットで有効に |
| 10月9日18時34分 | 修正（fixCleanup3_4_0）が80％超の支持を得る |
| 10月21日21時41分 | 支持が80％以下に下がり、2週間の数え直し |
| 10月21日23時46分 | 再び80％超に |
| 11月4日23時52分 | 修正がメインネットで有効に（レジャー番号108,112,129） |
権限委任がメインネットで使えるようになってから修正が有効になるまで、約27日あった。
XRPレジャーの不具合、悪用の有無は公式に記載なし
5日時点で、この不具合が悪用されたかどうかについて、XRPレジャーの開発者向けブログや公式文書に記載はない。10月9日の開示のような脆弱性の開示報告も同ブログに見当たらず、ブログやリリースノートは誰が見つけたのかも示していない。
3.4.0のリリースノートの記載は、焼却の権限によるゼロ残高をまたぐ送金を拒否するという1行だ。GitHubの記録では、修正のコードは9月中旬に作られて3.4.0に取り込まれ、書いたのはリップル社のメールアドレスを使う開発者だった。
サーバーの運営者は、10月9日に有効になった別のアメンドメントにより、すでに3.4.1以上への更新を求められている。
関連：数百XRPで総供給超えのXRPを生成可能だった──リップル社らが修正
関連：XRPレジャーでMMFのトークン化クラス、英保険大手アビバが2本目
