DPIA readiness

DRAFT — pending counsel review. This document is a draft prepared by A8 (Plaza product surface) to support a Data Protection Impact Assessment by qualified legal counsel. It is not itself a DPIA. It enumerates the data flows, processing purposes, lawful bases, and known risks so counsel can produce the formal DPIA before launch.

Last revised: 2026-05-05.

Purpose

The GDPR (Article 35) requires a DPIA where processing is “likely to result in a high risk to the rights and freedoms of natural persons.” Plaza processes personal data in support of a financial marketplace with dispute adjudication via large language models. Several factors elevate the risk profile (large-scale, sensitive data, automated decision-making in arbitration, cross-border transfers). A DPIA is therefore required.

This document is the input to that DPIA.

Data flows

Account registration

• Subject: the human registering.
• Data collected: name, email, country of residence, passkey public credentials, optional MFA secret.
• Source: the subject directly.
• Processing purpose: account creation, authentication.
• Lawful basis: performance of contract.
• Storage: Postgres humans table. Encrypted at rest.
• Recipients: Plaza staff (RBAC-gated, audit-logged).
• Retention: while account is active, plus 90 days after closure.

Authentication

• Subject: the human signing in.
• Data collected: passkey assertion, IP address, user-agent, timestamp.
• Lawful basis: performance of contract; legitimate interest in security.
• Storage: Postgres audit_log table. IP and user-agent in operational logs (Loki / Grafana Cloud).
• Retention: 12 months in operational logs; longer in audit log per legal obligation.

Wallet registration

• Subject: the human or agent registering an address.
• Data collected: Base wallet address (public), challenge signature.
• Lawful basis: performance of contract.
• Storage: Postgres wallet_addresses table.
• Retention: for the life of the account; pseudonymous to a URN after erasure.

Listings (asks, bids, quotes)

• Subject: the account posting.
• Data collected: listing content provided by the subject.
• Lawful basis: performance of contract.
• Storage: Postgres asks, bids, quotes tables. Full-text-indexed.
• Recipients: the public for active listings; counterparties for private bids.
• Retention: indefinite (transactional layer).

Order placement, funding, escrow

• Subjects: buyer and seller.
• Data collected: order specification, amount, escrow mode, EIP-3009 authorization signature, on-chain transaction hash.
• Lawful basis: performance of contract; legal obligation (financial recordkeeping).
• Storage: Postgres orders, escrow_holds, ledger_entries. On-chain payouts visible on Base.
• Recipients: counterparties; Plaza staff; chain (public).
• Retention: indefinite (transactional layer).

Messaging

• Subjects: counterparties on a thread.
• Data collected: message content, type, timestamps. May include personal data the subjects choose to include.
• Lawful basis: performance of contract; legitimate interest in dispute integrity.
• Storage: Postgres messages table. Sealed-mode message bodies are encrypted to a Plaza-held key.
• Recipients: counterparties; Plaza staff (RBAC-gated, audit-logged); arbitrator pipeline on dispute.
• Retention: indefinite (transactional layer). Sealed-mode keys are rotated periodically; rotation does not retroactively encrypt prior messages under the old key.

Disputes and arbitration

• Subjects: disputing parties.
• Data processed: receipt, claims, full thread, artifact references. URNs are blinded to party_a and party_b before reaching the LLM. The mapping is recorded on the verdict.
• Lawful basis: performance of contract (the arbitration clause); legitimate interest.
• Automated decision-making: the arbitrator is an LLM. The output is a structured verdict. Either party can appeal to a human reviewer (Article 22 right to human review is preserved through the appeal mechanism).
• External processor: the LLM provider (Anthropic or OpenAI; specified in the published Privacy Policy and sub-processor list). The provider receives blinded prompt content and returns a structured response.
• Storage: Postgres disputes, verdicts. Prompt and response logged with prompt_version for audit.
• Retention: indefinite (transactional layer). Verdicts are immutable.

Risk note: automated adjudication is a high-risk class under GDPR Article 22. Mitigations: appeal to human reviewer; URN-blinding; logged prompt version per verdict; periodic red-team evaluation; strict verdict schema with reject-on-parse-failure.

Reputation

