Privacy Policy

Last updated: 2026-09-06

Most of what gord shows you is public blockchain data copied into a database so pages load quickly. Beyond that we collect very little. This page is organised by what we actually hold rather than by legal category, and it starts with the uncomfortable part: some of this is written to a public blockchain, where it is permanent and where nobody can delete it, ourselves included.

The chain is public, and it is forever

Wallet addresses, token addresses, trades, balances, fee accruals, locks and bindings are public facts on GIWA. Anyone can read them with or without gord. We index them so the site is fast. We did not create them and we cannot remove them.

Two of them are worth naming, because they involve you rather than a market:

When a token designates a social account, an identifier for that account goes in plain text into the transaction that creates its fee vault, and a hash of it fixes the vault's permanent address. A launcher can do this before the account holder has ever visited gord, so the identifier can be on chain before you know it exists.
If you then bind a payout wallet, the link between that vault and your wallet address is recorded on chain, permanently and publicly.

The image a launcher uploads for a token is also referenced by a URL written into the token's on-chain record. The bytes are ours and we can stop serving them. The URL is not ours and stays where it is.

What our database holds

One Postgres database, run for us by our hosting provider. In it:

A mirror of the chain. Tokens, curves, trades, balances, candles, locks, Main Runner events and buybacks, all derived from public logs and keyed by public addresses. We do not delete it, because it mirrors something that cannot be deleted and can be rebuilt from the chain at any time.
Token content. The name, symbol, description, links and image a launcher supplies at creation.
Social profiles. For each YouTube channel or X account looked up or designated: the platform's permanent id, the handle, display name, avatar URL, profile URL, subscriber or follower count, and when we last refreshed it. All of it is public profile data, cached so a page view does not re-query the platform. A bio, where a platform returns one, is shown to the person typing the handle and never stored.
Claim records. While a claim is in flight: a short-lived sign-in session, the wallet you asked to bind, the exact message you were given to sign and its hash, your signature until the binding confirms, and the resulting transaction hash.
1-Click ownership links. If you bind a main wallet as the owner of a 1-Click wallet, both public addresses are indexed from the on-chain event like any other chain fact.

A dump of that database is taken nightly into a private bucket, and the fourteen most recent are kept.

What your browser holds

Most of this never leaves your device. The cookies are the exception, and the list below names each one.

Preferences. Theme, language, board sorting, your quick-buy amount and slippage, the last wallet you connected and its last known balance, and which filters you had open. Two of these ride in cookies, which do go to our server with every page load: gord_chip, so a hard refresh renders the board filter you had, and gord_lang, which carries your language. A third, gord_track, is left over from an older filter, and the app expires it as soon as it sees it.
The 1-Click wallet key. The private key is encrypted with a key held in IndexedDB that the browser will not let any script export, and the ciphertext sits in local storage. Neither half is ever sent to us and we have no copy. Our error reporting strips session handles, tokens, keys and OAuth parameters out of URLs and breadcrumbs before a report leaves your browser, and drops a report the stripper cannot process. That covers where identifiers usually leak, but no stripper can vouch for the text of an arbitrary error, so we will not promise a key can never surface in a diagnostic. If you lose that browser storage without an exported backup, the wallet is gone unless you set an owner for it first.
One sign-in cookie. During an OAuth round a single __Host- cookie goes to our API domain with each request in that round, which is how the round is tied to your browser. It is cleared when the round ends.
The session handle. A completed sign-in returns its handle in the URL fragment, which browsers never send to a server. Our error reporting strips it out of any URL it would otherwise record, in your browser and on our servers.

What we never have

Your private keys or seed phrase, for your main wallet or for the 1-Click one. We cannot move your funds.
A refresh token for your Google or X account. We request none and store none, so our access dies with the one access token, inside the hour.
Payment details. There is nothing to pay us; you pay gas and contract fees.
An analytics or advertising product. There is no tracking pixel, no ad network and no profile of you on this site, and we do not sell data.

