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:

Each is a "party", and together they are the "parties".

1.2 Signed version. Where the parties sign this DPA:

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:

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:

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:

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:

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 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.

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:

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.

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.

On request, the Provider will confirm the deletion in writing.

5.10 Information and audits.

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:

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:

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:

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:

8.4 The Provider's responsibilities. The Provider will:

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.

Annex 1 – Details of processing

Annex 2 – Technical and organisational measures

Encryption

Credentials and sign-in

Access control and separation

Retention

Payments

On-chain controls

Incident response

People

Annex 3 – Sub-processors

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.

Annex 4 – Transfer mechanisms