Privacy Policy

This policy explains what personal data we hold when you use dvmkit, why, who else sees it, and what you can do about it. It describes what is actually true today rather than what a template would say.

DVM Technologies Ltd, the company that operates dvmkit, is the controller of the personal data this policy describes. Contact us about anything on this page at privacy@dvmkit.com.

Most DVMs are run by independent builders, not by us. When you use one, the builder decides what happens to your job data, and their own privacy notice covers it. This policy covers what we hold: what our platform records when your requests pass through it, the jobs you send to the DVMs we run, and our website and builder accounts.

The short version

Calling a DVM requires no caller account, name or email address. The DVM sees the work you sent, how you paid, and the key you signed with, if you signed. Reusing a signing key lets a DVM recognise jobs from that key.

When a builder runs the DVM, the builder decides what happens to your job data. When we host their DVM, we store and pass on its data for them, and we do not read your jobs. We do keep records of our own: the IP address each request came from, and a record of the prepaid credit you fund or reclaim, including the key that holds it. We also use job outcomes, timing, endpoint checks and feedback to help callers compare DVMs, as sections 2 and 4 explain.

When we run the DVM, we decide what happens to your job data. Job content goes to the AI providers behind our DVMs, because that is how the work gets done.

Payments on Base and Tempo are public and permanent, because they settle on a public chain. Payments in Cashu ecash are not, by construction.

The data that identifies people by name or email address is somewhere else: the builder waitlist, and the accounts of the builders currently invited to the dashboard.

We set no tracking cookies and run no cross-site advertising. That is why the site has no cookie banner.

There is a companion page in the documentation, Privacy, which explains the architecture behind all of this and where its limits are. This page is the legal statement; that one is the honest engineering account, and they should agree.

1. What any DVM sees

Whoever runs a DVM, builder or us, necessarily sees:

• the job: its input, its parameters, and the result;
• one payment-shaped identifier, which depends on how you paid: the lock key on your ecash, the sending address on a chain payment, or the public key you signed the request with;
• if you hold a prepaid balance there, the balance and the draws against it.

A DVM you use repeatedly can tell it is the same customer coming back. That is a real limit, and it is inherent: a prepaid balance only you can spend has to be keyed to something that is durably you. Your signing key is one identity, not one per DVM. Unless you create more with dvm identity create, every job you sign carries the same key, so DVMs that compare notes can tell it is the same customer. The privacy documentation covers this in full.

Chain payments are public. A payment on Base or Tempo is visible to anyone, permanently, and neither we nor you can delete it. Cashu ecash is different: the mint that issued your tokens cannot link them to where you spent them, which is arithmetic rather than a promise.

2. When a builder runs the DVM

The builder is responsible for your job data. They decide what their DVM collects, what it is used for, which providers receive it and how long it is kept, and their own privacy notice applies to it. A builder's DVM must say who runs it and how to contact them. If you cannot find out how a builder handles your data, email privacy@dvmkit.com and we will pass your request to them.

When we host their DVM, your requests pass through our platform on their way to it, and its database, logs and traces live on our infrastructure. We handle that data only for the builder, under our data processing agreement, and we do not read your jobs. The builder's DVM receives your request as you sent it, including your IP address.

What we record for ourselves about requests to a DVM we host:

We use these records to run the platform securely and to keep each builder's accounts straight.

Service records. We record job acceptance, outcomes and timing, and check whether listed DVMs are reachable. We use these records to publish service figures and warnings and order search results. We use signing-key information to detect manipulation. These records do not include job content. Public listings do not show individual jobs or caller identifiers.

When a builder runs their DVM somewhere else, your requests do not pass through our platform and we do not observe those jobs directly. We may check a listed endpoint, and a caller can submit a job receipt with feedback as section 4 describes.

Sanctions check. To apply the sanctions restrictions in our terms of service, we check the approximate location of the IP address each request comes from, on the website, on our platform, and at every DVM we host. We refuse requests that appear to come from a sanctioned region. We do not store the location, except that our router's technical log of a refused request notes the sanctioned region. IP geolocation by DB-IP.

Legal basis: our legitimate interest in running the platform securely, giving builders an accurate account of what their DVMs have taken and owe, and helping callers compare DVMs and prevent manipulation of rankings. For the sanctions check, complying with our legal obligations under sanctions law, and our legitimate interest in not providing services into sanctioned regions.

3. When we run the DVM

The DVMs we run are cast, narrate, scrape, scribe and discover. For these, we are responsible for your job data. What we hold:

Legal basis: performing the contract with you (running the job you asked for), and our legitimate interest in keeping the service secure and working. We keep payment records to meet our accounting obligations.

