1 / 4
Before you click
Connect Freighter on Stellar Testnet
Keep one account selected, check the required XLM balance on the enrollment page, then tick the disclosure box. The button stays disabled until you do.
Hosts get a scoped ID and verdict, not the Stellar address.
Already enrolled? Use the two tabs below to compare their separate private IDs without leaving this page.
Public account
The same address can appear across services.
Challenge
single use
Origin
scoped
Wallet
withheld
Enrollment, step by step
You will approve at most two Freighter prompts, then wait for one explicit success message. The page shows the active step the entire time.
No popup? Open Freighter from the browser toolbar, unlock it, and return to the enrollment tab. Do not refresh while a signature request is open.
Before you click
Keep one account selected, check the required XLM balance on the enrollment page, then tick the disclosure box. The button stays disabled until you do.
Freighter approval 1
Freighter may ask VeilPass to read the active public address. Approve it. If you already allowed VeilPass, this prompt can be skipped automatically.
Freighter approval 2
Approve the enrollment message without switching accounts. It is an off-chain signature, not a transaction, and it cannot move your funds.
Finish
Keep the tab open while VeilPass issues and saves the credential locally. After the success message appears, open App A or App B to log in privately.
Switch between the two host tabs, compare the payloads, replay a challenge, and revoke the simulated credential. Use the live link only when you want to test the production origin.
The demo stays on this page. Switch hosts to compare the origin-scoped result.
A private member area that accepts the gate verdict without receiving a wallet address.
https://app-a.veilpass.dev
No host session yet
Compare a public wallet payload with a minimized VeilPass response.
The live login opens in a new browser tab because App A and App B need separate origins to prove that their private IDs differ.
Open live App ADefault wallet login leaks too much
A normal wallet login gives the host a public account it can reuse and inspect. VeilPass returns only the access fields the host needs.
| Host can learn | Wallet | VeilPass |
|---|---|---|
| Stellar wallet address | ||
| Public account activity | ||
| Same ID across apps | ||
| Gate eligibility verdict | ||
| Origin-scoped returning ID |
Run App A, switch to App B, then test replay and revocation. The product shows the exact point where the wallet stops.
The same wallet becomes a separate host identifier for each allowed origin.
Replay attempts hit the spent-challenge path instead of creating another session.
The host receives the verdict fields it needs and nothing that identifies the wallet.
The exact boundary
Sees the Stellar address during enrollment and signs the credential.
Checks eligibility and derives a private ID scoped to one origin.
Gets a scoped ID and verdict without the wallet address. Its verification API still receives proof and public inputs; treat them as sensitive and never log them.
The repo keeps the contract ID, test matrix, screenshots, and proof limitation notes close to the product code.
Soroban eligibility gate
Unit, e2e, a11y, build, and contract smoke are wired
Privacy model and limitations stay visible
The success result supports access control without the wallet address. The host verifier still processes proof and public inputs transiently; keep those out of logs and analytics.
{
"ok": true,
"eligible": true,
"privateAppId": "vp_appA_72f1",
"gateId": "premium-holder",
"epoch": 1,
"origin": "https://app.example",
"expiresAt": "2026-10-25T09:00:00.000Z"
}Short answers for the privacy, deployment, and proof claims that need clean edges.
No. The issuer sees the wallet during enrollment. The host verification API receives proof bytes and public inputs, which are sensitive and must not be logged, but the login result excludes the Stellar wallet address. VeilPass gives each allowed origin its own scoped private app ID and does not hide IP, timing, browser fingerprint, or later on-chain activity.
Set Vercel's Root Directory to frontend and keep the contract workspace in the repository. Run the Vercel CLI from the repository root because the linked project already applies the frontend root setting. Configure production environment values in Vercel; do not commit them.
Hosted login generates a local Noir/UltraHonk membership proof and the server verifies it with a pinned verification key. The separately labeled Simulated proof route is a non-production compatibility fixture and is never accepted by the verifier.
The successful result contains an eligibility verdict, gate ID, epoch, expiry, origin, and a private app ID scoped to that origin. The host's POST /api/verify endpoint also receives the raw proof and public inputs transiently; do not log or persist that request. Neither contains the Stellar wallet address.
Open the controlled bench, replay a spent challenge, then revoke the gate and watch verification fail.
Open the demo