2026年7月21日に一般提供が始まったマイナウォレットは、Ethereum の Account Abstraction と公的個人認証を組み合わせ、秘密鍵や端末を失っても復旧できる一般利用者向けウォレットを実現している。同じことは Cardano でもできる。足りないのは技術ではなく、統合された標準である。
Cardano に必要なのは新しいウォレットアプリではなく、ERC-4337 に相当するエコシステム共通の復旧可能スマートウォレット標準である。
部品はすでにある。マルチシグ、時間ロック、Plutus validator、状態 UTxO、そして CIP-1854・106・141・146。統合されていないだけである。
まず、プログラマブルウォレットが従来のウォレットと何が違うのかを整理する。
いまのウォレットは、利用者に次の運用を求めている。
24 語のシードフレーズを安全に保管してください 他人には絶対に見せないでください 紛失したら誰にも復旧できません 盗まれたら資産を奪われる可能性があります
暗号資産に慣れた人には当然に見えるが、高齢者、子ども、機種変更に不慣れな人、紙のバックアップを安全に保てない人、家族に資産を引き継ぎたい人にとって、「24 語を一生なくさず誰にも見せずに管理する」は現実的ではない。台帳がどれほど堅牢でも、紙を一枚なくしただけで資産に永久に触れなくなるなら、社会インフラとしては弱点が残る。
問題は秘密鍵の存在ではなく、秘密鍵が唯一絶対の条件であることにある。鍵の紛失、盗難、フィッシング、端末故障、相続、認知機能の低下、誤操作。人間の側で普通に起きることに、この構造は何も対応できない。
現在の一般的なウォレットも複数の UTxO を持つが、それらは基本的に同じ秘密鍵系統で管理されている。
シードフレーズ │ 鍵を生成 ▼ 支払い秘密鍵 │ ├─ UTxO ① 100 ADA ├─ UTxO ② NFT └─ UTxO ③ USDM
資産の箱は複数あるが、開ける条件は基本的に正しい秘密鍵の署名があることの一点。したがってシードフレーズを失えば、すべての箱が同時に開かなくなる。
各 UTxO を秘密鍵だけでなく Plutus スクリプトのルールで保護する。鍵や復旧設定そのものは、独立した状態 UTxO に台帳として記録される。
Cardano Smart Wallet │ ├─ 状態 UTxO │ ├─ 現在の操作鍵 │ ├─ 復旧鍵 ・ guardian │ ├─ 復旧待機時間 │ ├─ 送金上限 │ └─ ウォレット識別子 │ ├─ 資産 UTxO ① 100 ADA ├─ 資産 UTxO ② NFT └─ 資産 UTxO ③ USDM
これらをウォレットアプリがまとめて、利用者には一つの残高・一つの口座として見せる。資産を動かすとき、スクリプトは操作の種類ごとに異なる条件を判定する。
プログラマブルウォレットでも、内部では通常どおり鍵を使う。パスキーの暗号鍵、Cardano の署名鍵、ハードウェアキー、guardian の鍵。変わるのは鍵の有無ではなく、一つの秘密鍵だけがウォレット全体を永久に支配する構造ではなくなるという点である。
鍵 A を持っているか？
│
├─ Yes → 全操作可能
└─ No → 何もできない
今回の操作は
設定された条件を
満たしているか？
│
└─ 通常送金 ／ 高額送金 ／
復旧ごとに判定
表現を整えるなら、プログラム可能な金庫室の中に、複数の UTxO という資産箱が入っていると考えると分かりやすい。
| Ethereum AA | Cardano で考えられる構成 |
|---|---|
| スマートアカウント | Plutus スクリプトで管理される論理ウォレット |
| コントラクトの保存状態 | 状態 UTxO |
| アカウント残高 | 関連する資産 UTxO 群 |
| owner の変更 | 状態 UTxO 内の操作資格情報を更新 |
| social recovery | guardian 署名＋時間制限 |
| Paymaster | 手数料 UTxO を提供するスポンサー |
| ウォレットアドレス | スクリプトアドレス＋ウォレット識別子 |
Cardano でも、秘密鍵で直接支配される UTxO 群をウォレットと考えるのではなく、プログラム可能なルールで管理される UTxO 群と状態 UTxO を、一つの論理的なスマートウォレットとして扱えばよい。
この資料の出発点になった疑問。結論から言うと、前提が少しずれている。
Ethereum の EOA は、プロトコルレベルで secp256k1 の ECDSA 署名を検証するという規則が焼き付けられている。この検証ロジックは差し替えられない。つまり Ethereum では「鍵を持っているか」以外の条件でアカウントを守ることが、そもそも原理的にできなかった。
ERC-4337 が取った解決は、プロトコルを変更せずに済ませることだった。通常のトランザクションとは別に、UserOperation → Bundler → EntryPoint というもう一本のパイプラインをアプリケーション層に作る。EntryPoint も Paymaster も Bundler も、EOA の制約を迂回するために必要になった部品であって、スマートウォレットという概念に本質的に必要な部品ではない。
2025年5月の Pectra アップグレードで入った EIP-7702 は、既存の EOA が一時的にコントラクトとして振る舞えるようにするもので、これも「すでに大量にある EOA をどう救うか」という Ethereum 固有の移行問題に対する答えである。
迂回路とはいえ、実運用では十分に育っている。ある集計では、2026年4月時点で ERC-4337 は 12 チェーン・約 5,680 万アカウントで累計 10 億件超の UserOperation を処理している。Cardano 側にこれに相当する運用実績はない。
eUTxO では、スクリプトアドレスがそのままスマートアカウントである。validator に書いた条件が、そのアドレスの資産を動かす条件になる。EOA とコントラクトアカウントという区別が構造として存在しないので、「アカウントの検証ロジックを差し替える」という課題自体が発生しない。
したがって「Cardano には AA がない」というより、AA が解こうとした問題が Cardano にはない、というのが正確なところになる。「Cardano には口座をプログラム化する発想がない」という説明を見かけるが、これは正確ではない。スクリプトアドレスは最初からプログラム可能な口座である。
Cardano にはネイティブスクリプトという、Plutus より下の層がある。ここで atLeast（M-of-N）と時間ロックが書ける。つまり第 I 部で挙げた「guardian 2 人＋48 時間の待機」は、実はスクリプトを書かなくても表現できる。
any
├─ 本人の鍵 ← 通常時
└─ all
├─ atLeast 2 of [G1, G2, G3] ← guardian
└─ after (slot + 48h) ← 待機Plutus を使わないので手数料が安く、後述するコラテラルも不要。ただし状態を持てないのが決定的な差になる。送金上限のような動的な判定ができず、何より鍵を入れ替えるとスクリプトが変わり、アドレスそのものが変わってしまう。
第 I 部で状態 UTxO を分けて置いたのは、まさにこれを避けるためである。アドレスを固定したまま中の資格情報だけを差し替えられること。それが Plutus と状態 UTxO を持ち出す理由になる。
「原理的にできる」と「製品にできる」の間にあるものを、具体的に並べる。
Plutus に組み込まれている署名検証は Ed25519 と、CIP-49 で 2023 年に追加された secp256k1 の ECDSA／Schnorr。一方、パスキー・Secure Enclave・YubiKey・WebAuthn が使うのは P-256（secp256r1）で、これを検証するビルトインは、2026 年 7 月時点で標準に入っていない。Ethereum 側は L2 にプリコンパイルとして載っている。
影響：マイナウォレットの「パスキーで操作」を、そのままオンチェーン条件にできない。パスキーはアプリ側の認証に留めて別途 Ed25519 鍵を持たせるか、ZK で検証する（高コスト）ことになる。ここが一番具体的な差。
口座の状態を一つの UTxO に置くと、それを消費するトランザクションは同時に一つしか通らない。連続送金がぶつかる。eUTxO で口座モデルを素直に真似ると必ずここに当たる。
回避策は確立している。Vasil で入った参照入力（CIP-31）を使えば、状態 UTxO を消費せずに読むだけにできる。通常送金では参照のみ、鍵の更新など状態を書き換えるときだけ消費する、と設計を分ければ競合しない。
Plutus スクリプトを実行するトランザクションはコラテラルを差し出す必要があり、そのコラテラルはスクリプトアドレスに置けない。通常の鍵アドレスにある、他トークンを含まない純粋な ADA でなければならない。
つまり完全にスクリプト管理のウォレットでも、手数料・コラテラル用の平の UTxO を別に持ち続けることになる。ここを誰が用意するかが、そのまま手数料スポンサー（Paymaster 相当）の設計論点になる。
dApp とウォレットをつなぐ CIP-30 は、signTx が署名の witness を返すモデルになっている。しかしスクリプトウォレットで必要なのは署名ではなく、validator を満たすトランザクションを組み立てることである。実際、マルチシグ向けの拡張である CIP-106 は signTx() と signData() を無効化し、代わりに非同期の submitUnsignedTx() / getCompletedTx() を置いている。署名モデルが合わないことが、規格の側でも認められている。
後述するとおり拡張案自体は存在する（CIP-106・CIP-141）。ただしいずれも Proposed で、複数ウォレット・複数 dApp に広く採用された共通標準にはなっていない。
「誰も考えていない」わけではない。むしろ議論され、合意に至らずに閉じられている。
「Arbitrary Script as Native Script spending conditions」。ネイティブスクリプトに RequireScript という条件を足し、同じトランザクション内に指定の Plutus スクリプトがあるときだけ使えるようにする案。当時「Cardano に Account Abstraction を」と報じられた。狙いは、利用者が datum の構造を知らなくてもスクリプトウォレットに送金できるようにすること。
二重充足（double satisfaction）による悪用の懸念、datum を持たない寄付のようなケースしか扱えないという指摘、そして「ネイティブスクリプトを拡張するより、datum なしの Plutus 実行やアドレス表記の拡張で解くべきでは」という代替案が出て、まとまらなかった。
スクリプトアドレスを持つウォレットと dApp をつなぐ CIP-30 拡張。更新可能マルチシグ、多要素認証、相続、セミカストディアルなど、まさにスマートウォレットの用途が並んでいる。以後 Proposed のまま。
Charles Hoskinson が、24 語のリカバリーフレーズを明かさずに所有を証明し、スマートコントラクトのプールから資産を解放する復旧方式を実験中と表明。これは「シードフレーズを失っても復旧できる」ものではなく、「シードフレーズを見せずに証明できる」ものである点に注意。根が 24 語である以上、後述する身元ベースの復旧の代わりにはならない。
ERC-4337 と公的個人認証による復旧を実装した一般向けアプリが、EVM 6 チェーン対応で出荷された。Cardano は含まれていない。
比較対象が実在の製品になったので、公開情報から読み取れる範囲で構成を確認する。
2026年7月21日、マイナウォレット株式会社が App Store・Google Play で一般提供を開始。「KYC 済みノンカストディアルウォレット」と説明され、Account Abstraction 技術と公的個人認証サービスを活用することで、デバイスや秘密鍵の紛失時でもアカウントの復旧が可能とされている。
同社は 2023 年時点で、ERC-4337 準拠のスマートコントラクトとしてリカバリー・セッションキー・利用限度額を開発していると説明しており、Ethereum Foundation の ERC-4337 Account Abstraction Grant Round にも採択されている。突然の機能追加ではなく、数年かけた開発の製品化にあたる。
カード自体が資産を直接動かす署名鍵になっているとは限らない。公開情報から見る限り、役割はこう分かれていると考えられる。
スマートフォンのパスキー
↓
日常的な送金・操作
マイナンバーカード ＋ JPKI
↓
本人性の確認
↓
紛失時の復旧プロセス
↓
新しいパスキーを操作権限として登録つまりカードは毎回金庫を開ける鍵ではなく、鍵をなくしたときに本人であることを証明して錠前を交換するための公的な本人確認手段に近い。第 I 部の guardian の位置づけと同じである。
端末・鍵をなくした → カードをタッチして復旧（自宅で完結） カードもなくした → 役所でカード再発行（従来の窓口手続き） → 新しいカードでウォレット復旧
注目すべきは、新しい復旧制度を作る必要がないことである。カード再発行という既存の窓口業務が、そのまま最終的な復旧経路になる。
| 知識ベース | 身元ベース | |
|---|---|---|
| 根拠 | シードフレーズを知っていること | 現実世界の本人性 |
| 例 | 24 語、ZK による所有証明 | JPKI、guardian、窓口での本人確認 |
| 全部失ったら | 復旧できない | やり直せる |
| 必要な構造 | HD ウォレットで足りる | 鍵を交換できる論理口座が必要 |
ZK による復旧は、24 語を他人に見せずに証明するもので、依然として左の列にある。マイナウォレットが選んだのは右の列であり、この二つは代替関係にない。そして右の列は、アドレスを保ったまま操作鍵を差し替えられる構造がなければ実装できない。だからスマートウォレットが要る。
判断基準は「利用者が秘密鍵を直接見ているか」ではなく、サービス提供者が利用者の意思なしに資産を動かせるかである。
通常送金
└ 本人のパスキーのみ
復旧
└ 本人確認 ＋ 別要素
＋ 待機時間
運営会社
├ 単独では送金不可
└ 単独では所有者変更不可
運営会社 ├ 管理鍵で所有者を変更可能 ├ 任意に資産を移動可能 ├ 口座を凍結可能 └ 復旧を単独承認可能
同じ「AA を使ったウォレット」でも、この両極のあいだのどこにでも実装できる。Account Abstraction だから安全なのではなく、どのような復旧条件を実装したかで安全性が決まる。
マイナンバーカードだけで復旧が成立するのか、新端末のパスキーも必要か、待機時間はあるか、旧端末に通知され拒否できるか、運営会社が単独で所有者を変更できるか、コントラクトはアップグレード可能か、その権限は誰が持つか。2026年7月21日時点の公開情報だけでは、これらは確認できない。客観的な評価には、コントラクトアドレス、ソースコード、監査報告、復旧条件、管理者権限、サービス終了時の移行方法の公開が要る。
JPKI の署名検証そのものは、EVM 上でオンチェーンに行うのは現実的ではない。したがってオフチェーンで本人確認を行い、その結果をオンチェーンに伝える主体が必要になる。この点について、マイナウォレット社は公的個人認証の認定プラットフォーム事業者であり、自社で本人確認を完結できるとされる。外部の検証事業者を挟む構成ではない。
これは利用者にとって経路が短くなる一方、設計上は論点を一つに絞り込む。検証主体が運営会社自身であるということは、復旧における実質的な guardian が運営会社だということである。したがって問うべきは「誰が本人確認するのか」ではなく、次の一点になる。
運営会社の承認「だけ」で操作鍵を差し替えられるか？
Yes → 実質的に運営会社が口座を掌握できる
（資産を直接動かせなくても、
鍵を自分のものに替えれば同じこと）
No → 承認に加えて次が要る設計になっているか
├─ 新端末のパスキー登録
├─ 待機期間
└─ 旧端末からの取消資産を直接動かす権限を持たないことと、所有者を変更できないことは別の話である。第 V 部の復旧ステートマシンで待機期間と異議申立てを必須にしているのは、まさにこの差を埋めるためにあたる。
ゼロからではない。個別の仕様は存在する。統合されていないだけである。
複数当事者の署名を要するウォレットの鍵派生を定義する。purpose=1854' で通常ウォレット（CIP-1852）と区別し、支払い・委任のスクリプトテンプレート、部分署名トランザクションの検証と署名手順を規定する。四つのうち唯一 Active。ただし対象は鍵の派生と管理であり、スマートウォレット全体を定義するものではない。
dApp とマルチシグウォレットの通信を定義する CIP-30 拡張。スクリプト記述子の提供、長時間に及ぶ署名のための非同期 API（submitUnsignedTx() / getCompletedTx()）、Plutus V2 以降向けのコラテラル管理を加える。前述のとおり signTx() / signData() は無効化される。
保有アドレスが公開鍵ではなく Plutus スクリプトに対応するウォレットのための CIP-30 拡張。想定用途として、更新可能マルチシグ、定期支払い、多要素認証、セミカストディアル、トークン化ウォレット、相続管理、Cardano 以外のアドレスで制御されるウォレットが挙げられている。この資料が提案しているものに最も近い既存 CIP。2023年10月提案、以後 Proposed。
マルチシグウォレットをオンチェーンに登録し、関係者やウォレットソフトから発見できるようにする。メタデータラベル 1854 にネイティブスクリプトとウォレット情報を格納し、CIP-1854 の派生パスから検証鍵を導いて該当する登録を検索する。参加者情報やオフチェーン JSON 共有、CIP-83 による暗号化にも対応。
並べてみると、Cardano にはマルチシグ鍵の標準・dApp 接続インターフェース・Plutus ウォレットの構想・ウォレットの登録と発見が個別に存在する。しかし、パスキー、社会的復旧、鍵交換、手数料スポンサー、ステーキング、ガバナンス、dApp 接続を一人の利用者の一つの口座として統合した標準にはなっていない。ERC-4337 が持っている「一つの合意点」がない。
第 II 部の四つの欠落が技術的な穴だとすれば、こちらは設計上の負担にあたる。
Ethereum ならコントラクトのストレージに owner、guardian、limit、recoveryDelay と書けば済む。Cardano では状態は UTxO であり、旧状態を消費して新状態を作る遷移として表す。明示的で決定論的という利点の裏で、ウォレット側は現在の状態 UTxO の発見、資産 UTxO の選択、datum と redeemer の構築、新状態の正しい生成まで面倒を見ることになる。
validator は UTxO が使われようとしたときに可否を判定するだけで、「48 時間経ったので自動的に鍵を変更する」という取引を自ら発生させることはない。誰かが組み立てて提出する必要がある。
ただし致命的ではない。ウォレットアプリ、リレーヤー、復旧サービスが取引を構築・提出し、validator がオンチェーンで正当性を判定すればよい。むしろ判定と実行が分離しているのは監査上の利点でもある。
ERC-4337 には Paymaster がある。Cardano でも第三者が手数料 UTxO やコラテラルを提供する取引は設計できるが、誰が取引を作るか、どの UTxO を出すか、署名順序、コラテラルの扱い、悪用防止、dApp との共通インターフェースが標準化されていない。
Cardano のウォレットは単なる支払い口座ではない。アドレスは支払い資格情報とステーク資格情報を持ち、委任、報酬引き出し、DRep 委任、投票が関わる。したがって Cardano 版スマートアカウントは、支払い鍵の復旧だけでなくステーク権限とガバナンス権限の復旧まで設計に含める必要がある。Ethereum の AA には対応する論点がない。
問題提起で終わらせず、現在の Cardano で実装可能な範囲から積み上げる。
「Account Abstraction」という Ethereum 固有の語をそのまま使ってもよいが、Cardano はアカウントモデルではないため、対外的には Recoverable Wallet ／ Programmable Wallet ／ Smart Wallet ／ Plutus Wallet のほうが誤解が少ない。既存の CIP-141 が「Plutus wallets」を名乗っている以上、その語彙に寄せるのが実際的だろう。
口座設定を表す状態 UTxO を定義する。一意性は NFT（ウォレット識別トークン）で保証し、「どれが正規の状態 UTxO か」を判別できるようにする。
状態 UTxO を毎回消費する設計にすると、第 II 部で述べた単一書き込み点の問題に直行する。通常送金では参照入力（CIP-31）として読むだけにし、消費するのは鍵の更新・復旧・ポリシー変更のときに限る。この分離が実用性を左右する。
資産 UTxO は同じウォレットの validator で保護し、取引ごとに次を確認する。正しい状態 UTxO を参照しているか、通常操作の認証を満たすか、復旧中でないか、送金上限以内か、高額送金に追加承認があるか、許可された送金先か、状態更新が正しいか。
通常状態 ↓ 復旧申請（新しい操作鍵を提示） 待機状態 ↓ 異議申立期間（24h / 48h / 7d） │ ├─ 旧端末・予備鍵が「不正だ」と取消 → 通常状態へ戻る │ ↓ 期間満了 復旧確定（primaryCredential を更新）
この段階化により、本人確認事業者の認証が漏えい・誤用された場合でも、即座に全資産を奪われることを防げる。単一の guardian が単独で口座を掌握できない構造は、ここで担保される。
公的 ID と組み合わせる場合、guardian に求められるのは資産を預かる能力ではなく、本人確認をやり直す能力である。窓口と戸籍を持つ主体はその意味で適任にあたる。カード紛失時の再発行と、鍵紛失時の復旧は構造が同じだからである。
ただし guardian にできるのは鍵の入れ替えに参加することだけで、資産を動かす権限は持たせない。そして単独の guardian（1 of 1）にした時点で、それは social recovery ではなく預託になる。しきい値の中の一票として置いて初めて意味を持つ。
guardian 3 のうち 2 ＋ 48 時間の待機 ├─ 公的機関 ： 本人確認の担い手 ├─ 家族・信頼できる第三者 └─ 自分の別端末・予備鍵 → 公的機関の署名は必要だが、それだけでは足りない → 待機中は旧端末から取消できる
逆に、公的機関でなければ扱えない場面もある。相続（死亡の事実を確認できるのは戸籍を持つ側だけ）、成年後見、法的手続きに基づく差押え。これらは「秘密鍵を持つ者が本人」という従来型ウォレットでは原理的に表現できず、プログラマブルウォレットにして初めて条件として書ける領域になる。裏を返せば、公的機関を guardian に入れることは凍結・検閲の経路を自ら設けることでもあり、利便性とのトレードオフとして意識的に選ぶ話になる。
署名用電子証明書は転居や氏名変更で失効する。復旧のアンカーをこの証明書に紐づけると、引っ越しただけで復旧経路が切れうるため、再バインドの設計が要る。また署名用電子証明書は 15 歳未満と成年被後見人には原則発行されないため、上で挙げた成年後見のケースは、この方式では逆にカバーできない側に落ちる。制度の細部は必ず一次情報を確認すること。
JPKI は「この人物が以前登録された本人と同一である」ことの確認に使い、事業者が資産を保有したり直接送金したりする設計にはしない。個人情報はオンチェーンに載せない。代わりに、認証事業者の署名、一時的な認証トークン、ゼロ知識証明、個人情報を含まない復旧承認証明のいずれかを validator が検証する形にする。マイナウォレット社も、第三者へ公開する情報を最小化するため ZK を活用したプライバシー保護機能を研究していると説明している。
パスキーは端末内の鍵管理・アクセス制御に用い、最終的な Cardano 署名は端末内の Ed25519 鍵で行う。P-256 が検証できない現状で唯一すぐ実装できる形。利用者から見た体験は生体認証で完結する。
Plutus が WebAuthn・パスキー由来の署名、またはその証明を直接検証できるようにする。P-256 ビルトインの追加、または ZK による証明が前提になる。
複数端末、ハードウェアキー、公的本人確認、社会的復旧を一つのポリシーとして扱う。
一般利用者向けには「ADA を持っていないので送金できない」も解く必要がある。
スポンサーは「1 日 N 回まで」「地域通貨の送金のみ」「特定トークンのみ」「一定額以下」「KYC 済み利用者のみ」といった条件を付けられる。重要なのは、スポンサーが資産の操作権限を持つのではなく、手数料部分だけを提供する設計にすることである。
すべてを同じ鍵にする必要はない。むしろ分離することで、「一つのシードフレーズがすべてを支配する」構造より安全にできる。
少額送金 └ スマホのパスキー 高額送金 └ スマホ ＋ ハードウェアキー ステークプール変更 └ スマホのパスキー DRep 変更 └ スマホ ＋ 追加確認 復旧 └ 公的本人確認 ＋ 予備鍵 ＋ 待機時間
台帳変更なしで、いまの Plutus と UTxO モデルだけで構築する。スクリプト管理ウォレット、主鍵＋予備鍵、2-of-3 の社会的復旧、時間制限付き鍵交換、状態 UTxO、スマートフォンアプリ、CIP-141 ベースの dApp 接続、通常の Cardano 署名方式（P-256 が使えないため）、手数料スポンサーの試験実装。この段階で「シードフレーズを失っても予備鍵や guardian で復旧できる Cardano ウォレット」を実証できる。
生体認証、複数端末、セキュリティキー、復旧通知、待機期間、送金上限、送金先制限。
認証事業者との接続、個人情報を載せない認証証明、不正復旧対策、自治体地域通貨、給付金、KYC 済みウォレット。
新 CIP の作成と、CIP-141・106・146 との統合。複数ウォレット・複数 dApp での実装、SDK、リファレンス validator、セキュリティ監査、バグ報奨金。
MVP を実装してボトルネックが明確になった場合に限り、署名方式（P-256 ビルトイン）、スポンサー取引、スクリプト効率、状態管理、ウォレット発見などのプロトコル改善を提案する。最初から「Cardano の台帳モデルでは無理」と結論づける必要はない。
対策復旧事業者単独では変更不可とし、複数要素を必須化する。オンチェーンの待機期間、旧端末からの取消、guardian の利用者選択、復旧事業者の交換可能性。
対策小さく単純な validator。形式手法とプロパティテスト、複数監査、オープンソース、段階的な利用上限、バグ報奨金、安全な移行機能。
対策アップグレード不可の固定版を用意する。移行は利用者の明示承認があるときのみ。タイムロック、マルチシグ管理、オンチェーン告知、旧バージョンから資産を直接回収できる出口。
対策プリセットを用意する。個人・簡単（本人のスマホ＋予備端末）／個人・安全（スマホ＋ハードウェアキー＋家族）／行政サービス向け（パスキー＋公的本人確認＋待機時間）／法人（担当者 3 名中 2 名＋監査担当）。
対策状態 UTxO の形式を公開し、他ウォレットへの移行を標準化する。復旧プロバイダーの交換、複数実装、オープン SDK、サービス終了時の退避取引。
2026年7月、マイナンバーカードを活用したデジタル資産ウォレット「マイナウォレット」が一般公開されました。注目すべきなのは、マイナンバーカードで本人確認できること自体ではありません。Ethereum の Account Abstraction を用い、通常時はパスキーで操作しながら、端末や秘密鍵を失った場合には公的個人認証でアカウントを復旧できる点です。
従来のウォレットは「シードフレーズを絶対になくさないでください。なくしたら誰にも復旧できません」という前提に立っています。一般利用者、高齢者、子ども、自治体サービスの利用者に、この責任をすべて負わせることは現実的でしょうか。
Account Abstraction は秘密鍵をなくす技術ではありません。秘密鍵を資産を操作する唯一絶対の条件ではなくし、パスキー、予備端末、ハードウェアキー、家族や guardian、公的本人確認、待機期間、高額送金時の追加承認を組み合わせられるようにする発想です。
Cardano でも、Plutus スクリプト、マルチシグ、時間ロック、状態 UTxO を組み合わせれば同様のウォレットは実現できます。実際に、マルチシグ鍵の CIP-1854（Active）、dApp 接続の CIP-106、Plutus ウォレットの CIP-141、登録・発見の CIP-146 という動きがあります。ただしこれらは個別の仕様にとどまり、パスキー・鍵交換・社会的復旧・手数料スポンサー・ステーキング・ガバナンス・dApp 接続を一つのスマートウォレット標準として統合するところまでは進んでいません（後者三つはいずれも Proposed）。
Cardano は UTxO モデルであるため、Ethereum のスマートアカウントをそのまま移植することはできません。一方で、資産 UTxO 群とウォレット設定を持つ状態 UTxO を、一つの論理的な口座として扱うことは可能です。たとえば ―
Cardano に必要なのは新しいウォレットアプリではなく、シードフレーズを唯一の復旧方法としない Cardano Recoverable Smart Wallet Standard を、エコシステム共通の仕様として整備することです。まずは現在の Cardano 上で、主鍵・予備鍵・社会的復旧・待機期間を備えた Plutus ウォレットを実証できます。その後、パスキー対応、手数料スポンサー、公的本人確認連携、ステーク／DRep 権限、他ウォレットへの移行、dApp 接続、複数事業者による共通実装へ広げるべきです。
Cardano はブロックチェーン自体の安全性を重視してきました。次に必要なのは、人間が鍵をなくすこと、端末を失うこと、判断を誤ることまで前提にしたウォレット設計ではないでしょうか。
Cardano は「シードフレーズをなくしたら終わり」という自己管理の形を守り続けるのではなく、自己管理性を維持したまま鍵を交換・復旧できる、Cardano ネイティブなスマートウォレット標準を優先的に整備すべきである。
足りないのは技術そのものより、問題を最優先課題として定義すること、分散した CIP を統合すること、リファレンス実装を作ること、ウォレット事業者と dApp 事業者が共通仕様を採ること、そして一般利用者向け UX として完成させることである。
CIP-141 を軸に、復旧・鍵交換・スポンサーまで含めて一つの標準へ束ねる。
状態 UTxO の読み書きと取引組み立てを、アプリが意識せず扱える層。
guardian の招待、待機中の通知、取消操作までを含む利用者向けの手順。
パスキーを直接検証するためのビルトイン。フェーズ 5 の主要議題。