What we hold about you

Version 2026-10-04. Last updated 4 October 2026.

This is all of it. Kahyna is a small service and it collects a small amount of data.

There is no third-party analytics on this site. The only thing a page sends about your visit is the count of the day’s lookups: when you open a wallet, a market, a match or a wallet check, the page tells our own server, which sets no cookie for it and keeps no IP address (section 2, “Counting lookups”). No advertising, no tracking pixel, no session recorder, no third-party script of any kind on any page. The fonts are served from our own server rather than a font host. That is why nothing has asked you to accept cookies: the only cookie you carry around is the one that signs you in, and there is nothing else here to consent to. Kahyna counts visits itself, in aggregate, from its own server’s logs, with no cookie, and the count keeps no IP address (section 2, “Counting visits”). The one thing you can choose to bring in is a match’s stream on a Live page, from Twitch, YouTube or Kick, and nothing from them loads until you press play (section 3).

1. Who is responsible

This notice covers kahyna.com and the API behind it. Write to the address above about anything on this page and a person will read it.

2. What we collect, and why

If you register with an email and a password

• Your email address. It identifies the account and it is the only way we have of reaching you about it.
• Your password, hashed with argon2id. The password itself is never stored and we cannot read it or recover it. If somebody stole our database they would not get your password out of it.
• The date the account was created.
• The date you accepted these terms and which version you accepted. That is the record that you agreed, and it is the reason the version number is printed at the top of this page.
• Whether the account has been disabled, in the event we ever have to disable one.
• Whether you have confirmed your email address, and the date you did. Confirming means you opened a link we sent to that address, which is how we know it really reaches you. Until you do, it is only what somebody typed into a form.

Lawful basis: performing the contract you asked for when you created the account (GDPR Article 6(1)(b)).

If you sign in with Google

• The account identifier Google gives us for you. It is an opaque number, not your email, and it is what we key your sign-in on.
• The email address on your Google account, and whether Google says it is verified.

We never see your Google password, and we ask Google for nothing else. No contacts, no calendar, no files, no profile beyond the email. Ask us to disconnect Google from an account and the record goes with it, by hand today, because there is no button for it yet. Where it is the only way in, we refuse to remove it rather than lock you out of your own account.

Lawful basis: contract, the same as above.

Email we send you

There are two messages this service sends because something you did asked for one, both of them to the address on your own account: a link to confirm your address, and a link to set a new password when you have forgotten yours. One more goes once without being asked, about a day before a new account’s free days of Pro end: it says when they end, what stays free and how to keep Pro, goes only to a confirmed address and never to an account that pays, carries no tracking pixel, and the account notes when it was sent so that it never goes twice. There is no newsletter, no product announcement and no marketing email of any kind, and there is nothing to unsubscribe from.

Each of those links carries a one-time token. We do not keep the token itself: what is written down is a SHA-256 fingerprint of it, which account it belongs to, when it was made, when it stops working, and whether it has been used. The fingerprint means that a copy of our database is not a set of working reset links. A reset link stops working one hour after it is sent, a confirmation link after 24 hours, and either stops the moment it is used once.

Sending them means handing your address, and the message, to the company that delivers our mail. Section 4 says who that is and what they get.

Lawful basis: contract for the reset link, since letting you back into your own account is part of providing it, and for the reminder, which tells you about a change to your own account; our legitimate interest in keeping accounts secure for the confirmation link (Article 6(1)(f)).

Every time you sign in

We write one session row: a SHA-256 fingerprint of the sign-in cookie (never the cookie itself), when it was created, when it expires, the IP address the sign-in came from, and the user-agent string your browser sends. The fingerprint means a leaked database cannot be turned into a working session.

The IP and the browser string are there so that a sign-in from somewhere you have never been is visible if you ever ask us to look, and so a session can be revoked. We do not look at them otherwise and nothing analyses them.

