Privacy policy

You do not sign in or create an account to read anything Evidesa produces, and no report changes because a reader signed in. We do not ask for your name or your email. No page here can initiate a transaction, and none asks you to approve one. The only page that talks to a wallet is the account page, only when you ask it to, and the only two things it can request are an address and a signature over a message it has already printed.

Two surfaces accept a signature, and both work the same way. The claim profile has an optional field where a project can paste a signature to demonstrate that it holds the key at an address it named; the sign-in page accepts one to open a session. In both, the message is issued by the server and shown to you in full before you sign anything, you sign it in your wallet or wherever you already keep that key, and the result comes back here. We never see the key, never ask for it, and never obtain it from a wallet. The signature itself is verified and discarded in the same request that carries it — what a sign-in keeps is the session it opened, not the signature.

A signature proves that somebody holds a key. It does not tell us who they are, and we do not attempt to find out. On the claim profile a signature still creates no account and no session — only the sign-in page does, and what an account holds is the address it was created for, timestamps, and the hash of a session token. A session lives in an httpOnly cookie in your browser; our side stores only its SHA-256, which is not presentable as a session by anyone who reads it.

Four things you can choose to put INTO an account are then held for it: the watchlist entries you add — mint addresses and the short notes you write beside them; if you publish a claim profile while signed in, the record that this account filed it; if you buy a plan, the plan it holds — the plan name, its validity, and the subscription reference; the promises you file under a proven key — the project’s own commitments, published on the token’s dossier beside its claim profile and kept as withdrawn if you withdraw them; and the team you open or join — its name, the wallet addresses seated on it, its shared list of mints and notes, an audit trail of who changed what, a ledger of the files its seats exported, its investigation rooms (hypotheses, counter-evidence, notes, decisions, frozen pointers into the observation ledger, and incident marks naming which seat acknowledged or was assigned a saved observation — written once and never edited), and its private overlay (labels on wallets with confidence, evidence, attribution and an expiry), all of which every seat on that team can read and no one outside it can. All are visible to this account’s sessions and published nowhere, and none changes what any report shows.

Buying a plan happens on Paddle’s hosted checkout page, never here — and the sale itself is processed by Paddle as the merchant of record, so your receipt, billing details and card numbers go to Paddle under Paddle’s own policy and never reach Evidesa. What comes back to us is a signed event naming the account and the subscription — nothing about the payment instrument. Evidence is never gated on any plan, no score moves with money, and correction requests and the right of reply stay free.

This is otherwise unchanged across the project-side pages — the launch-readiness checklist, the claim profile, and the template-reuse comparison. Because there is no sign-in, we cannot confirm that whoever fills one in speaks for the project it names, and we make no claim to anyone that they do. A verified signature narrows that for one address; it does not close it.

• Mint addresses you submit. A token mint address is used to fetch on-chain and market data and to build the report. It appears in the report URL, so it may be recorded in standard server and infrastructure logs. A mint address is a public on-chain identifier, not your personal identity.
• Server and infrastructure logs. Our hosting provider may automatically record technical request data such as IP address, user agent, timestamps, and requested paths. Evidesa uses a coarse, in-memory rate-limit signal derived from forwarded IP headers to protect the service; this is not stored durably or used to profile you.
• Privacy-conscious analytics (when enabled). If analytics is configured, Evidesa records a small set of aggregate product events (for example, a scan was submitted or a report opened) using a cookieless, privacy-focused provider. The event properties we attach are minimized by design — they do not include mint addresses, wallet identity, report contents, secrets, or your full IP address added by the application. The provider does, however, record the page address of every view, and a report page carries the token's mint address in its own URL — so the provider sees which tokens were looked at. A mint address is a public token identifier, not your personal identity.
• Addresses and transactions you paste into the tools. The address exposure page and the transaction pre-check both take input you paste. Each is sent to the server in the body of a request — never in a URL, so it does not reach the analytics provider, referrer headers, or browser history — used to build the result, and then discarded. Neither is stored, written to a log, or recorded in the change history. Building the result does require sending the address to a Solana RPC provider, and the mints held to the market-data provider, which see them under their own policies.
• What you type into the project-side pages. The launch-readiness checklist, the claim profile, and the template-reuse comparison each take a mint address. Two of them take more: the checklist takes the items you tick about a project’s own arrangements, and the claim profile takes statements you write — addresses, links, figures, and free text. All of it is sent in the body of a request, never in a URL, so none of it reaches the analytics provider, referrer headers, or browser history. It is used to build the result you are handed, and then discarded. Nothing you submit there is stored, published, attached to a report, indexed, or recorded in an analytics event. Our operational logs record that a submission was processed, a fixed rejection code if it was refused, and counts such as how many statements it contained — never the mint address and never what you wrote. Building the result still requires reading that mint from a Solana RPC provider, and, where the result needs market data, from a market-data provider — which see it under their own policies. Please do not put personal or sensitive information into a free-text field: the document you get back reproduces what you wrote, word for word, and where you publish it is your decision.
• The Telegram evidence watch, if you start it. If you start our Telegram bot, we store a one-way keyed reference to your chat, an encrypted copy of the chat identifier needed to send you a message, and the token mint addresses you ask to watch. The identifier is encrypted with a key held outside the database, and every lookup uses the one-way reference instead, so the stored rows on their own contain nothing that could contact you. We do not store the messages you send. Sending /stop removes the identifier and every watch. Telegram keeps its own copy of the conversation under its own policy, which we cannot reach.
• Feedback you choose to send. If you answer the optional “Was this useful?” prompt, we process your yes/no response and any short comment you write. Do not include personal or sensitive information in the comment. Feedback is not linked to a wallet or account.

