This policy explains what veilnebu.la collects, why, how long it is kept, and what you can do about it. The controller is the operator of veilnebu.la. veilnebu.la is operated anonymously. There is no company behind it — no incorporation, no registration number, no registered office, no named officers — and none is waiting to be filled in later. The counterparty you deal with is simply the operator of the Service, identifiable only by the domain it runs on (veilnebu.la) and the keys it uses to sign API responses and webhooks, not by a filed legal name.
1. The wallet keeps your keys; we see addresses
The wallet is non-custodial. Your recovery phrase and private keys are generated on your device and sealed there; they are never transmitted to us. We could not disclose them to anyone — including a court — because we never receive them.
Balances and transaction history are not read by your browser from a blockchain directly. The wallet asks our API at /v1/wallet for the balances of a public address, for its history, and to broadcast a transaction you have already signed. Those requests carry no account, session, email or device identifier — a non-custodial wallet has none to send — but they do carry the public addresses being looked up and the IP address the request came from. That is the link this policy has to be honest about: our server can see that one network origin asked about a set of addresses at a certain time. It cannot see who owns them.
Our access log records the method, the path with its query string stripped, the status and the latency — not the IP, the user agent or the request body. Rate limiting keys its counter by an HMAC of the IP under a salt held only in memory and regenerated at least once a day, so the raw IP is never a key. A custom RPC endpoint or a SOCKS5/Tor proxy would keep your addresses off our server altogether; both are planned and neither is in this version.
One more limit worth stating plainly. The web wallet is JavaScript we serve, so whoever serves it — us, someone who takes over the server, or someone who can intercept TLS with a certificate they control — can change it. Your keys stay yours, but a changed page could show a different recipient or receive address. Use the mobile app for amounts you would mind losing; it is installed and updated through the app stores, not replaced on every launch.
Everything below concerns the gateway: the merchant account you use to accept payments.
2. Two account types, two very different answers
Anonymous accounts. You can create a merchant account with no email and no password. We then hold no identifying data about you at all: the session token is the only credential, and we store only a hash of it. We cannot reset it, recover it, or tell you who you are.
Email accounts. If you register with an email address we hold that address, a hash of your password, and — if you enable it — your multi-factor secrets and passkey credentials, encrypted at rest.
3. What we collect
- Account: email and a password hash, or nothing at all for anonymous accounts
- Multi-factor secrets and passkey credentials, encrypted at rest, if you enable them
- Merchant and project metadata: names, settings, hashed API keys
- Payment records: amounts, assets, networks, deposit addresses, transaction hashes, invoice status and fee breakdowns
- Ledger records: your balance, the fee split, and every entry that produced them
- Screening results: addresses screened, status, score and reasons
- Webhook destinations and delivery attempts
- Support correspondence you send us
- Server logs: a request id, the method, the path with its query string stripped, the status and the latency. Not the request body, and not the IP address or the user agent: the access log defaults to dropping both. A request that carries an x-api-key header — a merchant call, never a wallet call, which has no key — also records the first eight characters of that key as a debugging hint.
4. What we do not collect
- Identity documents of any kind — we run no identity verification
- Private keys or recovery phrases, yours or anyone’s
- Browser fingerprints, advertising identifiers, or third-party analytics
- Your customers’ personal data, except what you choose to send us on an invoice
The full inventory of what the site stores in your browser is on the cookies page, and it is an inventory rather than a summary.
5. Where blockchain data fits
Addresses and transactions we record are also, by construction, public. We did not publish them and we cannot unpublish them. Where a chain address relates to an identifiable person it is personal data, and everything in this policy applies to our copy of it — but only to our copy.
6. Legal bases (GDPR)
- Contract — account, project, payment, ledger and payout data. Without it there is no service to perform.
- Legal obligation — sanctions screening, record-keeping, and any report we are required to make.
- Legitimate interests — security telemetry, fraud and abuse prevention, service integrity. Balanced against your interests, which is why logs exclude request bodies and never record query strings.
- Consent — marketing email, if you ever opt in. Withdrawable at any time.
An anonymous account holds no personal data, so most of this section has nothing to apply to.
7. Retention — including where it is not enforced
Retention periods that are actually configured and run automatically:
- Expired authentication tokens: purged after a 30-day grace period
- Delivered webhook history: 90 days
- Failed webhook history: 365 days
- Database backups: 30 days
Account, payment, ledger, screening and audit records are retained for the life of the account and afterwards, because financial-regulation record-keeping — five to seven years under the AML and payment-services regimes — is why erasure tombstones a record rather than deleting it.
Two honest qualifications rather than a comfortable round number. No automatic purge is configured for those records, so in practice they are retained indefinitely rather than deleted at the end of a fixed term. And the audit log is append-only by application design — each entry is hash-chained to the previous one and the day’s entries are anchored with a signed digest, which makes tampering detectable, not impossible. There is no database constraint that stops an operator with direct access from writing to it.
8. Who else processes it
We use subprocessors in three categories: hosting and infrastructure, edge network and DNS, and server-side error monitoring. Error monitoring is optional and sends nothing unless the operator has configured it; there is no error-reporting SDK in your browser. A current, named list is available on request from [email protected].
Where the operator has configured a transaction-screening provider, addresses — not identities — are sent to it for screening. Which providers can be configured is set out in the AML and sanctions policy, §3.
We do not sell personal data and we do not share it for advertising.
9. Your rights
Access, rectification, erasure, portability, restriction and objection, plus the right to withdraw consent and the right to complain to a supervisory authority. The operator has no establishment in the EU or the UK, so there is no single lead supervisory authority to name here. You have the right to lodge a complaint with the data-protection authority of the country you live in regardless of where the operator is. Write to [email protected] and we will respond within one month.
Data protection: No DPO appointed. One is not required under Art. 37 GDPR for this processing: the Service runs no identity-verification process and holds no identifying data at all for most accounts (see docs/no-kyc-position.md), and where an email address exists it was supplied voluntarily at signup rather than collected as part of an onboarding process.
Paid a merchant through us without an account? The e-mail you gave at checkout is the only thing that links our records to you. Send it to the address above and we will export what we hold under it, or erase it: the invoices stay, because they are the merchant’s and our financial record, but the address is removed from them — including where an older invoice had it written into the invoice’s own description — and from any dispute you filed, along with what you wrote in it and our stored copy of the notice we sent the merchant about that dispute.
Three limits we would rather state than have you discover:
- An anonymous account cannot exercise these rights. Not because we refuse, but because we have no way to establish that the account is yours, and handing account data to whoever asks would be the larger breach.
- Erasure does not reach the blockchain. A broadcast transaction is public and permanent, and no controller can delete it.
- There is no self-service export button today. Export and operator-initiated erasure are administrative operations; ask at the address above and a person will run them. The one thing you can do entirely on your own is delete your account, which is described next.
10. Deleting your account
You can delete your own account from the mobile app or via DELETE /v1/me. It erases your email — replaced with a non-routable tombstone — destroys your password hash, revokes every session, and deletes your multi-factor and passkey credentials. It is immediate, has no grace period, and cannot be undone.
It is refused while any merchant you belong to holds a balance, refused if you are the sole owner of a merchant that still has other members, and requires your current password if you have one. Transaction and audit records survive it; where they mention your e-mail address they hold a one-way hash of it, not the address. Audit entries written before 22 October 2026 may still contain the address itself — every screen shows only the hash, but the log cannot be edited without breaking its chain. Deleting your login does not delete the merchant or revoke its API keys. The full conditions are in the Terms, §15.
11. Security
Secrets are encrypted at rest. Passwords and API keys are stored as hashes, never in a recoverable form. Your session token is held in a cookie that page scripts cannot read, and it never appears in the response body a script could intercept. None of this makes a compromise impossible, and if one occurs that is likely to result in a risk to your rights we will notify you and the supervisory authority as required.
12. International transfers
Where personal data leaves the EEA or the UK, transfers rely on adequacy decisions where one applies, and otherwise on Standard Contractual Clauses with supplementary measures. Details of the transfers in effect are available at the privacy address above.
13. Children
The Service is not for anyone under 18. We do not knowingly collect data from children, and will delete it if we learn we have.
14. Changes
We publish substantive changes here at least 30 days before they take effect, and email merchants who have given us an address. Anonymous accounts have no address to notify, so this page is the only notice you will get — check it before relying on it.
15. Contact
[email protected]
the operator of veilnebu.la