ネイティブなアカウント抽象化が存在しないシステムでは、一般ユーザーが使用する署名スキームを変更することは、通常次のいずれかを意味する：全ユーザーのトランザクション形式を更新するプロトコルレベルのハードフォーク、またはユーザーが新しいスキームをすでに実装した新しいアドレスに資金を移動する大規模な移行である。 どちらの選択肢も、調整コスト、ユーザーのミスリスク、一時的な流動性の断片化を引き起こす。 ネイティブなアカウント抽象化はこのモデルを逆転させる。 アカウント自体がスマートコントラクトであるため、その検証関数は、アカウント自身のロジックが定義する認証済みのアップグレード経路を通じて置き換えることができる。 アドレスとストレージは変更されず、署名が有効かどうかを決定するコードのみが更新される。 @Starknetはこのモデルをデフォルトとして実装している。 公開デモでは、アカウントコントラクト内でFalcon-512の検証が実行されていることが示されており、別の概念実証では、携帯電話のセキュアエレメントに保存されたML-DSAキーが使用されている。 これらの実装は、重要な点で監査されておらず、広範なウォレットサポートが欠けているため、一般ユーザー向けの本番環境にはまだ適していないが、このメカニズムが存在することを示している。 検証にかかるガスコストは古典的なECDSAよりも高いが、最適化されたバージョンでは現在の1トランザクションあたりの制限内に収まることを確認されている。 したがって、残りの作業は主にコアプロトコルの外側にある：ウォレットインターフェースが新しいキー形式をサポートし、 Custodians が署名インフラを更新し、ユーザーに中間バージョンがサポートされていてもアカウントがロックされない明確なアップグレード経路を提供する必要がある。 アカウント層での暗号学的柔軟性は、協調的な変更の規模を縮小するが、周囲のエコシステムの慎重な設計が必要であることを排除しない。