4. Search, wallet pairing and feedback

Searching for DVMs. dvm search and dvm browse send your query to discover, a DVM we run, so section 3 applies to it. A natural-language search goes to an AI provider to be interpreted. To show what each result offers, your dvm tool then fetches each result's public description, so those DVMs, including builders' ones, receive a request from you.

Pairing a wallet. dvm wallet pair hands a wallet connection from your browser to your agent through our platform. We store the key that asked for the pairing, your computer's hostname so the page can show you which machine is asking, and the wallet connection itself, encrypted so that only your agent can read it. We delete it as soon as your agent collects it. A pairing nobody collects expires after 10 minutes and is deleted within the hour after that.

Sending feedback. dvm feedback sends a message to whoever runs the DVM it is about, through our platform. We store what you wrote, the DVM and job it is about, and the key you signed it with, which we also use to limit how many messages one key can send. The DVM's operator can read all of it: the builder for their DVM, or us for ours. Feedback about dvmkit itself comes to us. If you put personal data in the text, the operator will see it.

Feedback from builders. When you or your agent send feedback with dvmctl feedback send, we store the message, your builder account and organisation, and any trace ID sent with the message. The tool may also send its version, the project's SDK version, your operating system and Node.js version, the command and error code that prompted the feedback, whether it followed a failure, a first deployment, or a periodic check-in, and the DVM ID when sent from a DVM project. We use this feedback to understand and fix problems with building on dvmkit. It goes to our team, not to other builders or callers. The tool does not automatically attach source code, environment variables, credentials, or file contents; text you choose to send, including text read from a file, is the message we store.

Verified feedback. You can submit a verdict with a signed job receipt. We store your verdict, signing key and receipt, including its job details, payment references and timing. The DVM’s operator sees its own feedback and receipts. We also compare receipts submitted under the same key across DVMs to detect manipulation of feedback scores. That comparison stays private. Public listings show combined feedback scores and caller-key counts, not individual feedback or receipts. Submitting feedback is optional.

Legal basis: our legitimate interest in helping you find DVMs, pair a wallet, reach their operators, improve builder tools, and prevent manipulation of feedback.

5. When you use the website

We run cookieless, aggregate analytics on the marketing pages and the documentation. It does not identify you, does not follow you to other sites and is not used for advertising. We use it to see which pages people read.

We also send website performance measurements to our website host on the home, pricing, manifesto, and documentation pages. These describe loading speed, response to interactions, and layout movement, with the page path, browser, device and operating system, network speed, country, and the page element involved. We remove URL queries and fragments before sending them. These measurements use no cookies and do not identify you or reconstruct your browsing session. We use them to find and fix slow pages.

Website errors. We use Sentry to find and fix errors in the website, including the builder dashboard. Browser and server reports contain the error type and message, a page address with query strings and fragments removed, browser or runtime details, the software release and environment, and stack locations showing where the error occurred. Sentry also derives approximate city and country from the incoming connection, even though storing IP addresses is disabled.

We exclude request bodies, headers, cookies, user identity and arbitrary application context. We scrub email addresses and recognised credentials from messages, but an unexpected error message may still contain personal data. Reports from wallet-pairing pages are excluded. Session Replay, performance tracing and log collection are disabled; Sentry does not record your session.

Our hosting providers keep server logs, including IP addresses, to serve requests and to detect abuse.

Our website host also tells us the country and region each request appears to come from. We use that only for the sanctions check described in section 2, and we do not store it.

Legal basis: our legitimate interest in understanding how the site is used, fixing website errors, and keeping it fast and secure.

6. When you join the builder waitlist

If you submit the waitlist form we store your email address, whatever you wrote in the free-text field, where you came from, how many times you have submitted, and when we last heard from you. If you submit more than once, we keep each earlier submission rather than overwriting it, so the record accumulates.

We email you once to say you are on the list. We also record whether and when we invited you, and a single-use invitation link that expires.

We deliberately do not record your IP address here. The rate limit on that form is a single global counter rather than a per-person one, precisely so nothing is keyed to you.

We use this to contact you about builder access and nothing else. We do not send marketing to people who have not asked for it, and every email we send you will have a way to stop them.

Legal basis: taking steps at your request before entering a contract, and our legitimate interest in developing the product.

7. When you hold a builder account

Builder accounts are invite-only today. If you have one we hold your email address, your name and handle if you gave one, your session records, which version of the builder terms you accepted and when, the organisations you belong to, the DVMs you publish, and your billing records.

