ULTRAMINT — PRIVACY POLICY

Data Controller: Vivaach SRL (Costa Rica)
Version: v1.10 — [DRAFT]
Effective date: [insert]
Last updated: [insert]

---

Capitalized terms used but not defined in this Privacy Policy have the meanings given in the ULTRAMINT Terms of Service.

---

1. Data Inventory, Processing Purposes, and Legal Bases

1.1 Data Controller

(a) Vivaach SRL, a company organized under the laws of Costa Rica ("Vivaach," "we," "us," or "our"), is the data controller for all Personal Data processed off-chain in connection with the ULTRAMINT prediction-market platform (the "Platform").

(b) On-chain data. Public wallet addresses, transaction hashes, smart contract interaction records, and other data written to the Blockchain are publicly visible, immutable, and permanently recorded on a decentralized public ledger. Once data is committed to the Blockchain, it is outside the exclusive custody or control of Vivaach SRL. Vivaach SRL does not act as a data controller in respect of data that exists solely on the Blockchain and that Vivaach SRL did not independently collect or store off-chain. Your use of a public blockchain inherently makes certain transaction information publicly accessible, and neither Vivaach SRL nor any other party can erase, modify, or restrict access to on-chain data.

(c) Contact. For all data-protection inquiries, requests, and complaints: legal@ultramint.xyz.

1.2 Categories of Personal Data Collected

We collect and process the following categories of data. We do not collect, store, or have access to your private keys, seed phrases, or signing credentials at any time.

---

1.2.1 On-Chain Data (Publicly Visible)

Note: On-chain data is inherently public and pseudonymous. Any person with access to a blockchain explorer can view it. On-chain data cannot be erased, modified, or restricted by Vivaach SRL or any other party — see Section 2.2(b) for implications on the right to erasure.

Security control: Transaction authorization signatures stored off-chain by the Platform's infrastructure are encrypted at rest using cloud key-management service (KMS) encryption, with each ciphertext cryptographically bound to its row identity, so that a compromised database row alone is insufficient to reconstruct the signature.

---

1.2.2 Off-Chain Technical and Infrastructure Data

Relay data retention: Transaction relay data described above is retained for thirty (30) days after a submission reaches a terminal state (confirmed on-chain or definitively failed), and is deleted on your request in accordance with the Terms of Service (§5.6(c)) and Section 2.4 (Data Rights Request Process) of this Privacy Policy. This period is enforced automatically. A purge process running on the Platform's backend destroys, without any request from you and without operator action, the signature, its nonce, your wallet address, the stake amount, the selected outcome, and the validity window of every relay past that period — together with the encrypted signature material itself and the payment provider's own copy of the submission. What remains afterwards is the skeleton of the record with no personal data in it: that a relay occurred, which market it concerned, and its resulting transaction hash, which is in any event public on the Blockchain. Section 4.1 describes the method; Section 2.2(a)(iii)(A) describes why the thirty days is a floor rather than a period you can shorten by request. Data written to the Blockchain by a relayed transaction is public, permanent, and cannot be deleted by the Platform or by anyone.

Note on audit log immutability: Certain backend audit-log tables are configured with database-level restrictions that prevent deletion at the application layer. Where an erasure request relates to data in such tables, we will comply to the extent technically feasible and will disclose any limitation in our response to your request — see Section 2.2(d) (Audit-Log Limitation).

---

1.2.3 Onboarding and Eligibility Data

Current state of identity verification. As disclosed in the Terms of Service (§4.8(a)), the Platform does not presently conduct identity verification ("Know Your Customer" / KYC), sanctions or watchlist screening, source-of-funds checks, or age-document verification of any user. Eligibility is currently enforced by the geographic and anti-circumvention controls described in the Terms of Service (§4.5) and by your own representations and self-certifications under §4.1. Where the Platform introduces identity verification or sanctions screening in the future, the following will apply:

• KYC identity documents will be submitted to and processed by an independent, third-party KYC processor acting as a data processor under a Data Processing Agreement ("DPA") with Vivaach SRL. Vivaach SRL will not directly store, access, or retain copies of your identity documents, photographs, or biometric extracts. Vivaach SRL will receive only the verification result (pass/fail/pending), risk scores, and associated metadata necessary to enforce eligibility requirements.
• Sanctions and watchlist screening will be conducted by a third-party compliance screening provider under a DPA with Vivaach SRL.
• The third-party processors and links to their respective privacy policies will be identified in the Platform's onboarding flow and in an updated version of this Privacy Policy before any such processing begins.

---

1.2.4 Account and Profile Data

Two settings, and exactly what each one does.

(a) Discoverability. Turning it off removes your handle, your bio, your images and the link to your profile from the surfaces where the Platform names people. It does not remove you from rankings: a leaderboard that excluded you would misstate every other participant's position, so your row remains and is shown without your identity.

(b) Hiding your activity. Turning it on stops the Platform from emitting your positions into other people's feeds, alerts, and activity views. It does not make those positions private. Every position, settlement, and claim is recorded on a public blockchain and is permanently attributable to your wallet address, as described in Sections 2.1 and 2.3. This setting governs what the Platform's own surfaces show; it has no effect on the blockchain, on anyone reading it, or on any third party that has already read it.

The leaderboard prints your handle next to what your wallet settled. Two boards are published: traders ranked on realized profit and loss, creators on the fees their markets accrued, each over a window you choose. Every figure on them is arithmetic over settlements that are already recorded on the public blockchain — the Platform computes a sum and attaches the name from your profile; it learns nothing new about you to do it. Three consequences are worth stating plainly. A window counts money claimed inside it rather than markets resolved inside it, so a position you won and have not claimed appears on no board, and the dates a board names are a settlement clock rather than a record of when you were right. Being ranked is not a setting: the row is computed from the chain, so there is nothing to opt out of — which is the same reason paragraph (a) keeps your row when you turn discoverability off. It is then a rank and an amount, with no handle, no image, no link to a profile and no button offering to follow it. And a board is a public page, readable by visitors who are not signed in and by anything that reads the page, so a figure on it is published to everybody rather than to the accounts that follow you.

Following is published on both sides. A follow is a record about two accounts and it is shown on both: the account you followed gains a follower, you gain a following, and either list is readable by any visitor to the profile it belongs to. There is no private follow. An account that has turned discoverability off is listed without its identity, on the basis given in paragraph (a) above — it is still counted, because a count that omitted it would misstate the account being looked at, and it is still named to nobody.

Blocking is private, and it ends any follow in both directions. A block is disclosed to nobody, including the account blocked, and appears in no list. Its effect is symmetrical and immediate: any follow between the two of you is deleted at that moment, both ways, and neither account is assembled into the other's feeds, follower lists, or comment threads for as long as the block stands. Two consequences of that are deliberate. A follower count can exceed the number of accounts a particular visitor is shown, because the count is what the record says and the list is what that visitor may be shown. And a block does not retract what has already been published — Section 2.3 applies — nor does it reach the blockchain, where every position remains attributable to the wallet that took it irrespective of who has blocked whom.

A take is published to everyone who follows you, and it is your own words. Posting one puts it in the feed of every account that follows you at the time they read it, and — where you attached a market — beside that market. Unlike a position, it is not a fact the Platform observed about you: it is content you authored, so nothing about it is bucketed, hidden by the activity setting in paragraph (b), or otherwise softened. Deleting a take removes it from the Platform's surfaces and from its database; it does not reach anybody who has already read it, quoted it, or screenshotted it, and Section 2.3 applies to it in full. Where a take is attached to a market that is restricted to an allowlist, the take is shown without the market it names, so a private market's existence is not disclosed by a sentence about it.

An invitation can name somebody who has no account here, and their address came from the sender. A Town's admin invites a person by handle, by wallet address, or by email address. In the first two cases nothing new is collected: a handle is resolved to the wallet address the account already publishes, and the invitation waits on the Platform for that person to sign in. In the third, the sender types an address we did not previously hold, and we use it once — to send that person a message saying who invited them and to what — and for nothing else. It is not added to a mailing list, it is not used to build a profile, and it does not create an account. The invitation is bound to the address it names: the link in the message identifies the invitation but grants nothing, and the credential that admits somebody to the Town is released only to an account whose own address matches. Forwarding the message therefore admits nobody. If you receive such a message and do not recognise the sender, ignoring it is sufficient — the invitation expires by itself, we tell the sender nothing about whether you opened it, and §2.2 governs how long the record is kept.

A comment is published under the market it is about, and deleting one may leave the space it occupied. A comment is pulled rather than pushed: it is shown to whoever opens that market, including a visitor who is not signed in, and it is not sent into anybody's feed. Like a take, it is content you authored, so the activity setting in paragraph (b) does not govern it. Deleting a comment nobody has replied to removes it and its text from the Platform's database outright. Where somebody has replied to it, the text is destroyed and the empty position remains, marked as removed and attributed to nobody — because deleting the record would delete the replies hanging from it, which are another person's words. The same is true when you close your account, and Section 2.2(f)(ii)(G) states it there. Section 2.3 applies in full either way: deletion does not reach anybody who has already read it.

Reporting is private, and it keeps a copy of what you reported. A report is recorded against the account that filed it and is shown to nobody else, including the account reported. It stores the reported text as it stood at the moment you reported it, because a reviewer has to see the thing the objection was about and the author may delete or change it in the meantime — which means a report can outlive the content it concerns. Reporting something flags it for review; it does not hide it. That is deliberate: content that disappeared on the first report would make the report button a way to silence people rather than a way to reach a reviewer.

A handle can be changed at most once every thirty days. The limit is not a technical constraint. On a platform where people follow one another, a freely rotating handle lets a reputation built under one name be handed to a different occupant, which those following it cannot distinguish from having chosen the new one. A handle you release becomes available to anyone.

What you publish is published. A handle, a bio, a banner, a social link, a take, a comment, and the accounts you follow are personal data you have chosen to make public, under Section 2.3. They are visible to every visitor, including visitors who are not signed in, and to anything that reads a public page. Do not put in them anything you would not publish, and do not put in them personal data about anybody else.

---

1.2.5 AI-Assisted Market Creation and AI Oracle Resolution Data

The Platform uses third-party AI and search services in two distinct contexts: assisting you when you create a market, and resolving markets assigned to the AI Oracle. Both are described below.

What is and is not sent.

(a) Market-creation chat. Only the text you type into the market-creation chat is sent to Anthropic for that feature. Wallet addresses, transaction data, position information, and email addresses are not transmitted for market-creation assistance.

