Data Processing Addendum

This Data Processing Addendum ("DPA") forms part of the Terms of Service between FOP Tkach Oleksandr ("TUWA," "we," "us," or "our") and the organization that uses Quasar Cloud ("Customer"). It applies to personal data that we process on the Customer's behalf when we provide Quasar Cloud ("Customer Personal Data").

1. Roles

• The Customer is the controller of Customer Personal Data, or a processor acting for its own controller. We are its processor, or its sub-processor in the second case.
• This DPA does not cover personal data that we process as a controller, such as the accounts of the Customer's team members, billing and security records. Our Privacy Policy describes that processing.

2. Details of Processing

3. AML Screening

AML screening of the senders of incoming transactions is not available in Quasar Cloud. Before we offer it, we will update this DPA and tell the Customer under Section 7.

4. Instructions

We process Customer Personal Data only on the Customer's documented instructions. These Terms, this DPA, the Customer's settings in the Quasar dashboard and the Customer's API requests are its instructions. We inform the Customer if, in our opinion, an instruction infringes data protection law, and we may refuse to follow it. If the law requires us to process Customer Personal Data otherwise, we tell the Customer before we do, unless that law prohibits it.

5. Confidentiality

Everyone we authorize to process Customer Personal Data is bound by confidentiality.

6. Security

We implement the technical and organizational measures in Annex B. We may update them, but not in a way that lowers the overall protection of Customer Personal Data.

7. Sub-processors

• The Customer gives us a general authorization to use the sub-processors in Annex C.
• We tell the Customer about a new or replaced sub-processor by email to the owners of its organization at least 30 days before it starts processing Customer Personal Data. The Customer may object on reasonable data protection grounds within that period, and we will discuss the objection with it in good faith. If we cannot resolve the objection, the Customer may stop using Quasar Cloud before the new sub-processor starts processing its data, after exporting the data of its apps (Section 10).
• Where the Customer is a processor (Module Three of the standard contractual clauses). We inform the Customer's controller through the Customer of a new or replaced sub-processor and of any other new version of this DPA that changes the controller's instructions, the categories of data or of data subjects, the security measures, the sub-processors or international transfers, or its rights, and we send a copy of our notice to the email address of the controller that the Customer gives in the Quasar dashboard. The Customer forwards our notice to its controller without delay and passes the controller's objection on to us; the controller may also send its objection to us directly. We handle that objection as one of the Customer. We check with our email provider that each copy was delivered and show the result in the Quasar dashboard. If a copy is not delivered, the Customer corrects the address and we send the copy again to the corrected address. The controller has at least 30 days from the delivery of the copy of a notice of a new or replaced sub-processor to object. If that copy is delivered less than 30 days before the date the change takes effect, the change does not apply to the data of the Customer's apps until 30 days after the delivery: we do not accept Customer Personal Data from its apps from the date of the change until then, and where the new sub-processor would also process the data we already hold, we postpone the change for all Customers until that period ends. Until a copy of another change is delivered, we do not accept Customer Personal Data from the Customer's apps from the date that change takes effect.
• We impose on each sub-processor data protection obligations that are no less protective than this DPA, and we remain responsible to the Customer for its performance.
• Providers that the Customer sets up. Quasar Cloud reads the transactions of the Customer's apps only through providers that the Customer sets up for an app: a custom RPC endpoint, Alchemy or QuickNode keys, a Pimlico key or a bundler URL sent with a transaction, and a Gelato key. The Customer chooses each of them, obtains the endpoint or key from its own account with that provider and contracts with it; we have no contract with these providers for this processing, and we do not choose, instruct or replace them. On the Customer's instruction, we send them only the data each request needs, such as a transaction hash, a user operation hash or a task ID, through the endpoint and with the credentials that the Customer gave us, and we keep those credentials encrypted (Annex B). For these reasons they are providers of the Customer, not our sub-processors. We do not send Customer Personal Data to such providers through accounts or keys of our own; a provider we engage that way is our sub-processor and is listed in Annex C first. The Customer is responsible for its agreement with each such provider, including any data protection terms and transfer safeguards it requires; where it sets up a public endpoint that needs no account, the terms of that endpoint apply.

8. Assistance

• Requests of data subjects. We forward to the Customer any request we receive about Customer Personal Data and do not answer it ourselves unless the Customer instructs us to. The Customer can find, export and delete the data of its apps in the Quasar dashboard; we help with anything these tools do not cover.
• Security, impact assessments and consultations. We give the Customer reasonable assistance with its obligations under Articles 32 to 36 of the GDPR, taking into account the nature of the processing and the information available to us.

9. Personal Data Breaches

