Багато ранніх проектів блокчейну використовували хешування Pedersen, оскільки воно ефективно працює всередині груп еліптичних кривих і природно поєднується з тими самими кривими, що використовуються для підписів. Проте безпека Pedersen спирається на припущення про дискретний логарифм. Заміна його хеш-функцією, безпека якої ґрунтується лише на стійкості до колізій, видаляє цю залежність. @Starknet виконала цю заміну для хешу програми операційної системи та хешу конфігурації, які зустрічаються в основному контракті. Ця зміна була обмежена за обсягом, але закрила один конкретний пункт у опублікованому дорожньому плані та продемонструвала, що такі заміни можна виконати без порушення існуючих акаунтів. Додаткові заміни залишаються в дорожньому плані: зобов’язання дерева стану та отримання адрес контрактів. Оскільки ці значення вже зафіксовані в блокчейні, будь-яка зміна повинна супроводжуватися стратегією міграції історичних даних. Одним із підходів, який обговорюється, є інструменти, що дозволяють існуючим контрактам повторно обчислювати ключі зберігання за новим хешем без ручного переміщення даних. Інженерні витрати не є незначними, але вони локалізовані та можуть розгортатися незалежно від термінів власного рівня розрахунків. Ці поступові кроки ілюструють практичний патерн. Замість очікування одного квантово-стійкого форку, мережа може поступово виводити з ужитку припущення про еліптичні криві поверхня за поверхнею, впроваджуючи кожну зміну, як тільки реалізація та шлях міграції будуть готові. Публічний реєстр міграції, який відстежує статус кожної поверхні, робить залишкову відстань помітною, а не лише риторичною.