Privacy Policy
What we hold, and why
Version 2026-10-15. This number is shared with the Terms of Use, so that one string identifies the whole agreement your account recorded. This policy changed on 2026-10-15, because you can now add a picture to your account, which we keep, and put it on a card you share if you choose; it takes effect with the release of the site that carries it. The Terms changed on the same day, in clause 9, to say what such a picture may not be. Before that the number moved on 2026-10-11 because the Terms changed — this policy did not. Before that it changed on 2026-10-06, because a browser you have signed in from now keeps a second cookie, so that it can still sign in while somebody elsewhere is trying wrong passwords against your email address; it takes effect with the release of the site that carries it. Before that it changed on 2026-10-05, because a card you share now keeps how many days no price could value, so that its page can say its figure is a floor; it takes effect with the release of the site that carries it. Before that it changed on 2026-10-04, because a delegated holding’s row can now record your operator’s fee; it takes effect with the release of the site that carries it. Before that it changed on 2026-10-03, because a card you share for all time now keeps what you were paid in each calendar month since the first day we could measure, up to the last 30 months; and because a bonded holding’s row can now record your node’s operator fee; it takes effect with the release of the site that carries it. Before that it changed on 2026-10-02, because a card you share is now of the period your dashboard was showing — 24 hours, 7 days, 30 days or all time — and we store which one, and that period’s figures, and because a card you share now shows the day and time it was made, to the minute, and because your portfolio page now shows the link of each card you share, which we keep encrypted; it takes effect with the release of the site that carries it. Before that it changed on 2026-10-01, because you are now known by a username you choose rather than by your first name and surname, neither of which we store any more; and because a card you share now keeps what you were paid on each of the last 30 days, and no longer keeps the earnings per $10,000 or how many times over your earnings would repay what you put in; it takes effect with the release of the site that carries it. Before that it changed on 2026-09-30, because you can now remove a card you shared, and to describe four things a shared card shows or keeps that the previous version did not name; before that it changed on 2026-09-29, because you can now share your card as a link that anyone who has it can open; before that on 2026-09-23, because the sign-in cookie was renamed and now covers both pineomics.com and app.pineomics.com; before that it changed on 2026-09-21, because removing a linked address is now something you do yourself and now asks whether the transactions imported from it should go with it; before that on 2026-09-17, to describe a wallet address and the two node providers an address is sent to when you ask us to read one, and its text had not changed since 2026-09-11. This policy describes what the software actually does, field by field — not what a website of this kind usually does.
The short version
We run no analytics. We show no advertising. We set no tracking cookies. We sell nothing, share nothing for marketing, and profile nobody. We send no email at all.
If you read the site without an account, we store nothing about you and set no cookie. If you create one, we hold the handful of things listed below for as long as you keep it.
Who we are
Pineomics is the controller of the personal data described here, and is established in the Netherlands at:
Pineomics
Keizersgracht 572
1017 EM Amsterdam
Netherlands
Pineomics currently operates as an unincorporated venture, so there is no company name or Chamber of Commerce number to give you yet. When that changes, this page will name the company and its registration number and carry a new effective date.
For anything about your data, including the rights set out below, email privacy@pineomics.com. We have not appointed a data protection officer, and are not required to.
Reading the site without an account
Browsing pineomics.com or the dashboard at app.pineomics.com creates no record of you. No account row, no session row, no cookie. Choosing “access for free” on the dashboard is handled entirely inside your own browser and tells our servers nothing.
Two things still happen, as they do on any website, and both are covered further down: our host keeps short-lived request logs, and your browser fetches fonts from Google.
What an account stores
This is the complete list. Every item below is a column in our database. The only thing it does not name is the timestamps recording when each row was created or last changed.
The name you choose at signup, stored as you typed it: 3 to 30 letters, digits, dots, dashes or underscores, and no two accounts share one, whatever their case. Used to address you in the dashboard, and shown on any card you choose to share. We do not store your first or last name. If your account existed before 2026-10-01, its username was made from the first name you gave us — with accents and any other character outside those taken out, and a number added where the result was too short or already taken — and both names were then deleted from our database, though our host’s backups of it taken before then keep them for as long as their own retention says.
Stored lower-cased. It identifies the account and is what you sign in with. We have never sent an email to it and this version of the site cannot.
We do not store your password. We store an Argon2id hash of it, which is a one-way transformation: it lets us check a password you type, and it cannot be turned back into the original. Nobody here can read your password, and a copy of our database would not reveal it.
A single yes or no from the signup form. We record your answer and have acted on it in no way whatsoever — no newsletter exists yet and no email has been sent. If one is ever introduced we will ask you again before sending anything.
Optional. Every part of the site works without it, and we never ask for one unprompted. If you link an address we store the address itself, which chain it is on, and when we last read it — so that an import can be repeated without you typing it again. A blockchain address is public and permanent, so linking one ties this account to everything that address has ever done on that chain; that is why it is yours to offer and yours to take away. An address is stored only when you import from it. Asking the dashboard what an address holds keeps nothing about it at all; the address is written down at the moment you accept the holdings that reading found, so that a later import does not ask you to type it again. You can do the first without ever doing the second — see reading a wallet address below.
When you remove the address, you choose what happens to the rows imported from it. Every transaction an import creates carries a reference that names the address, asset and venue it came from, so that importing the same wallet twice does not duplicate your holdings. That reference contains a copy of the address, so it outlives the address itself. Removing an address asks you which you want: remove the address only, and those rows stay in your ledger with the reference on them — or remove it and delete them, after which our database holds no copy of it. Neither is chosen for you, and the dashboard tells you how many rows the second would delete before you confirm it. That is not the same as the address never having been here, and saying so is more use to you than a cleaner sentence: if you ever asked the dashboard what that address holds, that request carried it in a web address and so left it in the request logs described under Server logs, which removing it now does not reach; and our host keeps backups of the database, which hold whatever they captured for as long as their own retention says.
Every buy, sell and move you enter: which asset, which venue, whether it was a buy, a sell or a move between two venues, how many tokens, the price if you gave one, and the day it happened. Each row also records where its price came from — whether you stated it or nobody could — and, if the row came from a wallet import, a reference naming the address, asset and venue it was imported from. For a bonded holding, a row may also record the fee your node’s operator takes — the one you gave us, or the one we read from your node when you imported the address and you kept; for a delegated holding, the fee your operator takes, which only you can give us. That holding is measured after it. This is the ledger your yield is measured from, and taken together these rows say what you own — which makes them the most revealing thing on this page. They are yours: nothing computed from them is published unless you share a card yourself, and the public figures the site shows carry nothing from any account.
Optional. When you share the card on your dashboard, we store a copy of what it showed at that moment: your username; which period it showed — the last 24 hours, the last 7 days, the last 30 days or all time; the figures it was drawn from — what your holdings paid you over that period, your return over it and the price and yield halves of that return; for a 30-day or an all-time card, what they have paid you since the first day we could measure them, and that day; for an all-time card, your yield on what you paid in; what you were paid on each of the last 30 days, ending on the latest day we have figures for, whichever period the card showed — a day we could not total is kept as no figure, and how many days could not be totalled and, for a card shared since 2026-10-05, how many could not be priced; for an all-time card shared since 2026-10-03, what you were paid in each calendar month since the first day we could measure, up to the last 30 months — a month in which no day could be measured is kept as no figure; and the assets it listed, with their tickers; and, if you chose to put it on the card, a copy of your picture as it was at that moment. Changing or removing your picture afterwards does not change a card you have already shared; removing the card removes its copy, and we may take the picture off every card you shared if it breaks the rule on pictures in the Terms. A card shared before 2026-10-02 records no period, and is shown as the 30-day or all-time card it was made as. We also keep the moment you shared it, and the card and its page print it, to the minute in UTC, for a card shared since 2026-10-02 — the day alone for one shared before, so anyone opening an old link can see how old the figures are. The copy never changes afterwards, so a change to your holdings does not reach a card you have already shared — with one exception, made once: when usernames replaced names on 2026-10-01, every card already shared was changed to show its holder’s username in place of the name it was made with. And a picture we take off under the Terms leaves the card it was on. We also store a SHA-256 digest of the secret part of its link, which is what opens the card, and, for a card shared since 2026-10-02, the link itself, encrypted under a key we keep apart from the database, so that your portfolio page can show it to you again. A copy of the database alone cannot be used to open a card; someone who also had that key could. Anyone who has the link can see the card, with no account — that is what sharing it means — so share it only where you would show those figures yourself.
You can remove a card you shared from your portfolio page at any time, and it is deleted outright, with its link, from our database, though our host keeps backups of the database, which hold whatever they captured for as long as their own retention says. Its link then stops opening the card within ten minutes rather than at once: our server, and a browser that has already opened it, may each keep a copy for up to five minutes. A preview a service has already drawn from it is that service’s own copy, and we cannot reach it.
Optional. If you add a picture, we keep only the copy our server makes of it: a 256 × 256 square cut from its centre and saved afresh, so nothing else in the file you chose — its name, where or when it was taken, or anything hidden in it — is kept. It is shown on your own pages, and on a card you share only if you choose to put it there. We also keep a short fingerprint of that copy, so your browser knows when it has changed. You can change or remove it at any time, and it is then deleted outright, though our host’s backups of the database hold whatever they captured for as long as their own retention says.
A single number you can set on the portfolio page so it can show progress against a goal of your own. Optional, and used for nothing else.
The version string of the Terms of Use you were shown, and the moment you ticked the box. It exists so that “you agreed to this” can be shown to be true, and so it points at the text you actually saw rather than at whatever replaced it.
When you sign in we create a random token, put it in a cookie, and store only a SHA-256 digest of it alongside your account and an expiry. The token itself is never written down anywhere on our side, so a copy of this table cannot be used to sign in as you.
Reading a wallet address
When you ask the dashboard what an address holds, our server asks the public blockchains, not your browser. The address goes out in that request: on Ethereum inside the body of a call to eth.drpc.org, and on THORChain as part of the web address we request from gateway.liquify.com. We identify our application to both — every request we make anywhere carries our name and this site's address — and we send Liquify one further identifier so it can tell our requests apart from anonymous ones. Because our server makes the request, your own IP address does not reach either of them — ours does.
Neither is told anything else about you: not your username, not your email address, not that an account exists. We have no contract with either, so neither is acting on our instructions; they receive a public address and what they do with the request is governed by their own policies, which are linked below.
We take the address out of our own error output before anything is recorded, and an automated test checks that it stays out — the same kind of test that keeps passwords and session tokens out of our logs. It is not equally invisible everywhere, and saying so is more use to you than a tidier sentence: the address travels inside the web address of your request, so it reaches ordinary request logs the way any path does — including our host’s, described under Server logs, whose retention is not ours to set.
A read keeps nothing about the address itself. Like every request made while you are signed in, it advances a short-lived counter against your account, described under Keeping sign-in safe. Reading an address and linking one are separate things, and you can do the first without the second.
To remove an address you have linked, open your portfolio and use Remove beside it under Linked addresses. Nothing is ever read from it again. You are asked to choose first: keep the transactions imported from it, because they are your record of what you own and are no different from rows you typed yourself — or delete them with the address, which is the only way the copy of it inside each of those rows goes as well. The dashboard says how many rows that is before you confirm. You can still email privacy@pineomics.com instead.
Unlike reading an address, removing one does not put it in a web address — it travels inside the request rather than in its path, so it is not written into the request logs described under Server logs. That does not erase the entries an earlier read already left there.
Cookies
Two cookies. The first, named __Secure-session, is set only when you sign in. It holds the session token described above and nothing else. It is marked HttpOnly so scripts cannot read it, Secure so it only travels over HTTPS, and SameSite=Lax, which means another site cannot make your browser send it in the background or attach it to a form submitted at us — though it is still sent when you follow an ordinary link to us from somewhere else, which is what lets you arrive already signed in.
It also carries Domain=.pineomics.com, which means your browser sends it to every address ending in pineomics.com — both pineomics.com and app.pineomics.com — so that signing in on one recognises you on the other. Saying plainly what that costs is more use to you than a shorter sentence: until 2026-09-23 the cookie was locked to the single address that set it, and it no longer is.
If your browser ever presents two cookies of that name, we refuse the request instead of guessing which one is yours. Clearing this site’s cookies in your browser and signing in again resolves it.
It is strictly necessary to provide a service you asked for — staying signed in — so under article 11.7a of the Dutch Telecommunicatiewet it does not require your consent, and that is why you are not being shown a cookie banner. We set no analytics, advertising or tracking cookies of any kind, so there is nothing else to consent to.
Signing out deletes that cookie and the stored session.
Since 2026-10-06 there is a second cookie, named __Secure-device, set when you sign in or create an account. It holds your account’s identifier, when it expires, a random number and a signature only our server can make — no password and no session. It is marked HttpOnly, Secure and SameSite=Strict, and your browser sends it only when you sign in (Path=/api/login), and only to pineomics.com. It has one job: if somebody elsewhere is trying wrong passwords against your email address and we have paused sign-ins to it, a browser holding this cookie can still sign in with the right password. It lasts until a year after you last sign in. Signing out does not delete it, so the browser stays known; clearing this site’s cookies does. It is strictly necessary for the same reason the first one is — keeping your account one you can sign into — so it does not require your consent either.
Keeping sign-in safe
To stop somebody guessing passwords at scale, our server counts recent failed sign-in attempts against the email address tried and against the IP address it came from. It also counts recent successful sign-ins, against the account signed into and against the IP address they came from, so that no one account or address can sign in without limit; recent attempts to create an account, against the IP address they came from, so that no one address can create accounts without limit; recent requests carrying a sign-in cookie that matches no session, against the IP address they came from, so that no one address can make us look for sessions without limit; recent requests against the account making them, so that no one account can make unlimited ones; and recent picture uploads, against the account making them and against the IP address they came from, so that no one account or address can make us process pictures without limit. These counters live in the server’s memory only, are never written to the database, and are discarded within an hour of the last attempt — or, for the failed-attempt counters on your email address, immediately when somebody signs in successfully, except that a sign-in from a browser we already know leaves the counter for your email address in place, because that counter is what the other attempts used up. One more counter works the same way for shared cards: each time one is looked up, it counts the IP address the request came from, whoever is asking and whether or not they have an account, so nobody can work through guessed links at scale. Signing in does not reset it. While a page of ours is showing live prices, our server also counts how many live-price connections are open from your IP address, so no one address can hold them all; that count is gone the moment the connection closes.
Server logs
Our host, Railway, keeps the ordinary output of the running service: the path and method of requests, response codes, and errors. These help us see that the service is working and diagnose it when it is not. They are not used to build any picture of an individual.
Passwords, password hashes and session tokens are never written to a log, and we have an automated test that scans our log output to keep that true.
A shared card’s link is the exception, and saying so is more use to you than a tidier sentence: its secret part is in the web address, so every time somebody opens the card, the link reaches these logs the way any path does. Anyone who could read those logs could open the card.
Who else sees your data
- Railway hosts the service and the database. Everything in the list above sits on infrastructure they operate, and they hold the request logs. They process it on our instructions and for no purpose of their own.
- Google serves the fonts this site uses. When a page loads, your browser requests them from
fonts.googleapis.comandfonts.gstatic.com, which means your IP address reaches Google. This happens on every page including this one, and whether or not you have an account. We receive nothing from Google in return and pass nothing to them ourselves. If you would rather this did not happen, a content blocker will stop it; the pages will still work and will fall back to a typeface already on your device. - DRPC and Liquify are blockchain node providers, and they see an address only when you ask us to read one, and never otherwise. DRPC receives an Ethereum address at
eth.drpc.org; Liquify receives a THORChain address atgateway.liquify.com. Both also receive our application’s name, as every request we make does. Neither receives your IP address or anything that identifies you, and we have no contract with either — so, unlike Railway, they are recipients of a public address rather than processors acting on our instructions, and we are not in a position to tell you what they keep. Their own policies are at drpc.org/privacy-policy and in Liquify’s RPC privacy policy (PDF). - Anyone you give a shared card’s link to sees your username, your picture if you put it on the card, the figures on that card and the day and time you shared it, and, where some days could not be totalled or priced, or where a coin’s payout is worked out over every coin ever minted, a sentence saying the figure is a floor rather than a measurement — and so does anyone they pass it on to; no account is needed. A service you paste the link into — X, Discord, Slack and the like — fetches the card to draw its preview and may keep its own copy under its own policy, which is outside our reach once it has been fetched.
Nobody else. We use no analytics provider, no advertising network, no email provider, no payment processor and no customer-support tool.
The figures are not about you
The revenue and yield figures on the dashboard are computed from public blockchain and market data, and are the same for everybody. Fetching them sends nothing about you to those sources, and the public figures endpoint carries no account data of any kind — which, again, is something we test for rather than merely intend.
Reading a wallet address and sharing a card are the two things that carry something of yours to somebody else, and each happens only when you ask for it.
Where your data is held
On Railway’s infrastructure. Railway is a United States company and may store or process data outside the European Economic Area. The Google Fonts request described above also reaches infrastructure operated by a United States company.
Transfers to the United States rest on the European Commission’s adequacy decision for the EU–US Data Privacy Framework (Implementing Decision (EU) 2023/1795), supplemented by the standard contractual clauses our providers put in place. In the interest of not overstating it: that decision was upheld by the General Court in September 2025 and is under appeal to the Court of Justice (case C-703/25 P), which had not ruled at the time of writing. If it falls, we will move to another lawful basis for the transfer and say so here.
Your rights
You can ask us to:
- give you a copy of what we hold about you;
- correct anything that is wrong;
- delete your account and everything in it;
- remove a wallet address you linked, choosing as you do whether the transactions imported from it stay or go;
- restrict what we do with it, or object to processing we base on our legitimate interests;
- give you your data in a portable form;
- withdraw your consent to the newsletter flag, which you may do at any time without affecting anything else.
Removing a linked address you can now do yourself, under Linked addresses in your portfolio. For everything else on this list, email privacy@pineomics.com and we will do it.
If you think we have handled your data badly, please tell us first so we can put it right. You also have the right to complain to a supervisory authority. We are established in the Netherlands, so ours is the Autoriteit Persoonsgegevens, which takes complaints at klachten.autoriteitpersoonsgegevens.nl. You may also complain to the authority in the country you live in.
Children
An account requires you to be 18 or over, because that is the age at which you can enter into an agreement in your own right under Dutch law. We do not knowingly hold data about anyone younger. If you believe a child has created an account, email us and we will delete it.
Whether you have to give us anything
No. Every figure on this site is free to read with no account and no data at all. The items listed above are needed only if you want an account, and without them we cannot create one — that is the only consequence of not providing them.
Changes to this policy
When it changes, the effective date at the top changes with it. If a change materially affects what we do with your data, we will bring it to your attention on the site before it takes effect.