We notify the Customer without undue delay after we become aware of a personal data breach that affects Customer Personal Data. The notice describes, as far as we know at the time, the nature of the breach, the categories and approximate number of data subjects and records concerned, its likely consequences and the measures taken or proposed. We provide further information as it becomes available.

10. Deletion and Return

• The Customer can export the data of its apps and delete an app or its organization in the Quasar dashboard at any time.
• When the Customer deletes an app or its organization, we delete the related Customer Personal Data: transactions, webhook endpoints and delivery logs. Deleting large volumes of data may take some time.
• At the end of the services for the Customer's organization (Terms of Service, Section 5), the Customer chooses between return and deletion: until the end date it can export the organization in the Quasar dashboard, or, where its access was closed without notice, ask us for the export file within 30 days after the closing. We delete the remaining Customer Personal Data 30 days after the end date.
• Webhook delivery logs are also deleted automatically after 3 months.
• Deleted data can remain in our encrypted database backups for up to 8 days, after which those backups are deleted.
• We keep Customer Personal Data longer only where the law requires us to, and we do not return it where the law forbids it.

11. Audits

We make available to the Customer the information necessary to demonstrate compliance with this DPA, including this DPA, the description of our security measures, our sub-processor list and answers to reasonable security questionnaires. We also allow audits, including inspections, by the Customer or an auditor it mandates who is bound by confidentiality, on at least 30 days' notice, during business hours and at the Customer's cost. Where the information above or a remote review of documents is enough, the audit is done that way. An on-site inspection takes place no more than once in any 12 months, unless a personal data breach, a supervisory authority or reasonable grounds to suspect a breach of this DPA require another one.

12. International Transfers

• Flows. The Customer's apps send Customer Personal Data to Quasar Cloud, whose servers are in the Netherlands and which we operate from Ukraine. We send Customer Personal Data to the sub-processors in Annex C. Providers that the Customer sets up receive data on its instruction (Section 7).
• Standard contractual clauses. Where the Customer is subject to the GDPR and transfers Customer Personal Data to us, and our processing of that data is not itself subject to the GDPR, the standard contractual clauses approved by Commission Implementing Decision (EU) 2021/914 apply to that transfer: Module Two where the Customer is a controller, and Module Three where the Customer is a processor. The Customer is the data exporter and we are the data importer. We conclude the clauses with such a Customer, with their annexes completed and signed by both parties, before it sends Customer Personal Data to Quasar Cloud. The Customer gives the facts of its flow in the Quasar dashboard: how the GDPR applies to it and where it is established, its role and, where it is a processor, its controller, and what its apps put in free fields and what its webhook endpoints answer. We prepare clauses only on an approved version of our internal conclusion that, on the facts it lists, our processing of the data of such flows is not itself subject to the GDPR, and the clauses name that version; the conclusion is preliminary, and we check it again as those facts change. If we withdraw that version, new clauses wait for a new one. We first establish why it no longer holds and whether that affects the clauses in force that rest on it: where it may, we assess each of those flows again and suspend the acceptance of its data if the clauses no longer cover it; where we cannot comply with the clauses for those flows or their assessment no longer holds, we suspend the acceptance of their data at once. A suspension lasts until new clauses are concluded, and we tell the Customers concerned.
• Flows that our signatory assesses. Unless a flow is concluded on the standard flow profile as described in the next paragraph, we assess the Customer's flow under Clause 14 before the clauses are prepared and write our conclusion with the reasons of that flow into Annex I.B: the flow can proceed, it needs additional measures that the clauses then name, or we cannot conclude the clauses for it. Additional measures are in place before the data of the flow is transferred: the Customer confirms it when it signs, and our signatory checks it and records how before we sign. Our signatory signs the clauses for us.
• Flows on the standard flow profile. Our transfer assessment assesses one kind of flow in advance, the standard flow profile: a Customer that is a controller (Module Two), registered in the Member State of the European Union where it is established, whose free fields and webhook responses carry only technical data, and whose data, storage, access and measures are those described in Annexes D and B. While a standing offer of our signatory for that profile is in force, a flow whose answers meet every condition of the profile gets its conclusion: the Quasar dashboard records the match, with the conditions, the version of the transfer assessment and the time, and prepares the clauses with that conclusion in Annex I.B. When it signs, the Customer confirms that its flow matches the profile, what its apps send, and that it will change its answers before its apps send anything else; Quasar Cloud does not check the content of free fields or of webhook responses. For such a Customer, Quasar Cloud keeps only the status of each webhook response, not its content. The offer covers only a Customer that accepted, in the Quasar dashboard, the version of this DPA that the offer names; a version that binds the Customer only after a notice is not enough. The Customer accepts the standing offer only by signing, in the Quasar dashboard, the final package of clauses prepared for its flow, identified by its SHA-256. At that moment we sign that package through the offer, but only if the Quasar dashboard finds for it every condition recorded with the offer; we record what it found, and otherwise the package waits for our signatory as in the previous paragraph. The offer confirms no fact about a Customer in advance. An offer withdrawn before our signature of a package is recorded does not apply to that package, and withdrawing it does not affect clauses already concluded. Without a standing offer in force, or where a condition is not met or is in doubt, our signatory assesses the flow.
• Signing. The Customer signs only if its own assessment agrees, and otherwise declines the clauses with the reason. The parties conclude the clauses electronically in the Quasar dashboard: an owner of the Customer's organization signs for the Customer after confirming their authority, and FOP Tkach Oleksandr signs for us, by its signatory or through its standing offer; each party agrees that this electronic form binds it. We record each signature with the confirmations as shown, the versions and the time, and the evidence copy of the clauses names both signatures. Until data processing is set up for an organization, Quasar Cloud does not accept Customer Personal Data from its apps; for a flow under these clauses, that means until the clauses are concluded by both parties, with the details of Annex I.A, the assessment of the flow and any additional measures in place.
• Options in the clauses. Clause 7 (docking clause) applies. Under Clause 9(a), Option 2 (general written authorisation) applies, with the notice period in Section 7. The optional language in Clause 11(a) does not apply. The competent supervisory authority is determined under Clause 13(a). Under Clause 17, Option 1 applies and the clauses are governed by the law of Ireland. Under Clause 18, disputes are resolved by the courts of Ireland.
• Annexes of the clauses. Annex I.A: the details of the parties that the Customer gives when it concludes the clauses, and Annex A of this DPA. Annex I.B: Annex D of this DPA, with the assessment of the Customer's flow and our conclusion on it, or the conclusion of the standard flow profile with the record of the match. Annex I.C: the supervisory authority under Clause 13. Annex II: Annex B. Annex III: Annex C.
• If our processing becomes subject to the GDPR. If our processing of Customer Personal Data becomes directly subject to the GDPR under its Article 3(2), we will tell the Customer before that happens. The parties will then reassess the transfer and put in place the safeguard that the law requires before transfers continue; the clauses above do not by themselves cover that case.
• Our sub-processors. The safeguards for our transfers to sub-processors are listed in Annex C.

