Privacy notice

What we collect

• Your email address and the workspace / project metadata you create.
• Telemetry events from the chainkit SDK: chain, network, operation name, provider name, success/failure, latency, retry attempts, and an error class (e.g. rate_limit, timeout).
• Scoring events from the SDK's provider scoring engine: provider name, event type, score-after value, response-time milliseconds.
• Whatever the SDK explicitly attaches via cloudagent.WithOperationMetadata (see "Caller-controlled fields" below) and the raw upstream error text on a failed call.
• Standard request metadata for the dashboard (IP and user agent on sign-in, retained only as long as the session).

What the ingest envelope rejects

On the top-level event envelope — the chain, network, operation, provider, attempts trace, and score-event subtree — the ingest endpoint enforces a hard-coded banlist. A property name matching address, xpub, tx, amount, sat, wif, or anything containing key is rejected with HTTP 400. This is the defence against an SDK accidentally adding a wallet field to a telemetry record.

Caller-controlled fields (read this)

Two specific places bypass the banlist and store whatever you send, byte for byte:

• Operation metadata. When you call cloudagent.WithOperationMetadata(map[string]any{…}) the contents of that map are stored verbatim in the event row's metadata column and displayed as a key/value table in the explorer drawer. The banlist is intentionally skipped on this subtree — it's a developer-facing escape hatch for troubleshooting context (correlation ids, internal request ids, feature-flag values, etc.).
• Upstream error text. When a provider call fails, the SDK ships the raw err.Error() string from the upstream provider in the event's err_msg field. Provider error responses occasionally echo back the address or transaction id that failed, so anything the provider chose to put in the error text lands here too.

Treat both fields as "anything you put here, you'll see again in the dashboard, and so will anyone you share a session with." Don't put wallet addresses, transaction ids, signed payloads, customer PII, or key material in operation metadata. If you need an opaque correlation id, hash it client-side before attaching.

A future paid-tier setting will let projects opt in to "strict mode" that re-runs the banlist over the metadata subtree and redacts upstream error text. Until then, the responsibility is the operator's.

Who is the controller

chainkit is established in Greece (Hellenic Republic) and is the controller of the personal data you give us directly: your email address, password hash, MFA secret, billing identity, and session metadata. Our lead supervisory authority is the Hellenic Data Protection Authority (dpa.gr).

For the telemetry your application's SDK pushes to us, chainkit is a processor — your workspace is the controller, and we process that data on your documented instructions under a Data Processing Agreement. The DPA template lives on the trust page; ask [email protected] for a counter-signed copy.

Merchant payments — your customers' data

If you use the merchant-payments product (xpubs, invoices, receipts), some of your customers' personal data flows through chainkit-cloud. The roles for this stream are different from the rest of the service.

• You are the controller of your customers' personal data — the email and name they enter on the customer-facing invoice page, the IP address attached to that page-view, and the on-chain transaction ids that settle the invoice.
• chainkit-cloud is the processor for that data, acting on your documented instructions under the same DPA template linked above.
• No private keys, ever. The merchant-payments product is non-custodial by construction. We accept only extended public keys (xpub / ypub / zpub or testnet equivalents) and derive a fresh receive address per invoice. xprv / yprv / zprv submissions are rejected at the API and form layer. Settlement is direct to your wallet — chainkit cannot sweep funds, freeze a payout, or recover an address if you lose your seed.

What we store for your customers: The customer-facing invoice page collects (optionally, one-shot, capped at one email + one name per invoice) the customer's contact details so the merchant can email a receipt. The fields land on the merchant_invoices row tied to that invoice. Nothing else about the customer is captured — no analytics cookies are set on /p/:public_id, no third-party tracking pixels load.

Right to be forgotten. When one of your customers asks you to delete their data, you can wipe their email + name across every invoice in your project via the dashboard's Privacy page (Payments → Privacy → Forget customer). The endpoint NULLs customer_email and customer_name across every matching row; the invoice row itself stays so your tax record is preserved. The operation is idempotent and irreversible.

