Many early blockchain designs used Pedersen hashing because it is efficient inside elliptic-curve groups and pairs naturally with the same curves used for signatures. Pedersen’s security, however, inherits the discrete-logarithm assumption. Replacing it with a hash function whose security rests only on collision resistance removes that dependency. @Starknet performed this substitution for the operating-system program hash and the configuration hash that appear in the core contract. The change was limited in scope, yet it closed one concrete item on the published roadmap and demonstrated that such replacements can be executed without disrupting existing accounts. Further replacements remain on the roadmap: the state trie commitments and the derivation of contract addresses. Because these values are already committed on-chain, any change must be accompanied by a migration strategy for historical data. One approach under discussion is tooling that lets existing contracts re-derive storage keys under the new hash without manual data movement. The engineering cost is non-trivial, but it is localized and can proceed independently of the settlement layer’s own timeline. These incremental steps illustrate a practical pattern. Rather than waiting for a single quantum-safe hard fork, a network can retire elliptic-curve assumptions surface by surface, shipping each change once the implementation and migration path are ready. A public migration register that tracks the status of each surface makes the remaining distance observable rather than rhetorical.