13. Liability and Precedence

Each party's liability under this DPA is subject to the limitations in the Terms of Service, to the extent permitted by applicable law. If this DPA conflicts with the Terms of Service, this DPA prevails; where standard contractual clauses apply and conflict with this DPA, the clauses prevail.

14. Term

This DPA applies for as long as we process Customer Personal Data.

Annex A. Parties

• Customer (controller or processor): the organization named in the Customer's Quasar Cloud account; contact: the owners of that organization.
• TUWA (processor): FOP Tkach Oleksandr, Ukraine; contact: [email protected].

Annex B. Security Measures

• Encryption. TLS for every connection to Quasar Cloud. Stored secrets, such as provider API keys and webhook secrets, are encrypted with AES-256-GCM. Database backups are encrypted before they leave our servers: the continuous backups with libsodium, the daily dumps with GPG.
• Access control. Every record is scoped to its organization. Organizations have owner, admin and member roles. Accounts can use two-factor authentication and passkeys. Access to the servers is limited to the people who operate Quasar Cloud.
• Our access to Customer Personal Data. We read it in the Quasar admin panel, which records each view (who, which records, when) and keeps the record for 1 year. A view that cannot be recorded is refused. There is no web tool for the database: it is reached only over SSH with the keys of the operator, for deployments and migrations, backups and restores, incidents and work the admin panel cannot do. Every hour an automated check copies the views in the admin panel, the SSH sign-ins of the servers and the requests to the admin panel in the log of our reverse proxy, which keeps each request (time, path and status, not the data) for 7 days, into the review of the week, and alerts us at once to a sign-in or a view it does not expect. Every week we review them and record the reason of each SSH session and the data read; the reviews are kept for 3 years.
• Webhooks and outbound requests. Webhooks are signed (HMAC-SHA256). Webhook delivery and the Customer's RPC endpoints are protected against server-side request forgery. The API has rate limits.
• Monitoring. Services are monitored with alerts. Error monitoring excludes cookies, request identity headers and account data. Deleted organizations and their removed members are recorded.
• Development and release. Dependencies are updated regularly. Release images are scanned for vulnerabilities, signed (cosign) and published with a software bill of materials; a rollback deploys only images whose signature is verified. Operations follow written runbooks, including for incidents and restoring backups.

Annex C. Sub-processors

Providers that the Customer sets up for its apps are not sub-processors (Section 7).

Annex D. Description of the Transfer (Annex I.B of the Clauses)