Solana の Kora サイニングノードは、コンシューマークリプト競争をリセットする可能性を秘めた静かな UX の転換点である
5 年間、「insufficient SOL for transaction」は Solana における最も高くつくエラーメッセージであり続けてきました。非クリプトユーザーをターゲットにしたすべてのコンシューマーアプリは、まさにそのステップで一定の割合のユーザーを失っていました。最初のトークンを使うためだけに、見ず知らずの人が 2 つ目のトークンを入手しなければならないというチェックアウトの手順においてです。2026 年 4 月、Solana Foundation はついにその答えをリリースしました。それが Kora です。これは、dApp がネイティブにトランザクションをスポンサーし、任意の SPL トークンで手数料を支払い、署名を TEE または KMS バックのボルトにアウトソーシングできるようにする手数料リレイヤーおよび署名ノードです。これは派手なローンチではありません。インフラ(配管)のアップグレードです。そして、こうしたインフラのアップグレードこそが、Base や Abstract が過去 12 か月間のコンシューマーオンボーディングを静かに独占してきた理由なのです。
もはや問題は、Solana が EVM コンシューマーチェーンのガスレス UX に匹敵できるかどうかではありません。Kora はその部分を些細なものにします。問題は、ラストマイルのギャップを埋めることが、すでに別の場所で構築を始めた開発者を呼び戻すのに十分かどうかです。
Kora が実際に提供するもの
マーケティングを除けば、Kora はトランザクションリレイヤー、リモートサイナー、ポリシーエンジンの 3 つを組み合わせたものです。dApp がトランザクションを構築し、Kora ノードを手数料支払者(fee payer)として設定すると、ユーザーは組み込みウォレットからペイロードに署名し、Kora オペレーターが共同署名(co-sign)してブロードキャストします。バリデーターには引き続き SOL で支払われますが、ユーザーが SOL を保持する必要は全くありません。
興味深いのは検証レイヤーです。Kora ノードは、ユーザーから渡されたものを盲目的にリレーするわけではありません。署名前に 3 つのチェックを行います。
- 関連する Solana プログラムに対する インストラクションの検証。これにより、不正な形式や悪意のあるインストラクションはリーダーに届く前に拒否されます。
- オラクルに裏打ちされた手数料の妥当性確認。提示された SPL トークンの量と現在の SOL 価格にオペレーターのマージンを加えたものを比較し、リレイヤーが赤字にならないようにします。
- プログラムおよびトークンレベルでの アローリストとブロックリストの適用。これにより、特定の dApp のために Kora ノードを運用しているオペレーターが、監査されていないランダムなコントラクトをターゲットにしたトランザクションを誤ってスポンサーすることを防ぎます。
署名パスは、このアーキテクチャが野心的である部分です。Kora は Turnkey や AWS KMS によるリモート署名を標準でサポートしています。つまり、手数料を支払う秘密鍵がリレイヤーのディスク上に存在することはありません。Solana 上で構築するフィンテック企業にとって、これは「自分たちでペイマスターを構築して幸運を祈る」のと、「秘密鍵の管理体制が SOC 2 監査に合格する」ほどの違いがあります。
全体として Runtime Verification によって監査とディファレンシャル・ファズテストが行われており、これは機関投資家が項目を精査することを想定している場合にのみ言及されるような詳細です。