The same row also notes when the session was last used. It is one time, written when you sign in and updated at most once a day after that, and it says nothing about what you did: not which pages you opened, not which markets you looked at. Your account holds one more time of the same kind: the first time you used Kahyna signed in on a day after the day you registered. That one is written once and never changes. We use the two in two ways. One is a count, as one total across all accounts, of how many new accounts come back on a later day and how many do within their first week. The other is a private page that only the operator’s admin account can open, which lists each account with its email address, the day it registered, its plan and its free days of Pro, whether its address is confirmed, the day it was last used, and whether and when it came back. It is how we know who has signed up and whether they return. It shows nothing about what anyone looked at, and nothing on it is shared with anybody.

Your account also holds when your free days of Pro started: the first time you used Kahyna signed in with your email address confirmed. It is written once and never changed, and it is used for one thing: to work out when those days end, so that you get them and then go back to Free.

Lawful basis: our legitimate interest in keeping accounts secure, and in knowing who has signed up and whether people find the service worth coming back to (Article 6(1)(f)). For the start of your free days: giving you what the terms promise (Article 6(1)(b)).

Server logs

The web server keeps an ordinary access log: IP address, time, the page or endpoint requested, the address of the page that linked to it when your browser sends one, and the user-agent. It is how errors and abuse become visible, and it is what we count visits from (below). It is not joined to accounts, and it is not copied into our backups. It rotates on the server and is overwritten.

The API behind the site keeps a second log of the same shape in the server’s system journal: one line per request with the calling IP address, the method, the path and the status code. It is the same information twice, in two places, and both rotate on the machine. If you sign in with Google, the address you are sent back to carries a one-time code in it, which is written to those logs like any other path and which has already been spent by the time the line is written.

The messages the application writes itself are separate again and contain no personal data at all: failures by method and path, a warning when a request body is over the size limit, a line when a sign-in from Google is refused and why, a line if the database refuses to write the last-used or first-return time described above, or the start of your free days, and start-up and shutdown lines. Sending mail adds a few more of the same kind: that a reset was asked for more often than we will act on, that a reset finished and how many sessions it signed out, and, when the mail provider is unreachable or refuses a message, which error it was. No email address, no password, no sign-in token and no link out of any message we send is ever written to any log. That last one is deliberate and it is the reason a reset link is written into the part of the address after the#, which browsers never send to a server: it keeps a working link out of the access log for the hour in which it would let somebody into your account.

Lawful basis: legitimate interest in running and defending the service.

Counting visits

A job on the same server reads that access log and keeps only totals, day by day: how many visitors, how many pages were opened and which ones, where visitors came from (a search engine, an AI assistant, a social site, another site, or no link at all), and which crawlers (search engines and AI) fetched which pages. Of the page that sent you, only the name of its site is kept.

While it counts, and only in memory, the job also works out a few things about each visit, and keeps their totals, never which visitor they belong to. The country the IP address is in, looked up in a free database of address ranges kept on our server (DB-IP’s IP to Country Lite, which the server downloads from DB-IP once a month; looking an address up sends it nowhere). The kind of device (phone, tablet or computer), the browser and the operating system, read from the browser string as families such as “Chrome” or “iOS”. How the pages a visitor opens in a day follow one another, which gives how many pages a visit sees, whether it sees only one, and roughly how long it stays on each. And how many visitors send the sign-up form, and from which of our pages they went to it. Only totals are kept, day by day, such as how many visitors were in each country or used each browser.

A second job counts the last 30 minutes of the same log in the same way every two minutes, for a live view on the private page described above, and replaces its totals each time. Its random value exists in memory for one run and is never written down.

IP geolocation by DB-IP, under the CC BY 4.0 licence.

To count a visitor once a day without knowing who they are, the job combines, in memory, the IP address and the browser string with a random value made fresh each day, and counts the distinct results. That random value is kept for the day it is made and the next, then deleted; without it, nothing the count leaves behind can be matched back to an IP address. The count writes no IP address and no browser string anywhere, sets no cookie and runs nothing in your browser. Crawlers and other bots that identify themselves are not counted as visitors.

The totals are kept on our server and only the operator reads them, on the private page described above. They name no one.

Lawful basis: our legitimate interest in knowing how many people use the service and how they find it (Article 6(1)(f)).

Counting lookups