If you sign in with GitHub or Google, we also hold that provider's account identifier, the name and profile picture link it returns, and the access, refresh and ID tokens it supplies. We keep the name and picture link as details of your sign-in profile. We use the provider identifier and tokens to complete and support sign-in. If you only use login links, we hold none of those provider details or tokens. We keep provider details and tokens with your builder account: while it is open, then for 30 days, as set out in section 9.

We hold no password. You sign in with your GitHub or Google account, or with a one-time login link that we email to you when you ask for one.

Legal basis: performing our contract with you, and our legal obligations for tax and accounting.

8. Who else sees it

We do not sell personal data and we never will. Besides the builders described in sections 2 and 4, we share it with the service providers we rely on to run dvmkit and with anyone we are legally required to disclose it to. The providers below, apart from the plan payment service described separately, process it on our instructions and for the purposes we give them.

The AI providers behind the DVMs we run. Running your job means sending it to the service that does the work: speech synthesis for narrate, transcription and speaker separation for scribe, extraction and cleanup for scrape, and natural-language search for discover. Each receives the job content you sent to that DVM, and nothing else. Where a DVM offers a faster or higher-quality tier, or falls back when its usual provider is unavailable, more than one provider may be involved.

A page-fetching service for scrape. Retrieving a page that needs a full browser goes through a third party, which receives the URL you asked for and the page that comes back.

Infrastructure. Website hosting and analytics, our database, the servers that run the platform, the router and the DVMs, object storage for files uploaded to cast, and an email service that delivers waitlist notifications to us and acknowledgements, invitations, and login links to you. These see what passes through them: requests, logs and IP addresses, and in the case of storage, the files themselves.

Website error monitoring. Sentry (Functional Software, Inc.) receives the diagnostic reports described in section 5. Its data processing terms describe how it handles personal data. Our selected Sentry region stores these reports in the EU. This does not mean all processing stays there: Sentry and its service providers may process data elsewhere, including the United States.

Plan payments. When you pay for a builder plan, the payment service receives your organisation’s name or handle, its billing email if supplied, and account identifiers. It collects your payment details, billing address and any tax identifier, and records the plan and payments. It uses this data to process payments and manage subscriptions, and also for its own purposes, including preventing fraud, meeting legal duties and improving its services.

Two more recipients are not our processors and are worth naming separately. Cashu mints see that tokens were issued and later redeemed, but cannot connect the two. Public blockchains (Base, Tempo) receive the payment itself, which becomes permanently public. Neither is something we can undo on your behalf.

International transfers. Most of our providers are in the United States. Where personal data leaves the UK we rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or on adequacy where it applies.

9. How long we keep it

Structured diagnostic schedule. We have approved a 730-day window for sanitized platform, payment, runtime, scheduled-task, and operator-command traces. Publication precedes activation. Until activation, platform, payment, and runtime traces remain on their previous 90-day window, scheduled-task traces on 30 days, and operator-command traces on 365 days. Provider-native logs and website error reports keep their separate windows above.

For ordinary trace expiry, a named incident hold records an owner, reason, and review date and remains until explicitly released. An overdue review does not release it. Relevant source traces also remain until the service-performance summary has complete source coverage. This does not permit retaining job copies we hold as a processor for a builder beyond the maximum 90 days after a hosted DVM is destroyed. Those copies and their related job-trace linkage are removed separately even when a generic incident hold or missing source coverage remains. Existing summary facts survive; incomplete source evidence remains identified. Platform financial and security evidence is retained for its separate controller purposes and is not erased solely because a DVM is destroyed.

Job records need a straight answer. While a DVM remains in service, we use a 730-day default for caller-controlled content after a job reaches a final status. Reading a job or its messages does not restart that period. When eligible content is removed, the DVM removes the input, parameters, results, messages, temporary state, and replay-only authentication material. Content expiry preserves the job identifier, capability, final outcome, payment linkage, and signed receipt evidence. We retain these records for financial reconciliation, recovery, and verification without deleting them solely because they are old. Their retention is separate from the raw-content window.

We may retain a job's content for a support or dispute case. A hold records its reason, the operator who placed it, and a review date. It remains active until explicitly cleared, even if the review is overdue. Clearing the last active hold restores the original expiry, which may already have passed. A hold cannot restore content already removed.

An independent builder can choose a shorter or longer whole-day window for their DVM, or turn automatic age expiry off with jobRetentionDays: 0. Check that builder's policy before sending personal data. These active-service windows and holds do not extend separate deletion rules or the 90-day maximum for hosting backups, logs, and traces after destruction.

Service history and its evidence. We keep a listed service's performance history, and the evidence needed to verify and correct it, while those records contribute to its listing. We remove caller-linked evidence when that contribution ends or we uphold a deletion request. Records needed for an active investigation are kept until it is resolved. Platform financial records follow the separate rule below.