What we do NOT do: we do not contact your customers, do not retain their PII for any purpose beyond serving the invoice page back to them and (optionally) emailing them their receipt, do not profile them, do not share their contact details with any third party (other than the email-delivery subprocessor when you trigger a receipt send), and do not sell or rent their personal data under any circumstances. The security page documents the non-custodial posture in technical detail.

Lawful basis

Under GDPR Article 6 we name a lawful basis for each processing purpose:

• Account, billing, MFA, sessions: Article 6(1)(b) — necessary for the contract you enter into when you create an account.
• Customer telemetry processing: Article 6(1)(b) — necessary to perform the SaaS contract; we act as your processor under Article 28.
• Security, abuse prevention, audit logs: Article 6(1)(f) — legitimate interest in keeping the service available and detecting unauthorised access. Balanced against your reasonable expectations as a B2B service user.
• Transactional email (verification, password reset, invitations): Article 6(1)(b) — necessary to deliver the contracted service.
• Legal obligations (tax records, court orders): Article 6(1)(c) when a binding obligation applies.
• Product analytics (PostHog): Article 6(1)(a) — consent, captured via the cookie banner on first visit. Decline keeps everything off; no events are recorded and no analytics cookies are set. You can change your mind from Settings → Privacy & data.

Retention windows

Retention is set to the minimum compatible with the product's purpose (GDPR Article 5(1)(e), data minimisation):

• Raw events — 7 days by default. Enough for per-event drill-down and the explorer's "what just happened?" question.
• 1-minute aggregates — 30 days. Powers charts, alerts, budgets. No raw identifiers.
• 1-hour aggregates — 13 months. Powers year-over-year baselines. No raw identifiers.
• Sessions — 30 days from login, or until logout, whichever comes first.
• Invitations — 7 days after the link expires; accepted invitations stay as an audit-trail join row.
• Billing records — kept for the period required by Greek and EU tax law (currently 10 years).
• Backups — 14 daily + 8 weekly Postgres snapshots, encrypted at rest. Deleted data can persist in backups for up to ~70 days before the relevant snapshot is rotated out. Backups are restore-only — we do not query them.
• Application logs — 90 days. Request method, path, status, latency, client IP; never request or response bodies.

Paid plans can extend the raw event window once paid billing goes live; the aggregate windows are global.

International transfers

Our infrastructure (Postgres, Redis, the cloud-srv binary) runs on njalla VPS in Sweden — inside the EU/EEA, no transfer mechanism required. The PostHog analytics tool we use is hosted on PostHog's EU instance (Frankfurt, Germany) — also inside the EU/EEA, no transfer mechanism required. Five subprocessors are US-based:

• Vercel — marketing site + console frontend hosting. Receives request logs (IP, user agent, path) on every page view. Transfer basis: Standard Contractual Clauses (SCCs, 2021/914 Module 2) and EU-US Data Privacy Framework certification.
• MailerSend — transactional email (verification, password reset, invitations, billing notices). Transfer basis: Standard Contractual Clauses.
• Stripe — card billing. Receives a Stripe customer id, subscription id, and the billing email; card data never reaches us. Transfer basis: Standard Contractual Clauses and EU-US Data Privacy Framework certification.
• OpenNode — Bitcoin / Lightning invoice processing. Receives the invoice id and charge metadata; no PII beyond what's needed to settle the payment. Transfer basis: Standard Contractual Clauses.
• Sentry — application error monitoring. Receives stack traces, request method + path, IP, and user agent on errors; request and response bodies are stripped before transmission. Transfer basis: Standard Contractual Clauses and EU-US Data Privacy Framework certification.

Where we transfer personal data outside the EEA, the receiving party is bound by one or both of the mechanisms above. Copies of our SCCs are available on request to [email protected].

How we store it

Postgres + TimescaleDB on a private VPC; no public database endpoint. MFA secrets and invitation tokens are AES-256-GCM at rest. API keys are stored as prefix(8) + sha256(secret) — we cannot reveal a lost key. Passwords are bcrypt-hashed with a per-row salt.

Subprocessors

A current subprocessor list, with transfer basis and processing purpose, lives on the trust page. We commit to notifying account owners by email at least 30 days before a new subprocessor starts processing personal data, so you have time to object.