Without an account you have 5 lookups a day in every section (a wallet, a market, a match or a wallet check, each counting one), and a free account 15. To count them without knowing who you are, the server keeps, for two days, a hashed key per visitor and a hash of each item opened. The key is made from your IP address and a secret value made fresh each day, and that secret is deleted after two days, along with every count from before yesterday; once it is gone, nothing that is left can be matched back to an IP address. The IP address itself is never stored, and no cookie is set. These counts and the secret are never copied into a backup, so deleting them deletes them everywhere. With an account, the key is made from the account instead of the IP address. Crawlers that identify themselves are not counted when they read a public page; a lookup of our read or of what a wallet holds counts for whoever asks.

Lawful basis: our legitimate interest in keeping the service free to read while limiting how much one visitor can open in a day (Article 6(1)(f)).

What we do not collect

No name, no postal address, no phone number, no date of birth. No card number, no expiry date and no security code, and that is not because there is nothing to buy. There is: a subscription, described in section 9 of the terms. It is that paying happens on Stripe’s own pages rather than ours, so a card is typed into their form and never reaches this service at all. What we keep about a subscription is which plan it is, whether it is live, when the period ends, and the identifiers Stripe gives us for the customer and the subscription. What Stripe holds is in section 4. We do not record which markets you looked at, what you searched for, or what you clicked: the visit count says how many times a page was opened on a day, in total, never by whom. The one exception is the daily lookups count, which keeps a hash of each item opened for two days and then deletes it (“Counting lookups”, above). There is no profile of you anywhere in the system, because there is no table that could hold one.

If you scan a wallet

The wallet page takes an address that you paste in. Here is exactly what happens to it. We check that it is a well-formed address, then ask Polymarket’s and Limitless’s public trade APIs for that address’s trade history, the two venues that publish who traded. The answers are held in memory on our server for about a minute, so that reloading the page does not fetch them again, and then they are gone.

The address itself is never written to our database and does not appear in any backup. A scan counts as one of the day’s lookups, so for two days the daily lookups count keeps a hash of the address, made with that day’s secret, together with the hashed key it keeps for you (made from your account if you are signed in, from your IP address if not), so that scanning it again the same day is not counted twice. For those two days, someone who could read that table and already had a list of addresses could tell which key scanned which of them. Then the hash, the key and the secret are deleted, and none of them is ever copied into a backup (“Counting lookups”, above). The trades themselves are public on the blockchain and published by the venues. We are reading a public record, not keeping one. Polymarket and Limitless see the address and our server, not you. The page needs no account; the daily count is what stops it being used as an anonymous proxy, and your account is never sent with the request.

Things your browser keeps, not us

Your theme choice and the stake amount in the stake box are stored by your own browser. They never leave it, they are never sent to us, and we cannot read them. Clearing your browser storage clears them.

3. Cookies

The one that signs you in is called arbor_session, it is set when you sign in, and it contains a random token and nothing else. No name, no email, nothing readable. It is httpOnly, so scripts on the page cannot read it. It is Secure, so it only travels over an encrypted connection. It is SameSite=Lax. It lasts 30 days. Signing out deletes it in your browser and revokes it on our side at the same moment, so a copied cookie stops working immediately.

Signing in with Google sets one more cookie that exists only for the few seconds of the redirect and is discarded when you come back. Its only job is to confirm that the reply from Google arrived at the same browser that started the sign-in.

There is no other cookie on this site, from us or from anybody else. No consent banner is shown because nothing here needs consent.

One thing is yours to switch on. A Live match page can play the match’s own stream from Twitch, YouTube or Kick, the channel the venue names for that match. Nothing from them is loaded until you press the button that says whose player it is. When you do, their player runs in a frame on the page: that service serves the video, sees your visit and may set its own cookies, under its own privacy policy. YouTube is loaded from its privacy-enhanced address.

4. Who else sees it

Five parties, and others only if you choose them.

