ایسے نظاموں میں جہاں اکاؤنٹ ایبسترکشن کا اصلی سپورٹ نہیں ہوتا، عام صارفین کے استعمال کی جانے والی سائنچر سکیم کو تبدیل کرنا عام طور پر دو چیزوں میں سے ایک کا مطلب ہوتا ہے: ایک پروٹوکول سطح کا ہارڈ فورک جو ہر کسی کے لیے ٹرانزیکشن فارمیٹ کو اپڈیٹ کرتا ہے، یا ایک بڑی منتقلی جس میں صارفین کو نئے ایڈریسز پر فنڈز منتقل کرنا پڑتا ہے جو پہلے سے ہی نئی سکیم کو لاگو کرتے ہیں۔ دونوں اختیارات میں تعاون کے اخراجات، صارف کے غلطی کا خطرہ، اور عارضی لکویڈٹی کا تقسیم شامل ہے۔ اصلی اکاؤنٹ ایبسترکشن ماڈل کو الٹ دیتی ہے۔ چونکہ اکاؤنٹ خود ایک اسمارٹ کنٹریکٹ ہے، اس کا ویلیڈیشن فنکشن اپنے اپنے منطق کے ذریعے تعریف شدہ تصدیق شدہ اپڈیٹ پاتھ کے ذریعے تبدیل کیا جا سکتا ہے۔ ایڈریس اور اسٹوریج غیر متغیر رہتے ہیں؛ صرف وہ کوڈ جو فیصلہ کرتا ہے کہ سائنچر درست ہے یا نہیں، اپڈیٹ ہوتا ہے۔ @Starknet اس ماڈل کو ڈिफالٹ کے طور پر لاگو کرتا ہے۔ عوامی ڈیمو نے اکاؤنٹ کنٹریکٹ کے اندر Falcon-512 ویریفکیشن کو چلایا ہے، اور ایک الگ پروف آف کنسپٹ نے فون کے سکیور ایلمنٹ میں محفوظ ML-DSA کلید استعمال کی ہے۔ ان عملدرآمدات ابھی تک عام صارفین کے لیے پروڈکشن ریدی نہیں ہیں کیونکہ وہ اہم پہلوؤں میں آڈٹ نہیں ہوئے ہیں اور ان کا وسیع والٹ سپورٹ نہیں ہے، لیکن وہ ظاہر کرتے ہیں کہ یہ مکانزم موجود ہے۔ ویریفکیشن کا گاس لاگت معمولی ECDSA سے زائد ہے، لیکن آپٹمائزڈ ورژن میں اسے موجودہ ٹرانزیکشن لِمٹس کے اندر فٹ کرنے کا ثبوت دِلایا جا چکا ہے۔ اس لئے باقی کام بنیادی پروٹوکول سے باہر ہے: والٹ انٹرفيسز کو نئے کلید فارمٹس کو سپورٹ کرنا چاہئے، کسٹوڈینز کو اپنے سائننگ انفراسٹرکچر کو اپڈیٹ کرنا چاہئے، اور صارفین کو واضح اپگرید پاتھ فراہم کئے جانے چاہئے جن میں درمیانی ورژن کے سپورٹ نہ ہونے پر اکاؤنٹس لوک نہ ہو جائیں۔ اکاؤنٹ لیر پر کرپتوگرافک اجائلٹی تعاون والے تبدیلی کے سائز کو کم کرتی ہے، لیکن ماحول کے اردگرد دقت سے منصوبہ بندی کی ضرورت کو ختم نہیں کرتی۔