(b) AI Oracle resolution. Only the market's question, resolution criteria, any creator-supplied source URLs, and publicly retrieved evidence are transmitted to the search and LLM-judge providers. No wallet address, position, stake amount, account identifier, or email address is transmitted to any AI Oracle provider. The market question and criteria are, in any event, publicly displayed on the market card before any position is taken.

(c) Creator-authored content. Because market questions and resolution criteria are authored by users, you should not include personal data about yourself or any other person in a market you create. Content you author is public and is transmitted to the providers listed above.

---

1.2.6 Notification, Watchlist, and Price-Alert Data

The Platform keeps a notification tray in your account, and mails you about the notices in it that you have not turned off. The tray is filled by the market lifecycle (a market you hold resolving, value becoming claimable) and by instructions you give it yourself (following a market, arming a price alert).

What the notification data does not contain, and why that is structural. The notification tray and the delivery records are held in the Platform's market database, and your email address is not in that database — it is on your account record, in a separate schema, reachable only by the component that sends the mail. The two are joined only at the moment a message is composed, and nothing writes the address back. Accordingly:

    (a) A delivery record names a notice and a status. It does not record your email address, the subject line, or the body of the message. It therefore says no more about you than "a notice about this wallet was mailed", and it is retained for the same period as the tray row it belongs to (see §4.1).

    (b) A notice never asserts a payout. Where a notice carries a figure it is a cost basis or a crossing price, labelled as such; the amount claimable from a market is determined by the market contract on chain and by nothing the Platform mails you.

    (c) Notification emails contain no tracking pixel, no open or click tracking, and no advertising content. Every message carries a link to the settings page holding your topic preferences.

    (d) Following a market, arming a price alert, and reading a notice are recorded against your wallet address, not against your email address or display name.

---

1.2.7 Support Correspondence Data

The Help Center provides a support email address (§4.6). Contacting support is entirely at your option: no notice, action, or feature depends on it.

What support is not given, and what that means for you. Support correspondence is not automatically joined to your account, wallet address, balance, or positions. Support therefore knows only what you include in your message — which is why a question about a specific market or transaction usually requires you to name it yourself, and why support cannot be used as a route to information about an account you have not demonstrated is yours.

    (a) Do not send private key material. Support will never ask for a seed phrase, a private key, or a signature, and no genuine support request requires one. Anything you include in an email is readable by whoever answers it.

    (b) Support is never a channel for eligibility, resolution, or fund decisions. What a market resolves to is determined under the Market Resolution Policy and what you can claim is determined by the market contract on chain; nothing said in support correspondence changes either.

---

1.2.8 Data We Do Not Collect

For the avoidance of doubt, the Platform does not collect:

• Passwords — the Platform uses passwordless authentication via Magic.link; no password is created, stored, or transmitted
• Phone numbers
• Payment card or bank account details — the Platform is funded exclusively via stablecoin on the Blockchain; no fiat payment rails are accepted
• Private keys, seed phrases, or signing credentials — the Platform's non-custodial architecture means these never leave your device or your authentication provider's secure enclave
• Biometric data (except to the extent incidentally contained in identity documents, if KYC is introduced in the future — see §1.2.3)
• Email open, click, or engagement tracking — the notification emails described in §1.2.6 carry no tracking pixel and no instrumented links, so the Platform does not know whether a message was opened or a link followed

---

1.3 Purposes of Processing and Legal Bases

This Section sets out the specific purposes for which we process your Personal Data, together with the legal basis on which each processing activity rests. Where we reference GDPR Article 6 bases, we do so to provide a transparent framework for all users regardless of jurisdiction; to the extent Costa Rican data-protection law (Ley No. 8968) or other applicable law requires a different or additional basis, we rely on the corresponding lawful basis under that law.

---

1.3.1 Platform Functionality and Contract Performance

---

1.3.2 Legal Compliance, Geographic Restrictions, and Eligibility Enforcement

---

1.3.3 Security, Integrity, and Abuse Prevention

---

1.3.4 Dispute Resolution, Regulatory Cooperation, and Record Retention

---

1.3.5 [Reserved]

---

1.3.6 Webhook Notifications

Note: Webhook events carry transaction data — your wallet address, stake amount, selected outcome, shares, and transaction hash — to endpoints registered with the Platform. Webhook delivery is not a user-facing feature and is not something you configure or control.

    (a) Where the registered endpoint is operated by the Platform, the data does not leave Vivaach SRL's control.

    (b) Where a registered endpoint is operated by a third party (for example, an integration partner consuming settlement events), that third party receives the transaction data listed above and processes it under its own arrangements. Any such recipient is engaged under a Data Processing Agreement, and Vivaach SRL will identify any category of third-party webhook recipient in Section 1.6 and in an updated version of this Privacy Policy before, or promptly upon, any such endpoint being registered.

    (c) Data transmitted via webhooks is limited to the transaction details necessary for the event notification. It does not include your email address, display name, or authentication data. The underlying transaction data is, in any event, public and permanent on the Blockchain (see Sections 1.1(b) and 2.1).

Not the same thing as your notifications. Webhook delivery is machine-to-machine integration infrastructure with registered endpoints; it is not the user-facing notification tray or the email described in Section 1.3.7, and the two share no data path.

---

1.3.7 Notifications, Watchlist, Price Alerts, and Notification Email

Your preferences govern, and the master switch beats everything. Your settings hold one switch per topic and one overall switch. Turning the overall switch off stops all notification mail, including the transactional topics — the notices remain in your in-app tray, so nothing is withheld from you, only un-mailed. Two notice kinds (in-app announcements and release notes) are never mailed under any setting.

No marketing use. Your address is used for the notices described above and for service and legal communications. It is not used for advertising, is not shared with any advertiser or data broker, and is not used to profile you or to make any automated decision about you.

---

1.3.8 Support Correspondence

Not used for anything else. Support correspondence is not analysed to profile you, is not used for marketing, and is not fed into any automated decision about you or about a market. It is also not a record of eligibility: nothing you say to support establishes or defeats the self-certification described in §1.2.3.

---

1.4 Sensitive Personal Data

(a) No active collection. Vivaach SRL does not actively collect, request, or process any special categories of personal data ("sensitive data") as defined in GDPR Article 9, including but not limited to:

• racial or ethnic origin;
• political opinions;
• religious or philosophical beliefs;
• trade union membership;
• genetic data;
• biometric data for identification purposes;
• data concerning health; or
• data concerning a person's sex life or sexual orientation.

(b) No private cryptographic material. The Platform's non-custodial architecture means that your private keys, seed phrases, and wallet-signing credentials are never transmitted to, received by, accessible to, or stored by Vivaach SRL or any of its service providers. Your Wallet is a non-custodial embedded wallet provisioned through the Platform's authentication provider (Magic.link), and your keys are managed within that provider's secure infrastructure and are not accessible to Vivaach SRL — see Terms of Service §5.9(c).

(c) KYC documents — future processing. If identity-verification documents are collected in the future under Section 1.2.3, they may incidentally contain sensitive personal data (for example, a photograph on an identity document). Such data will be submitted directly to the third-party KYC processor acting under a DPA and processed solely for the purposes of identity verification. Vivaach SRL will not receive, view, store, or retain copies of these documents or any biometric extracts derived from them.

(d) Incidental inference. We acknowledge that certain data we do collect (such as IP-derived geolocation) could, in combination with external data, theoretically permit inferences about characteristics that might be considered sensitive. We do not make, store, or act on any such inferences, and we process IP-derived data solely for the functional and legal-compliance purposes stated in Section 1.3.2.

---

1.5 Legitimate Interest Balancing

Where we rely on legitimate interest (GDPR Article 6(1)(f)) as a legal basis, we have conducted a balancing assessment that considers:

(a) The nature and purpose of the processing — each legitimate-interest processing activity described above is directed at a specific, concrete objective (security, market integrity, legal compliance, or platform functionality) rather than a broad or open-ended purpose.

(b) The impact on data subjects — the data processed is limited to what is necessary for the stated purpose; we do not use it for profiling, scoring, automated decision-making with legal effects, marketing, or any purpose unrelated to those stated. The processing primarily involves pseudonymous identifiers (wallet addresses, IP addresses) rather than directly identifying information. The public rankings described in §1.2.4 order participants by their own on-chain settlement figures: they are a published ordering rather than an assessment of you, no automated decision is taken on them, and nothing about your access to the Platform, the price you trade at, or your eligibility follows from where you appear on one.

(c) Reasonable expectations — a user of a real-money, compliance-regulated prediction-market platform would reasonably expect that the operator monitors for fraud, manipulation, sanctions evasion, and geographic circumvention, and that the operator retains records for dispute resolution and regulatory cooperation.

(d) Safeguards — we apply data-minimization principles (Section 4.1(a)), access controls, encryption of sensitive fields at rest (including KMS-encrypted transaction signatures), and retention limits (Section 4.1), and honor your right to object to legitimate-interest processing where applicable (Section 2.2(a)(vi)).

---

1.6 Third-Party Service Providers Receiving Personal Data

The following third-party service providers receive Personal Data in connection with the processing activities described in this Section. Each acts as a data processor on behalf of Vivaach SRL unless otherwise noted. Further detail on data sharing, international transfers, and sub-processor management is provided in Section 3 (Third-Party Processors, Service Providers, and Regulatory Disclosures).

---

2. On-Chain Data Immutability, Decentralized Networks, and User Data Rights

2.1 Blockchain Data: Immutability and Public Nature

(a) As introduced in Section 1.1(b), data written to the Blockchain — including public wallet addresses, transaction hashes, smart contract interaction records, market positions, resolution outcomes, settlement allocations, and claims — is publicly visible, immutable, and permanently recorded on a decentralized public network.

(b) Vivaach SRL does not own, operate, or control the underlying blockchain network or any of its nodes, validators, or sequencers. Vivaach SRL does not have the technical ability to modify, censor, delete, or restrict access to any data written to the Blockchain. No person or entity has this ability; immutability is a fundamental property of the technology.

(c) Gasless relay does not create privacy. Transactions submitted via the Relay Service (as described in Section 1.2.2) are broadcast to and permanently recorded on the public Blockchain. The Relay Service pays the network gas fee from an operator-controlled wallet, which means the relayer's address — not yours — appears as the gas payer. However, your signed transaction authorization and the resulting on-chain position are publicly and permanently attributable to your wallet address. Relay intermediation does not anonymize, obscure, or shield your on-chain activity in any way.