Proving you manage a YouTube or X account

Fees designated to a social account are claimed by proving you manage it. There are two ways, and only one involves signing in.

Signing in with Google requests the https://www.googleapis.com/auth/youtube.readonly scope and uses it for exactly one call: channels.list with mine=true, to read back the id of the channel you manage. That single call is the whole proof. The access token serves it and is discarded, no refresh token is requested or stored, and we never read your videos, analytics, subscribers, comments, email or anything belonging to any other Google service.

Signing in with X requests users.read and tweet.read and calls /2/users/me once, to read back your numeric account id. Same shape: one call, token discarded, no refresh token.

You can revoke our access at any time at myaccount.google.com/permissions or in X's connected apps settings. Since we hold no refresh token, revoking takes effect immediately.

Limited Use

gord's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. We do not use Google user data for advertising, we do not sell it, we do not transfer it to third parties except as needed to operate the claim feature or to comply with law, and no human reads it except with your explicit consent, for a security investigation, or where the law requires it.

Proving it without signing in

gord can instead generate a short phrase that names the payout wallet you want. On YouTube you put it in your channel description and we read the description of the channel being claimed. On X you post it and give us the link, and we check that your account wrote the post, because the phrase is public and anyone could otherwise post it from their own account. No sign-in, no token, no permission granted to us: both reads use public endpoints or our own API key, never your account. And because the phrase names the wallet, a phrase posted for one wallet cannot be reused to bind another.

Uploads and moderation

A token image you upload is stored in an object bucket and served publicly, because a URL to it is written into the token's on-chain record. Files are named by the hash of their own bytes, so nothing about you is attached to one. The first time we see a given set of bytes they go to an automated classifier that scores them for nudity and gore, and we refuse the upload if it scores badly or, while the gate is armed, if the classifier cannot be reached at all. We remember only that a hash cleared, so the same image is not sent again. A bot check runs on the same endpoint. Link previews we fetch for a token's socials go through the same classifier before they are shown.

Technical data

IP address. Used to apply rate limits and connection caps, as a counter key that expires with its own window (an IPv6 address is collapsed to its routed block first). It is not written to the database and not used to build a profile of you. Ordinary request logs kept by our hosting and CDN providers are theirs, on their own retention.
Error reports. When something breaks, a diagnostic report may go to our error-monitoring provider. API keys, OAuth parameters and session handles are stripped before it leaves, in your browser and on our servers alike, and a report the stripper cannot process is dropped rather than sent.

Who else touches this

We use service providers. Each sees only what its job needs.

Vercel. Website hosting.
Railway. The indexer, the database and the cache.
Cloudflare. DNS, CDN, the image bucket and the backups. Its bot check on uploads is sent your IP address with the challenge result.
Nodit. Our main RPC endpoint. Your browser calls it directly, so it sees your IP address and the addresses you look up.
GIWA's own public RPC. The fallback your browser uses when the main endpoint fails, so it sees the same thing. It is run by the network operators, not by us.
An Ethereum mainnet RPC. Used only to turn addresses into ENS names for display, several times on a token page. It sees your IP address and the addresses being resolved. Unless we configure a host, this is the default public endpoint built into the wallet library the site uses.
Reown / WalletConnect. Only if you connect that way instead of with a browser wallet.
Sentry. Error monitoring.
Sightengine. The image classifier.
AWS KMS. Our signing keys. It holds no user data.
Google and X. Only if you sign in with them.

Most of these providers are outside the Republic of Korea, so using gord means the small amount of data described above crosses a border. Each entry above says what that provider sees. None of them receives more than that, and none of them receives it for any purpose except the job named. Where a data protection law requires the receiving country, the items transferred, the purpose and the retention period to be set out provider by provider, we will publish that alongside the operating entity's details rather than approximate it here.

We do not sell your data and we do not share it for advertising. We may disclose information where the law requires it.

How long we keep things

