Privacy Policy

Effective: 4 June 2026 · DCS Verify, a product of DCS AI Technologies L.L.C, Dubai, UAE

This policy explains what we collect, what we deliberately do not collect, and how the unusual parts of a cryptographic verification system affect your data. It is written to be as honest as the product.

1. What we collect

Who you are	What we store	Why
Verifier (checking a credential)	Nothing identifying. We count verification events (credential ID, issuer, result, timestamp) — never who verified. No account, no cookies required, standard server logs only (IP, briefly, for abuse prevention).	Network statistics, trust-score volume
API key holder	Your email and a SHA-256 hash of your key (never the key itself).	Authentication, abuse prevention, contact
Issuer	Organisation name, issuer ID, DID, contact email, sector profile.	The public registry lists real, accountable issuers
Credential subject	The claims the issuer chose to include (e.g. a name, a degree title), stored verbatim inside the signed receipt.	That is the credential — it cannot work otherwise

2. Roles: the issuer chooses what goes in a credential

For personal data inside credential subjects, the issuer decides what to include and must have a lawful basis (such as the subject's consent) to do so. We process that data to provide the service: signing, storing, and serving receipts for verification. If you believe a credential about you was issued without your consent, contact the issuer first; you may also contact us and we will review.

3. What is public by design

The registry — issuer organisations, their DIDs, and their trust-score inputs (issuance counts, revocation rates). No personal data of credential subjects.
Status lists — anonymous bitstrings. Reading one reveals nothing about any person, only that bit N of list L is set.
Network statistics — aggregate counts only.
Receipts — retrievable by their ID or content hash (unguessable values). Anyone holding a receipt or its CID can fetch and verify it; that is the product. Do not put data in a credential subject that should not be visible to whomever the credential is shown.

4. The blockchain part — what is and is not on-chain

Only hashes go on-chain. An anchor is a content hash (CID) written into a Base mainnet transaction. A hash is not reversible into the credential's contents and contains no readable personal data. On-chain data is permanent and cannot be deleted by anyone, including us. The credential contents themselves stay in our database and in copies held by the issuer and holder.

5. Deletion, revocation, and honesty about limits

Revocation marks a credential invalid for everyone, immediately, via the public status list. This is usually what people actually want.
Database deletion — issuers can request deletion of a credential's stored subject data; verification of that receipt from our store then ceases to work. We cannot delete copies of receipts that holders or third parties already have, and we cannot delete on-chain hashes.
Account deletion — email us and we delete your email and revoke your keys, except records we must keep for legal or security reasons.

6. What we deliberately do not do

We do not record who verifies a credential — verification is anonymous by design.
We do not sell or share personal data with advertisers. No advertising, no tracking pixels.
We do not use credential contents to train models.
Reputation and fraud signals are aggregate-only — never an individual's verification trail.

7. Where data lives and who touches it

Hosting and processing use: Railway (API hosting), Supabase (database), Cloudflare (website/CDN), and the public Base network (anchors). Each processes data on our instructions per their own terms. Data may be processed outside your country; we choose providers with strong security practices (encryption in transit and at rest, access controls).

8. Security

Signing keys exist only as server environment variables, never in code or the database. API keys are stored hashed. Status lists, receipts, and scores are verifiable by anyone, which means tampering is detectable by anyone — security through verifiability, not secrecy. Report vulnerabilities via dcslabs.ai.

9. Your rights

Subject to applicable law (including UAE PDPL and, where it applies to you, GDPR), you may request access, correction, deletion (within the limits in §5), or restriction of your personal data, and complain to your local data-protection authority. Contact us via dcslabs.ai; we respond within 30 days.

10. Children

The Service is not directed at children under 16. Issuers issuing credentials about minors (e.g. school results) are responsible for obtaining appropriate guardian consent.

11. Changes

Material changes will be posted here with a new effective date.