A blockchain can execute a transaction correctly even when the account owner never intended to send it. That distinction helps explain @Starknet’s approach to preparing for quantum threats. Two cryptographic components answer different questions: ▸ Account signatures: does the transaction satisfy the account’s authorization rules? ▸ STARK proofs: did the computation follow the specified rules? If an attacker could forge a signature accepted by an account, the signature check could pass and the transaction could execute exactly as programmed. A proof could correctly attest to that execution. It would not establish that the real owner intended the transfer. Starknet has two architectural foundations relevant to this problem. Its STARK proving layer uses hash-based commitments rather than relying on the elliptic-curve hardness assumptions threatened by Shor’s algorithm. Its native account abstraction allows a new account implementation to adopt a post-quantum signature verifier without a network-wide hard fork, provided it fits Starknet’s validation limits. These choices support preparation across both computation and account authorization. Full migration still involves account adoption, protocol components and Ethereum-facing dependencies; security also depends on the chosen hashes, parameters and implementations. A proof can establish that the rules were followed. Protecting ownership also requires secure rules for authorizing the transaction. Explore the architecture and migration register: quantum.starkware.co/