The Arc mainnet documentation has added post-quantum wallet signature support based on SLH-DSA-SHA2-128s, but it uses an optional mode.

This detail is worth looking at more than the phrase “anti-quantum”: whether the security upgrade can be implemented depends on whether wallets, hardware devices, and applications can migrate together.

The real threat of quantum computing is public-key cryptography. If, in the future, an attacker can derive private keys from public keys, they could forge transaction signatures. For long-term RWA holdings and institutional wallets, the question isn’t whether they will be broken today, but whether the keys exposed now and the on-chain data can remain secure until the migration is completed.

Arc’s approach is to first provide accounts with a new signing path, then gradually handle privacy data, node communication, and validator signatures. This is more realistic because post-quantum signatures are usually larger than traditional signatures, and hardware wallets, MPC, custody systems, and transaction encoding all need to be re-adapted.

So when users see “Support for post-quantum signatures,” they shouldn’t just look at the algorithm name—they also need to confirm three things: whether the wallet can create and restore new accounts, whether the hardware or custody system supports it, and whether old assets can be transferred safely during the migration.

The Arc documentation also clearly reminds that hardware wallet support takes time, and standards and tooling are still evolving.

Post-quantum security isn’t a one-time upgrade button, but a process of maintaining compatibility with legacy systems, migrating assets, and replacing infrastructure. For RWA, whether you can smoothly “swap keys” matters just as much as which algorithm you choose.

#Arc #WalletSecurity #PostQuantumCryptography