Privacy Policy

Who is responsible

The interface at wyrm.trade is operated by the site operator. For the purposes of the EU General Data Protection Regulation, the UK GDPR and the Swiss Federal Act on Data Protection, the association is the data controller for the processing described on this page. If you are in Switzerland, the EEA or the UK you have statutory rights over that processing, and they are set out below.

The same association operates this interface. The terms acceptance records described below live in a database it already uses for that other interface, separated by a key prefix rather than by a separate instance. It is one controller and one set of safeguards, but we would rather state the arrangement than let you discover it.

What we do not do

There is no sign-up, no password, no login and no profile. The one thing here that behaves at all like a session is a random id generated fresh on every page load and attached to error reports, which is described under error reports below. We run no analytics and no advertising, attribution or measurement code of any kind. We set no cookie. We do not perform identity verification: no KYC, no document check, no name. We do not intentionally collect special category data such as health, biometric, racial or political data, and you should not send us any.

The markets page fetches nothing from anyone else: both typefaces and every image are served from this domain, and the pool figures come through our own server. That stops being true in two places, both covered below. Opening a pool page makes your browser read the chain from the node endpoint directly, and choosing WalletConnect loads a third party's code into the page. We collect only what the functions described here need, and we do not sell personal data.

The terms acceptance record

This is the one thing we store about you on purpose rather than because something broke, and it is the reason this page exists at all. Before your first deposit your wallet is asked to sign a short sentence: that you have read and agree to the terms of service, and that you are not in a restricted jurisdiction and are not misrepresenting your location. We check the signature on our server and write down seven fields, which are the whole record:

• your wallet address, lower-cased
• the version of the terms you agreed to
• the time the message was issued
• the time we recorded it
• a two-letter country code, taken from our host's country header, or nothing at all when the host gives us no signal
• the exact text you signed
• the signature itself

Your IP address is deliberately not part of that record. The restricted-jurisdiction question only ever needed a country, and an IP is the single highest-cost field to hold, so the code takes the country and discards the rest. You can check that: the server reads only the country header and never touches an IP header.

The lawful basis is our legitimate interest in keeping evidence that a user agreed to the terms and in being able to establish, exercise or defend legal claims, alongside our interest in managing the compliance risk of offering this interface at all. Where the law obliges us to keep such records, we also rely on that legal obligation.

The record is stored in a Redis database run by Upstash. We keep it for ten years from your last interaction, because that matches the Swiss record-keeping period for business records under the Code of Obligations and comfortably covers the limitation periods within which a claim about your use of this interface could still be brought.

A signature is a deliberate piece of evidence, not incidental telemetry, so it is the one thing here you cannot make us forget by clearing your browser, and an erasure request will normally be refused for it.

One thing about the endpoint that checks whether you have already accepted, worth saying rather than leaving for you to find. It answers anyone asking from this site: give it an address and it says whether that address has accepted, and nothing else. It holds nothing that could name you, and an address that has provided liquidity here has necessarily accepted, so for those the answer is already readable from the chain. For an address that accepted and never deposited it is not, and that is the residual.

It used to take your address in the URL as well, which put it in our host's access logs, somewhere we did not choose and cannot expire on our own schedule. It now travels in the body of the request, which is not logged.

The country check

Taking a position is gated by country. When you deposit, withdraw or claim, our server reads the two-letter country code our host stamps on the request and refuses the action if it is on a blocked list. Browsing, charts and pool figures are not gated. The default list is the United States plus Cuba, Iran, North Korea and Syria, and the deployment can change it. A refusal is answered with HTTP 451 and the country code, and nothing else is stored: the verdict itself is never written down.

The check reads a country, never an IP, and it fails open. If our host gives us no country signal the action proceeds. This is not sanctions screening and it is not wallet screening, neither of which we do. It stops casual access; the representation you signed is what does the legal work.

Automated decisions, and how to contest one

The country check is automated, so this needs saying plainly. We do not make decisions about you that are based solely on automated processing and produce legal or similarly significant effects, within the meaning of Article 22 GDPR. The check gates one feature for compliance reasons, and it runs on our legitimate interests and, where applicable, on a legal obligation.

If you have been refused and you believe the answer is wrong, a person will look at it. Write to privacy@wyrm.trade, tell us what happened, and we may ask you to prove control of the wallet by signing a message.

Your wallet address

A wallet address is pseudonymous, not anonymous, and under the GDPR it is personal data. We hold no name, no email and nothing else to attach to it, but once an address has been linked to you anywhere it is linked to you across its whole history, backwards as well as forwards.