(d) Pseudonymity, not anonymity. On-chain data is pseudonymous — it is identified by wallet address rather than by name. Any person with access to a blockchain explorer can view the complete transaction history of any wallet address. Vivaach SRL does not publish or disclose any link between your wallet address and an identity you have not put on your profile; your email address in particular is published nowhere. What the Platform does publish against your wallet address is the profile you chose to give it — your handle, your images and any social account you elected to show — wherever it names people, including the feeds, activity views and rankings described in Section 1.2.4, and turning discoverability off withdraws it from those surfaces. However, Vivaach cannot control, and is not responsible for, any correlation or re-identification performed by third parties using publicly available on-chain data, off-chain data, or any combination thereof.

---

2.2 Scope of Your Data Rights: Off-Chain Data vs. On-Chain Data

Your rights under applicable data-protection law differ materially depending on whether your Personal Data is held off-chain (under Vivaach SRL's direct or instructed control) or on-chain (on the public Blockchain). This Section explains that distinction and its consequences.

2.2(a) Rights That Apply to Off-Chain Personal Data

The following rights apply to Personal Data that Vivaach SRL collects, controls, or processes off-chain, as described in Sections 1.2.2 through 1.2.6 of this Privacy Policy. These rights are provided under the General Data Protection Regulation ("GDPR"), the UK General Data Protection Regulation ("UK GDPR"), Costa Rican data-protection law (Ley No. 8968 and its regulations), and any other applicable data-protection legislation:

(i) Right of Access (GDPR Art. 15; UK GDPR Art. 15; Ley 8968 Art. 5). You may request a copy of the off-chain Personal Data we hold about you, including data held by our third-party processors on our behalf (as listed in Section 1.6).

(ii) Right to Rectification (GDPR Art. 16; UK GDPR Art. 16; Ley 8968 Art. 5). You may request correction of inaccurate off-chain Personal Data. Note: Certain off-chain data reflects historical facts that were accurate at the time of creation and cannot be "corrected" in a meaningful sense — for example, relay transaction records documenting the parameters of a transaction you actually signed, or self-certification responses you actually submitted. Where rectification is not appropriate, Vivaach will add a supplementary statement to the record.

(iii) Right to Erasure (GDPR Art. 17; UK GDPR Art. 17; Ley 8968 Art. 5). You may request deletion of off-chain Personal Data, subject to the following limitations:

    (A) Retention obligations. Vivaach may retain data where necessary for compliance with a legal obligation, for the establishment, exercise, or defense of legal claims, or for the retention periods described in Section 4.1 (Data Retention and Destruction). Relay data is subject to a minimum thirty (30) day retention period after terminal state, as disclosed in Section 1.2.2 and committed to in the Terms of Service (§5.6(c)); that period is a floor and not a ceiling — an erasure request does not shorten it, and at its expiry the data is destroyed automatically whether or not you ask.

    (B) Audit-log structural limitation. See Section 2.2(d) below.

    (C) Data held by third-party processors. See Section 2.2(e) below.

    (D) Erasure by closing your account. You do not have to submit a request to exercise this right for the data an account closure covers. The account settings carry a Close account control that performs the erasure directly, without operator involvement, and reports what it deleted. Section 2.2(f) describes what it deletes, what it does not, and the one condition under which it is refused.

(iv) Right to Restrict Processing (GDPR Art. 18; UK GDPR Art. 18). You may request restriction of processing in the circumstances specified by applicable law (for example, where you contest the accuracy of the data, where the processing is unlawful but you oppose erasure, or where Vivaach no longer needs the data but you require it for legal claims).

(v) Right to Data Portability (GDPR Art. 20; UK GDPR Art. 20). You may request to receive, in a structured, commonly used, and machine-readable format, the off-chain Personal Data you provided to us, where the processing is based on consent or contractual necessity and is carried out by automated means. You may also request that we transmit this data directly to another controller, where technically feasible.

(vi) Right to Object (GDPR Art. 21; UK GDPR Art. 21). Where we process your Personal Data on the basis of legitimate interest (see Section 1.3), you may object to such processing at any time. We will cease the processing unless we demonstrate compelling legitimate grounds that override your interests, rights, and freedoms, or the processing is necessary for the establishment, exercise, or defense of legal claims.

(vii) Right to Withdraw Consent (GDPR Art. 7(3)). Where processing is based on your consent, you may withdraw it at any time, and withdrawal does not affect the lawfulness of processing conducted before withdrawal. One activity rests on consent: notification email under a non-transactional topic (Section 1.3.7), withdrawn through the email settings on your account, which also carry a single switch that stops all notification mail.

---

2.2(b) Rights That Cannot Be Exercised Against On-Chain Data

The Right to Erasure, the Right to Rectification, the Right to Restrict Processing, and the Right to Data Portability — to the extent any of these would require modification, deletion, or restriction of data recorded on the public Blockchain — cannot be exercised against on-chain data.

This is not a policy limitation that Vivaach SRL has chosen to impose. It is a technical impossibility inherent to public blockchain architecture. No person, entity, data controller, data processor, court, or regulator has the ability to modify, delete, or restrict data committed to the Blockchain. Vivaach SRL cannot comply with such a request because compliance is technically impossible.

This limitation:

(i) persists indefinitely — it is not subject to any time limit, contractual expiration, or account termination;

(ii) applies regardless of any legal or regulatory requirement that would otherwise mandate erasure or modification — because the impossibility is structural, not discretionary; and

(iii) applies to all on-chain data, including but not limited to: your wallet address, transaction hashes, positions taken, resolution outcomes, settlement allocations, claims, and any other data recorded by the Protocol Contracts.

Your privacy interest in on-chain data is limited to the pseudonymity afforded by the Blockchain's address-based identification system. Vivaach SRL takes the following measures to preserve that pseudonymity:

(A) Vivaach does not publish any mapping between a wallet address and an identity its holder has not put on a public profile, and publishes no email address anywhere. A handle, an image or a social link you chose to publish is shown against your wallet address wherever the Platform names people, including the rankings in Section 1.2.4; discoverability withdraws it.

(B) Vivaach does not provide blockchain analytics services or tools that facilitate re-identification or correlation of wallet addresses with off-chain identities.

(C) Vivaach will not voluntarily disclose the association between a wallet address and an off-chain identity to any third party, except as required by applicable law, court order, or regulatory demand (see Section 3.3).

---

2.2(c) Indexed On-Chain Data

The Platform durably indexes certain on-chain data off-chain (as described in Section 1.2.1) for display through the Interface — including wallet addresses, positions, and market state. Upon a valid erasure request:

(i) Vivaach may remove your wallet address and associated indexed records from its own off-chain database.

(ii) This does not erase the underlying on-chain data, which remains publicly accessible via any blockchain explorer or direct node query, regardless of whether the Platform's index retains it.

(iii) Removal from the Platform's off-chain index may impair or prevent your ability to use the Interface with that wallet address, as the Interface relies on indexed data to display your positions and activity.

---

2.2(d) Audit-Log Limitation

As disclosed in Section 1.2.2, certain backend audit-log tables are configured with database-level access controls that revoke DELETE, UPDATE, and TRUNCATE privileges at the database-role level. This means that the application — and Vivaach SRL as its operator — cannot delete or modify records in these tables through any application-layer operation.

Where an erasure or rectification request encompasses data stored in such tables:

(i) Vivaach will disclose this limitation in its response to your request, identifying the specific data affected and the reason it cannot be deleted or modified.

(ii) Vivaach will restrict access to the data to the minimum personnel necessary for the purposes for which retention is justified.

(iii) The data will be used only for security monitoring, regulatory compliance, legal defense, and audit purposes — and for no other purpose.

(iv) This retention is justified under GDPR Art. 17(3)(b) (compliance with a legal obligation requiring processing under Union or Member State law) and Art. 17(3)(e) (archiving in the public interest, scientific or historical research purposes, or statistical purposes, insofar as the right to erasure would render impossible or seriously impair the achievement of the objectives of that processing).

---

2.2(e) Data Held by Third-Party Processors

For Personal Data held by the Platform's third-party processors (as listed in Section 1.6):

(i) Upon receiving a valid, verified rights request, Vivaach will instruct the relevant processor to delete, restrict, or provide access to your data in accordance with the applicable Data Processing Agreement.

(ii) Where a processor's own retention policies, technical limitations, or legal obligations prevent immediate compliance (for example, Anthropic's retention of market-creation chat text under its own data policies), Vivaach will:

    (A) disclose this limitation and the reason for it in its response to your request; and

    (B) provide the processor's identity and contact information so you may direct an independent request to the processor.

(iii) Future KYC processor. Where identity-verification services are introduced in the future and identity documents are held by a third-party KYC processor (see Section 1.2.3), erasure requests for those documents must be directed to the KYC processor. Vivaach will facilitate the request and provide the processor's contact information, but Vivaach does not hold, and cannot directly delete, data it never received or stored.

---

2.2(f) Closing Your Account

The account settings include a Close account control. It is an exercise of the Right to Erasure that does not require a request, a verification exchange, or any act by an operator: it runs when you confirm it and reports what it deleted.

(i) What it deletes. Your email address and its verification records; your display name, which becomes a value derived from your account identifier and identifies nobody; your handle, which is released and becomes available to anyone; your bio; your avatar and your banner; your profile appearance preference; every social account handle and profile link recorded against your account; every follow, in both directions, so the accounts you followed lose a follower and the accounts following you lose a following; every block you recorded and every block recorded against you; every take you ever posted, together with every report anyone filed about one of them; every like you gave a comment; every comment you ever posted that nobody has replied to, together with every report anyone filed about one of those, and the text of every comment somebody has replied to, which is destroyed in place under paragraph (ii)(G) below; the link between your account and your wallet; your notification email preferences; every active session, so the closure signs you out everywhere; any pending beta-access grant; any staged tenant-registration continuation stored in your browser; and, on the Platform's market databases, your watchlist, your price alerts, and your entire notification tray together with the delivery records belonging to those notifications.

