Privacy

Calling a DVM needs no account, name or email address. The provider sees your job and the key or payment identifier you use. Reusing a signing key lets a DVM recognise jobs from that key. Chain payments are public; ecash keeps issuance separate from spending. The platform uses limited job records and optional feedback to help callers compare services.

The privacy policy explains what we keep, who can read it, and how to request access or deletion.

Three places information can leak

A payment touches three parties, and each sees something different. Being specific about which is the only way to be honest about any of them.

1. Whoever issues the money

If you pay with ecash, the mint that issued it learns nothing about where you spend it. This is not a policy, it is arithmetic: your wallet blinds each token before the mint signs it, so when you later spend, the mint can confirm the signature is one of its own but cannot connect it to the moment it was issued. It never sees which provider you paid.

This holds even when you funded over Lightning. The invoice settles at the mint's node, and the tokens it then issues are unlinkable to it.

The mint's real risk is different, and it is not a privacy risk: a mint is custodial and could disappear with the balance behind your tokens. Fund light, spread across more than one, and treat any mint as a hot wallet rather than savings.

Stablecoins are the opposite trade, on purpose. Tempo and Base settle on a public chain. The recipient, the amount, and the timing are visible to anyone who looks, by design. That is the cost of deterministic on-chain settlement, and it is your agent's choice per job rather than the provider's.

2. The provider

A provider necessarily sees the work. The request goes to them over HTTPS, through our router if we host them, with nothing published anywhere, but the job itself is theirs to read: the input, the parameters, the prompt text. They also see the IP address it came from.

They also see one payment-shaped identifier, which depends on the rail: the lock key on your ecash, the sending address on a chain, or your signing key on any job where you are authenticated.

The real leak is that repeat visits are linkable. If the identifier is stable, a provider can stitch your calls to them into a history, with no account and no login anywhere. Where you hold a prepaid balance this stops being an inference and becomes explicit, because a balance only you can spend has to be keyed to something that is durably you.

That is a genuine cost and it buys something specific: a balance nobody else can spend, and a refund path that can only pay you. Paying per call keeps the looser shape, and it is always available.

Your signing key is one identity, not one per provider. Unless you create more, every authenticated job you send is signed by the same key, so two providers comparing notes can line those jobs up as the same customer. What the wallet does derive per provider is narrower and sits on the ecash rail: the refund key riding on an ecash payment comes from that provider's own identifier, so it differs at each one. Reclaiming a prepaid balance is the exception on that rail, because a reclaim pays back to the single key your wallet holds.

Separating providers is manual, and it costs you the history. dvm identity create <name> makes a second signing identity and --as <name> sends under it. A fresh identity arrives at a provider with no balance and no completed jobs behind it, so the trust ladder starts from the bottom there. On the stablecoin rails the equivalent would be a fresh address per provider, and the CLI does not rotate those for you today, so a caller who needs on-chain unlinkability should be on the ecash rail.

3. The platform

For job payments, dvmkit is not in the path at all. Money goes from your wallet to the builder's: ecash lands directly in their own wallet, stablecoins settle straight to their address. We never hold or route it.

What the platform does store is deliberately narrow. For a provider we host, it records that the provider took a payment of a given size, in a given currency, on a given rail, because that is what an accounting figure needs. A deposit, reclaim, or expiry record can carry the signing key that holds the balance, because the provider's books have to show whom it owes. Some per-job payment reports also carry a signing key. A reclaim row still omits where the money went: no refund key, no chain address. The router also logs the IP address each request came from. To apply the sanctions restrictions in the terms, the website, the platform, and the DVMs we host check the approximate location of each request's IP address and refuse a request that appears to come from a sanctioned region. The location is not stored, except that the router's log line for a refused request names the region.

What it does hold is builder-side: an email and any name or handle a builder gave us, plus their subscription billing records. If a builder signs in with GitHub or Google, we also store that provider's account identifier, the name and profile picture link it returns, and any access, refresh and ID tokens it supplies. The name and picture link are sign-in profile details; the identifier and tokens support provider sign-in. A builder who only uses login links has none of those provider details or tokens. We keep them for the builder-account period in the privacy policy. Callers are not in this account layer.

Financial history

We keep platform financial facts without deleting them solely because they are old. They include credit movements, charges, adjustments, payouts, and invoices. This history lets us reconcile money and explain what was paid.

Routine signing-key copies on credit and per-job payment records are removed after 730 days from the recorded event or our receipt of it, whichever is earlier. We keep key copies needed for unresolved balances, support or dispute cases, and required verification evidence. Missing or unclear evidence also means key copies stay until reviewed. We review the continuing need for personal fields at least annually. A case protects those copies until it is closed, even if its review is overdue.

Removing our copy of your key does not change the amounts owed or your ability to reclaim a balance from the provider. Independent providers' own records and payment services' retention rules are separate. The privacy policy gives the full retention rules.

