Aspis Data Processing Agreement
Version 1.0 — 1 October 2026
This Data Processing Agreement (the "DPA") sets out how Aspis Protocol Ltd processes personal data for its business clients, and how each party handles personal data it shares with the other.
1. Parties and how this DPA applies
1.1 The parties. This DPA is between:
- Aspis Protocol Ltd, a company registered in England and Wales with company number 15506799, whose registered office is at 167-169 Great Portland Street, 5th Floor, London W1W 5PF, United Kingdom, ICO registration number ZB866437 (the "Provider"); and
- the organisation that has entered into the Agreement with the Provider, as named in the Agreement or in the signature table below (the "Client").
Each is a "party", and together they are the "parties".
1.2 Signed version. Where the parties sign this DPA:
- at the same time as a Subscription Services Agreement, it forms part of that agreement from its effective date; or
- after a Subscription Services Agreement has been signed, it forms part of that agreement from the date of the last signature below. It is then the data processing agreement that the parties agreed to enter into on request under clause 9.1 of that agreement, and it applies to all Client Personal Data the Provider processes from that date, including data it received earlier.
1.3 Online version. This DPA is published at aspis.finance/dpa. Where the Client uses a self-serve organisation account under section 8 of the Aspis Terms of Use, this DPA is incorporated into the Agreement by reference and forms the data processing terms referred to in section 8.6 of those terms. It applies from when the Client accepts the Agreement or, for an organisation account opened before 1 October 2026, from the date the updated Aspis Terms of Use apply to that account. The person who accepts the Agreement for the Client also accepts this DPA for it, and confirms that they are authorised to do so. No signature is needed.
1.4 Signed agreement first. If the Client has both a signed Subscription Services Agreement and a self-serve organisation account, the signed agreement and the DPA signed with it govern the Services provided under that agreement.
1.5 Order of precedence. If there is a conflict:
- this DPA prevails over the rest of the Agreement on anything to do with the protection of personal data; and
- the Transfer Clauses, where they apply under clause 6, prevail over this DPA and the rest of the Agreement.
1.6 Improving the Services. Any right in the Agreement for the Provider to use Client Data to improve the Services applies to Client Personal Data only in aggregated or de-identified form under clause 3.4.
1.7 Earlier terms. This DPA replaces any earlier data processing terms between the parties about the Services. Any security clause in the Agreement continues to apply, supplemented by Annex 2.
2. Definitions and interpretation
2.1 Definitions. In this DPA:
- "Agreement" means either:
- the Subscription Services Agreement between the Provider and the Client (including its Order Form, schedules and any addendum) to which this DPA is attached or which refers to it; or
- where the Client uses a self-serve organisation account without a signed agreement, the Aspis Terms of Use, together with the Subscription Terms and any plan or fees agreed with the Client, as they apply to the organisation account.
- "Authorised Users" means the Client's employees, contractors and organisation members who are permitted to use the Services on its behalf.
- "Business Day" means a day other than a Saturday, Sunday or public holiday in England.
- "Client Data" means data and content provided to the Services by or on behalf of the Client, its Authorised Users or its end users.
- "Client Personal Data" means personal data that the Provider processes on behalf of the Client in providing the Services, as described in Annex 1. It does not include personal data the Provider processes as a controller under clause 3.2, or Member Data.
- "controller", "processor", "data subject", "personal data", "processing" and "supervisory authority" have the meanings given in the Data Protection Laws.
- "Data Protection Laws" means all laws on data protection and privacy that apply to the processing of personal data under the Agreement, including, where they apply:
- the UK GDPR and the Data Protection Act 2018, as amended, including by the Data (Use and Access) Act 2025;
- the Privacy and Electronic Communications (EC Directive) Regulations 2003 ("PECR");
- the EU GDPR and the national laws of EEA states that supplement it; and
- US State Privacy Laws.
- "EU GDPR" means Regulation (EU) 2016/679 (the General Data Protection Regulation).
- "EU SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.
- "IDTA" means the International Data Transfer Agreement issued by the Information Commissioner under section 119A(1) of the Data Protection Act 2018, as revised under its terms.
- "Member Data" has the meaning given in clause 8.1.
- "Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Client Personal Data processed by the Provider or its Sub-processors.
- "Restricted Transfer" means a transfer of personal data subject to the UK GDPR or the EU GDPR to a country outside the UK or the EEA (as applicable) that is not covered by adequacy regulations or an adequacy decision.
- "Services" means the services the Provider provides to the Client under the Agreement.
- "Sub-processor" means any third party (other than the Provider's staff) that the Provider engages to process Client Personal Data on the Client's behalf.
- "Transfer Clauses" means the EU SCCs, the IDTA and the UK Addendum, as incorporated into this DPA under clause 6.
- "UK Addendum" means the International Data Transfer Addendum to the EU SCCs issued by the Information Commissioner under section 119A(1) of the Data Protection Act 2018, as revised under its terms.
- "UK GDPR" means the EU GDPR as it forms part of UK law under the European Union (Withdrawal) Act 2018, as amended.
- "US State Privacy Laws" means the California Consumer Privacy Act of 2018 (as amended by the California Privacy Rights Act of 2020) and comparable consumer privacy laws of other US states, to the extent they apply.
2.2 Interpretation. "Including" and "for example" do not limit the words before them. A reference to a law includes that law as amended or replaced. "In writing" includes email. Terms defined in the Agreement have the same meaning here unless this DPA defines them differently.
3. Roles of the parties
3.1 The Provider as processor. For Client Personal Data, the Client is the controller and the Provider is its processor. If the Client acts as a processor for another controller, the Provider is the Client's sub-processor, and the Client confirms that its controller has authorised it to appoint the Provider on these terms.
3.2 The Provider as independent controller. The Provider processes some personal data connected with the Services for its own purposes, as an independent controller. These purposes are:
- setting up and running the accounts of the Client's contacts and Authorised Users, including sign-in and account security;
- billing and invoicing;
- detecting and preventing fraud and abuse, and monitoring the security of the Services;
- complying with the law, and establishing, exercising or defending legal claims;
- creating aggregated or de-identified service metrics (clause 3.4);
- reading public blockchain data for its own products (clause 3.5); and
- providing its own services to any end user who creates their own Aspis or AgentCouncil account (clause 3.6).
For these purposes, the Provider complies with Data Protection Laws as a controller and processes the data as its Privacy Policy describes. Clause 8 covers organisation member seats.
3.3 Limits on controller use. The Provider uses Client Personal Data for the purposes in clause 3.2 only as far as reasonably necessary for them. It never uses it to sell it, to build profiles of the Client's end users, or to contact or market to them.
3.4 Aggregated and de-identified data. The Provider may create aggregated or de-identified data from Client Personal Data to measure, maintain and improve the Services. It will never use that data to identify an end user, will not try to re-identify it, and will not disclose it in a form that identifies the Client or any individual.
3.5 Public blockchain data. The Provider reads public blockchain data for its own products. A wallet address appearing in Client Personal Data does not make that public data Client Personal Data. The Provider will not use, for its own purposes, the link between a wallet address and any identifier or other data the Client gives it.
3.6 End users with their own accounts. If one of the Client's end users creates their own Aspis or AgentCouncil account, the personal data they give the Provider through that account is not Client Personal Data. The Provider is its controller, and the Aspis Privacy Policy applies.
4. The Client's obligations
4.1 Lawful basis. The Client will comply with Data Protection Laws in its use of the Services. It is responsible for having a lawful basis for the processing of Client Personal Data, including for giving it to the Provider and instructing the Provider to process it, and for obtaining any consent that Data Protection Laws (including PECR) require.
4.2 Notices to data subjects. The Client will give its end users, Authorised Users and other data subjects the information Data Protection Laws require about the processing of Client Personal Data. Its privacy notices must describe the Provider at least as a category of recipient, for example "our technology and infrastructure provider". The Client need not name the Provider publicly, but it must not make any untrue statement about the Services, the infrastructure behind them, or where Client Personal Data is processed.
4.3 Lawful instructions. The Client's instructions to the Provider must comply with Data Protection Laws. The Client is responsible for the instructions it gives through the Services, including the data it chooses to send.
4.4 Data the Client must not send. The Client will not send, or allow its Authorised Users or end users to send, to the Services:
- special category data (as described in Article 9 of the UK GDPR and the EU GDPR);
- personal data relating to criminal convictions and offences; or
- personal data of anyone under 18.
If the Provider becomes aware that such data has been sent, it may tell the Client and delete it.
4.5 Accuracy. The Client is responsible for the accuracy, quality and lawfulness of the Client Personal Data it sends, including wallet addresses it submits for analysis, and for how it obtained that data.
4.6 The Client's own systems and choices. The Client is responsible for the security of its own systems, API keys and Authorised Users' credentials, and of Client Personal Data after the Provider returns it. It is also responsible for its choice to use third-party platforms and protocols with the Services (such as Telegram, public blockchains and decentralised exchange aggregators: see Annex 3), and for describing them to its end users.
5. The Provider's obligations as processor
This clause sets out the terms required by Article 28(3) of the UK GDPR and the EU GDPR.
5.1 Documented instructions. The Provider will process Client Personal Data only on the Client's documented instructions, including with regard to transfers to other countries. Those instructions are:
- the Agreement, including this DPA and Annex 1;
- the Client's calls to the Provider's API and connectors;
- the Client's configuration of the Services, including in the dashboard; and
- any other written instructions the Client gives that are consistent with the Agreement. Instructions beyond the scope of the Services may need to be agreed, including any fees.
The Provider may process Client Personal Data otherwise only where UK law (or, where the EU GDPR applies, EU or member state law) requires it. It will then tell the Client of that legal requirement before processing, unless the law prohibits this on important grounds of public interest.
5.2 Instructions that infringe the law. The Provider will tell the Client promptly if, in its opinion, an instruction infringes Data Protection Laws, and may suspend the affected processing until the Client confirms or changes the instruction.
5.3 Confidentiality. The Provider will ensure that everyone it authorises to process Client Personal Data, including staff and contractors, is bound by a duty of confidentiality, by contract or by law. Access is limited to people who need it to provide, support or secure the Services.
5.4 Security. The Provider will implement and maintain the technical and organisational measures in Annex 2, as required by Article 32 of the UK GDPR and the EU GDPR, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risks to data subjects. It may update these measures, as long as updates do not reduce the overall level of protection. The Client agrees that, given clause 4.4, Annex 2 provides an appropriate level of security.
5.5 Sub-processors.
- General authorisation. The Client gives the Provider general written authorisation to engage the Sub-processors listed in Annex 3.
- Notice of changes. The Provider will give the Client at least 30 days' notice by email before it adds or replaces a Sub-processor, giving its name, service and location.
- Objection. Within that 30-day period, the Client may object in writing on reasonable data protection grounds, giving its reasons. The parties will discuss the objection in good faith, and the Provider may propose a reasonable alternative, such as not using the new Sub-processor for Client Personal Data.
- Termination. If the objection is not resolved before the change takes effect, the Client may terminate the affected Services (or, if they cannot reasonably be separated, the Agreement) by written notice, without any termination fee. The Provider will refund, pro rata, any fees paid in advance for the period after termination.
- Flow-down. The Provider will engage each Sub-processor under a written contract imposing data protection obligations equivalent to those in this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures. On request, the Provider will give the Client a copy of those terms, from which it may remove commercial information.
- Liability. The Provider remains fully liable to the Client for the performance of each Sub-processor's obligations.
5.6 Data subject requests. Taking into account the nature of the processing, the Provider will help the Client by appropriate technical and organisational measures, as far as possible, to respond to requests from data subjects to exercise their rights. In particular:
- where the Services let the Client retrieve, correct or delete Client Personal Data itself, the Client will use those features first;
- if the Provider receives a request from a data subject about Client Personal Data, it will forward it to the Client within 5 Business Days, where it can identify the Client from the request; and
- the Provider will not respond to the request itself unless the Client instructs it to in writing or Data Protection Laws require it.
This does not stop the Provider responding to a request about personal data it processes as a controller.
5.7 Impact assessments and prior consultation. Taking into account the nature of the processing and the information available to it, the Provider will give the Client reasonable assistance with any data protection impact assessment, and any prior consultation with a supervisory authority, that the Client must carry out about the Services.
5.8 Personal Data Breaches.
- Notice. The Provider will notify the Client without undue delay, and in any case within 48 hours, after becoming aware of a Personal Data Breach. It will notify the Client's contact for notices under the Agreement or, for an organisation account, the organisation's owner.
- Information. The notice will include, as far as it is then available:
- the nature of the Personal Data Breach, including, where possible, the categories and approximate number of data subjects and of personal data records concerned;
- the name and contact details of the Provider's contact for the breach;
- the likely consequences of the Personal Data Breach; and
- the measures taken or proposed to deal with it, including, where appropriate, to reduce its possible adverse effects.
- Information in phases. Where the Provider cannot give all this information at once, it will give it in phases as it becomes available, without undue further delay.
- Cooperation. The Provider will take reasonable steps to contain, investigate and reduce the effects of the Personal Data Breach. It will cooperate with the Client and give it the information it reasonably needs to meet its own obligations to notify a supervisory authority or data subjects.
- No public notification. The Provider will not notify any data subject, supervisory authority or the public of a Personal Data Breach in a way that names or identifies the Client without the Client's prior written consent, unless the law requires it. Where it does, the Provider will tell the Client first, where lawful.
- No admission. Notifying or responding to a Personal Data Breach is not an admission of fault or liability.
Unsuccessful attempts that do not compromise the security of Client Personal Data, such as failed sign-ins, pings or port scans, are not Personal Data Breaches.
5.9 Deletion or return at the end. When the Agreement ends, the Provider will, at the Client's choice, return Client Personal Data to the Client or delete it, within 30 days after the end.
- The Client may make its choice before the end or within 14 days after it. If it makes no choice, the Provider will delete the data.
- The Provider will return data through the export features of the Services or in a commonly used, machine-readable format.
- Copies in backups are overwritten on their normal cycle within 35 days, and server logs are deleted on their normal cycle within 90 days. Until then, those copies remain protected by this DPA and are not used, except to recover from an incident or where the law requires.
- The Provider may keep Client Personal Data that the law requires it to keep, for as long as the law requires, and will process it only for that purpose.
- Transactions on public blockchains are public and permanent, and neither party can delete them.
On request, the Provider will confirm the deletion in writing.
5.10 Information and audits.
- Information. The Provider will make available to the Client the information reasonably necessary to demonstrate its compliance with Article 28 of the UK GDPR and the EU GDPR, including this DPA, a description of the measures in Annex 2 and the list of Sub-processors. It will also answer a written security and data protection questionnaire from the Client, no more than once in any 12 months.
- Audits. If that information is not enough to demonstrate compliance, the Client, or an independent auditor it appoints who is not a competitor of the Provider, may audit the Provider's compliance with this DPA on-site or remotely. The Client must give at least 30 days' written notice with the proposed scope. The audit takes place during business hours (09:00 to 17:00 UK time on Business Days) and must not disrupt the Provider's business unreasonably.
- Confidentiality and scope. The Client and its auditor must agree in writing to keep confidential what they learn in the audit. The audit does not cover other clients' data, legally privileged material, information whose disclosure would put the security of the Services at risk, or Sub-processors' premises and systems. For Sub-processors, the Provider will pass on the information they make available, such as their audit reports.
- Frequency. Audits are limited to one in any 12 months, unless a Personal Data Breach has occurred or a supervisory authority requires more.
- Costs. The Client bears the costs of the audit, including the Provider's reasonable costs of supporting it, which the Provider will estimate in advance. The Provider will not charge its costs if the audit reveals a material breach of this DPA by the Provider.
- Findings. The Provider will take reasonable steps, without undue delay, to remedy any material non-compliance the audit finds.
5.11 Requests from public authorities. If a public authority, including a court, regulator or law enforcement body, asks or orders the Provider to disclose Client Personal Data, the Provider will:
- notify the Client promptly where the law allows, and try to redirect the authority to the Client. If the law prohibits notice, it will use reasonable efforts to have the prohibition lifted;
- review the lawfulness of the request, and challenge it where, after careful assessment, it reasonably concludes that there are grounds to do so; and
- disclose only the minimum Client Personal Data needed to comply, based on a reasonable interpretation of the request.
5.12 Records and further assistance. The Provider will keep a record of its processing for the Client as Article 30(2) of the UK GDPR and the EU GDPR requires, and will otherwise assist the Client with its obligations under Articles 32 to 36 as this clause 5 describes. It will not charge for the assistance in clauses 5.6 to 5.8. For other assistance beyond the features of the Services, it may charge reasonable costs agreed in advance, unless the assistance is needed because of its own breach of this DPA.
6. International transfers
6.1 General. The Provider is based in the UK. Its Sub-processors process Client Personal Data in the locations in Annex 3. The Provider will make a Restricted Transfer of Client Personal Data only under a mechanism in this clause and Annex 4, or as Data Protection Laws otherwise allow. For its onward transfers of UK GDPR data, it relies on UK adequacy regulations, the UK Extension to the EU-US Data Privacy Framework (the "UK-US data bridge") for certified US Sub-processors, or otherwise the IDTA or the UK Addendum with an assessment of the transfer.
6.2 Clients in the EEA. Transfers of Client Personal Data from the Client to the Provider rely on the European Commission's adequacy decisions for the UK, renewed on 19 December 2025 until 27 December 2031. If those decisions stop applying and no other mechanism is available, the EU SCCs are incorporated into this DPA from that date, with the Client as data exporter and the Provider as data importer: Module 2 where the Client is a controller, and Module 3 where it is a processor. The Provider's onward transfers of EU GDPR data to Sub-processors outside the UK and the EEA rely on the EU SCCs Module 3 or, for certified US Sub-processors, the EU-US Data Privacy Framework.
6.3 Clients outside the UK and EEA. Where the Provider's return of Client Personal Data to the Client, or the Client's access to it, is a Restricted Transfer from the UK, the UK Addendum, with the EU SCCs Module 4 (processor to controller), is incorporated into this DPA, with the Provider as data exporter and the Client as data importer. The parties may instead agree in writing to use the IDTA. Where the EU GDPR applies to that transfer, the EU SCCs Module 4 apply in the same way.
6.4 Completing the Transfer Clauses. Where Transfer Clauses are incorporated under this DPA, they are completed as follows:
| Clause or table | How it is completed |
|---|---|
| EU SCCs Clause 7 (docking clause) | Included |
| EU SCCs Clause 9(a) (Sub-processors) | Option 2 (general written authorisation), with at least 30 days' notice of changes (clause 5.5) |
| EU SCCs Clause 11(a) (redress) | Optional language not used |
| EU SCCs Clause 13 (supervision) | The supervisory authority competent for the data exporter under Clause 13(a) |
| EU SCCs Clause 17 (governing law) | Irish law |
| EU SCCs Clause 18 (forum and jurisdiction) | The courts of Ireland |
| EU SCCs Annexes I, II and III | Annexes 1, 2 and 3 of this DPA, with the parties' details as set out in the Agreement |
| UK Addendum Tables 1 to 3 | The parties' details in the Agreement; the EU SCCs with the modules and options in this table; and Annexes 1 to 3 of this DPA |
| UK Addendum Table 4 (ending the Addendum when the Approved Addendum changes) | Both the importer and the exporter may end it |
| IDTA, where agreed | Law of England and Wales and its courts. Tables 1 to 4 completed from the Agreement and Annexes 1 to 3. Both parties may end it when the Approved IDTA changes |
6.5 If a mechanism fails. If a transfer mechanism relied on under this clause ceases to be valid, the parties will cooperate in good faith to put a valid alternative in place, and the Provider may suspend the affected transfer until then.
7. US State Privacy Laws
7.1 Role. To the extent US State Privacy Laws apply to Client Personal Data, the Provider acts as the Client's "service provider" or "processor" (as those laws define them). The business purposes of the processing are those in Annex 1.
7.2 Restrictions. The Provider will not:
- sell or share Client Personal Data (as those laws define "sell" and "share", including sharing for cross-context behavioural advertising);
- retain, use or disclose Client Personal Data for any purpose other than the business purposes in Annex 1, or outside the direct business relationship between the parties, except as US State Privacy Laws permit; or
- combine Client Personal Data with personal data it receives from or on behalf of anyone else, or collects from its own interactions with the data subject, except as US State Privacy Laws permit.
7.3 Compliance and notice. The Provider will comply with the obligations US State Privacy Laws place on it and give Client Personal Data the level of privacy protection they require. It will notify the Client if it decides that it can no longer meet those obligations. The Client may then take reasonable and appropriate steps to stop and remedy any unauthorised use of Client Personal Data.
8. Organisation member seats (controller to controller)
8.1 Scope. This clause applies where the Client adds Authorised Users as members of its organisation account. The Client gives the Provider its members' names and email addresses. The Provider creates an account for a member who does not have one, or links an existing account, and emails the member. The Provider then shows the organisation's owners each member's name, email address, role, account creation date and last sign-in, and lets them remove members. This information is "Member Data". Content about Authorised Users that the Client processes through the Services is Client Personal Data, not Member Data.
8.2 Independent controllers. Each party is an independent controller of the Member Data it processes. The Client decides whom to add and how it uses what its owners see. The Provider decides how it runs member accounts, as its Privacy Policy describes. The parties are not joint controllers, and clause 5 does not apply to Member Data.
8.3 The Client's responsibilities. The Client will:
- have a lawful basis for giving Member Data to the Provider and for its own use of it;
- tell its members, before adding them, that it will give their name and email address to the Provider, and what its owners will be able to see;
- add only people who have agreed to be added; and
- make sure the Member Data it gives is accurate.
8.4 The Provider's responsibilities. The Provider will:
- use Member Data only to create and run members' accounts, to provide and secure the Services, and for the other purposes its Privacy Policy describes;
- make its Privacy Policy available to each member, including when it invites them;
- show owners only the Member Data listed in clause 8.1, and not members' chats, analyses or payment details; and
- not use Member Data to send marketing unless the member has agreed to it or PECR otherwise allows it.
8.5 Security. Each party will protect the Member Data it holds with appropriate technical and organisational measures.
8.6 Cooperation. If either party receives a data subject request, or a complaint or enquiry from a supervisory authority, about the other party's processing of Member Data, it will pass it on within 5 Business Days and give reasonable help. If either party becomes aware of a personal data breach affecting Member Data that is likely to affect the other, it will tell the other without undue delay and cooperate reasonably in dealing with it.
8.7 Transfers of Member Data. Where making Member Data available to a Client outside the UK is a Restricted Transfer, the UK Addendum with the EU SCCs Module 1 (controller to controller), completed as in clause 6.4, is incorporated for that purpose, unless the parties agree in writing to use the IDTA.
9. Liability
9.1 Limits in the Agreement apply. Each party's liability arising out of or in connection with this DPA, and, as far as they allow, the Transfer Clauses, is subject to the limitations and exclusions of liability in the Agreement. Where the Agreement sets a separate or higher limit for breaches of data protection obligations, that limit applies to claims under this DPA. Liability under this DPA counts towards the limits in the Agreement and is not in addition to them.
9.2 Data subjects' rights. Nothing in this DPA or the Agreement limits any right of a data subject against either party under Data Protection Laws (including the right to compensation) or under the third-party beneficiary provisions of the Transfer Clauses, or any liability that cannot be limited or excluded by law.
9.3 Sharing responsibility. Where both parties are liable to a data subject for the same damage and one party has paid full compensation, it may claim back from the other the part that corresponds to the other's responsibility, as Article 82(5) of the UK GDPR and the EU GDPR provides.
10. Term, changes and general terms
10.1 Term. This DPA takes effect as described in clause 1 and continues until the later of the end of the Agreement and the date the Provider no longer processes any Client Personal Data. It cannot be terminated separately while the Agreement continues, except under clause 5.5.
10.2 Survival. Clauses 5.9, 9 and 10, and any other provision intended by its nature to continue, survive the end of the Agreement. The Provider's obligations under this DPA continue for as long as it processes Client Personal Data.
10.3 Changes to the signed version. A signed DPA may be changed only in writing signed by both parties, except that the Provider may update Annex 3 under clause 5.5, and may make changes that Data Protection Laws require (including adopting new versions of the Transfer Clauses) on at least 30 days' written notice, or any shorter period the law requires.
10.4 Changes to the online version. The Provider may update the online version to reflect changes in Data Protection Laws, regulatory guidance, the Transfer Clauses, the Services or Sub-processors. It will give the organisation's owner at least 30 days' notice by email of any change that materially reduces the Client's protection. If the Client does not agree, it may end its organisation plan before the change takes effect, and any refund is dealt with under the Agreement. Sub-processor changes follow clause 5.5.
10.5 Notices. Notices under this DPA are given in writing to the addresses for notices in the Agreement. The Provider's address is info@aspis.finance. For an organisation account, the Provider sends notices to the organisation owner's email address.
10.6 Severance. If any provision of this DPA is invalid or unenforceable, the rest continues to apply, and the parties will agree any change needed to keep this DPA compliant with Article 28 of the UK GDPR and the EU GDPR.
10.7 Third parties. Nobody other than the parties may enforce this DPA under the Contracts (Rights of Third Parties) Act 1999, except data subjects to the extent the Transfer Clauses give them third-party beneficiary rights.
10.8 Governing law and jurisdiction. This DPA, and any dispute or claim arising out of or in connection with it (including non-contractual disputes or claims), is governed by the law that governs the Agreement and is subject to the same courts' jurisdiction. If the Agreement does not say, the law of England and Wales applies and the courts of England and Wales have exclusive jurisdiction. This does not affect the governing law and jurisdiction set out in the Transfer Clauses.
10.9 Signing. A signed DPA may be signed electronically, including through DocuSign, and in counterparts.
Signature
For the signed version only. If this DPA applies through the online version (clause 1.3), no signature is needed.
| Item | Provider | Client |
|---|---|---|
| Company | Aspis Protocol Ltd | [Client name] |
| Company number and country | 15506799, England and Wales | [number], [country] |
| Agreement this DPA applies to | Subscription Services Agreement dated [date] | Subscription Services Agreement dated [date] |
| Contact for notices and Personal Data Breaches | info@aspis.finance | [email address] |
| Signature | ||
| Name | Renat Vakhabov | [name] |
| Title | Director | [title] |
| Date |
Annex 1 – Details of processing
| Item | Details |
|---|---|
| Parties and roles | Client: controller, or processor for its own customer (clause 3.1). Provider: processor, or sub-processor. Contact details: as in the Agreement and the signature table. Exporter and importer roles under the Transfer Clauses: as in clause 6. |
| Subject matter | The provision of the Services under the Agreement, including white-label or embedded use of the Aspis vault infrastructure (including copy-trading and leaderboard vaults), the AgentCouncil platform and its Agents System, Aspis Copilot, custom API connectors and a dedicated dashboard. |
| Duration | The term of the Agreement, and afterwards until the Client Personal Data is deleted or returned under clause 5.9. |
| Nature of the processing | • Hosting and storage • Analysis • AI processing • Building and relaying on-chain transactions on the instructions of the Client or wallets it authorises • Reporting • Support |
| Purpose | To provide the Services to the Client so that it can offer them in its own product, on its documented instructions (clause 5.1). These are also the business purposes for clause 7. |
| Data subjects | • The Client's end users, including lead traders and followers in copy-trading • The Client's Authorised Users, as content • People whose wallet addresses the Client submits for analysis |
| Categories of personal data | • Wallet and vault addresses • On-chain activity linked to them (deposits, withdrawals, trades, holdings) • Portfolio inputs • Identifiers the Client assigns to its end users • Telegram ID, username and messages, where the Client's product uses the Copilot or Telegram integration • Email addresses, where the Client sends them • Prompts and chat messages sent to the Agents System or AI features, and AI outputs • Trading instructions and orders • API request metadata, including the IP addresses of callers |
| Special category data | None. The Client must not send special category, criminal offence or children's data (clause 4.4). |
| Frequency | Continuous. |
| Retention | • Server logs: up to 90 days • Backups: up to 35 days • Other Client Personal Data: deleted or returned within 30 days after the end of the Agreement, except where the law requires the Provider to keep it |
| Sub-processors | The services, locations and transfer mechanisms in Annex 3, for the purposes and duration above. |
| Supervisory authority | The Information Commissioner's Office for the Provider. Where the EU SCCs apply, as in clause 6.4. |
Annex 2 – Technical and organisational measures
Encryption
- TLS for all connections, including between servers and to databases.
- Data at rest encrypted by the hosting provider (Google Cloud default encryption).
Credentials and sign-in
- Passwords stored only in hashed form.
- Vault API keys and organisation API keys stored only as hashes, and shown once.
- Sign-in tokens expire after 15 minutes, and refresh tokens after 7 days.
Access control and separation
- Least-privilege staff access, with key staff actions recorded in an audit log.
- Client Data logically separated by organisation account.
Retention
- Server logs kept for up to 90 days.
- Backups kept for up to 35 days.
Payments
- Card data handled by Revolut, which is certified to the payment card industry standard (PCI DSS). The Provider never receives full card numbers.
On-chain controls
- No party, including the Provider, can transfer or withdraw depositors' assets from a vault to an external address. Depositors keep the redemption rights enforced by the vault smart contract.
- Vault code cannot be upgraded.
- The guardian is a multisig: any action needs approval from at least two of the Provider's authorised signers.
Incident response
- The Provider notifies the Client without undue delay, and in any case within 48 hours of becoming aware, of a Personal Data Breach (clause 5.8).
People
- Staff and contractors are bound by confidentiality.
Annex 3 – Sub-processors
| Sub-processor | Service | Location | Transfer mechanism (UK GDPR) |
|---|---|---|---|
| Google Cloud (Google Cloud EMEA Ltd / Google LLC) | Hosting and databases | United States and other countries | UK-US data bridge, or IDTA / UK Addendum |
| Vercel Inc. | Dashboard and web app hosting | United States and other countries | UK-US data bridge, or IDTA / UK Addendum |
| Cloudflare, Inc. | DNS, content delivery and protection | Global | UK-US data bridge, or IDTA / UK Addendum |
| Amazon Web Services | File storage (logos and images) | Germany | UK adequacy regulations (EEA) |
| Better Stack | Server logs | EU or United States | EU: UK adequacy regulations US: UK-US data bridge, or IDTA / UK Addendum |
| OpenAI | AI processing for the Agents System and Copilot (paid API; no training on the Provider's data) | United States | UK-US data bridge, or IDTA / UK Addendum |
| Google (Gemini API) | Backup AI provider (paid tier; no training on the Provider's data) | United States | UK-US data bridge, or IDTA / UK Addendum |
| Alchemy | Reading blockchain data and sending transactions | United States | UK-US data bridge, or IDTA / UK Addendum |
| Amplitude, Inc. | Usage analytics and session recordings in Provider-hosted dashboards and apps, only where the person using them has given consent (typed text masked) | United States | UK-US data bridge, or IDTA / UK Addendum |
| Reown (WalletConnect) | Connecting wallets in Provider-hosted dashboards and apps | United States | UK-US data bridge, or IDTA / UK Addendum |
| ipinfo.io | Looking up the country of an IP address | United States | UK-US data bridge, or IDTA / UK Addendum |
| Google Workspace (Google LLC) and Zoho | Sending service emails, for example invitations and notifications, to Authorised Users or End Users | Google: United States and other countries. Zoho: European Union | Google: UK-US data bridge, or IDTA / UK Addendum. Zoho: UK adequacy regulations (EEA) |
The UK-US data bridge is relied on only where the Sub-processor is certified to it; otherwise the IDTA or UK Addendum in its data processing terms applies, with an assessment of the transfer. For EU GDPR data, the EU equivalents apply: the EU-US Data Privacy Framework for certified US Sub-processors, or otherwise the EU SCCs Module 3.
Not Sub-processors.
- Telegram is a platform the Client or its end users choose to use. It acts as an independent controller.
- Public blockchains are public networks. Transactions sent to them are public and permanent.
- DEX aggregators (1inch, Odos and Uniswap) receive vault addresses, tokens and amounts to route trades. They are third-party protocols the Client chooses to use.
- Providers the Provider uses only for its own controller purposes (such as payments, accounting and business email) are listed in its Privacy Policy.
Annex 4 – Transfer mechanisms
| Scenario | Mechanism |
|---|---|
| Client in the UK sends Client Personal Data to the Provider | No Restricted Transfer |
| Provider sends UK GDPR data to a Sub-processor in the EEA | UK adequacy regulations |
| Provider sends UK GDPR data to a certified US Sub-processor | UK-US data bridge |
| Provider sends UK GDPR data to any other Sub-processor outside the UK | IDTA or UK Addendum, with an assessment of the transfer |
| Client in the EEA sends Client Personal Data to the Provider | EU adequacy decisions for the UK (renewed 19 December 2025, until 27 December 2031) |
| As above, if those decisions stop applying | EU SCCs Module 2 (Client as controller) or Module 3 (Client as processor) (clause 6.2) |
| Provider sends EU GDPR data onward to a Sub-processor outside the UK and EEA | EU SCCs Module 3, or the EU-US Data Privacy Framework for certified US Sub-processors |
| Provider returns Client Personal Data to, or gives access to, a Client outside the UK and EEA (for example in the US or UAE), where this is a Restricted Transfer | UK Addendum with EU SCCs Module 4, or the IDTA if agreed; EU SCCs Module 4 where the EU GDPR applies (clause 6.3) |
| Provider makes Member Data available to a Client outside the UK, where this is a Restricted Transfer | UK Addendum with EU SCCs Module 1, or the IDTA if agreed (clause 8.7) |
| Client or its end users use Telegram, public blockchains or DEX aggregators | Not a transfer to a Sub-processor. The Client chooses these services and describes them to its end users |