Data Processing Agreement

These terms have specific meanings in this DPA. Capitalized terms not defined here have the meanings assigned in the Principal Agreement or the GDPR.

• "Controller" — you, the entity that determines the purposes and means of processing Personal Data. You decide what data to send us and why.
• "Processor" — Dyva, the entity that processes Personal Data on your behalf and according to your instructions.
• "Sub-processor" — any third party that Dyva engages to process Personal Data on your behalf. Listed in Section 6.
• "Personal Data" — any information relating to an identified or identifiable natural person that Dyva processes on your behalf under this DPA.
• "Processing" — any operation performed on Personal Data, as defined in GDPR Article 4(2). This includes collection, storage, retrieval, use, transmission, deletion, and everything in between.
• "Data Subject" — the individual whose Personal Data is being processed.
• "Data Breach" — a security incident resulting in accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Personal Data.
• "Standard Contractual Clauses" ("SCCs") — the European Commission's approved clauses for international data transfers (Commission Implementing Decision (EU) 2021/914).

2.1 Subject Matter. Dyva processes Personal Data to provide the services described in the Principal Agreement — AI conversations, character interactions, voice processing, memory and knowledge base features, analytics, and related platform functionality.

2.2 Duration. Processing continues for the duration of the Principal Agreement, plus whatever additional time is needed to complete data return or deletion under Section 10 of this DPA.

2.3 Nature and Purpose. We collect, store, retrieve, process, analyze, transmit, and delete Personal Data as necessary to operate the Dyva platform on your behalf. This includes generating AI responses, maintaining conversation memory, processing voice input/output, providing analytics, and supporting the features you have enabled.

2.4 Categories of Data Subjects. End users of your Client Application, website, or service who interact with Dyva-powered features.

2.5 Types of Personal Data. The specific data depends on which features you use, but may include:

• Account information: email addresses, display names, profile data
• Conversation content: text messages, voice transcripts, uploaded files and images
• Voice data: audio recordings (for speech-to-text), voice samples (for cloning, if enabled)
• Memories: facts a character has retained from conversation, including memories the end user has disabled or asked the character to forget
• Usage data: message counts, feature usage patterns, session timestamps, sign-in history and IP addresses
• Knowledge base content: documents and data you upload to character knowledge bases
• Any other Personal Data you or your end users submit through the Service

2.6 Model Inference. Generating a character response means transmitting the conversation content, and the memories and knowledge base entries selected for that turn, to a third-party model provider. The same is true of the smaller classifiers that run over conversation content. Those providers are named in Section 6, with the country each one processes in. Section 9 covers the transfer mechanism.

2.7 Training. Dyva does not use Personal Data processed under this DPA to train or fine-tune models. The account setting that would permit training on a user's own content defaults to off and is opt-in — it is never enabled on a user's behalf.

Dyva commits to the following. These are not aspirational — they are binding obligations:

• Instruction-bound processing. We process Personal Data only according to your documented instructions (the Principal Agreement and this DPA constitute your instructions), unless required by EU or Member State law to do otherwise. If law compels us to process beyond your instructions, we will inform you before doing so unless legally prohibited.
• Confidentiality. All personnel authorized to process Personal Data are bound by appropriate confidentiality obligations, whether by contract or statutory duty.
• Security. We implement and maintain technical and organizational security measures appropriate to the risk, as detailed in Section 5.
• Sub-processor governance. We follow the Sub-processor requirements in Section 6 before engaging any third party to process your data.
• Data Subject requests. We assist you in responding to Data Subject rights requests (access, rectification, erasure, portability, restriction, objection). Where the Data Subject holds a Dyva account, access and portability are served by a self-service export covering 24 categories of data — profile and consent settings, every conversation and message, memories including ones the user disabled or forgot, room and direct messages, orders and ledger entries, sign-in history, and age verification — and erasure by a self-service account deletion. Section 10 describes what deletion removes, what it anonymizes, and what it retains.
• Compliance assistance. We help you meet your obligations under GDPR Articles 32-36 (security, breach notification, impact assessments, prior consultation) to the extent relevant to our processing and the information available to us.
• Data return and deletion. At your choice after the Service ends, we will either return all Personal Data in a standard, machine-readable format or securely delete it — and confirm deletion in writing. Details in Section 10.
• Audit support. We make available all information necessary to demonstrate compliance with this DPA and support audits as described in Section 7.

Your responsibilities as the Controller:

• Lawful processing. Comply with all applicable data protection laws in your use of the Service and in the processing instructions you give to Dyva. We process data on your instructions — make sure those instructions are lawful.
• Legal basis. Ensure you have a valid legal basis (consent, legitimate interest, contractual necessity, etc.) for providing Personal Data to Dyva and for the processing you instruct us to perform.
• Data quality. You are responsible for the accuracy, quality, and legality of the Personal Data you provide or that your end users submit through the Service.
• Transparency. Provide all required privacy notices to Data Subjects and obtain all necessary consents before their data is processed through Dyva. Your end users should know their data is being processed by an AI platform.
• Instructions. Ensure your processing instructions to Dyva do not cause us to violate any applicable law. If we believe an instruction infringes data protection law, we will inform you.

These are the technical and organizational measures actually in place. We have stated them at the level we can evidence; a measure we cannot evidence is not listed here, however conventional it would look:

• Encryption in Transit: Traffic between clients and Dyva is served over TLS 1.2 or higher. The API refuses plaintext HTTP.
• Credential Storage: Account passwords are hashed with Argon2id (older bcrypt and scrypt hashes are still verifiable for accounts that predate the change). Session tokens, API keys, and password-reset tokens are stored as hashes, never in plaintext. Two-factor secrets are encrypted with a separate key.
• Authentication: API access uses cryptographically generated keys, shown once and stored only as a hash with a display prefix. Time-based two-factor authentication is available on any account. Repeated failed sign-ins lock the account for a cooling-off period.
• Rate Limiting and Abuse Controls: Authentication, money-path, and messaging endpoints are rate limited per account and per source address. Sensitive pre-authentication endpoints fail closed rather than open when the limiter is unavailable.
• Data Minimization: Guest sessions record a hashed source address and no directly identifying information. Realtime and voice session tickets bind to a hashed address rather than a stored one. Sign-in history and active-session records do store the IP address, because that is the record you and your end users need in order to recognize and revoke a session you do not.
• Infrastructure Security: DNS, CDN, and DDoS protection sit in front of the application through Cloudflare. The database and cache are not exposed to the public network.
• Logging: API requests, authentication events, and moderation actions are written to an audit record retained independently of the account they concern.
• Incident Intake: Suspected vulnerabilities and incidents are received at [email protected]. Our notification obligation to you is in Section 8.

5.1 What is not claimed. Dyva is not end-to-end encrypted: message content is readable by the service, because generating a reply, recalling a memory, and moderating content all require it. We do not claim application-level or column-level encryption of message content at rest, and we do not currently hold a SOC 2 or ISO 27001 certification. If your risk assessment depends on any of these, raise it before you send us production data rather than after.

6.1 Authorized Sub-processors. By accepting this DPA, you authorize Dyva to use the following Sub-processors. The list includes the model, speech, and media providers that receive conversation content — on an AI platform those are the entries that matter, and a list that omits them is not a real list. Where a provider is integrated and authorized but switched off in the current configuration, the status column says so.

6.2 Changes to Sub-processors. We will notify you at least 14 days before adding or replacing a Sub-processor, via email to the address associated with your account. If you object on reasonable data protection grounds, we will work with you in good faith to address the concern. If we cannot resolve it, you may terminate the affected portion of the Service without penalty.

6.3 Sub-processor Obligations. Every Sub-processor is bound by a written agreement imposing data protection obligations at least as protective as those in this DPA. We do not hand off your data without equivalent safeguards. Dyva remains fully liable for each Sub-processor's compliance with the obligations under this DPA.

7.1 Right to Audit. You have the right to audit our compliance with this DPA. You may conduct one audit per calendar year with at least 30 days' written notice. Audits must be conducted during normal business hours, subject to reasonable confidentiality requirements, and must not unreasonably disrupt our operations or compromise the security of other customers' data.

7.2 Audit Scope. Audits may cover: (a) our technical and organizational security measures; (b) our Sub-processor management; (c) our data processing activities under this DPA; and (d) our compliance with your documented instructions.

7.3 Alternative Evidence. In lieu of an on-site audit, Dyva may provide detailed written responses to your reasonable audit questions, together with any third-party audit report or penetration-test result we hold at the time of the request. As stated in Section 5.1, we do not currently hold a SOC 2 or ISO 27001 certification, so written responses are what is available today.

7.4 Cost. Each party bears its own costs for audits. If you require an on-site audit beyond one per year, you will reimburse Dyva's reasonable costs for facilitating it.

8.1 Notification Timeline. We will notify you of a Data Breach affecting Personal Data processed under this DPA within 72 hours of becoming aware of it. If we cannot provide full details within 72 hours, we will provide what we have and supplement it as more information becomes available.

8.2 Notification Content. Our breach notification will include, to the extent available at the time:

• A description of the nature of the breach, including the categories and approximate number of Data Subjects and Personal Data records affected
• The name and contact details of our point of contact for further information
• A description of the likely consequences of the breach
• A description of the measures taken or proposed to address the breach, including steps to mitigate its effects
• A timeline of events as we understand them

