Draft · Devnet preview · Updated November 7, 2026
Privacy Policy
What Veilpay records, why it records it, and what remains public. This draft describes the current Solana devnet preview, not a future privacy protocol.
About this draft
Operator identity, contact details, applicable jurisdiction, processing grounds and a verified retention schedule have not yet been supplied. This document is incomplete and is not a final public-launch privacy notice.
Account and agent data
Signing in supplies your public wallet address and a signed authentication challenge. The service records your wallet address, account identifier and session-token hash. It stores agent names, public addresses, budget limits, approved vendor origins and recipients, pause status and revocation status.
Agent access tokens are stored as hashes. Agent signing keys are generated by the service and stored encrypted. The running service can decrypt those keys to authorize payments. Your connected wallet's seed phrase and private key are not requested by the sign-in flow.
Payment records
For payment authorization and reconciliation, Veilpay records the agent, request identifier, request fingerprint, resource URL, amount, recipient, signed payment payload, transaction message, status and any verified transaction signature. The SDK makes requests to the merchant directly; the payment service does not need the purchased response body.
Resource URLs can contain sensitive information. Do not place passwords, personal data or API secrets in URLs, agent names or payment memos. The SDK computes a request fingerprint; it does not make merchant content private.
Why this data is used
The service uses these records to authenticate wallet ownership, separate accounts, enforce spending rules, prevent duplicate authorizations, reconcile receipts and investigate failures. Rule checks can automatically reject a payment when a budget, recipient or pause condition is not satisfied.
Cookies and infrastructure
The dashboard uses an HTTP-only session cookie named veilpay_session, with a 24-hour lifetime and SameSite=Strict. It uses Secure when the configured origin is HTTPS. Logging out removes the current session. Blocking this cookie prevents signed-in use.
Hosting, database, RPC and wallet providers may receive connection metadata such as IP addresses and request times. A production provider inventory, storage locations and any international-transfer safeguards must be confirmed before launch. These details are not yet finalized.
Public chain, independent vendors
Solana addresses, transfers, amounts and timing are publicly observable. Veilpay does not currently provide a shielding pool, unlinkability or encrypted onchain transfers. Calling the product privacy-oriented does not change this limitation.
Merchants receive the requests you send and the payment payloads needed to settle. RPC providers receive blockchain queries or transactions. Wallet software and merchants operate independently and have their own policies. Public blockchain history cannot be erased by deleting an account.
Retention and controls
Authentication challenges expire after five minutes; expired challenges are removed when another challenge is created. Sessions expire after 24 hours, but expiry is not the same as database deletion. The current build has no scheduled cleanup for expired sessions, rate-limit rows, account records or payment history. A retention and backup-deletion process is a release requirement.
You can edit agent policies, pause new authorizations and sign out. Account deletion and data export are not yet available in the dashboard. Depending on applicable law, you may have rights to access, correct, erase, restrict or object to processing, receive portable data, and complain to a supervisory authority. A verified contact channel must be published before public launch.
Changes
This draft must be reviewed when the operator, providers, network, retention rules or payment architecture change. No claim of regulatory compliance or guaranteed anonymity is made by this preview.