★ Wallets & the keys question

The example app holds its own keys: it spins up an in-browser EmbeddedWallet with a Schnorr initializerless account (no deploy tx needed), persists the secret in localStorage, and pays fees through a SponsoredFPC. That's perfect for a quickstart — the visitor does nothing and still gets one private identity (and therefore one vote per election).

A real app usually shouldn't hold user keys. When an external wallet manages them, your code can't just construct an account — it has to ask the wallet what it supports first. The flow gains a step at the front:

MANIFEST — discover the wallet's capabilities and accounts before anything else. The rest (CONNECT → REGISTER → SIMULATE → SEND) is the same as the main quest; the wallet just signs and sends on your behalf instead of your app holding the secret.