Connecting a wallet gives the interface its address. It is held in the page's memory while the tab is open, and it is written to your browser's local storage once you have accepted the terms, so that you are not asked to sign again. It is used to read your balances and positions and to build the transactions you sign. It leaves the page in five places:

• To the node endpoint, which is asked for your balances and your positions. Your browser makes that request itself, so the endpoint also sees your IP address and your browser's user agent.
• To Uniswap's liquidity service, through our server, whenever a deposit or a withdrawal is quoted or built. That request carries your address, the pool, the amounts, the price range and, when one is needed, a token approval signature.
• To your wallet, and, if you chose to connect by WalletConnect, to that protocol's relay on the way there.
• To our own acceptance endpoint, as described above.
• To our own error endpoint, but only when a transaction fails. The report of that failure carries the address that was going to sign it, along with the action and the pool, and it is described under error reports below.

It is deliberately not sent to Uniswap's data service, which supplies the charts and the pool figures. Our proxy rebuilds that request from a fixed list of fields and rejects any other field by name, so an address cannot reach it even if something tried to send one.

Linking an X account

Creating a referral code requires linking an X account. This is optional in the sense that nothing else on Wyrm needs it: you can provide liquidity, earn points and be referred without ever linking one. It is only the referral code that asks.

Linking is your express consent to associate that X account with your wallet address. X calls this off-platform matching and it is the reason the step is a deliberate action with its own button rather than something that happens quietly during sign in. We receive your account id and your handle, and nothing else. We do not receive your posts, your followers, your email or your direct messages, and we ask for no permission to post on your behalf.

We store the id, the handle and the moment you linked. We do not store an access token, so we hold nothing that could be used to act as you on X, and there is no long lived credential to lose. The handle is never shown to anyone but you: the page tells other people whether a wallet is linked, never which account it is linked to.

Unlink by linking a different account, which replaces the record. To have it removed entirely, ask, and it is deleted from the live store; the append-only backup described below keeps the earlier entry until it is rotated out.

The blockchain is public, and it is not ours

Everything you do on chain is written to a public ledger by design: the deposit, the range you chose, the position, every fee collected and every later change. Anyone can read it, it is permanent, and it is not ours to delete, correct or restrict. No request to us, and no obligation on us, can change what is on it. This is a real limit on the right to erasure and we cannot engineer around it.

We also cannot interfere with block explorers or archival nodes that have copied it. What we can do is delete or isolate the off-chain copies we hold and stop displaying an address in this interface. Treat anything you put into a field that ends up on chain as published.

Who receives data, and what they receive

We do not sell personal data. These are everyone we send it to:

• The node endpoint, which is Robinhood Chain's public RPC unless the deployment is configured otherwise. Your browser talks to it directly, so it sees your IP address, your user agent, your wallet address and every read the interface makes on your behalf. This is the largest single disclosure using Wyrm causes, and how they handle it is theirs to state, not ours.
• Vercel, our host. It serves this page and runs every endpoint behind it, so its request logs record the IP address of anyone who loads the site, on its own schedule and under its own terms.
• Upstash, which runs the database holding both the acceptance records described above and the error reports described below.
• Uniswap Labs. Quotes and transaction calldata reach their liquidity service through our server and carry your wallet address, the pool, the amounts and the range. Charts and pool figures reach their data service through our server and carry a pool and a timeframe, and no address. Because both pass through our server, they see our server's address rather than yours.
• Sentry, if this deployment has an error channel configured. Reports are forwarded from our server, so Sentry sees our server's address rather than yours, and what is forwarded is five of the fields listed below: the code path, the error class, the message, the stack and the path. The transaction context, and so your wallet address, is not among them and does not leave our own database.
• Reown, which operates the WalletConnect relay, but only if you pick that row when connecting. Doing so loads fonts, wallet images and configuration from Reown's servers, opens a connection to its relay, and its library sends its own usage events to its own endpoint. That is third-party telemetry, it is not ours, and a browser-extension wallet never touches any of it.
• Discord, if you use the support desk or the Discord link in the menu. Following either takes you off this site to a service we do not run, which sees your IP address and holds your account, your messages and their metadata under its own policy. Nothing reaches it unless you go there.

Beyond those, we may disclose data to our legal, tax and audit advisers, to a counterparty in a merger or similar transaction under confidentiality, and to competent authorities responding to a lawful request. We assess such requests for legality, necessity and scope, we narrow or object where that is appropriate, and where we are lawfully able to we will tell you before disclosing, or as soon as we are permitted afterwards.

Where the data goes