(ii) What it does not delete, and you will be shown this before you confirm. The confirmation screen enumerates every category below, because a closure flow that implied total erasure while audit logs are undeletable by design would be a misrepresentation rather than a simpler interface:

    (A) Backend audit logs — undeletable at the database-role level, as described in Section 2.2(d) and Section 4.1.

    (B) Self-certification records and the client evidence recorded with them — retained for the period in Section 4.1, under Section 2.2(a)(iii)(A) and GDPR Art. 17(3)(e). A closure does not withdraw a representation you made.

    (C) On-chain data — outside anyone's custody, as described in Sections 2.1 and 2.2(b). The rankings and activity views computed from it (Section 1.2.4) therefore keep counting your wallet after a closure; what they lose is the handle, so the row reverts to an address.

    (D) Relay data still inside the thirty-day window — destroyed by the automatic purge described in Section 1.2.2 on the schedule stated there, which is a commitment about the age of a record rather than about the state of an account. A closure neither accelerates nor delays it.

    (E) Your wallet. The wallet is provisioned and held by Magic.link, not by Vivaach SRL. Vivaach issues the deletion request for your identity to Magic under the applicable DPA (see Section 4.1), but the key material is Magic's and Vivaach cannot delete it. If you may ever need to sign with that wallet again, establish your own recovery method with Magic before you close the account.

    (F) Reports you filed about somebody else's content. A report is a record about the account reported, and closing your own account does not withdraw an objection a reviewer may still be acting on. What the closure removes is the link back to you: the report continues to point at your account record, which by then identifies nobody, and the reason and the copied text remain for the review. Reports filed about your own takes are deleted with the takes, per paragraph (i).

    (G) The position a comment somebody replied to occupied. Your words are destroyed — the text is emptied, the comment is marked removed, and it names nobody, so nothing about you survives it. The row itself remains, because the replies underneath it are attached to it and deleting it would delete another person's words as a side effect of your closure. A report anyone filed about such a comment likewise remains, so that the thread a reviewer is looking at still exists — which means the copy of the text taken at the time of the report remains in that report, visible to the Platform's reviewers and on no public surface, for the period in Section 4.1.

    (H) Pseudonymous tenant-access history. Closing your account revokes its tenant membership but retains the membership row, registration-link claim provenance, and tenant/member state-transition audit under the opaque account identifier. Those records retain none of your erased email, wallet, profile, or Magic identity and contain no raw registration token; an operator transition may identify the authorizing administrator by their public wallet. They remain so the Platform can account for bearer-link use and preserve the access-control decisions that were made.

(iii) The one condition under which it is refused. A closure is refused while the account still holds value — an open position, an unclaimed payout, or a USDC balance in the wallet — and it is equally refused where the Platform could not confirm that the account holds none, because a check that did not answer is not an empty account. The refusal names which of the two it is. Positions on the Platform are held to resolution and cannot be exited early, so where a position is the obstacle the closure becomes available once that market resolves and you have claimed. This condition exists for your protection: closing the account removes the link between your account and the wallet, and Vivaach cannot recover funds from a wallet whose keys it has never held.

(iv) Signing in again. Signing in with the same email address after a closure creates a new and empty account. It does not restore the closed one, which no longer holds anything to restore. Joining an organization again requires opening a still-valid registration link, creates membership for the new account identifier, and consumes a new use of that link.

---

2.3 Voluntary Assumption of Public Exposure

(a) Your wallet address and its history are public. When you sign up, a non-custodial embedded wallet is provisioned to you through the Platform's authentication provider (Magic.link); the Platform does not support connecting an external or pre-existing wallet as your account identity or as a signer for any position. You may connect an external wallet solely to transfer USDC into that embedded Wallet; doing so does not make it your account, and the Platform does not record its address (§3.1(j)). Note, however, that such a transfer is itself public: it permanently links the two addresses on-chain even though the Platform stores no connection between them. By using that wallet on the ULTRAMINT interface, you knowingly and voluntarily make that wallet address and its full on-chain transaction history publicly visible and permanently associated with all Platform interactions conducted through that address. This includes every market position taken, every claim submitted, and every settlement received.

(b) Gasless relay does not create privacy. The Relay Service submits your transactions to the Blockchain using an operator-controlled wallet for gas payment. This means the relayer's address — not yours — appears as the gas payer in the transaction's from field. However:

    (i) Your signed transaction authorization (which you created and submitted to the Relay Service) specifies your wallet address as the position holder.

    (ii) The resulting on-chain position, settlement, and claim records are publicly and permanently attributable to your wallet address.

    (iii) Relay intermediation does not anonymize, obscure, or shield your on-chain activity in any way. Any person inspecting the smart contract's state or event logs can identify your wallet as the holder of the position.

(c) Privacy best practices. If you wish to limit the extent to which your on-chain Platform activity can be correlated with your identity or other blockchain activity, we recommend the following precautions. These are suggestions only and are not guarantees of privacy or anonymity:

    (i) Use a dedicated wallet address exclusively for Platform activity, separate from wallets you use for other purposes, exchanges, or platforms where your identity is known.

    (ii) Do not publicly disclose the wallet address you use on the Platform, including on social media or in public profiles.

    (iii) Be aware that on-chain analytics services operated by third parties may correlate wallet addresses across platforms, exchanges, and transactions using publicly available data — regardless of any action taken or not taken by Vivaach SRL.

    (iv) Understand what a public profile does. Showing a social account on your profile deliberately connects an identity you hold elsewhere to a wallet whose entire position history is public and permanent. That connection is the feature, and it cannot be undone on the blockchain's side: hiding the link afterwards removes it from the Platform's pages, not from anything that has already read them. Section 1.2.4(b) applies equally — the setting that hides your activity does not make it private.

(d) No guarantee of pseudonymity. While Vivaach SRL publishes no link between your wallet address and an identity you have not put on your profile, Vivaach cannot guarantee that your pseudonymity will be preserved. Third parties, including blockchain analytics firms, researchers, other users, and law enforcement, may independently correlate your wallet address with your identity using publicly available on-chain data combined with off-chain information from any source. Vivaach SRL is not responsible for, and has no control over, any such correlation or re-identification.

---

2.4 Data Rights Request Process

2.4(a) How to Submit a Request

All data subject access requests ("DSARs"), deletion requests, rectification requests, restriction requests, portability requests, objection notices, and any other rights requests under this Section or applicable law must be submitted in writing to:

legal@ultramint.xyz

Your request should include: (i) a clear description of the right you wish to exercise; (ii) the wallet address(es) and/or email address(es) to which the request relates; and (iii) any information necessary to verify your identity and your association with the data (see Section 2.4(b)).

2.4(b) Verification Requirements

Before processing any rights request, Vivaach must verify your identity and your association with the Personal Data to which the request relates. This protects you against unauthorized access to, or deletion of, your data. Depending on the nature of your request, one or more of the following verification methods will be required:

(i) Wallet ownership verification. For requests relating to data associated with a wallet address — including relay data, indexed on-chain data, and any position or transaction records — you must sign a challenge message provided by Vivaach with the private key of the wallet address in question. This cryptographic proof is the primary and preferred verification method.

(ii) Email verification. For requests relating to account or profile data associated with an email address — including your display name, social handles, profile images, and authentication records — you must submit the request from the email address associated with your account, or complete an email-based verification challenge provided by Vivaach.

(iii) Combined verification. For comprehensive requests covering both wallet-associated data and email-associated data, both methods described in (i) and (ii) may be required.

(iv) Rate-limiting and anomaly controls. To mitigate the risk that a compromised wallet key could be used to extract off-chain Personal Data, Vivaach applies the following safeguards to the DSAR process:

    (A) Cooling-off period. Upon receipt of a verified access request, Vivaach will notify the email address associated with the wallet's account (if any) that a data-subject access request has been received and that the response will be delivered no earlier than seventy-two (72) hours after notification. If the account holder contacts Vivaach during the cooling-off period to dispute the request, Vivaach will suspend processing and require additional verification before proceeding.

    (B) Scope limitation on access responses. Access-request responses will provide email addresses in a partially redacted format (for example, s***@example.com) unless the requestor independently provides the full email address as part of the verification, or the request is accompanied by both wallet-signature and email verification under subsection (iii).

    (C) Anomaly flags. Vivaach may apply additional verification steps, delay, or decline a request where indicators suggest the signing key may be compromised, including requests from an IP address or device not previously associated with the account, requests submitted immediately after a wallet-draining event, or multiple DSAR requests from different wallet addresses in a short period.

(v) Alternative verification where wallet access is lost. If you are unable to complete wallet-signature verification because you have permanently lost access to your wallet — for example, because of loss of the email address or authentication factor associated with your embedded wallet, or loss of any private key you have exported — Vivaach will consider alternative verification methods on a case-by-case basis, which may include:

    (A) verification of the email address associated with the account, together with corroborating information (such as approximate dates and amounts of transactions, markets participated in, or profile details);

    (B) any other method that provides Vivaach with reasonable assurance of your identity and association with the data, while protecting against unauthorized access.

Vivaach will not refuse a rights request solely because wallet-signature verification is unavailable, provided that an alternative method can reasonably establish your identity and your association with the data. Where no method provides sufficient assurance, Vivaach will explain the reason and, where feasible, suggest steps you can take.

(vi) No rights request will be processed without successful completion of the applicable verification procedure. This safeguards your data against unauthorized disclosure. Verification requirements are proportionate to the sensitivity of the data and the risk that an unauthorized person could exploit the request process.

2.4(c) Response Timeline

(i) Acknowledgment. Vivaach will acknowledge receipt of your request within five (5) business days of receipt.

(ii) Substantive response. Vivaach will complete the request or provide a substantive response — including any limitations, partial denials, and the reasons for each — within thirty (30) calendar days of successful verification of your identity.

(iii) Extension. Where a request is complex, involves coordination with multiple processors, or is one of several concurrent requests from the same person, the response period may be extended by an additional thirty (30) calendar days. Vivaach will notify you of any extension within the initial 30-day period, together with the reasons for the delay.

2.4(d) Scope of Response

A response to your request will include, as applicable:

(i) For access requests: All off-chain Personal Data held by Vivaach SRL associated with your verified wallet address(es) and/or email address(es), including data held by processors on Vivaach's behalf.

(ii) Limitation disclosures: A clear statement of any data that cannot be erased, rectified, restricted, or ported, together with the specific reason — whether blockchain immutability (Section 2.2(b)), audit-log structural limitation (Section 2.2(d)), legal retention obligation (Section 4.1), or processor retention policy (Section 2.2(e)).

(iii) Processor coordination: For data held by third-party processors, confirmation that deletion or restriction instructions have been issued to the processor under the applicable DPA, or the processor's identity and contact information where Vivaach cannot directly execute the request.

(iv) Exclusion of on-chain data. The response will not include on-chain data, which is publicly and freely available and can be accessed directly via any blockchain explorer without Vivaach's involvement.

2.4(e) Fees

Vivaach will not charge a fee for processing your first rights request in any twelve-month period. Where subsequent requests within the same period are manifestly unfounded or excessive — in particular because of their repetitive character — Vivaach may:

(i) charge a reasonable fee based on the administrative costs of complying; or

(ii) refuse to act on the request,