• The company we rent the server from. Kahyna runs on a single rented virtual server at OVH. They operate the machine it sits on. They do not use the data on it.
• The storage the backups go to. The nightly database backup is copied off the server, so that losing one machine is not losing the service.
• The company that delivers our email. We send mail through Resend. To send you a message they have to be given your email address and the contents of that message, so they hold both, along with their own record that we asked them to send it. They send on our instructions and for nothing else. They are not allowed to use your address for their own purposes and we do not give them anything beyond the messages described in section 2. There is no mailing list here, and no marketing email has ever been sent.
• The company that takes the payment. Subscriptions run on Stripe. This only begins if you start a checkout: at that moment we create a customer record at Stripe carrying your email address and your account id here, so that a receipt reaches you and so that a payment can be matched back to the right account. You then type your card on Stripe’s own pages. They hold it; we never see it, and it is never sent to us. Stripe tells us when a payment succeeds, fails or is cancelled, which is the only way this service ever learns whether an account is subscribed. If you have never opened a checkout, Stripe has nothing about you from us.
• Polymarket and Limitless, and only the wallet address you paste into the wallet page, as described above.
• Twitch, YouTube or Kick, only if you press play on a match’s stream: the service whose player it is then sees your visit, as described in section 3.

If you choose to sign in with Google then Google necessarily knows you signed in to Kahyna, because you signed in through them.

Nobody else. We do not sell data. We do not share it with advertisers. There is no analytics provider on this site at all, and the payment processor above receives an email address and an account id and nothing else, never what you looked at.

Where it is held

5. How long we keep it

• Account data for as long as the account exists. Ask us to delete it and we delete it from the live database.
• Sessions expire 30 days after you sign in and stop working that day. We do not yet delete the expired rows automatically, so an old row can sit there holding the IP, the browser string and the last-used time of a sign-in that no longer works. Those rows go when the account goes. Automatic cleanup is being built.
• Confirmation and password-reset links stop working within an hour or a day of being sent, whichever kind they are, and using one stops it immediately. The fingerprint row behind a link outlives the link itself, so that we can still answer “that link was already used” if you write to us about one. Those rows are meant to be cleared out a week after they expire, and today nothing does it automatically, so they are accumulating. It is the same gap as the sessions above and it is the same fix.
• Subscription records for as long as the account exists, and the record of a subscription that ended stays with it: which plan it was and when it stopped. We keep what Stripe tells us about your payments, in the form Stripe sent it, because that is the only evidence either of us has of what happened to a charge. It contains no card number. Stripe keeps its own copy under its own retention rules, and a deletion request that reaches us does not reach theirs: tax law requires them to keep payment records for years, and we are not going to pretend we can override that.
• Backups. The server keeps the four most recent nightly database dumps. Older copies live on the off-box storage described below.
• Access logs rotate on the server and are not archived anywhere.
• Daily lookup counts are kept for two days, then deleted with the secret that made their keys (section 2, “Counting lookups”).
• Visit totals are counts that name no one and hold no IP address, and we keep them. The random value behind the daily visitor count is kept for the day it is made and the next, then deleted. The live view’s totals are replaced every two minutes.

Deletion, and the part about backups that we are not going to dress up

6. Your rights

You can ask us to:

• give you a copy of everything we hold about you;
• correct anything that is wrong;
• delete your account and its data;
• restrict or object to what we do with it;
• hand it to you in a portable form.

Email us from the address on the account and we will answer within one month. You can also complain to the data protection authority where you live, and you do not need to talk to us first.

There is no self-service button for any of this yet. Export and deletion endpoints are being built. Until they exist a person does it by hand, which is slower and works.

7. Automated decisions

None are made about you. Our model makes estimates about markets, not about people. Nothing about your account is decided by an algorithm, and nothing you do here is scored, ranked or profiled.

8. Age

Kahyna is not for children and neither are prediction markets. You must be 18 or older, and 21 or older where your jurisdiction requires it. We do not knowingly hold data about a child. If you think we do, write to us and we will delete it.

9. Changes to this notice

When this text changes, the version at the top of the page changes with it. If a change matters we will say so where you will actually see it rather than quietly editing the page.

The other half of this is the Terms, which cover what the service is, what it is not, and what we are and are not promising.