У системах без нативної абстракції акаунтів зміна схеми підпису, що використовується звичайними користувачами, зазвичай означає одне з двох: протокольний хард-форк, який оновлює формат транзакцій для всіх, або масове перенесення, під час якого користувачі повинні перемістити кошти на нові адреси, які вже реалізують нову схему. Обидва варіанти призводять до витрат на координацію, ризику помилок користувачів та тимчасової фрагментації ліквідності. Нативна абстракція акаунтів інвертує цю модель. Оскільки акаунт є сам по собі смартконтрактом, його функцію перевірки можна замінити за допомогою автентифікованого шляху оновлення, визначеного логікою самого акаунту. Адреса та сховище залишаються незмінними; оновлюється лише код, який вирішує, чи є підпис дійсним. @Starknet реалізує цю модель як стандартну. Публічні демонстрації показали, що перевірка Falcon-512 працює всередині контракту акаунту, а окремий прототип використовував ключ ML-DSA, збережений у безпечному елементі телефону. Ці реалізації ще не готові до використання звичайними користувачами, оскільки вони залишаються неаудитованими у важливих аспектах і не мають широкої підтримки гаманців, але вони ілюструють, що такий механізм існує. Вартість газу для перевірки вища, ніж у класичного ECDSA, але було показано, що в оптимізованих варіантах вона укладається в поточні ліміти на транзакцію. Тому залишаючася робота в основному знаходиться поза основним протоколом: інтерфейси гаманців повинні підтримувати нові формати ключів, кастодіани повинні оновити свою інфраструктуру підпису, а користувачам мають бути надані чіткі шляхи оновлення, які не блокують акаунти, якщо проміжна версія не підтримується. Криптографічна гнучкість на рівні акаунту зменшує масштаб координованої зміни, але не виключає необхідності уважного проектування оточуючої екосистеми.