8.3 Cooperation. We will cooperate fully with your breach investigation and response efforts. This includes: (a) providing additional information as it becomes available; (b) taking commercially reasonable steps to contain and remediate the breach; (c) preserving relevant evidence; and (d) assisting with notifications to supervisory authorities and Data Subjects where required.

8.4 What Is Not a Breach. For clarity, unsuccessful security incidents (blocked attacks, failed login attempts, port scans) that do not result in unauthorized access to Personal Data are not Data Breaches under this DPA.

9.1 Dyva's Location. Dyva is based in the United States. Personal Data processed under this DPA is stored in the United States.

9.2 Onward Transfer to Model Providers. Storage location is not the whole picture. Generating a character response sends conversation content to a model provider, and not every model provider in Section 6 processes in the United States — the default text-inference provider processes in China. If your assessment of that transfer is that it is unacceptable for your end users' data, tell us before you send production data, so we can agree in writing on a routing restriction rather than discover the disagreement afterwards.

9.3 Transfer Mechanism. For Personal Data originating in the European Economic Area (EEA), United Kingdom, or Switzerland, we rely on the Standard Contractual Clauses — Commission Implementing Decision (EU) 2021/914 — which are incorporated into this DPA by reference. Dyva does not claim certification under the EU-U.S. Data Privacy Framework and does not rely on it.

By accepting this DPA, you execute the Standard Contractual Clauses with Dyva as the data importer and you as the data exporter. The details in Sections 1 and 2 of this DPA serve as the Annex I information required by the SCCs.

9.4 UK and Swiss Transfers. For UK transfers, the SCCs apply as amended by the UK International Data Transfer Addendum. For Swiss transfers, the SCCs apply as adapted for the Swiss Federal Act on Data Protection. References to GDPR are read as references to the applicable local law.

9.5 Supplementary Measures. In addition to the SCCs, Dyva applies the technical measures described in Section 5, and the limits stated in Section 5.1, to transferred data. Section 5.1 is part of the transfer picture, not a footnote to it.

10.1 Your Options. When the Principal Agreement ends, you have 30 days to request either: (a) return of all Personal Data in a commonly used, machine-readable format — the self-service account export produces a single JSON document, one array of rows per category; or (b) secure deletion of all Personal Data with written confirmation.

10.2 Default Action. If you do not make a request within 30 days, we will securely delete all Personal Data. We will confirm deletion in writing.

10.3 Legal Retention. We retain Personal Data past deletion only where retention is required for compliance with a legal obligation or for the establishment, exercise, or defence of legal claims — the grounds in GDPR Article 17(3)(b) and (e). In practice that is: commerce orders, entitlements, credit and Spark ledger entries, billing addresses, creator tax information, earnings and payout records, subscriptions, tips and gifts, age and identity verification results, safety reports, and the audit log. Conversation content is not in that set. Any retained data remains subject to the confidentiality and security obligations of this DPA until it is deleted.

10.4 Deletion of an Individual Account. Where a Data Subject deletes their own Dyva account, one transaction removes their private conversations and the messages in them, their memories, their credentials, sessions, two-factor enrolment and sign-in history, their library and activity, and any characters or rooms nobody else engaged with. Content that another person is part of is not deleted but is severed from the identity: messages in shared rooms, the user's messages inside another person's conversation, and group posts, community threads and replies, feed posts and comments are anonymized in place. The account row itself survives as a tombstone with identifiers and credentials cleared, because the retained payment records depend on it. Deletion is idempotent and writes a receipt.

10.5 Sub-processor Data. We will instruct every Sub-processor to delete or return Personal Data in accordance with this section, and will confirm to you when that instruction has been acknowledged.

11.1 Liability Cap. Each party's total aggregate liability under this DPA is subject to the liability limitations and exclusions set forth in the Principal Agreement.

11.2 Data Subject Rights. Nothing in this DPA limits either party's liability to Data Subjects under applicable data protection law. GDPR fines and Data Subject compensation claims are not subject to contractual liability caps where prohibited by law.

11.3 Indemnification. Each party will indemnify the other for damages arising from its breach of this DPA, to the extent such damages are not excluded by the liability limitations in the Principal Agreement.

This DPA is governed by the laws specified in the Principal Agreement. Exception: where data protection law requires otherwise (for example, GDPR-related claims are governed by the law of the applicable EU/EEA Member State, and UK GDPR claims by English law). For the Standard Contractual Clauses, the governing law is as specified in the SCCs themselves.

Data protection inquiries: [email protected]

Legal matters: [email protected]

Security incidents: [email protected]

For Data Subject access requests or deletion requests submitted by your end users, contact us at [email protected] with the subject line "DSAR" and we will respond within 5 business days.