Our hosting and infrastructure providers operate in the EEA, Switzerland and the United States, so some of this leaves Switzerland and the EEA. Where it does, we rely on the EU Standard Contractual Clauses, and the Swiss equivalents where the FADP applies, as those providers offer them in their standard terms. Traffic to every one of them is encrypted in transit. We require any provider we use to protect the data no less strictly than we do.

The list above is the whole list of providers. We would rather publish it than offer it on request, and we will update this page if it changes.

Error reports

When something in the interface fails, it sends one small report to our own endpoint, and we store it. Nine fields come from your browser, and this is the whole list: the name of the code path that failed, the error class, the error message, the stack, the path of the page you were on, which build you were running, a random id for that page load, how many times that same failure has already happened in that tab, and, when what failed was a transaction, the context described in the next paragraph. Our server adds two more when it writes the report down: the time it arrived, and a two-letter country code taken from our host's country header. Every string among them is truncated before it is stored or forwarded.

A transaction failure carries the address that signed it, or that was asked to sign and did not. That context is the action you were attempting, the pool, your wallet address, your wallet's own error code and the error data the node returned. It is there because "execution reverted" on its own does not say which pool, which action or which contract refused, and without it a failed deposit is close to undiagnosable. Declining the prompt in your wallet counts as a failure here and is reported too, under its own name, because the ratio of declines to reverts is how we tell a contract that is refusing us from a prompt people simply do not want. The consequence is worth stating rather than burying: a report from a deposit, a withdrawal or a claim is attached to your address as directly as the acceptance record is. Nothing else in the interface puts an address into a report.

• The random id, stored as sid, is what joins the reports from one page load to each other. That is the difference between one tab failing fifty times and fifty people failing once, which is the first thing worth knowing about a spike. It is generated fresh on every load, it is never written to your browser and it goes nowhere else, so it cannot join a report to an earlier visit, to another tab or to you. The wallet address on a transaction failure can do all three, and does.
• The path is the path only, never the query string. On a pool page the path contains the pool's id, so a report does say which market you were looking at.
• There is no cookie, no user agent and no IP address in a report. The country code is read from the same host header the country check uses. It is stored in a field named ip, which is a misnomer we should fix and not a description of what is in it.
• The message and the stack are whatever the failing code produced. We relay them without parsing them, so beyond the address described above, we cannot promise one never appears inside an error message we did not write.

Reports are stored in the same Redis database run by Upstash that holds the acceptance records, under a different key, as a single list of the newest five hundred. Older ones fall off the end as newer ones arrive, and the list is set to expire fourteen days after the last report written to it, so a deployment that stops failing leaves nothing behind within a fortnight. In addition, a report goes to Sentry if this deployment has an error channel configured, and otherwise a one-line summary of it goes to our host's runtime log, which is kept for about an hour and then gone.

When you contact us

If you write to us we receive your email address, whatever you put in the message and whatever your mail provider attaches to it. We keep that for as long as it takes to deal with what you wrote about and a reasonable period afterwards, up to three years, on our legitimate interest in answering people and in having a record of what we answered. It is not joined to anything else, and there is nothing here to join it to.

The support desk linked from the menu is a Discord server, which is not ours. If you open a ticket there, Discord holds your account, your messages and their metadata under its own policy, and we see what you write in the ticket. Do not send a private key, a seed phrase or anything else you would not want a third party to hold, there or anywhere.

Cookies, and what is stored in your browser

We set no cookie, no pixel and no tracking store. Our proxies do not pass your cookies upstream and do not pass an upstream response's headers back, so nothing on the other end can set one on this domain either. There is no consent banner on this site because there is nothing to consent to.

Six keys are written to your browser's local storage, and they stay on it:

• whether you dismissed the announcement at the top of the page
• whether you have opened the rewards panel in the header before
• whether you told us you had followed our account on X. Nothing checks it.
• which wallet you last connected with, so the same one is offered first next time. It is the wallet's own name, not an address.
• a referral code, if you arrived on a referral link, and the time it arrived. It is a pending intent and nothing else: no referral exists until you sign one, and it is dropped after thirty days or the moment you accept or ignore it.
• your wallet address, lower-cased, recording that this address accepted the current version of the terms. This is the one that says something about you, and it is there so that you are not asked to sign again on every visit.

Two more keys are written to session storage rather than local storage, and both are part of the error handling described above. When a tab left open across a deployment fails to load part of the interface, we reload it once and write down the time of that reload, so that a reload which cannot help does not turn into a loop; the second key records that the one reload has been spent, so a part of the page that still will not load gives up and reports the failure instead of reloading you round in a circle. Each holds a timestamp and nothing else, and your browser drops both when the tab closes.

If you connect by WalletConnect, that library keeps its own session records in the same place, which is what lets your wallet stay paired. Clearing this site's data in your browser removes all of them. The acceptance record on our server is unaffected, which is the point of it.