in either case providing reasons for the decision, in accordance with GDPR Art. 12(5) and UK GDPR Art. 12(5).

2.4(f) Right to Lodge a Complaint

If you are not satisfied with Vivaach's response to your rights request, or if you believe that Vivaach has processed your Personal Data in violation of applicable data-protection law, you have the right to lodge a complaint with the competent supervisory authority:

(i) GDPR (EU/EEA): The supervisory authority of the EU/EEA Member State in which you habitually reside, in which you work, or in which the alleged infringement occurred. A list of supervisory authorities is available at the European Data Protection Board website.

(ii) UK GDPR: The Information Commissioner's Office (ICO), United Kingdom.

(iii) Costa Rica (Ley No. 8968): PRODHAB — Agencia de Protección de Datos de los Habitantes, Costa Rica.

This right to lodge a complaint is without prejudice to any other administrative or judicial remedy available to you.

---

3. Third-Party Processors, Service Providers, and Regulatory Disclosures

3.1 Service Providers and Third-Party Data Processors

Vivaach SRL engages third-party service providers to deliver, operate, secure, and improve the Platform. Each provider listed in this Section that receives or processes Personal Data on behalf of Vivaach SRL does so as a data processor under a Data Processing Agreement ("DPA") requiring compliance with applicable data-protection law, unless otherwise noted. Section 1.6 provides a summary table; this Section provides operational detail.

---

3.1(a) Infrastructure and Content Delivery

Cloudflare provides content-delivery network (CDN), web application firewall (WAF), distributed denial-of-service (DDoS) mitigation, geographic-restriction enforcement, and image-hosting services for the Platform.

Cloudflare processes this data at points of presence worldwide. Vivaach SRL has instructed Cloudflare, under the applicable DPA, to retain HTTP request logs (including IP addresses and associated metadata) for a period of [thirty (30) / ninety (90)] days via Cloudflare Logpush or an equivalent log-archival mechanism. After the instructed retention period, Cloudflare deletes the logs in accordance with the DPA. Vivaach SRL does not store end-user IP addresses in its own application databases; the Cloudflare log archive remains the sole stored record of IP-address-level access data. The one derivative Vivaach SRL does store — a keyed, non-reversible digest written with a self-certification record — is described in the fifth bullet below and in §1.2.3.

The Platform's backend does process the originating IP address transiently, in memory, for the geographic and anonymizing-network determination described in Section 3.2(b). That processing is not retained in the form received:

• The address is submitted to IPinfo and discarded once a determination is returned.
• The resulting determination is held in a short-lived in-memory cache. Where the determination concerns a network (a VPN, proxy, Tor, or datacenter finding), it is filed against the network's routing prefix, which describes an operator's infrastructure rather than an individual. Where it concerns an individual address, it is filed against a truncated cryptographic digest of that address computed under a secret key, so that the cache entry does not contain, and cannot be reversed to, the address it describes.
• The cache is held only in the memory of a running process. It is not written to any database, is not backed up, and does not survive a restart or a deployment.
• No log line, span, database row, or other persisted record produced by the Platform contains an end-user IP address.
• One derivative of the address is persisted, and it is not the address. Where you submit a self-certification (§1.2.3), the record of that confirmation stores a truncated cryptographic digest of the address the confirmation arrived from, computed under a secret key held by Vivaach SRL. It is stored because a record of what you accepted, with no indication of the client it was submitted from, is of materially less evidentiary value. It is not reversible to the address, is not usable to locate you, is written only when you take that one affirmative act, and is deleted with the record it belongs to; its retention period is in §4.1.

Google Cloud Platform (GCP) provides cloud infrastructure hosting. All data that Vivaach SRL stores directly — including relay data, indexer data, audit logs, and account/profile data — resides in GCP Cloud SQL under Vivaach SRL's direct administrative control. GCP acts as a data processor providing infrastructure services and does not access, analyze, or use the stored data for its own purposes under the applicable DPA.

---

3.1(b) Authentication and Wallet Provisioning

Magic.link provides passwordless authentication and embedded wallet provisioning. When you sign in to the Platform:

Magic.link is the Platform's primary identity processor. Your email address is held by Magic.link and is also stored on your account record in the Platform's own database, which is where the notification email described in Section 1.3.7 is addressed from. See Section 1.2.3.

---

3.1(c) [Reserved]

---

3.1(d) [Reserved]

---

3.1(e) AI Services — Market Creation and AI Oracle Resolution

The Platform engages third-party AI and search providers in two distinct contexts.

(1) AI-assisted market creation. Anthropic provides AI services for the Platform's market-creation feature.

Only the text you type into the market-creation chat is sent to Anthropic for this feature. Wallet addresses, transaction data, position information, and email addresses are not transmitted. Retention is subject to Anthropic's own data policies; see Section 1.2.5.

(2) AI Oracle resolution. Markets that have no dedicated data-field API are resolved by the Platform's AI Oracle, an automated evidence-based pipeline. Resolving such a market transmits data to the following providers:

SearXNG (metasearch) and crawl4ai (page crawler) are self-hosted by the Platform; evidence processed through them does not leave the Platform's infrastructure to a third party.

Multiple providers receive the same evidence. The AI Oracle's consensus rules require the winning outcome to be supported by judges drawn from at least two distinct model families. One resolution therefore transmits the same evidence bundle to more than one of the providers above.

No account or transaction data is sent to any AI Oracle provider. Wallet addresses, positions, stake amounts, account identifiers, and email addresses are not transmitted for resolution. The market question and criteria transmitted are, in any event, publicly displayed on the market card before any position is taken. Retention by each provider is at that provider's discretion under its own terms.

---

3.1(f) Consent Management

CookieYes provides cookie and tracking consent management.

CookieYes does not receive your wallet address, email, transaction data, or any other Personal Data beyond consent preferences.

---

3.1(g) Blockchain Access (RPC Provider)

The Platform connects to the Blockchain through a third-party RPC (Remote Procedure Call) provider. The specific provider is to be confirmed; it will be an EVM-compatible RPC service (such as Alchemy, Infura, or an equivalent). Public RPC nodes may be used as a fallback. You should read this subsection carefully — it describes data transmissions to a third party that occur automatically when you use the Interface, even if you do not initiate a transaction.

Data is transmitted to the RPC provider through two distinct paths:

Path 1 — Relay-submitted transactions (write operations). When you take a position, submit a claim, or perform any other write operation, the Relay Service submits your signed transaction to the Blockchain through the RPC provider on your behalf. In this path, the RPC provider receives the Relay Service server's IP address (not yours), together with your wallet address and the full transaction parameters.

Path 2 — Direct Interface queries (read operations). When the Interface loads on-chain data — such as your positions, balances, market states, or eligibility status — your browser may make RPC calls directly to the RPC provider. In this path, the RPC provider receives both your IP address and your wallet address. This occurs automatically when you use the Interface and does not require you to initiate a transaction. Simply viewing a market page, checking your positions, or loading the Interface may trigger direct RPC calls that transmit your IP address and wallet address to the RPC provider.

What this means for you. By using the ULTRAMINT Interface, you should understand that:

(i) A third-party RPC provider may receive your IP address, your wallet address, and details of every on-chain read or write request made through the Interface — including requests for data about markets you view but never participate in.

(ii) This data transmission is inherent to how blockchain-connected applications work. The Interface must query the Blockchain through an RPC provider to display on-chain information, and each query transmits connection-level data. This is not unique to ULTRAMINT — it is a characteristic of virtually all blockchain-connected applications.

(iii) The RPC provider sees your wallet address on every blockchain interaction, including eligibility pre-checks for transactions that are subsequently rejected and never recorded on-chain.

Data boundary: what Vivaach SRL collects vs. what the RPC provider receives.

The following table clarifies the separation between data that Vivaach SRL collects and controls, and data that the RPC provider independently receives as a consequence of blockchain-connected architecture. These are distinct data flows governed by distinct privacy obligations.

Vivaach SRL's liability for RPC provider data practices.

(i) For relay-submitted transactions (Path 1), the RPC provider acts as a data processor receiving data from Vivaach SRL's Relay Service under the applicable DPA. For direct browser-to-RPC calls (Path 2), your browser transmits data directly to the RPC provider's infrastructure without passing through Vivaach SRL's servers. On Path 2, the RPC provider receives your data independently of Vivaach SRL and processes it under its own privacy policy as an independent controller of that data. Vivaach SRL does not receive, intercept, log, or have access to the data your browser transmits directly to the RPC provider on Path 2.

(ii) Vivaach SRL is not liable for any data breach, unauthorized disclosure, security incident, policy change, data retention decision, or data misuse by the RPC provider — whether the data was received via Path 1 or Path 2.

(iii) The RPC provider's own privacy policy and terms of service govern its handling of data it receives through RPC calls. Vivaach SRL will identify the provider by name and link to its privacy policy in an updated version of this Privacy Policy and in Section 1.6 once the provider is confirmed.

(iv) Retention of data (including IP addresses and wallet addresses) by the RPC provider is at the provider's sole discretion under its own terms. Vivaach SRL does not control, and makes no representations regarding, the RPC provider's data-retention periods.

(v) If you are concerned about IP-address exposure to the RPC provider on Path 2, you may use a VPN or other privacy-preserving network tool when accessing the Interface. However, the use of VPNs or anonymization tools must comply with the Terms of Service — in particular, they may not be used to circumvent geographic restrictions or access the Platform from a Restricted Jurisdiction (see Terms of Service §4.5).

---

3.1(h) The Blockchain (Not a Processor)

The Blockchain is a public, decentralized, and permissionless ledger. It is not a data processor and is not subject to a DPA. Data written to the Blockchain — including wallet addresses, transaction hashes, positions, resolution outcomes, and settlements — is public, permanent, and undeletable. No person or entity controls the Blockchain, and Vivaach SRL has no ability to modify, restrict, or erase on-chain data. See Sections 1.1(b) and 2.1.

---

3.1(i) Fiat-to-Stablecoin On-Ramp (Onramper) — An Independent Controller

(a) The Interface offers a card and bank-transfer route for funding your embedded Wallet, provided by Onramper and the payment and identity partners Onramper selects. It is presented in a hosted window operated by Onramper, not by Vivaach SRL.

(b) What the Platform sends. The Platform generates a widget address that names your own embedded Wallet address and the target network, and signs it. The signature exists so that the destination cannot be altered: the address is generated on the Platform's server from your session and never from anything you or any other party supplies in the request, so a purchase made through the Interface can only ever deliver funds to your own Wallet.

