Reference project
Two-origin host example
Run the complete App A and App B host integration, inspect each responsibility in source, and verify how the public SDK connects to real server-owned routes.
Example project and setup
The runnable two-origin reference project is in frontend/examples/two-origin-dapp/README.md. From frontend/, install dependencies with npm ci, generate the local scaffold using npm run env:local, then run npm run dev. Open app-a.localhost:3000/host/app-a and app-b.localhost:3000/host/app-b. The local scaffold does not provision PostgreSQL, owner keys, or a contract-synchronized credential root; use an operator-configured deployment for live wallet-backed login.
Browser client
App A and App B use @veilpass/sdk from a button click. It opens the configured login popup, validates the exact origin and popup source, posts one challenge and one proof to the host origin, and returns only a minimized verified result. It never returns a wallet address or raw proof to the page.
Host challenge, verify, and session
The example's /api/challenges route validates trusted origin and gate, then issues a durable one-use challenge. /api/verify reads current gate policy, calls the pinned cryptographic verifier, atomically consumes the challenge and nullifier, and sets a host-only HttpOnly cookie only after successful verification. /api/session restores that host session after reload.
Compare origins
Use one disposable enrolled credential to sign in to App A twice, then App B once. App A keeps the same privateAppId for the same credential and epoch; App B returns a different one because its normalized origin is bound into the proof. Each hostname has its own host-only session cookie.
Application adapters remain yours
The repository contains a working integration, not a turnkey hosted backend package. @veilpass/sdk is a browser popup client. @veilpass/server exposes proof policy verification primitives. Your app still owns durable storage, chain and revocation reads, the pinned proof key, abuse controls, route security, and its session system. Follow the example source and replace its deployment-specific policy and infrastructure before enabling your own host.
Automated and live verification
Run npm run test:system and npm run pack:check from frontend/. Browser tests use controlled fixtures for repeatability; production:acceptance checks public health and origin binding but does not enroll or sign a wallet. Replay, expiry, revocation, and live origin-separated login evidence is dated in the repository's live acceptance checklist.