Hosted job records

For a DVM hosted on our platform, the job's own request and response data lives in that DVM's database, which the builder controls. The platform does not read job content.

For the container DVMs we operate, caller-controlled job content has a 730-day default after the job reaches a final status. Reading a job or its messages does not restart that period. A support or dispute hold can retain the affected job until explicitly cleared, even when its review is overdue. Clearing the last hold restores the original expiry.

When eligible content expires, the DVM removes input, parameters, results, messages, temporary state, and replay-only authentication material. It keeps the job identifier, capability, final outcome, payment links, and full signed receipts as signed receipt evidence for financial reconciliation, recovery, and verification without a routine age cutoff.

Independent builders can choose shorter or longer whole-day windows, or disable automatic age expiry. Check their policy before sending personal data. Older services may not report expiry metadata. The container/Postgres controls do not imply isolate or custom-store support. These active-service windows do not extend seven-day trial recovery or the maximum 90-day lifetime of hosted copies after destruction.

Service records and feedback

The platform uses job outcomes, timing, reachability checks and optional receipt-backed feedback to help callers compare DVMs. It uses signing-key information to detect manipulation and compares submitted receipts under the same key across DVMs. That comparison stays private. Public figures describe services without showing individual caller records. Accepted feedback and its revisions stay available for support and disputes. A new verdict changes the current ranking vote while earlier comments remain. Necessary personal fields are reviewed annually, and explicit deletion and service-identity controls still apply. The privacy policy explains what we keep and who can read it.

Business audit history

The platform keeps the actor, action, target, time, and outcome of consequential account, access, deployment, and organisation decisions without an age-only cutoff. Event-specific fields exclude credentials and raw request or customer content. Necessary personal fields remain subject to purpose review and rights requests.

Unnecessary IP addresses and equivalent network detail expire after 365 days from the event or platform receipt, whichever is earlier. A named incident case preserves necessary detail with an owner, reason, and review date until explicitly released. An overdue review does not release it. The next scheduled pass removes eligible detail after all cases release. Authoritative audit facts are separate from diagnostic traces, whose current windows are listed in the privacy policy.

Business notifications

We keep the facts behind consequential deployment, payment, restriction, subscription, API-key, reputation, and organisation-invitation notices, together with existing read acknowledgements. Their age or read status does not erase that history. Durable messages exclude credentials, invitation links, and raw customer content. Invitation credentials expire separately.

Necessary personal linkage remains subject to purpose review and your rights. Scoped cleanup removes unnecessary personal fields while preserving required business facts; a retained account identifier is still personal data. The privacy policy states the retention rule.

Website error reports

The website, including the builder dashboard, sends browser and server error reports to Sentry so we can find and fix problems. These contain error messages, page addresses without query strings or fragments, browser or runtime details, software release and environment, and stack locations. Sentry derives approximate city and country from the incoming connection, even with IP storage disabled.

Request bodies, headers, cookies, user identity and arbitrary application context are excluded. Messages are scrubbed for email addresses and recognised credentials, but unexpected text may still contain personal data. Wallet-pairing reports are excluded. Session Replay, performance tracing and log collection are disabled. The privacy policy explains the recipient and transfer arrangements.

Where the limits are

Three limits, stated plainly:

A provider you use a lot knows it is you. Not who you are, but that the same counterparty keeps returning. Prepaid balances make this structural.

Timing is not covered by cryptography. A payment that moves at the moment a job runs correlates the two, however well blinded the payment is. Prepaying dilutes this by turning twenty payments into one, which is a real improvement, not a fix.

Key rotation is manual. Stronger unlinkability today means a second signing identity, rotating your wallet mnemonic and re-funding, or connecting fresh keys on the stablecoin rails. Nothing rotates on its own, and no setting turns it on.

Where to go next

• Security: the keys underneath this, and what must never be relayed.
• Wallets: choosing the rail whose privacy properties you want.
• Credits: the balances that trade pseudonymity for cheaper small jobs.
• Payments: how a job gets paid in the first place.

Structured diagnostic traces

We have approved a 730-day window after sanitized diagnostic traces end, covering platform, payment, runtime, scheduled-task, and operator-command diagnosis. Publication comes before activation. Until activation, the previous 90-day platform/payment/runtime, 30-day scheduled-task, and 365-day operator-command windows remain. Provider-native logs and website error reports have separate windows in the privacy policy.

Ordinary expiry respects named trace holds until explicitly released, including overdue reviews, and retains relevant sources until service-performance summaries have complete coverage. Job copies we hold for a builder, and their related trace links, still expire within 90 days after a hosted DVM is destroyed, even with a generic incident hold or incomplete coverage. Summary facts survive and incomplete source evidence remains identified. Records we keep for our own financial and security purposes follow their separate rules.