ऐसे प्रणालियों में जहाँ खाता अमूर्तीकरण मूल रूप से उपलब्ध नहीं है, सामान्य उपयोगकर्ताओं द्वारा उपयोग किए जाने वाले स्वाक्षरी योजना को बदलने का अर्थ आमतौर पर दो बातों में से कोई एक होता है: एक प्रोटोकॉल-स्तरीय हार्ड फ़ोर्क जो सभी के लिए लेन-देन के प्रारूप को अपडेट करता है, या एक बड़े पैमाने पर स्थानांतरण जिसमें उपयोगकर्ताओं को नए पतों पर धन स्थानांतरित करना पड़ता है जो पहले से ही नई योजना को लागू करते हैं। दोनों विकल्प समन्वय लागत, उपयोगकर्ता-त्रुटि का जोखिम, और अस्थायी तरलता खंडन को शामिल करते हैं। मूल खाता अमूर्तीकरण मॉडल को पलट देता है। चूँकि खाता स्वयं एक स् है, इसका सत्यापन कार्य खाते के स्वयं के तर्क द्वारा परिभाषित प्रमाणित अपग्रेड पथ के माध्यम से प्रतिस्थापित किया जा सकता है। पता और संग्रहण अपरिवर्तित रहते हैं; केवल वह कोड ही अपडेट किया जाता है जो यह निर्णय लेता है कि स्वाक्षरी मान्य है या नहीं। @Starknet इस मॉडल को डिफ़ॉल्ट के रूप में कार्यान्वित करता है। सार्वजनिक प्रदर्शनों में खाता स् के भीतर Falcon-512 सत्यापन को चलाया गया है, और एक पृथक प्रमाण-प्रस्तुति में एक मोबाइल के सुरक्षित तत्व में संग्रहीत ML-DSA कुंजी का उपयोग किया गया है। ये कार्यान्वयन अभी सामान्य उपयोगकर्ताओं के लिए उत्पादन-तैयार नहीं हैं क्योंकि वे महत्वपूर्ण पहलुओं में अभी भी समीक्षित नहीं हुए हैं और समग्र वॉलेट समर्थन की कमी है, लेकिन ये सुझाव करते हैं कि मैकेनिज़्म मौजूद है। सत्यापन की गैस लागत ECDSA से अधिक है, हालाँकि प्रभावी संस्करणों में प्रदर्शित किया गया है कि यह वर्तमान प्रति-लेन-देन सीमाओं के भीतर समाहित हो सकती है। इसलिए,शेष कार्य मुख्य प्रोटोकॉल के बाहर है: वॉलेट इंटरफ़ेस को नए कुंजी प्रारूपों का समर्थन करना होगा, संग्रहकर्ताओं को अपनी स्वाक्षरी बुनियादी संरचना को अपडेट करना होगा, और उपयोगकर्ताओं को स्पष्ट अपग्रेड पथ प्रदान किए जाने हेतु होगा,जिसमें मध्यवर्ती संस्करण के समर्थन के अभाव में खाते कुंजीबद्ध (lock) मत हों। खाता स्तर पर क्रिप्टोग्राफ़िक सजगता समन्वयित परिवर्तन के पैमाने को कम करती है,लेकिन परितंत्र के परिधि में सावधानीपूर्वक प्रयुक्त प्रयुक्ति कीआवश्यकता को हटा नहीं ।