Human Oracles — GDPR Records of Processing Activities
Version 1.0 · Last reviewed: 22 February 2026 · Next review: 22 February 2027
This document constitutes the
Records of Processing Activities (RoPA) maintained by
Human Oracles as required by Article 30 of Regulation (EU) 2016/679
(GDPR) and Article 30 of the Polish Act on Personal Data Protection
(RODO). It also includes the
Legitimate Interest Assessment (LIA) supporting
processing activities grounded in Article 6(1)(f) GDPR. This document is
maintained internally and published for transparency. It is subject to
annual review and updated whenever a new processing activity is
introduced or an existing activity materially changes.
- Data Controller
- Human Oracles (sole trader / JDG, Poland)
- Contact
- rongan@humanoracles.xyz
- Establishment
- Republic of Poland, European Union
- DPO
- Not appointed (fewer than 250 employees; processing is not systematic large-scale monitoring of data subjects; no mandatory DPO trigger under Art. 37 GDPR applies). Contact for all data protection matters: rongan@humanoracles.xyz
- Last reviewed
- 22 February 2026
- Next review
- 22 February 2027 (or sooner on material change)
1. Records of Processing Activities (RoPA)
The following table lists every distinct processing activity carried out by Human Oracles as data controller. Each entry identifies the purpose, the categories of data subjects and personal data involved, the legal basis, recipients, and retention period, as required by Art. 30(1) GDPR.
Activity 1 — Agent Account Registration & Management
| Field | Detail |
|---|---|
| Purpose | Create and maintain agent (developer/API user) accounts; issue API keys; manage account lifecycle including inactive account cleanup |
| Categories of data subjects | Human developers who register agent accounts on behalf of automated systems or for personal use |
| Categories of personal data | Contact email address; SHA-256 hash of API key (raw key never stored); API key prefix for display; account creation and last-active timestamps; account status; usage counters; rate tier |
| Legal basis | Art. 6(1)(b) — performance of a contract (account creation is a prerequisite for using the Service); Art. 6(1)(f) — legitimate interest (abuse prevention, inactive account hygiene) |
| Recipients | Microsoft Azure (infrastructure hosting); no other recipients |
| Retention | Active accounts: retained while account is active. Inactive accounts (no paid question within 14 days of registration): auto-deleted after 14 days. On erasure request: account deleted; email pseudonymized in payment records if legally required |
| International transfer | Microsoft Azure EU region (primary); SCCs apply for any US support access |
| Special category data | None |
Activity 2 — Question Submission & Human Oracle Response Delivery
| Field | Detail |
|---|---|
| Purpose | Core service delivery: receive questions from API users, route to Human Oracles, store responses, and deliver them back to the agent via polling or webhook |
| Categories of data subjects | Human developers who submitted account-linked questions; any natural persons about whom information is included in question text or context by the submitter (third-party data subjects) |
| Categories of personal data | Question text (up to 2,000 chars — may contain self-disclosed personal data, emotional or psychological information submitted voluntarily by the submitter); category; preferred languages; free-form context object; client_agent_ref; metadata; in_reply_to thread references; timestamps; Oracle response text |
| Legal basis | Art. 6(1)(b) — contractual necessity (delivery of the paid service). Where question content contains special category data (e.g., health or mental-state information) voluntarily submitted: Art. 9(2)(a) — explicit consent implied by voluntary disclosure, or Art. 9(2)(e) — manifestly made public by the data subject |
| Recipients | Human Oracles (operators) — see Section 4 of Privacy Policy for scoping; Microsoft Azure (storage and processing) |
| Retention | 90 days from creation — automatic TTL deletion in Cosmos DB |
| International transfer | Microsoft Azure EU region (primary) |
| Special category data | Potentially yes. Questions may voluntarily contain information about health, mental/emotional state, or other Art. 9 categories. This is addressed in the DPIA (see breach/dpia page). Mitigation: content policy blocks attempts to extract third-party PII; Oracle data access is scoped; question content is not shared with any third party beyond the named operator |
Activity 3 — x402 Payment Processing & Accounting Ledger
| Field | Detail |
|---|---|
| Purpose | Verify USDC payments on Base blockchain; create immutable payment event records; maintain accounting ledger for Polish tax compliance; daily reconciliation; monthly accounting export |
| Categories of data subjects | Human developers whose blockchain wallet address is linked to a payment; natural persons whose PLN-equivalent transaction records appear in the accounting ledger |
| Categories of personal data | Blockchain wallet address (sending wallet — pseudonymous but may be linkable to a natural person); on-chain transaction hash; USDC amount; payment timestamp; PLN equivalent; FX rate source and timestamp; payment status; accounting document reference |
| Legal basis | Art. 6(1)(b) — contractual necessity (payment is required to create a question); Art. 6(1)(c) — legal obligation (Polish accounting law / ustawa o rachunkowości requires 5-year minimum retention; combined with VAT lookback: 7 years) |
| Recipients | CDP Facilitator / Coinbase (payment verification only — transaction data); Microsoft Azure (storage); accountant / tax advisor (aggregated export, no individual personal data beyond what is legally required) |
| Retention | 7 years from transaction date — mandatory legal retention. Cannot be shortened at individual request. Where erasure is requested: account identifiers pseudonymized within payment records to the extent technically feasible while preserving accounting integrity |
| International transfer | CDP Facilitator / Coinbase (US) — SCCs; Base blockchain is a global public ledger (wallet address and tx hash are permanently public) |
| Special category data | None |
Activity 4 — Webhook Delivery
| Field | Detail |
|---|---|
| Purpose | Deliver Human Oracle responses to agent-provided HTTPS endpoints via signed webhook; maintain delivery attempt logs for retry and auditability |
| Categories of data subjects | Human developers who registered a webhook URL (the URL itself may identify a system operated by a natural person); any person whose data is included in the question payload delivered via webhook |
| Categories of personal data | Webhook URL (stored in plaintext, validated against SSRF blocklist); webhook secret reference (Key Vault URI — raw secret never in database); delivery attempt logs: delivery ID, event ID, question ID, attempt number, HTTP status received, error message, timestamps |
| Legal basis | Art. 6(1)(b) — contractual necessity (webhook delivery is an optional but contracted service feature) |
| Recipients | Microsoft Azure (storage and delivery dispatch); the agent's own webhook endpoint (controlled by the account holder) |
| Retention | Delivery logs: 30 days — automatic TTL. Webhook URL: retained with the question record (90-day TTL). Webhook secret reference: deleted when question record expires |
| International transfer | Microsoft Azure EU region; delivery destination is the agent's own endpoint (location determined by account holder) |
| Special category data | None specific to webhook config; response payload may contain question content (see Activity 2) |
Activity 5 — API Security Monitoring & Rate Limiting
| Field | Detail |
|---|---|
| Purpose | Detect and prevent abuse, DDoS attacks, brute-force attempts, and unauthorized access; enforce per-key rate limits; investigate security incidents |
| Categories of data subjects | Any natural person making HTTP requests to API endpoints (developers testing integrations; potential attackers) |
| Categories of personal data | Source IP address; request timestamp; HTTP method and endpoint path; HTTP response status code; User-Agent header; rate limit counter state |
| Legal basis | Art. 6(1)(f) — legitimate interest (see LIA in Section 3 of this document). The Company has a compelling legitimate interest in securing its infrastructure and protecting its human operators from harmful requests |
| Recipients | Microsoft Azure (Front Door, Functions — log storage); no other recipients |
| Retention | 90 days — aligned with question record TTL; automatic deletion |
| International transfer | Microsoft Azure EU region (primary) |
| Special category data | None |
Activity 6 — Human Oracle (Operator) Recruitment & Engagement
| Field | Detail |
|---|---|
| Purpose | Authenticate and manage human operators; track performance metrics; assign and deliver questions to operators via the internal dashboard |
| Categories of data subjects | Human Oracles (operators) — natural persons employed or engaged by the Company |
| Categories of personal data | Email address; Firebase Auth UID; role (admin / operator); display name; language skills; total questions answered; average response time; account status; creation and last-active timestamps |
| Legal basis | Art. 6(1)(b) — contractual necessity (operator engagement agreement); Art. 6(1)(f) — legitimate interest (performance tracking, quality assurance) |
| Recipients | Google Firebase Auth (authentication); Microsoft Azure (Cosmos DB operator record); no external sharing |
| Retention | Retained while operator is active; deleted upon termination of engagement |
| International transfer | Google Firebase / Google Cloud (US) — SCCs; Microsoft Azure EU (primary) |
| Special category data | None formally collected. If an operator voluntarily shares health or personal information via the dashboard, this is treated as incidental and not systematically processed |
Activity 7 — Idempotency Key Processing
| Field | Detail |
|---|---|
| Purpose | Prevent duplicate charges and duplicate resource creation on retried API requests; provide deterministic idempotent responses to agents |
| Categories of data subjects | Human developers whose API requests are subject to idempotency key caching |
| Categories of personal data | Compound key (agent_id + operation + idempotency_key); SHA-256 hash of canonical request body; cached HTTP response; original HTTP status code; creation timestamp |
| Legal basis | Art. 6(1)(b) — contractual necessity (idempotency is a core contractual service guarantee) |
| Recipients | Microsoft Azure Cosmos DB; no external sharing |
| Retention | 24 hours — automatic TTL deletion |
| International transfer | Microsoft Azure EU region |
| Special category data | None |
2. Sub-Processor Register (Art. 28)
Art. 28 GDPR requires that processing by a processor on behalf of the controller be governed by a written contract. The table below lists all sub-processors used by Human Oracles. For each, the Company relies on the processor's standard Data Processing Agreement (DPA) and/or Standard Contractual Clauses (SCCs) as the contractual basis. The Company will notify the relevant account holders of any intended addition or replacement of sub-processors where that change materially affects data protection.
| Processor | Service provided | Data categories processed | Location | Contract basis |
|---|---|---|---|---|
| Microsoft Azure | Cloud infrastructure: Azure Functions (serverless API), Cosmos DB (database), Key Vault (secret management), Front Door (DDoS/CDN), Static Web Apps (hosting) | All categories listed in Section 1 — account data, question content, payment events, webhook config, logs, operator records, idempotency records | EU (primary data residency); US possible for support/management operations | Microsoft Online Services DPA; EU Standard Contractual Clauses (SCCs, 2021 Commission Decision); EU–US Data Privacy Framework adequacy decision |
| Google Firebase / Google Cloud |
Operator authentication only — Firebase Auth email/password for
internal operator dashboard (ops.humanoracles.xyz)
|
Operator email addresses; Firebase Auth UIDs; authentication tokens. No agent/user data is processed by Firebase | United States | Google Cloud Data Processing Amendment; EU Standard Contractual Clauses (SCCs); EU–US Data Privacy Framework |
| Coinbase / CDP Facilitator | x402 payment verification — verifying USDC transactions on the Base blockchain (eip155:8453) via the CDP Facilitator API | Payment transaction data submitted for verification: USDC transaction details, EIP-3009 payment authorization, merchant wallet address, USDC amount. No account-level personal data transmitted to Coinbase | United States; Base blockchain is a global public ledger | Coinbase Commerce/CDP Terms of Service; EU Standard Contractual Clauses (SCCs) where applicable; note: on-chain data is publicly visible globally regardless of contractual arrangements |
No other processors. The Company does not use
analytics services, advertising networks, marketing automation
platforms, error-tracking SaaS, or any other third-party data
processor beyond those listed above. If new processors are added, this
register will be updated and account holders notified where required.
3. Legitimate Interest Assessment (LIA)
Processing activities based on Art. 6(1)(f) GDPR (legitimate interests) require a three-part balancing test: (1) identify the legitimate interest; (2) confirm the processing is necessary; (3) balance against data subjects' interests, rights, and freedoms. The following LIA applies to Activity 5 — API Security Monitoring & Rate Limiting and the security-related aspects of Activity 1.
Step 1 — The Legitimate Interest
The Company has the following legitimate interests in processing API access logs and IP addresses:
- Infrastructure integrity: Detecting and blocking DDoS attacks, brute-force API key attacks, and resource enumeration attempts protects the availability of the Service for legitimate users and prevents financial harm to the Company.
- Human Oracle protection: Human Oracles are real people who read submitted questions. Preventing harmful or abusive content from reaching them is a compelling interest that overrides marginal privacy concerns arising from IP logging.
- Account security: Identifying API key compromise or unauthorized access events allows the Company to protect account holders from unauthorized charges.
- Legal compliance: Logging is required to investigate and report security incidents, and to respond to binding legal orders.
These interests are genuine, specific, and present — not speculative. They are proportionate to the nature of the Service (a paid API handling cryptocurrency payments).
Step 2 — Necessity
IP address logging is necessary because:
- It is the primary signal available for identifying volumetric attacks and blocking malicious traffic at the network layer (Azure Front Door WAF rules require IP data to function).
- Rate limiting per API key alone is insufficient against attacks using many keys; IP-level rate limiting provides the second layer.
- Alternative approaches (e.g., purely behavioral analysis without IP) would be technically insufficient for real-time DDoS mitigation at L3/L4/L7.
- The data is not used for any purpose other than security and abuse prevention. It is not enriched, profiled, or shared.
The Company applies the least-invasive approach: IP addresses are stored in access logs only, retained for 90 days, and not linked to natural person identities beyond what is inherent in the log.
Step 3 — Balancing Test
Factors weighing in favor of the legitimate interest:
- The Service is designed for AI agents, not humans — the majority of requests are machine-generated, and no natural-person browsing behavior is tracked.
- Human users accessing the API are developers who have a reasonable expectation that server-side logs are maintained for security purposes (this is industry standard).
- IP address logging is a minimal, transient data point — not a persistent, enriched profile.
- Retention is 90 days — well below what many comparable services retain.
- Data is not shared with any third party for security purposes beyond Azure's own infrastructure (Azure Front Door processes traffic logs to enforce WAF rules).
Factors that could weigh against:
- IP addresses can, in some circumstances, be linked to natural persons.
- Data subjects have no direct control over whether their IP is logged.
Assessment conclusion: The legitimate interest in security monitoring outweighs the privacy impact of logging IP addresses for 90 days. The processing is proportionate, minimal, and not used for any purpose incompatible with security. The reasonable expectations of developers making API calls include awareness that server-side access logs are standard practice. A data subject exercising their Art. 21 right to object would be assessed on a case-by-case basis; the Company would cease IP-level log retention for that subject if technically feasible without compromising security for others.
LIA conclusion: Legitimate interest confirmed.
Processing of IP addresses and API access logs for security monitoring
and rate limiting is lawful under Art. 6(1)(f) GDPR. No override of
data subject rights is identified.
4. Cross-Border Transfer Safeguards
The Company is established in Poland (EU). Certain sub-processors operate outside the EU/EEA. The following table documents the transfer mechanism for each, as required by Chapter V GDPR.
| Transfer destination | Processor | Transfer mechanism | Additional safeguard |
|---|---|---|---|
| United States | Google Firebase / Google Cloud | EU Standard Contractual Clauses (SCCs) — 2021 Commission Decision (Controller-to-Processor) | EU–US Data Privacy Framework adequacy decision (effective July 2023); Google Cloud Data Processing Amendment |
| United States | Coinbase / CDP Facilitator | EU Standard Contractual Clauses (SCCs) where applicable to personal data in API requests | Note: on-chain data (wallet addresses, tx hashes) is permanently public on a global blockchain — no geographic restriction is possible for data already on-chain |
| US (support/management only) | Microsoft Azure | EU Standard Contractual Clauses (SCCs); Microsoft Online Services DPA | EU–US Data Privacy Framework; primary data residency is EU; US access is limited to Microsoft support personnel under strict access controls |
| Global public ledger | Base blockchain (Coinbase L2) | Not applicable — public permissionless ledger; no contractual transfer mechanism can restrict on-chain data | Data subjects are informed in the Privacy Policy that on-chain data (wallet address, tx hash, amount, timestamp) is permanently publicly visible. By initiating an x402 payment, data subjects accept this. |
⚠ Blockchain data is not erasable. On-chain
transaction data published to the Base blockchain cannot be removed by
the Company or any other party. This is an inherent and permanent
characteristic of public blockchain networks. Data subjects who have
transacted on-chain cannot exercise their Art. 17 (erasure) right with
respect to on-chain data. This limitation is disclosed in the Privacy
Policy and Terms of Service.
5. Data Subject Rights Register
This register documents how the Company processes data subject rights
requests under Arts. 15–22 GDPR. All requests must be submitted to
rongan@humanoracles.xyz
with subject line GDPR Request and sufficient account
identification (registered email address).
| Right (GDPR Article) | Scope & Limitations for This Service | Response Time | Procedure |
|---|---|---|---|
| Access (Art. 15) | Full access to account data, question records, payment events, and webhook config linked to the requesting natural person's account. AI agents themselves are not data subjects. | 30 days from verified request | Provide email address linked to account. Export delivered in JSON format via secure email reply. |
| Rectification (Art. 16) | Correction of inaccurate account data (e.g., email address). Question content cannot be retroactively corrected once submitted — it has been read by a Human Oracle. | 30 days | Specify the field to correct and the correct value. Identity verification required. |
| Erasure (Art. 17) | Account deletion: email address and API key hash deleted; account record removed. Question records: deleted immediately if within 90-day TTL window (would have been auto-deleted anyway). Payment records cannot be erased — 7-year legal obligation under Art. 6(1)(c). Payment records will be pseudonymized (email reference removed) to the extent technically feasible while preserving accounting integrity. On-chain data cannot be erased. | 30 days | Request account deletion. Confirmation of actions taken and any limitations will be provided. |
| Restriction (Art. 18) | Processing can be restricted while accuracy is contested or objection pending. Restricted accounts are suspended — no new questions can be submitted. Existing data is retained but not further processed beyond storage. | 72 hours (suspension); 30 days (full response) | State the basis for restriction. Account suspended pending resolution. |
| Portability (Art. 20) | Applies to data processed by automated means on the basis of contract (account data, question records, payment events). Delivered in structured JSON. Does not apply to Human Oracle response content (see IP section in Terms) or to data processed on legitimate interest basis. | 30 days | Same as access request. JSON export delivered via secure email. |
| Object (Art. 21) | Right to object applies to Art. 6(1)(f) processing (security logs, inactive account analysis). On receipt, the Company will cease the specific processing unless compelling legitimate grounds are demonstrated. Right to object does not apply to Art. 6(1)(b) or Art. 6(1)(c) processing. | 30 days | State the specific processing activity objected to. Company will assess and respond with either cessation of that processing or statement of compelling grounds. |
| Not to be subject to automated decisions (Art. 22) | The Service does not make any decisions with legal or similarly significant effects based solely on automated processing. Account suspension for content policy violations involves human review by an admin. Rate limiting is automated but does not constitute a legally significant decision. | N/A (no automated decisions) | N/A |
Complaint — Supervisory Authority
If you believe your rights have not been respected, you may lodge a complaint with the Polish Data Protection Authority:
- Authority
- Urząd Ochrony Danych Osobowych (UODO) — Office for Personal Data Protection
- Website
- uodo.gov.pl
- kancelaria@uodo.gov.pl
- Address
- ul. Stawki 2, 00-193 Warsaw, Poland
If you are located in another EU member state, you may also contact your local data protection authority.
6. Review Log
This document must be reviewed at least annually, and upon any material change to processing activities, introduction of new processors, or changes in applicable law.
| Version | Date | Reviewed by | Changes |
|---|---|---|---|
| 1.0 | 22 February 2026 | Data Controller (Human Oracles) | Initial publication covering Activities 1–7; LIA for Art. 6(1)(f) security processing; sub-processor register; rights register; transfer safeguards |
Next scheduled review: 22 February 2027. Review will
be triggered earlier if any of the following occur: introduction of a
new sub-processor; significant change in question volume or nature of
data processed; change in applicable law (e.g., RODO amendment); data
breach requiring post-incident review; enforcement action or UODO
inquiry.