Feedback history. We keep accepted caller and builder feedback and its revisions for support, disputes, customer history and product improvement, without deleting it solely because it is old. A new verdict changes the current ranking vote and preserves earlier comments. We keep only the attribution and verification evidence needed for those purposes and review the need for personal fields annually. Upheld deletion requests apply to the current message and its revisions. Permanent service-identity withdrawal or replacement removes its feedback and proof; temporary restrictions preserve the records while preventing their use.

Business and security audit history. We keep the facts needed to explain consequential account, access, deployment, and organisation decisions: who acted, what changed, the target, time, and outcome. We do not delete these facts solely because they are old. Event-specific fields exclude credentials and raw customer or request content. Necessary personal fields remain subject to purpose review and your rights below.

We remove unnecessary IP addresses and equivalent network detail after 365 days from the event or our receipt of it, whichever is earlier. A named incident case can preserve necessary detail with an owner, reason, and review date. A review becoming overdue does not release the case. Once all cases protecting that detail are explicitly released, eligible detail is removed on the next scheduled pass. These records are separate from the diagnostic traces listed above.

Business notifications. We keep the facts behind consequential deployment, payment, restriction, subscription, API-key, reputation, and organisation-invitation notices, together with existing read acknowledgements. We do not remove that history solely because it is old or has been read. Durable messages exclude credentials, invitation links, and raw customer content. Invitation credentials expire separately. Necessary personal fields remain subject to purpose review and your rights below. Scoped cleanup removes unnecessary personal fields while retaining required business facts. A retained account identifier remains personal data.

Financial history and signing keys. We keep platform financial facts without deleting them solely because they are old. These facts let us reconcile money and explain its history. Payment services apply their own retention rules. 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. If missing or unclear information prevents us from deciding whether a key copy is still needed, we keep it until reviewed. We review the continuing need for retained personal fields at least annually. A case protects the relevant key copies until it is closed, even if its review is overdue. Once its purpose ends, those copies follow the remaining retention rules.

Reclaiming a balance does not depend on our copy of your key: the DVM handles a reclaim from its own records.

10. Your rights

You can ask us to give you a copy of your personal data, correct it, delete it, restrict or object to how we use it, or send it to someone else. Where we rely on consent you can withdraw it at any time. We apply these rights to everyone who asks, wherever you live.

Email privacy@dvmkit.com. We will respond within one month. For job data at a builder's DVM, your request is for the builder to answer, and we will pass it to them.

Two honest limits.

If you called a DVM without identifying yourself, we usually cannot tell which records are yours. UK data protection law does not require us to collect extra information purely to identify you, and we are not going to start. If you can demonstrate control of the key a record is associated with, we can act on your request; otherwise we may have to decline it, and we will explain why.

A payment that settled on a public chain cannot be deleted by us or by anyone.

If you think we have got something wrong, please tell us first. You also have the right to complain to the Information Commissioner's Office at ico.org.uk/make-a-complaint, or to the supervisory authority where you live.

11. Cookies

We set five cookies, all of them strictly necessary, which is why you are not asked to consent to them:

• site-access holds proof that you entered the site password, while parts of the site are closed.
• A session cookie keeps you signed in to the builder dashboard.
• A preference cookie remembers which organisation you last used in the dashboard.
• A signed-in marker tells the marketing pages whether you are signed in, so the bar can offer the dashboard instead of sign-in; it holds no identity.
• A sign-in state cookie makes sure a GitHub or Google sign-in finishes in the browser that started it; it expires within minutes and holds no identity.

We set no advertising, profiling or cross-site tracking cookies. Our analytics uses none either.

12. Security

We use HTTPS everywhere, store no account passwords, keep secrets out of the codebase, and restrict access to production data to those who need it. No system is perfectly secure, and we will tell you and the ICO about a breach affecting your personal data where the law requires it.

Report a vulnerability to security@dvmkit.com. What we commit to in return is in the terms of service.

13. Children

dvmkit is not for anyone under 18, and we do not knowingly collect data about children. If you believe we have, tell us and we will delete it.

14. Changes

We may update this policy. The current version is always here, dated at the top. If a change materially affects you, we will give notice on the site before it takes effect.

15. Contact

• Privacy: privacy@dvmkit.com
• Security: security@dvmkit.com

DVM Technologies Ltd is registered in England and Wales under company number 17276970, and with the Information Commissioner's Office under reference ZC222333. Registered office: 167-169 Great Portland Street, 5th Floor, London, England, W1W 5PF.