The template-reuse comparison is the one place where using Evidesa causes a request to go out to a server that never asked to be read. When a mint address is submitted there, our server reads the links that token’s own on-chain metadata declares and requests at most three of those pages — one website, one documentation page, one more. Which addresses are requested is decided by the token’s metadata, not by anything you type beyond the mint.

That request tells the receiving host that Evidesa asked for the page. It arrives from this deployment’s network address, at the moment it was made, into whatever logs that host keeps. It does not come from your browser: your IP address, your user agent, and your cookies are not disclosed to that host, and the request carries nothing else that identifies you. What that host can learn is that this deployment requested the page and when — and because the request is made while you wait, that timing is the one thing about your use of the page that reaches it. A per-token cooldown means the same pages are not requested again for a reader who arrives shortly afterwards.

The text that comes back is measured on the server and discarded. It is not stored, not published, and not shown to you. Social platforms and code hosts are not requested at all.

One narrower version of this happens on any report: a token’s on-chain metadata can point at a document hosted anywhere, and fetching it discloses the same thing to whichever host that URI names. That has always been the case and is listed among the processors below.

• No passwords, no email addresses, no names. An account, where you create one, is an address, timestamps, and what you choose to put in it — watchlist entries and claim-profile filings. A claim-profile signature is verified and discarded in the same request — never stored, logged, or linked to anything; a sign-in signature is discarded the same way, and what remains is the session it opened.
• No card numbers and no billing details — checkout happens on Paddle's hosted page as merchant of record, and payment instruments never reach this application.
• No advertising trackers, fingerprinting, session replay, or keystroke capture.
• No non-essential cookies. Privacy-conscious analytics, when enabled, is cookieless.
• No selling or renting of data.

We cannot truthfully claim that no data at all is collected, because hosting and network providers may keep their own technical logs to operate and secure the service.

To generate a report, Evidesa sends the necessary requests to third parties, who process them under their own policies:

• The cloud hosting provider that runs the application and may log requests.
• A Solana RPC provider, to read on-chain mint, holder, and transaction data.
• DexScreener, for third-party market and liquidity data.
• IPFS and Arweave gateways — or whatever host a token's metadata URI names — when that URI must be fetched.
• The websites and documentation pages a token's own metadata links to, when the template-reuse comparison is run. Those hosts do not process anything on our behalf; we request a page from them, and they see that request under their own policies.
• A cookieless analytics provider, only if analytics is configured.
• Paddle, as merchant of record, when you buy a plan: the checkout, the payment instrument, the receipt and the billing relationship are Paddle's, under Paddle's own policy. What Paddle sends back to us names the account and the subscription, never the payment details.

When your browser loads a token logo image, that request goes directly from your browser to the image host and may reveal your IP address and user agent to that host.

The user-shaped data Evidesa holds is what the optional account system creates: an address, timestamps, hashes of session tokens, the watchlist entries you add (mint addresses and your own notes), the record of which claim profiles the account filed, and — if you open or join a team — the team’s name, the wallet addresses seated on it, its shared list and notes, its audit trail, its investigation rooms and its private overlay assertions. If you register a delivery destination, it also holds that destination — whether it is a webhook or a Discord channel, the endpoint URL you gave, any label you chose, its verification state and its recent failure count. Every delivery attempt writes a receipt, and a receipt records the channel, the mint, the observation it came from, the outcome and the timings — never the endpoint URL, which is replaced by a one-way digest so the public ledger cannot be read back to your infrastructure. This data is stored durably in this deployment's database and persists across restarts; where a deployment runs without durable storage it lives in process memory and ends when the instance restarts. Reports are generated on demand and are not tied to your identity or to any account. Provider logs and any aggregate analytics are retained according to those providers’ policies. Local price snapshots, when enabled, contain token prices only — no personal data.

The project-side pages write nothing durable. A submission exists for the length of the request that carried it; afterwards there is no record it was made beyond the operational log line described above, which holds an event name and counts and none of the content. There is also no way for us to retrieve a document produced there, which means there is nothing for us to delete on request and nothing we could restore for you if you lose your copy.

Evidesa relies on cloud and data providers that may process requests in countries other than yours. Using the service may involve transferring technical request data across borders.

Because an account is an address rather than an identity, we usually cannot tell which data, if any, is yours except by the same proof that created it — a signature from the key. Most requests therefore reduce to general technical-log handling by our providers. Depending on where you live, you may have rights to access, correct, or delete personal data. To ask a question or make a request, contact us via the contact page or at hello@evidesa.com.