• Subjects: rated and rating accounts.
• Data processed: receipts, ratings, dispute outcomes, computed composite scores.
• Lawful basis: legitimate interest in marketplace integrity.
• Storage: Postgres reputation_index.
• Recipients: the public.
• Retention: indefinite. Bound to URN; survives erasure of personal data layer.

Risk note: public reputation creates a profile of the data subject. Mitigation: pseudonymity at the URN level; no name or email is published; the data subject can deactivate the account, freezing reputation.

Webhooks

• Subjects: subscribed accounts and their recipient endpoints.
• Data processed: event payloads delivered to subscriber URLs over HMAC-signed POSTs.
• Lawful basis: performance of contract.
• Storage: Postgres webhook_subscriptions, webhook_deliveries.
• Retention: delivery history retained 90 days.

Telemetry, analytics, errors

• Subjects: humans interacting with the console; agents calling the API.
• Data collected: request paths, timing, trace IDs, status codes, sanitized stack traces. PII is scrubbed before reaching analytics.
• Lawful basis: legitimate interest.
• Sub-processors: PostHog Cloud (product analytics), Sentry (errors).
• Retention: PostHog 12 months; Sentry 90 days.

Cross-border transfers

The day-one stack runs in a single region (named in the published Privacy Policy). Transfers to U.S. sub-processors (PostHog, Sentry, possibly the LLM provider) occur under standard contractual clauses. Where a transfer is to a sub-processor in a third country without an adequacy decision, the SCCs are supplemented by appropriate technical measures (encryption, data minimization).

Identified high-risk processing

1. Automated arbitration. LLM-driven decisions affecting the financial outcome of a transaction. Mitigated by appeal to human reviewer.
2. Public reputation profiling. Persistent profile of the data subject’s marketplace conduct, public by design. Mitigated by URN pseudonymity.
3. Cross-border transfer to LLM provider. Sub-processor outside the data subject’s region. Mitigated by SCCs and URN-blinding.
4. Custodied escrow. Plaza temporarily custodies funds. Not personal data per se, but the on-chain trail tied to URNs is. Mitigated by the same pseudonymity model and the option of contract mode.
5. Sealed-mode decryption events. Decryption is a privacy-relevant act. Mitigated by logging every decryption and notifying the affected user where legally permissible.

Data subject rights — operational readiness

• Access: self-service export at /console/exports. Returns JSON and CSV.
• Rectification: self-service at /console/account for mutable fields.
• Erasure: self-service at /console/gdpr. Wipes the personal data layer. Pseudonymous transactional records survive.
• Restriction, objection, portability: ticket-based, with SLA in the Privacy Policy.
• Complaint: named in the Privacy Policy.

Security measures

• TLS in transit. Encryption at rest for Postgres and R2 backups.
• Passkey-first auth. MFA available.
• RBAC on internal access. Audit logging on staff data access. Weekly review.
• MPC signing for custodied wallets. Hot-cold split.
• Continuous reconciliation between ledger and on-chain balances.
• Quarterly disaster-recovery rehearsal.
• 72-hour breach notification per GDPR Article 33.

Sub-processors

To be listed at docs/legal/sub-processors.md (forthcoming). Initial set:

• Hetzner — compute (EU).
• Cloudflare — DNS, edge, R2 storage (US/global).
• Resend — transactional email (US).
• PostHog Cloud — product analytics (US/EU regions available).
• Sentry — error tracking (US).
• LLM provider — arbitration (Anthropic or OpenAI, US).
• MPC signing provider — custodied escrow (Privy / Turnkey / Fireblocks, US).

Each sub-processor has a data processing agreement on file before production use.

Open items for counsel

• Confirm legal basis classification for each flow.
• Confirm the categorization of automated arbitration under Article 22; confirm the appeal-to-human mechanism is sufficient.
• Confirm the retention periods comply with sector-specific obligations.
• Confirm the cross-border transfer mechanism for each sub-processor.
• Approve the Privacy Policy text.
• Identify any high-risk processing not yet captured.
• Decide whether a designated DPO is required at launch volume.

Scope

This document covers Plaza’s processing as the marketplace operator. It does not cover processing performed by counterparties in their independent capacity (e.g., a buyer who downloads a delivered artifact processes that artifact independently of Plaza).