Your rights

Under GDPR (and analogous regimes — UK GDPR, California CPRA, etc.) you have:

• Right of access (Article 15) — request a copy of the personal data we hold about you. The console's export buttons cover this for telemetry data; email us for account/billing data.
• Right to rectification (Article 16) — fix inaccurate or incomplete data. Your password is changeable from Settings → Security; workspace / project names and slugs are editable from the respective console pages. For corrections to your email or any other field that isn't directly editable yet, email [email protected].
• Right to erasure / "right to be forgotten" (Article 17) — delete your account from settings; we purge raw events, aggregates, and config history within 30 days. Aggregate rows that contain no personal identifier may persist as anonymous counts.
• Right to restriction (Article 18) — ask us to pause processing while a dispute is open.
• Right to data portability (Article 20) — export your data in a machine-readable format. The console exports raw events as JSON and aggregates as CSV.
• Right to object (Article 21) — object to processing based on legitimate interest. We'll stop unless we can show a compelling overriding ground.
• Rights regarding automated decision-making (Article 22) — none apply because we don't profile, score, or make automated decisions about you.
• Right to lodge a complaint with a supervisory authority — for Greek/EU customers, the Hellenic Data Protection Authority. For other EU jurisdictions, your local authority.

The console exposes self-service affordances for two of the most-asked-for rights: access & portability (Article 15 & 20) and erasure (Article 17). Both live on Settings → Privacy & data: download a zip of your workspace's data, or delete your account with a single confirm. For the other rights — rectification, restriction, objection — email [email protected]. We respond within 30 days; complex requests can be extended by 60 days with notice under Art. 12(3).

Verifying your identity

When you exercise a data-subject right by email, we may ask you to confirm the request from the email address on file or to provide additional information that lets us match the request to an account, before we act on it (GDPR Art. 12(6)). This is to prevent account takeover through the privacy channel. We use the minimum information necessary and discard it once the request is closed.

Children's data

chainkit cloud is a business-to-business product intended for use by adults administering blockchain applications. We do not direct the service to children and do not knowingly collect personal data from anyone below the applicable age of digital consent — 16 in most EU member states (15 in Greece under Law 4624/2019 Art. 21), 13 in the United States under COPPA. If you believe we have inadvertently collected data from a child, email [email protected] and we will delete the account on confirmation.

Marketing email

We send transactional email only — email verification, password reset, workspace invitations, alert notifications you configured, and account-critical notices (security incidents, subprocessor changes, material privacy-notice updates). These are necessary for the contract under Art. 6(1)(b) and cannot be opted out of while your account is active.

We do not currently run a marketing newsletter. If we start, it will be opt-in, with a one-click unsubscribe link in every message and a separate consent toggle in account settings.

California (CCPA / CPRA) notice

For residents of California: the personal data we collect is described in "What we collect" above; we do not collect sensitive personal information beyond the password hash and MFA secret that secure your account. Categories collected, per CCPA classification:

• Identifiers (email, account ID).
• Internet or other electronic network activity information (session metadata, application logs).
• Commercial information (subscription status — once paid billing launches).

We do not sell or share your personal information. "Sell" and "share" carry the specific meanings given in California Civil Code §1798.140 — including share for cross-context behavioural advertising. Because we do not engage in either, no "Do Not Sell or Share My Personal Information" link is required.

California consumers have the right to know, to delete, to correct, to limit use of sensitive personal information, and to non-discrimination for exercising these rights. The rights overlap one-to-one with the GDPR rights enumerated above, and the same self-service flows and contact email ([email protected]) apply. We respond within 45 days; the Attorney General's office may extend that by another 45 days for complex requests with notice.

Breach notification

If we become aware of a personal data breach that is likely to result in risk to your rights and freedoms, we will notify the Hellenic DPA within 72 hours under GDPR Article 33, and notify affected customers without undue delay under Article 34. Our internal runbook for breach handling is summarised on the trust page.

Contact

Email [email protected] for anything privacy-related. See also the security and terms pages.