(c) What the Platform does not receive. Everything you enter in Onramper's window — payment-card details, bank details, and any identity-verification data or documents its partners require — is provided by you directly to Onramper and its partners. Vivaach SRL does not receive, intercept, store, or have access to any of it. The Platform does not know whether you completed a purchase except insofar as funds arrive at your Wallet on the public Blockchain.

(d) Onramper is an independent controller, not the Platform's processor. In respect of the data you give it, Onramper and its partners act on their own account and under their own terms and privacy policies. Any identity or source-of-funds verification they perform is theirs, conducted for their own compliance obligations, and is not performed for, directed by, or reported to Vivaach SRL. Vivaach SRL is not liable for their data practices, their retention decisions, their verification outcomes, or any breach or disclosure affecting data they hold.

(e) A purchase is a transaction with a third party. Pricing, fees, exchange rates, limits, refusals, refunds, and settlement times are set and controlled by Onramper and its partners. The Platform makes no representation about them and is not a party to your purchase. Where a purchase fails after you have paid, your recourse is against Onramper and its partners under their terms, not against Vivaach SRL.

---

3.1(j) External-Wallet Connector (Reown AppKit) — Funding Only

(a) The Interface lets you connect a wallet you already hold for one purpose only: to send USDC into your embedded Wallet. The connector is Reown AppKit (formerly WalletConnect).

(b) A connected wallet is never your identity. It is not your account, not a login, not a signer for any position, order, claim, or resolution, and not a withdrawal destination. Your account and every position you hold remain bound to the embedded Wallet provisioned at sign-up (see §1.2.1 and Terms of Service §5.9). Connecting a wallet does not change, add to, or transfer your account.

(c) The connected address is not sent to the Platform. It is held in your browser for the duration of the transfer and is used there to build the transfer transaction. Vivaach SRL's servers do not receive it and its databases do not record it. The Platform learns of the transfer only as the public Blockchain records it.

(d) On-chain, the two addresses become permanently linked. This follows from the Blockchain, not from anything the Platform stores: a transfer from your external wallet to your embedded Wallet is a public, permanent record connecting those two addresses, visible to anyone. If the external wallet is associated with your identity anywhere — an exchange withdrawal, a public donation, an ENS name — that association can be followed to your embedded Wallet and therefore to your Platform activity. If you do not want that link to exist, fund your Wallet by card instead, or from an address you do not mind associating with your Platform activity. See §2.1 on the public nature of on-chain data.

(e) Reown's connector stores connection-session data in your browser. Its behaviour is governed by Reown's own documentation and is outside Vivaach SRL's direct control, in the same way described for the authentication provider in the Cookie Policy §1.6.

---

3.1(k) Application Email Delivery (Resend)

(a) The notification email described in Section 1.3.7 and Town invitations addressed to an email are delivered by Resend. Resend acts as a data processor under the applicable DPA with Vivaach SRL and is listed in Section 1.6.

(b) What it receives. One recipient address per message, and the message itself — a subject line and body stating the relevant notice and market or the Town invitation and its invitation link. It receives no wallet address, position, balance, or account identifier other than as the message's own content discloses, and it receives nothing at all about a message that is not sent.

(c) No engagement tracking. Open tracking, click tracking, and link instrumentation are disabled for the sending domain. Messages contain no tracking pixel and no rewritten links, so neither Resend nor Vivaach SRL learns whether you opened a message or followed a link in it. This is the same position stated for the Interface in Section 4.2(d) and the Cookie Policy §1.5.

(d) What the Platform records about notification delivery. Vivaach SRL records, in its own database, that a given notice was mailed and how that attempt ended — a notification identifier, a status, timestamps, an attempt count, and on a failure the reason the provider gave. It records no address, no subject line, and no message body, so the delivery record adds no category of personal data beyond the notification it refers to, and it is retained for the same period as that notification (Section 4.1).

(e) Bounces and unsendable addresses. A provider refusal is recorded as a failed attempt and the durable notification process may retry it up to its attempt limit. The notice remains in your in-app tray, and the underlying address on your account is unchanged — the Platform does not delete or alter your sign-in address on the basis of a delivery failure.

(f) Where delivery is not configured, no message is sent and nothing is transmitted to Resend. This is a deployment state rather than a user-facing setting, and it does not affect the in-app notification tray.

---

3.2 Geolocation, Fraud Prevention, and Compliance Screening Processors

3.2(a) Current Geolocation and Access-Control Measures

The Platform enforces geographic restrictions using two mechanisms, applied at different points:

(i) Cloudflare's CF-IPCountry header provides a country-level determination for each incoming request at the CDN edge. It is used for the Platform's front-end access decisions, subject to the corroboration requirement stated below.

(ii) IPinfo provides the determination used for the Platform's backend enforcement, which is the point at which access to authenticated actions is actually granted or refused. Cloudflare forwards the originating IP address to the backend, which submits it to IPinfo and receives a country, a first-level administrative region where available, and the anonymizing-network signals described in Section 3.2(b). IPinfo is a data processor under a DPA with Vivaach SRL and is listed in Section 1.6.

A Cloudflare country determination is used only where the network edge itself corroborates it. The header is, in isolation, a value a client could state about itself, so the Platform accepts it only when it matches the country the edge independently attributes to the connection, and discards it entirely when it does not, or when the edge could not place the connection at all (including requests arriving through Tor). A request with no corroborated country has no country for these purposes; it is not treated as originating anywhere, and a stated country cannot be used to obtain access.

3.2(b) VPN, Proxy, and Anonymization Detection

The Platform uses IPinfo to detect access from VPNs, proxies, Tor exit nodes, hosting and datacenter infrastructure, and other anonymization tools. IPinfo returns, for a submitted IP address, whether the address is associated with any of those categories. The Platform also continues to benefit from Cloudflare's built-in threat-intelligence signals (including bot scores and known-proxy flags) at the network edge.

A positive anonymizing-network finding refuses the request. It is treated as a positive finding rather than an absence, which is the distinction that governs what happens when the determination cannot be made: where IPinfo is unreachable or returns no determination, the Platform does not treat the request as anonymized. It instead applies the fail-closed rule stated in Prohibited Jurisdictions §4.1.1 to actions requiring a determination, and serves public pages normally.

What IPinfo receives is the IP address and nothing else. It does not receive your wallet address, your account handle, your email address, the action you were attempting, or any other Platform data, and it therefore cannot associate a lookup with an identified user. The address is submitted transiently and the retention limits stated in Section 3.1(a) apply to the result.

3.2(c) On-Chain Wallet Screening

As disclosed in the Terms of Service (§4.8(a)), the Platform does not presently conduct identity verification, sanctions screening, or wallet screening of any kind. No on-chain wallet screening vendor (such as a blockchain analytics or sanctions-list screening provider) is currently deployed.

3.2(d) Future Compliance Processors

The Platform reserves the right to introduce, at any time and without prior individual notice:

(i) Further IP-intelligence and geolocation vendors beyond the IPinfo deployment disclosed in Sections 3.2(a) and 3.2(b) (such as MaxMind, IPQualityScore, or equivalent services) for enhanced jurisdiction detection, VPN and proxy identification, and circumvention-attempt detection.

(ii) On-chain wallet screening vendors (such as TRM Labs, Chainalysis, or equivalent services) for screening wallet addresses against OFAC Specially Designated Nationals lists, sanctions lists, and databases of addresses associated with illicit activity. Wallet screening is conducted against your public wallet address on the public Blockchain and does not require transmission of any private data, private keys, or off-chain identity information.

(iii) Identity-verification (KYC) and sanctions-screening vendors as described in Section 1.2.3.

Where any such vendor is introduced:

    (A) it will operate as a data processor under a DPA with Vivaach SRL;

    (B) its identity and the categories of data it receives will be disclosed in an updated version of this Privacy Policy and in Section 1.6;

    (C) processing will be limited to the specific compliance or security purpose for which the vendor is engaged; and

    (D) outputs from these services — including risk scores, screening results, and geo-determination data — may result in access restriction, account suspension or termination, position-taking prohibition, relay-service refusal, or forfeiture of funds where circumvention of geographic restrictions, sanctions exposure, or other prohibited activity is detected, in accordance with the Terms of Service.

---

3.3 Compliance with Legal Process and Law Enforcement Disclosures

3.3(a) Disclosures Required by Law

Vivaach SRL may disclose your off-chain Personal Data — including IP-derived information (where held by Cloudflare or another processor), relay logs, wallet addresses, self-certification records, account and profile data, and any other data described in Section 1.2 — to third parties where such disclosure is:

(i) required by applicable law, statute, regulation, or binding legal obligation;

(ii) ordered by a court of competent jurisdiction;

(iii) demanded by a regulatory authority, financial intelligence unit, or law-enforcement agency through a lawful subpoena, investigation order, or equivalent legal instrument; or

(iv) necessary to comply with sanctions, anti-money-laundering, counter-terrorism financing, or other financial-crime regulations applicable to Vivaach SRL under Costa Rican law or any other law to which Vivaach SRL is subject.

3.3(b) Governing Legal Framework

Vivaach SRL is organized under and operates subject to the laws of Costa Rica. Vivaach SRL will evaluate any disclosure request — including requests from foreign governments, regulators, or law-enforcement authorities — under applicable Costa Rican legal standards, including Ley No. 8968 (Protection of the Person Against the Processing of Their Personal Data) and its regulations, the Costa Rican Code of Criminal Procedure (where applicable to mutual legal assistance requests), and any applicable international treaty or cooperation agreement to which Costa Rica is a party.

Requests from foreign authorities will be assessed for legal validity and procedural adequacy under Costa Rican law before any disclosure is made. Vivaach SRL is not obligated to comply with a foreign request that lacks legal force in Costa Rica, unless required to do so under an applicable treaty, international agreement, or Costa Rican court order recognizing the foreign request.

3.3(c) Disclosures for Platform Protection

Vivaach SRL may also disclose your off-chain Personal Data where reasonably necessary to:

(i) enforce the Terms of Service, including investigating suspected violations of the market-integrity, anti-manipulation, or anti-circumvention provisions;

(ii) establish, exercise, or defend against legal claims, Disputes, or arbitration proceedings;

(iii) protect the security, integrity, or availability of the Platform, its infrastructure, or its users; or

(iv) prevent or investigate fraud, manipulation, unauthorized access, or other harmful activity.

3.3(d) On-Chain Data and Legal Process

On-chain data — including wallet addresses, transaction hashes, positions, resolution outcomes, and settlements — is publicly visible on the Blockchain and accessible to any person, including law enforcement and regulators, directly via any blockchain explorer or node query. No legal process directed at Vivaach SRL is necessary to access on-chain data, and Vivaach SRL has no ability to prevent such access.

