Trong các hệ thống không có tính năng trừu tượng tài khoản bản địa, việc thay đổi sơ đồ chữ ký được người dùng thông thường sử dụng thường có nghĩa một trong hai điều: một phân nhánh cứng ở cấp giao thức cập nhật định dạng giao dịch cho tất cả mọi người, hoặc một cuộc di chuyển hàng loạt trong đó người dùng phải chuyển tiền đến các địa chỉ mới đã triển khai sơ đồ mới. Cả hai lựa chọn đều gây ra chi phí phối hợp, rủi ro lỗi của người dùng và sự phân mảnh thanh khoản tạm thời. Trừu tượng tài khoản bản địa đảo ngược mô hình này. Vì tài khoản chính là một hợp đồng thông minh, hàm xác thực của nó có thể được thay thế thông qua một con đường nâng cấp được xác thực do logic của chính tài khoản định nghĩa. Địa chỉ và bộ lưu trữ vẫn không thay đổi; chỉ mã quyết định liệu chữ ký có hợp lệ hay không mới được cập nhật. @Starknet triển khai mô hình này làm mặc định. Các buổi trình diễn công khai đã cho thấy việc xác thực Falcon-512 đang chạy bên trong một hợp đồng tài khoản, và một ví dụ minh họa riêng biệt đã sử dụng khóa ML-DSA được lưu trong phần tử bảo mật của điện thoại. Các triển khai này chưa sẵn sàng cho người dùng thông thường vì chúng vẫn chưa được kiểm toán ở những khía cạnh quan trọng và thiếu sự hỗ trợ rộng rãi từ các ví, nhưng chúng minh họa rằng cơ chế này tồn tại. Chi phí gas để xác thực cao hơn ECDSA cổ điển, nhưng đã được chứng minh là phù hợp với giới hạn mỗi giao dịch hiện tại trong các biến thể tối ưu hóa. Công việc còn lại do đó chủ yếu nằm ngoài giao thức cốt lõi: giao diện ví phải hỗ trợ các định dạng khóa mới, các bên lưu ký phải cập nhật hạ tầng ký của họ, và người dùng phải được cung cấp các con đường nâng cấp rõ ràng mà không khóa tài khoản nếu phiên bản trung gian không được hỗ trợ. Tính linh hoạt mật mã ở lớp tài khoản làm giảm quy mô của sự thay đổi phối hợp, nhưng không loại bỏ nhu cầu về kỹ thuật cẩn thận cho toàn bộ hệ sinh thái xung quanh.