> For the complete documentation index, see [llms.txt](https://polarischain-1.gitbook.io/polarischain/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://polarischain-1.gitbook.io/polarischain/11.-payment-infrastructure/11.5-wallet-ux-and-post-quantum-key-management.md).

# 11.5 - Wallet UX & Post-Quantum Key Management

`CRYSTALS-Dilithium2` key sizes are substantially larger than legacy elliptic-curve equivalents. Polarischain’s architecture explicitly addresses these differences to ensure wallet UX remains intuitive, secure, and compatible with existing user expectations.

**Key Size Comparison**

| Component  | Dilithium2    | Ed25519 (Reference) | Ratio |
| ---------- | ------------- | ------------------- | ----- |
| Public Key | `1,312 bytes` | `32 bytes`          | `41×` |
| Secret Key | `2,528 bytes` | `32 bytes`          | `79×` |
| Signature  | `2,420 bytes` | `64 bytes`          | `38×` |

**Practical UX Implications & Mitigations**

1. **QR Code Encoding:** A raw public key encodes to \~1,750 base64 characters—feasible but dense for standard QR scanners. Polaris addresses (`BLAKE2b-256` of the public key, 32 bytes) display as 64 hex or 47 Bech32 characters, matching Ethereum/Bitcoin QR readability. Full public-key QR exposure is only required at first signature.
2. **Mobile & Secure Element Storage:** 50 active wallets consume \~125 KB of secret material—negligible for modern smartphones, but requires optimized allocation in constrained hardware wallets.
3. **Transaction Broadcast Size:** Native `$POLA` transfers average \~10 KB on the wire (public key + signature + payload). Modern mobile and broadband networks handle this seamlessly; low-bandwidth contexts leverage batch settlement APIs.
4. **Paper Backup UX:** Polarischain uses **BIP39-compatible 32-byte seeds**, represented as 12 mnemonic words. Users back up the seed, not the 2,528-byte secret key. Paper backup workflows remain identical to existing industry standards.
5. **Hardware Wallet Integration:** Current PKCS#11 HSMs (Ledger, Trezor, YubiHSM) lack native Dilithium2 support. Polarischain’s modular signing backend is architected to integrate PKCS#11 seamlessly once vendor firmware updates roll out (industry target: mid-to-late 2027).
6. **Address Representation:** Addresses are derived via `BLAKE2b-256` hashing of the public key. End-user UX mirrors familiar hex/Bech32 address formats; the full public key remains hidden until first use, preserving bandwidth and privacy during initial interactions.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://polarischain-1.gitbook.io/polarischain/11.-payment-infrastructure/11.5-wallet-ux-and-post-quantum-key-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.