Where a legal request seeks on-chain data, Vivaach SRL will inform the requesting party that the data is publicly available and, where appropriate, indicate how it may be accessed directly. Vivaach SRL may supplement such a response with off-chain data (such as the association between a wallet address and an email address or account) to the extent required by the applicable legal instrument.

3.3(e) Notice to Users

Where legally permitted, Vivaach SRL will make reasonable efforts to notify you before disclosing your Personal Data in response to legal process, so that you may seek legal advice or challenge the request. However, Vivaach SRL may be prohibited from providing such notice by law, court order, or regulatory directive — including gag orders, secrecy requirements, or the nature of the investigation — and in such cases will comply with the prohibition without notice to you.

---

3.4 International Data Transfers and Safeguards

3.4(a) Location of Processing

Vivaach SRL is established in Costa Rica. Your off-chain Personal Data may be processed and stored by Vivaach SRL's third-party processors in jurisdictions outside Costa Rica, including the United States (where several of the Platform's processors maintain infrastructure) and the European Union. By using the Platform, you acknowledge that your data may be transferred to and processed in these jurisdictions.

3.4(b) Transfer Mechanisms for EU and UK Personal Data

The Platform is not offered to, and does not knowingly serve, residents of the European Union, the European Economic Area ("EU/EEA"), or the United Kingdom ("UK"), as set out in the Prohibited Jurisdictions Policy and the Terms of Service (§4.2). Vivaach SRL does not target or direct its services to individuals in those jurisdictions. Notwithstanding the foregoing, to the extent Vivaach SRL incidentally processes any Personal Data of individuals subject to the GDPR or UK GDPR (for example, where a visitor reaches the Interface before being geoblocked), the following safeguards apply.

Where Personal Data of EU/EEA or UK residents is transferred to a third-party processor located in a country that has not received an adequacy decision from the European Commission or the UK Secretary of State (as applicable), Vivaach SRL will ensure that appropriate safeguards are in place, including:

(i) Standard Contractual Clauses ("SCCs") adopted by the European Commission (for GDPR transfers) or the International Data Transfer Agreement / International Data Transfer Addendum issued by the ICO (for UK GDPR transfers), incorporated into the DPA with the relevant processor;

(ii) any supplementary measures necessary to ensure that the level of protection afforded to the transferred data is not undermined, as determined by Vivaach SRL's transfer impact assessment; or

(iii) any other lawful transfer mechanism recognized under applicable law, including binding corporate rules, approved codes of conduct, or approved certification mechanisms.

3.4(c) Costa Rican Data Transfer Requirements

Under Ley No. 8968 and its regulations, transfers of Personal Data to countries that do not provide an adequate level of protection require appropriate safeguards. Vivaach SRL relies on contractual protections (including DPAs incorporating data-protection obligations equivalent to those required under Costa Rican law) to safeguard international transfers of Personal Data processed under its control.

3.4(d) DPA Requirements

All third-party processors that receive Personal Data on behalf of Vivaach SRL are subject to a Data Processing Agreement that requires, at a minimum:

(i) processing only on Vivaach SRL's documented instructions;

(ii) confidentiality obligations on all personnel with access to the data;

(iii) appropriate technical and organizational security measures;

(iv) restrictions on sub-processing without Vivaach SRL's prior written authorization;

(v) assistance with data-subject rights requests and data-breach notifications; and

(vi) deletion or return of Personal Data upon termination of the processing relationship, subject to legal retention obligations.

---

3.5 Business Transfers, Governance Changes, and Cessation of Operations

3.5(a) Mergers, Acquisitions, and Restructuring

In the event of a merger, acquisition, reorganization, restructuring, asset sale, or change of control of Vivaach SRL — including any change in the ownership or control of its parent entity — off-chain Personal Data held by Vivaach SRL may be transferred to the successor or acquiring entity as part of that transaction.

Any such transfer will be subject to:

(i) the data-protection obligations set out in this Privacy Policy and applicable law;

(ii) notice to you, provided within a reasonable period before or after the transfer takes effect, disclosing the identity of the successor entity and any material changes to data-processing arrangements; and

(iii) your continued right to exercise the data rights described in Section 2 with respect to the transferred data.

3.5(b) Transition to Decentralized or DAO-Governed Operations

In the event that the Platform's frontend operations, governance, or data-processing responsibilities transition in whole or in part to a decentralized autonomous organization ("DAO"), community-governed structure, or other non-corporate entity:

(i) Vivaach SRL will provide reasonable advance notice of any material change to data-processing arrangements, including the identity (to the extent ascertainable) of the successor data controller or the governance mechanism that will assume data-processing responsibilities;

(ii) Vivaach SRL will use commercially reasonable efforts to ensure that successor data-protection obligations are in place before any transfer of off-chain Personal Data to a successor controller; and

(iii) where no successor controller with adequate data-protection obligations can be identified, Vivaach SRL will treat the transition as a cessation of operations under Section 3.5(c) with respect to the affected data.

3.5(c) Insolvency or Cessation of Operations

In the event of the insolvency, dissolution, or permanent cessation of operations of Vivaach SRL:

(i) off-chain Personal Data held by Vivaach SRL will be deleted or anonymized to the extent technically feasible, subject to any applicable legal retention obligations (including regulatory record-keeping, pending litigation holds, and audit requirements);

(ii) Vivaach SRL will instruct all third-party processors to delete Personal Data held on its behalf, in accordance with the applicable DPAs;

(iii) on-chain data is unaffected by the cessation of Vivaach SRL's operations — it remains permanently on the Blockchain, publicly accessible, and outside anyone's control; and

(iv) the audit-log structural limitation described in Section 2.2(d) may prevent deletion of certain audit-log records even in a cessation scenario. Where this applies, the data will be secured to the extent feasible and access restricted.

---

4. Data Retention, Security, Cookies, Regional Disclosures, and Policy Updates

4.1 Data Retention and Destruction

Vivaach SRL retains off-chain Personal Data only for the period necessary to fulfill the purpose for which it was collected, unless a longer period is required by applicable law, regulatory obligation, court order, or for the establishment, exercise, or defense of legal claims. The following table sets out the retention periods for each category of data described in Section 1.2.

4.1(a) Data Minimization

Vivaach SRL applies data-minimization principles by limiting the collection and retention of off-chain Personal Data to what is necessary for the specific purposes set out in Section 1.3. Where data is no longer necessary for its stated purpose and is not subject to a legal retention obligation, it will be deleted or anonymized.

4.1(b) Destruction Standards

Upon expiration of the applicable retention period, off-chain data will be:

(i) securely deleted from the Platform's databases and any backup or replica systems within a reasonable period; or

(ii) irreversibly anonymized such that it can no longer be attributed to an individual wallet address, email address, or user session.

Destruction methods include logical deletion from databases, issuance of deletion instructions to third-party processors under their respective DPAs, and (where technically feasible) cryptographic erasure of KMS-encrypted fields by destroying the corresponding encryption key.

4.1(c) Regulatory Override

Retention periods set out in this Section may be extended where required by:

(i) applicable law, statute, or regulation;

(ii) a court order or regulatory demand;

(iii) a litigation hold arising from pending or reasonably anticipated legal proceedings;

(iv) a regulatory investigation or audit; or

(v) a data-preservation request or legal-hold notice from a law-enforcement authority, regulatory body, or court, in which case Vivaach SRL will instruct its relevant processors (including Cloudflare) to preserve the specified data for the duration required by the legal process.

Where a retention period is extended under this subsection, Vivaach will notify you to the extent legally permitted and will delete the data upon the expiration of the overriding obligation.

4.1(d) Legal Process Preservation

Where Vivaach SRL receives a lawful preservation request, litigation hold, data-freeze order, or equivalent legal instrument from a court, regulator, law-enforcement authority, or other competent body — or where Vivaach SRL reasonably anticipates such a request — Vivaach SRL will suspend the automated deletion of all data within the scope of the request or anticipated request, regardless of the retention periods stated in this Section, and will retain the data for the duration specified in the legal instrument or, where no duration is specified, until the requesting authority confirms that the data is no longer required. Users will not be notified of a preservation hold where notification is prohibited by law, court order, or regulatory directive, or where notification would compromise an ongoing investigation.

---

4.2 Cookies, Local Storage, and Tracking Technologies

4.2(a) [Reserved]

4.2(b) Consent Management Cookie

CookieYes sets a cookie on your device to record your consent preferences (accept or reject, per cookie category). This cookie is classified as strictly necessary for the consent mechanism to function and is exempt from consent requirements under the ePrivacy Directive (Directive 2002/58/EC) and applicable law. It records only your consent choices and does not contain Personal Data beyond the consent record itself. This cookie persists across sessions so that your consent preferences are remembered on subsequent visits.

4.2(c) Strictly Necessary Local Storage

The Platform uses browser local storage for:

(i) Session persistence — maintaining your authenticated session (including your embedded-wallet session provisioned via Magic.link) across page navigations within a single visit so you do not need to sign in again on each page load.

(ii) Interface state preferences — storing display settings such as theme preference and layout choices.

(iii) A "last seen" marker for the Activity tab of your inbox — a single timestamp recording the most recent activity you were shown, so the inbox can tell you what has happened since. It is held on the device that displayed it, and it is held there because there is nothing on the Platform's servers for it to be held in: the Activity tab is assembled from the accounts you follow at the moment you open it, and no record is written when somebody you follow buys a position or posts. The consequence is one you will observe rather than one you need to be told: activity you have already read on one device is counted as new again on another, and clearing your browser storage resets the count. It is not transmitted anywhere, and it says nothing about which item you read — only how far down the list you had been shown. Your notifications, by contrast, are records on the Platform's own databases and their read state travels with them; Section 2.2(f)(i) describes what closing your account does to them.

This data is stored locally on your device only. It is not transmitted to Vivaach SRL, its servers, or any third party. It is strictly necessary for the Platform to function as intended and does not require consent under applicable law.

4.2(d) Technologies We Do Not Use

The Platform does not use:

(i) advertising cookies or advertising pixels;

(ii) retargeting or remarketing tags;

(iii) cross-site tracking technologies of any kind;

(iv) fingerprinting, canvas fingerprinting, or device-identification technologies;

(v) social-media tracking pixels or login plugins that report activity to social-media platforms; or

(vi) any mechanism that tracks, monitors, or reports your activity across other websites, applications, or services.

The only cookie set by the Platform is the CookieYes consent-management cookie (strictly necessary).