How long things are kept

• Acceptance records: ten years from your last interaction, for the reason given above, and longer if a dispute, an audit or a legal hold requires it.
• Error reports in our own database: the newest five hundred, and the whole list expires fourteen days after the last report written to it. Both bounds are real and the tighter one wins. The clock restarts on every new report, so on a deployment that keeps failing a report can be older than a fortnight, and on any deployment it is gone once five hundred newer ones have arrived.
• Our host's request logs: on its schedule and under its terms, not ours. Its runtime log, where the one-line summary of an error report lands when no error channel is configured, is kept for about an hour.
• Error reports sent to Sentry, where one is configured: on that service's retention.
• Correspondence with us: up to three years after the matter it concerns is closed. A Discord ticket is kept on Discord's terms, not ours.
• Browser storage: until you clear it.
• Anything on chain: permanently, and outside anyone's control, including ours.

Security

What we can claim, we can point at in the code. Secrets are held on the server and are never compiled into the page you download. The proxies accept a fixed list of fields and reject anything else by name, refuse cross-origin callers, cap request sizes and time out upstream calls. Responses from our endpoints are never cached. The acceptance store holds no IP address and nothing that identifies you by name, which is the strongest security measure available to us: not holding it.

We have not commissioned a penetration test and we do not run a security operations centre, and we would rather say so than list controls we do not have.

If we become aware of a personal data breach likely to pose a risk to people, we will notify the competent supervisory authority without undue delay, and within 72 hours where the GDPR applies and that is feasible. Where the risk is high we will also tell the people affected without undue delay. Under the FADP we will notify the Swiss Federal Data Protection and Information Commissioner as soon as possible where the breach is likely to result in a high risk. If you have found a vulnerability, write to security@wyrm.trade with the steps to reproduce it.

Your rights

If you are in Switzerland, the EEA or the UK you have the rights below, and we will answer each of them concretely rather than abstractly, because there is so little to answer about: an acceptance record, any error report from the last fourteen days that carries your address, and any correspondence you have sent us.

• Access and portability: we will confirm whether we hold an acceptance record for your address and send you the seven fields, in a machine-readable format, together with any error report still held that carries that address.
• Rectification: if a field is wrong we will correct it. The signed text itself cannot be altered without destroying what makes it evidence.
• Erasure: we will delete or isolate off-chain data where we can. An error report is a debugging artefact and not evidence of anything, so we will delete one on request, even though it would have expired on its own within a fortnight. We will normally keep the acceptance record itself, because it exists to establish, exercise or defend legal claims, and we will restrict access to it instead. Nothing on chain is within our reach at all.
• Restriction: you can ask us to restrict processing in the circumstances the law allows.
• Objection: our processing rests on legitimate interests, so you can object to it and we will weigh your objection rather than dismiss it.

Write to privacy@wyrm.trade. Because we hold no name and nothing attached to your address that could identify you, the only identity check available to us is the wallet itself, so we will normally ask you to prove control of the address by signing a message. We aim to answer within one month, and we may extend that by up to two further months for complex or repeated requests, in which case we will tell you. We do not charge, unless a request is manifestly unfounded or excessive.

If you are unhappy with the answer, you can complain to the Swiss Federal Data Protection and Information Commissioner, or, if you are in the EEA or the UK, to your local supervisory authority, such as the ICO in the UK. We would rather you came to us first.

Other services you reach through this page

When you use this interface you also deal with Uniswap's protocol and its APIs, the Robinhood Chain node endpoint, the issuer of the tokens in these pools, your own wallet, and Discord if you follow the support link. Their own privacy notices and terms govern what they do, we do not control them and we do not endorse them, and choosing to use them is your decision.

Children

This interface is intended for adults over eighteen, and we do not knowingly collect anything from anyone younger. If you believe a child has given us data, tell us at privacy@wyrm.trade and we will delete it and, where it is appropriate, disable the related access.

Changes

This page can change, and the version here is the one in force. If what the interface does with data changes materially, this page changes with it and we will say so. The terms have a version number that is part of your signed record, and an acceptance of one version does not carry forward to the next: if the wording changes materially you will be asked to sign again rather than be treated as having agreed to something you never saw.

Last updated: 21 August 2026.

Contact

the site operator. For anything on this page, including access, erasure, objection and contesting a country block: privacy@wyrm.trade. For security reports: security@wyrm.trade. For everything else there is the support desk linked from the menu and x.com/TryWyrmfi, neither of which is a route for a data protection request: use the email address, so that it is recorded and the response times set out above start running. See also the terms of service and the documentation.