qid-connectlisted

# Integrating qID Connect ## What you are building, and the one invariant A user proves control of a post-quantum BTX address by signing a one-time, origin-bound challenge. Your server verifies the signature and issues a session. That address is the account: first successful sign-in creates it, there is nothing else to collect. The invariant that shapes every decision below: **a qID login signature is domain-separated from transactions and can never move funds.** There is no transaction endpoint in this surface, so the worst case for a fully compromised integrator site is stolen sessions on that site, never stolen coins. Keep that line intact and you cannot build a catastrophic bug here. ## Get oriented first Ask, or work out from the codebase, three things before writing code: 1. **The runtime.** Express, Next.js, or a static site with a backend elsewhere. Each has a reference file below; read only the one you need. 2. **The exact origin users land on.** Not the domain, the origin: scheme, host, and port after every redirect. This is the single most common cause of a dead integration, and it is worth two minutes of certainty now. 3. **Whether more than one server instance will serve this**, now or later. Serverless counts. If yes, the default in-memory stores are wrong and you need a shared store from the start. Then follow the four steps. They are ordered so you always have something verifiable before you add the next piece. A developer who knows their