4.2(e) Clearing Cookies and Local Storage

You may clear cookies and local storage at any time through your browser settings. Doing so:

(i) will not affect your on-chain positions, settlements, claims, or Platform eligibility — these are recorded on the Blockchain and are independent of your browser state;

(ii) will not delete any data held by Vivaach SRL or its processors; and

(iii) may require you to sign in again, re-set your interface preferences, and re-submit your cookie consent choice on your next visit.

4.2(f) Future Changes to Tracking Technologies

If the Platform introduces additional tracking technologies, non-essential cookies, or third-party integrations that process Personal Data beyond what is described in this Section, this Privacy Policy will be updated and users will be notified in accordance with Section 4.5 before any such technology is deployed.

---

4.3 Data Security Measures and Limitation of Liability

4.3(a) Technical and Organizational Security Measures

Vivaach SRL implements the following measures to protect off-chain Personal Data against unauthorized access, loss, alteration, and disclosure:

(i) Encryption in transit. All data transmitted between your device and the Platform's infrastructure is encrypted using TLS (Transport Layer Security). All communications between the Platform's backend services and its database infrastructure are similarly encrypted.

(ii) Encryption at rest. Transaction authorization signatures stored off-chain by the Platform's relay infrastructure are encrypted using cloud key-management service (KMS) encryption, with each ciphertext cryptographically bound to its row identity, so that a compromised database row alone is insufficient to reconstruct the signature (as described in Section 1.2.1).

(iii) Access controls. Administrative access to off-chain databases is restricted on a need-to-know basis to authorized personnel of Vivaach SRL and of its affiliated engineering group — that is, engineering personnel of Vivaach SRL's parent and affiliated entities who operate and maintain the Platform's infrastructure on Vivaach SRL's behalf and under its instruction. Such personnel are bound by confidentiality obligations and by the same access-control and data-protection requirements that apply to Vivaach SRL's own personnel, and intra-group access is subject to the international-transfer safeguards described in Section 3.4. Database-level access controls enforce separation of privileges, including the immutability control on audit-log tables (described in Section 2.2(d)).

(iv) Non-custodial architecture. The Platform's non-custodial design means your private keys, seed phrases, and signing credentials are never transmitted to, received by, accessible to, or stored by Vivaach SRL or any of its service providers (other than Magic.link, which manages embedded-wallet key material in its own secure infrastructure — see Terms of Service §5.9(c)). Vivaach SRL cannot sign transactions on your behalf and cannot access your wallet.

(v) Third-party processor security. All third-party processors are bound by Data Processing Agreements requiring appropriate technical and organizational security measures commensurate with the sensitivity of the data they process (see Section 3.4(d)).

4.3(b) Phishing and Social Engineering Warning

Vivaach SRL will never request your private keys, seed phrases, wallet passwords, recovery phrases, or signing credentials — by email, through the Interface, via social media, or through any other channel. Any communication purporting to be from ULTRAMINT or Vivaach SRL that requests such information is fraudulent and should be:

(i) not responded to — do not provide any credentials or click any links;

(ii) reported immediately to legal@ultramint.xyz.

4.3(c) Security Disclaimer and Limitation of Liability

(i) Despite the implementation of the security measures described in this Section, no method of electronic transmission over the internet, no method of electronic data storage, and no decentralized blockchain network is guaranteed to be completely secure. Security incidents, including but not limited to unauthorized access, data breaches, and cyberattacks, may occur despite commercially reasonable precautions.

(ii) You interact with the Platform, the Protocol Contracts, and the underlying Blockchain at your own risk.

(iii) To the maximum extent permitted by applicable law, Vivaach SRL is not liable for:

    (A) unauthorized access to, loss of, corruption of, or alteration of your off-chain Personal Data resulting from a security breach, cyberattack, or other security incident;

    (B) data breaches, security incidents, or unauthorized disclosures affecting Personal Data held by any third-party processor, including Magic.link, Cloudflare, Anthropic, CookieYes, the RPC provider, and any future processor identified in Section 1.6 or Section 3;

    (C) exploitation of the Blockchain, the Protocol Contracts, the AMM, or any on-chain component by any third party;

    (D) loss of access to your wallet, private keys, seed phrases, or embedded-wallet key material, whether due to your own action, the action of a third party, or the action or inaction of the Platform's authentication provider; or

    (E) any consequence of the gasless relay model, including the exposure of your wallet address and transaction parameters to the RPC provider as described in Section 3.1(g).

(iv) This disclaimer does not exclude or limit any liability that cannot lawfully be excluded or limited under applicable law. Where any exclusion or limitation is held unenforceable, it applies to the maximum extent permitted, and the remainder of this Section remains in full force and effect.

---

4.4 Regional Statutory Privacy Disclosures

4.4(a) Governing Law

Vivaach SRL is organized under and operates subject to the laws of Costa Rica, including Ley No. 8968 (Protección de la Persona Frente al Tratamiento de sus Datos Personales) and its regulations. Costa Rican data-protection law is the primary legal framework governing this Privacy Policy and the processing of Personal Data by Vivaach SRL.

4.4(b) European Union and European Economic Area (GDPR)

The Platform is not offered to, and does not knowingly serve, residents of the EU or the EEA, as set out in the Prohibited Jurisdictions Policy and the Terms of Service (§4.2). Vivaach SRL does not target or direct its services to individuals in those jurisdictions. To the extent the GDPR nonetheless applies to any incidental processing of Personal Data of EU/EEA individuals (for example, where a visitor reaches the Interface before being geoblocked), the following disclosures are provided for transparency and completeness:

(i) The legal bases for each processing activity are set out in Section 1.3.

(ii) Your data-subject rights — including the rights of access, rectification, erasure, restriction, portability, objection, and withdrawal of consent — are set out in Section 2.2(a), subject to the on-chain data limitations in Section 2.2(b) and the audit-log limitation in Section 2.2(d).

(iii) International transfer safeguards, including Standard Contractual Clauses, are described in Section 3.4.

(iv) You have the right to lodge a complaint with your competent supervisory authority (see Section 2.4(f)).

(v) No automated individual decision-making. Vivaach SRL does not engage in automated decision-making that produces legal effects concerning you or similarly significantly affects you within the meaning of GDPR Article 22. Geographic-restriction enforcement (blocking access from Restricted Jurisdictions based on Cloudflare's country determination) is an automated process, but it implements a legal obligation and does not constitute profiling-based decision-making with legal effects beyond access restriction.

(vi) No discrimination. No adverse consequence, penalty, or degradation of service will result from the exercise of your data-protection rights.

(vii) EU Representative (GDPR Art. 27). Vivaach SRL is not established in the European Union and does not offer goods or services to, or monitor the behaviour of, data subjects in the EU/EEA within the meaning of GDPR Article 3(2). The Platform actively prohibits access by EU/EEA residents under the Prohibited Jurisdictions Policy and the Terms of Service (§4.2). On this basis, Vivaach SRL has determined that designation of an EU representative under Article 27 is not required. If this assessment changes, Vivaach SRL will appoint and identify an EU representative in an updated version of this Privacy Policy.

4.4(c) United Kingdom (UK GDPR)

The Platform is not offered to, and does not knowingly serve, residents of the United Kingdom, as set out in the Prohibited Jurisdictions Policy and the Terms of Service (§4.2). To the extent the UK GDPR (the Data Protection Act 2018 and the retained EU GDPR as incorporated into UK law) nonetheless applies to any incidental processing, the rights, safeguards, and protections described in Section 4.4(b) apply equally. Complaints may be directed to the Information Commissioner's Office (ICO).

Vivaach SRL does not offer goods or services to, or monitor the behaviour of, data subjects in the United Kingdom. On this basis, Vivaach SRL has determined that designation of a UK representative under Section 13 of the UK Data Protection Act 2018 is not required. If this assessment changes, Vivaach SRL will appoint and identify a UK representative in an updated version of this Privacy Policy.

4.4(d) Costa Rica (Ley No. 8968)

Users subject to Costa Rican data-protection law may exercise their rights of access (derecho de acceso), rectification (rectificación), and deletion (supresión) as described in Section 2.2(a), subject to the limitations described in Sections 2.2(b) through 2.2(e). Complaints may be directed to PRODHAB (Agencia de Protección de Datos de los Habitantes), Costa Rica.

4.4(e) United States

The Platform is not offered to, and prohibits access by, citizens and residents of the United States (see Terms of Service §4.1). Vivaach SRL does not knowingly collect Personal Data from US persons. The Platform does not sell Personal Data and does not share Personal Data for cross-context behavioral advertising.

4.4(f) Children

The Platform is not directed at, and is not intended for use by, any person under the age of eighteen (18). Vivaach SRL does not knowingly collect Personal Data from children under 18. If you believe that a child under 18 has provided Personal Data to the Platform, please contact legal@ultramint.xyz and Vivaach SRL will take steps to delete that data.

4.4(g) Other Jurisdictions

Users in jurisdictions not specifically addressed in this Section retain all rights afforded to them under applicable local data-protection law. To exercise any such right, contact legal@ultramint.xyz. Vivaach SRL will assess and respond to your request in accordance with the applicable legal framework.

---

4.5 Amendments and Policy Updates

(a) Vivaach SRL reserves the right to modify this Privacy Policy at any time.

(b) The Effective date at the top of this Policy will be updated to reflect the date of any revision.

(c) Material changes — including changes to the categories of Personal Data collected, the addition of new third-party processors receiving Personal Data, changes to retention periods, changes to the exercise or scope of data-subject rights, or the introduction of new tracking technologies — will be communicated via a prominent notice on the ULTRAMINT interface no fewer than fourteen (14) days before the change takes effect. Your continued use of the Platform after that date constitutes your acceptance of the updated Privacy Policy.

(d) Non-material changes — corrections, clarifications, formatting adjustments, updated processor names where the processing activity remains the same, or changes that do not alter the substance of your rights or the scope of data processing — may be made without advance notice.

(e) Prior versions of this Privacy Policy will be archived and available for review at the Policy's URL.

---

4.6 Contact Information

All privacy inquiries, data-subject access requests, deletion requests, rectification requests, restriction requests, portability requests, objection notices, consent withdrawals, and legal notices should be directed to:

Vivaach SRL
Email: legal@ultramint.xyz
Jurisdiction: Costa Rica

Response timeline: Acknowledgment within five (5) business days of receipt; substantive response within thirty (30) calendar days of successful identity verification (see Section 2.4(c) for full details, including extension provisions).

---

This Privacy Policy was last updated on [insert date]. Prior versions are archived at [insert URL].