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 によって監査とディファレンシャル・ファズテストが行われており、これは機関投資家が項目を精査することを想定している場合にのみ言及されるような詳細です。
なぜここで「ネイティブ」が「スマートコントラクト」に勝るのか
Kora を ERC-4337 と比較して、Solana が追いつこうとしていると考える誘惑に駆られるかもしれません。しかし、アーキテクチャは異なる役割を担っており、その違いが重要です。
ERC-4337 は、Ethereum の上に並列システムとして実装されたアカウント抽象化です。これは、個別のメモリプール、UserOperation オブジェクト、バンドラー（bundler）の役割、および EntryPoint コントラクトを導入しますが、ベースプロトコルはこれらをネイティブには理解していません。バンドラーがユーザーオペレーションをパッケージ化し、ペイマスターが手数料をスポンサーし、オンチェーンコントラクトが検証を強制します。これは機能しており、Ethereum メインネットや主要な L2 にデプロイされていますが、プロトコルが想定していなかった UX 機能を後付けするための 6 年越しの建設計画のようなものです。
Solana の設計は、数年前にプロトコルレイヤーでその複雑さを解消していました。すべてのトランザクションにはすでに feePayer フィールドがあります。部分署名はネイティブ機能です。プログラムは任意のインストラクションを検証できます。Kora はバンドラーとペイマスターの構成ではなく、feePayer スロットを埋め、プロトコルがすでに受け入れている部分署名の 1 つを使用して署名するノードオペレーターです。
実用上の結果は、レイテンシと開発者の作業範囲に現れます。ERC-4337 トランザクションは、独自の順序付けルールと伝播遅延を持つ個別のメモリプールを経由します。Kora トランザクションは、他のすべての Solana トランザクションと同じパスを通り、400 ミリ秒未満の同じファイナリティを持ちます。考慮すべきバンドラーのアービトラージ市場も、追跡すべき EntryPoint コントラクトのバージョンも、デバッグすべき UserOperation のガス見積もりもありません。
これが Solana 開発者にもたらすものは、「手数料支払者フィールドを設定して dApp をリリースする」というシンプルさに近いものです。失われるのは、EVM スマートアカウントが標準で得られる柔軟性の一部（マルチキー認証、バッチ呼び出し、オンチェーンセッションポリシーなど）ですが、その多くは PDA やプログラム制御アカウントを通じて Solana 上で個別に構築されています。
Solana が実際に抱えていたラストマイルのギャップ
2025 年から 2026 年にかけての Solana の開発者の勢いについての議論の中で、コンシューマーウォレットレイヤーは遅れをとっていた部分でした。インフラストラクチャスタックは急速に成熟しました。Pump.fun の DEX ボリュームは 2026 年第 1 四半期に 20 億ドルを超え、Jito と Marinade がリキッドステーキングを支配し、Tensor は NFT 取引をプロフェッショナルなターミナルに変えました。しかし、これらの製品はすべて「ユーザーが SOL を持っていない」という問題に対して独自の回答を用意しなければなりませんでした。
ワークアラウンドは独創的でした。Pump.fun は組み込みのオンランプを通じて初期のトークン取得をルーティングしました。Jito はダスト（微量）の SOL をユーザーアカウントに事前に付与 しました。Tensor は、ユーザーが板に到達する前に Phantom や Backpack に頼って SOL 取得ステップを処理させました。これらは個別に機能しましたが、相互運用性はありませんでした。Pump.fun のフローでオンボードされたユーザーは、手数料支払い用の残高を持った状態で Tensor にたどり着くことはありませんでした。
一方、Base は Coinbase Smart Wallet のパスキーフロー、Coinbase Developer Platform を通じた無料のガス代スポンサーシップ、そしてメールログインの裏側に秘密鍵の概念を完全に隠す開発者 SDK をリリースしました。Abstract は同じアイデアをさらに進め、Web2 アプリのように感じられる組み込みウォレットを提供しました。2025 年のコンシューマーアプリ開発者への総合的な売り文句はこうでした。「Base で構築すれば、ユーザーはオンチェーンであることを意識せず、スケールする間の手数料は私たちが支払います」。
Kora はその売り文句をそのままコピーするものではありません。Kora が行うのは、Solana dApp が同じような売り文句を作成できないというアーキテクチャ上の理由を取り除くことです。Kora を使えば、Solana チームは以下の機能を提供できるようになります：
- Privy、Turnkey、または Coinbase Embedded Wallets を通じたメールまたはパスキーによるサインアップ。
- トランザクションに SOL 残高が不要。
- USDC、BONK、または dApp 独自のネイティブトークン（存在する場合）による手数料支払い。
- パスにバンドラーを介さない 1 秒未満のファイナリティ。
以前からピースは存在していました。Octane はオープンソースの先祖でした。Circle の Gas Station、Openfort、Portal、Gelato、Biconomy、その他多くのベンダーがサービスとして手数料リレーを提供していました。Kora が変えるのは、Solana Foundation 自体が、標準化され、監査済みで、KMS 互換のリファレンス実装をリリースしている点です。これにより、これまで独自に構築したりベンダーに支払ったりしていたすべてのチームの意思決定プロセスから、「どのサードパーティのペイマスターを信頼すべきか」という問いが取り除かれます。
Kora の上位にあるベンダー層
興味深いのは、Kora が解消したギャップの周囲にすでに構築されていた、組み込み型ウォレットベンダーに何が起こるかという点です。
Privy は、2025 年 6 月に Stripe に買収されましたが、メールログインを希望する Solana dApp にとって有力なコンシューマーアプリ向けウォレットであり続けています。Privy にとって Solana は公式にはセカンダリチェーンであり、その深みは EVM にありますが、組み込み型ウォレットのフローは Solana にも及んでおり、Privy はアプリが管理する手数料支払い用ウォレット（fee payer wallet）の設定をすでにサポートしています。Kora は Privy を置き換えるものではありません。各顧客が独自のペイマスターサービスを運用するのではなく、Privy がプラグインできる標準化されたバックエンドを提供します。
Turnkey は、セキュリティ重視の組み込み型 サイナーであり、Kora のリモート署名 API と自然に組み合わさります。Turnkey は明示的にペイマスターインフラを含んでいないため、ハードウェア分離されたキーとガスレスな UX の両方を求める Solana チームは、2 つのベンダーを無理やり結合させる必要がありました。Kora はその統合を簡素化します。
Dynamic は、2025 年に Fireblocks に買収され、マルチチェーン認証をエンタープライズチームに提供しています。Fireblocks の支援を受けたポジショニングにより、Dynamic はエンタープライズコンプライアンスを備えた Solana と EVM の両方のカバレッジを必要とするフィンテック企業にとって自然な選択肢となっています。Kora は Dynamic に対し、Fireblocks が競合するペイマスターをリリースすることなく、クリーンな Solana 手数料抽象化の仕組みを提供します。
Coinbase Developer Platform は、少し厄介な存在です。Coinbase は、Coinbase Smart Wallet、Base のガス代無料化、組み込み型ウォレット SDK を通じて、Base をデフォルトのコンシューマーチェーンにすることに多額の投資を行ってきました。Kora は、Base がこれまで販売してきた差別化要素を狭めます。特に、Solana がすでに規模の優位性を持っている USDC ネイティブなフローを求めるアプリにとっては顕著です。
考えられる結果として、Kora は、自社でペイマスターサービスを運用したくないすべての組み込み型ウォレットベンダーにとって、デフォルトの Solana バックエンドになるでしょう。ベンダーは認証 UX、キー管理、ポリシー制御で競い合います。Kora はその下で手数料のリレーを処理します。これは、すべてのコンシューマー向け Solana dApp が独立したベンダー決定を行い、各候補の独自リレーヤーのセキュリティを評価しなければならなかった以前の状態よりも、エコシステムにとって健全です。
これが解決すること、解決しないこと
Kora は 1 つのギャップを決定的に埋めますが、他のいくつかのギャップは残したままです。どれがどちらであるかを正確に把握しておく価値があります。
Kora が解決すること：
- 他のトークンで手数料を補助しようとする dApp にとっての、「ユーザーは SOL を保持しなければならない」という UX の崖。
- 以前は運用の負担かベンダーロックインかの選択を迫られていたチームにとっての、「ペイマスターを自前で作るか買うか」の決定。
- 監査と KMS サポートにより、規制対象のエンティティが独自に構築することなく Kora ノードを運用できるようになったため、機関投資家レベルの受容性のギャップが解消されます。
Kora が解決しないこと：
- ウォレットの獲得自体 — ユーザーは依然として Phantom、Privy、Turnkey、または Coinbase のどこからか組み込み型ウォレットを取得する必要があります。
- アカウント抽象化プリミティブ（バッチ呼び出しやセッションキーなど）。これらは依然として、PDA やその他のプログラムレベルのパ ターンを通じて Solana 上で個別に組み立てられています。
- Kora オペレーターが立て替える SOL の支払いを誰が負担するかという経済的な問題。トークン収益やステーブルコインの流動性がある dApp にとっては問題ありませんが、無料製品の場合、ガス代のスポンサーシップは単なる顧客獲得コスト（CAC）に過ぎません。
- クロスチェーン UX。これは依然として、ユーザーがブリッジや LayerZero、Wormhole、Across のようなチェーン抽象化レイヤーと対話する必要があります。
「プロトコルプリミティブとしてのガスレスインフラ」というテーゼは、両刃の剣です。Solana は現在、主要なチェーンの中で最もクリーンなネイティブ手数料抽象化の仕組みを持っています。それは同時に、差別化のポイントがウォレット UX、リカバリーフロー、そして EVM が数年のアドバンテージを持つアカウント抽象化機能へとスタックの上位に移動することを意味します。
ビルダーのための戦略的解釈
2026 年半ばにチェーンを選択するチームにとって、その計算は変化しました。12 か月前、コンシューマーのオンボーディングに対する答えは、Base、Abstract、または新しい EVM コンシューマーチェーンのいずれかであり、それ以外に選択肢はありませんでした。Solana は開発者の関心とインフラの勢いを持っていましたが、SOL 取得のステップで一般ユーザーを逃していました。それはもう過去の話です。
フロントエンドに Privy または Turnkey を使い、バックエンドに Kora を使用して今日 Solana でローンチするコンシューマー dApp は、Base 上の同等のスタックと機能的に同じ UX 表面を持っています。メールログイン、ガスレス取引、USDC での手数料支払い、1 秒未満のファイナリティ。残る違いはランタイムモデル、ツールエコシステム、および利用可能な流動性です。Solana のスループットと DEX の深さを求めるアプリにとって、EVM を選択する UX 上の議論は大幅に弱まりました。
すでに Base で展開しているチームにとって、Kora は即座の決定を変えるものではありません。しかし、長期的な競争圧力は変化します。新しいインフラのおかげで統合の悩みが 1 つ減り、最もクリーンな UX を持つコンシューマー dApp が Solana に登場し始めれば、Base のコンシューマーオンボーディングという堀（モート）の周囲にある重力はシフトし始めます。
正直な見解として、Kora は必要条件ではありますが、十分条件ではありません。開発者がコンシューマーアプリに Solana を選ばなかった特定の理由を取り除きます。それ自体が Solana を選ぶ新しい理由を創出するわけではありません。今後 2 四半期で、組み込み型ウォレットベンダーが実際に Kora をデフォルトにするか、新しいコンシューマー dApp がチェーン選択の理由として Kora を挙げるか、そして既存の EVM コンシューマーチェーンが自社のインフラストーリーを改善することで対抗するかが明らかになるでしょう。
いずれにせよ、「取引前にユーザーが SOL を取得しなければならない」という問題は、ついに現在の課 題ではなく、過去の遺産となりました。それだけで、出荷する価値があります。
BlockEden.xyz は、コンシューマー dApp、決済レール、および取引システムを構築するチーム向けに、本番環境グレードの Solana RPC インフラを運営しています。ガスレスフローの統合や Solana 製品のスケーリングを行っている場合は、次世代のコンシューマークリプト向けに設計された低遅延エンドポイントについて、当社の API マーケットプレイスをご覧ください。
参考文献
