私が働いた結婚式のコート預かりでは、番号付きの紙チケットを使っていました――片方をちぎって、もう片方を控えとして持つ。番号ごとに1着だけ。機械が同じ番号を一度しか印字しなければ、単純な仕組みです。

ところが夜の途中で詰まり、すでに無くなった番号を再び印字し始めました。2人がチケット#114を持って現れました。しかも、その番号の下に掛かっていたコートは1着だけです。

私が思い当たる言葉としては「余分なチケット」――請求（クレーム）が一度以上発行されてしまうことです。というのも、請求を印字する側は裏で実際に掛かっているものを確認しないから。ビットコインの流動性ステーキング・トークンも同じ露出を抱えています。入金に対して、受領書（レシート）が発行される。発行されるのは、それをミントするコードがどれだけ誠実かに等しいだけのことです。

3月、Solv ProtocolのBROバルートで、1 BTCの入金が本来よりも多くのSolvBTCをミントできてしまいました。リエントラント（再入可能性）のバグにより、単一のNFT入金がコールバックを引き起こし、最初のミントが完了する前に2回目のトークン群が発行されたのです。セキュリティ会社Halbornはこれを、その二重ミントの経路にまで追跡し、被害額は約$2.7Mとされました。ユーザーは払い戻されましたが、一時的にレシート・トークンが、それを裏付けるビットコインを先回りする形になりました。

バビロンのステーキング統合は、まさにこの理由で、レシート・トークンの手順をスキップしています。ステークされたBTCのバルートには、作成時にあらかじめ3つの支出条件（アンステーク、リクイデート、スラッシング）が署名済みで、スマートコントラクトが「入金の上に」請求をミントするのではなく、ビットコインのスクリプト自体によって直接強制されます。二度発行されうる2つ目のトークンなど存在しません。なぜならトークンがないからです。

私が抱えている結論はこうです。Solvは、悪用後に契約をパッチしてユーザーを払い戻せるかもしれない。しかし事前署名されたバルートはパッチできません――作成時に署名された条件は、そのバルートの一生にわたる条件だからです。直せるバグを直すことで、直せないミスと引き換えるようなもの。これもまた別種のリスクです。

チケット#114は、今でも覚えている番号です。コートそのものよりも。

テストネットからの私自身の引き出し要求は、まだチャレンジ期間の真っ最中です。実際にウォレットへ着地したら報告します――ダッシュボードに出ているだけではなく。

@BabylonLabs_io $BABY #baby