An in-flight OAuth round: 10 minutes, then deleted.
A sign-in session: 30 minutes, single use, then deleted.
Your bind signature: deleted when the binding confirms, and cleared from an unfinished request when its challenge expires. The request record itself is deleted a week later.
Cached social profile data: kept while a token designates the account, and refreshed whenever we look again. We clear it if you ask, and it comes back: the next time anybody looks that account up we fetch it from the platform's own public data again, because the on-chain designation that triggers the lookup is not ours to remove. The rights section below says what the route actually is.
Indexed chain data: for as long as the service runs. It mirrors the chain.
Database backups: the fourteen most recent nightly dumps.
On-chain records: permanent, and not ours to keep or to delete.

Why we are allowed to hold this

Where a data protection law asks us to name a legal basis, these are the ones we rely on.

Performing what you asked for. Serving the page you requested, running a claim from sign-in to binding, and showing a token you created.
Our legitimate interests in keeping the service working and honest: rate limits and connection caps, the bot check and the image classifier, error monitoring, backups, and caching public profile data so a page view does not re-query a platform.
Your consent, for the one thing that asks for it. Signing in with Google or X is your choice, the alternative proof needs no sign-in at all, and you can withdraw it from those platforms at any time.
Legal obligation, where a law or a lawful order requires us to keep or hand over something.

What you can ask for, and what nobody can do

Where the law where you live gives you these rights, we honour them: access to the data we hold about you, correction of it, deletion of it, objection to a use of it, and a copy in a portable form. Write to privacy@gord.pro. We aim to answer within thirty days, and sooner where the law where you live sets a shorter deadline. We may need to check that the request is really yours, which for a wallet usually means a signature from it, and where a request is complicated or that check takes time we will tell you why it is taking longer. You can also complain to the data protection authority where you live, and you do not have to come to us first.

Two ordinary things need no request at all. Disconnect your wallet whenever you like: nothing here requires an account and nothing is waiting for you to log back in. Revoke our Google or X access from those platforms' own settings, and because we hold no refresh token it takes effect immediately.

Nothing on a public blockchain can be deleted, by us or by anyone. Your address, your trades, a designation of your account, a binding, a lock: those are written to GIWA, copied by explorers and by anyone else who indexes the chain, and no request to us can reach them. What we can delete is the off-chain data we hold, such as a claim record. If part of what you ask for falls on the other side of that line, we will say so plainly and tell you which part.

Two limits on deleting off-chain data are worth naming rather than leaving you to find. Our nightly database backups keep the fourteen most recent dumps, so a record we delete today can still sit in a backup until the last dump holding it rolls off, about two weeks later; we use backups for nothing but restoring the service. And a cached social profile we clear is rebuilt the next time anybody looks that account up, because what causes the lookup is an on-chain designation we cannot remove. If you want a token here to stop carrying your account, the route is a takedown request to abuse@gord.pro, and even that reaches this interface rather than the chain.

Age

gord is not directed to children and is not for anyone under 18. You must be 18 or older to use it, which is also a condition of the Terms of Service. We do not knowingly collect anything from a child. If you believe a child has given us something, write to privacy@gord.pro and we will delete what we hold, keeping in mind that anything already on chain is beyond deletion by anyone.

Contact and changes

gord is operated from the Republic of Korea. The operating entity is being formed, and this page will name it, and the person responsible for privacy inside it, as soon as it exists. Until then the operator is the team that publishes this site, a privacy question reaches that team at the address below rather than a named officer, and these are the ways to reach it:

Privacy questions, access and deletion requests: privacy@gord.pro
Legal notices and general contact: legal@gord.pro
Abuse, infringement and takedowns: abuse@gord.pro

We aim to answer privacy requests and legal notices within thirty days, and sooner where the law where you live sets a shorter deadline. We are a small team rather than a support desk, and we would rather name a date we can keep.

If this policy changes, the date at the top changes with it, and that date is the notice. Material changes to how we handle Google user data will be described here before they take effect.