Privacy notice

1. Service and contact

Gramium.io is the service described in this notice. Questions, access requests, correction requests or deletion requests can be sent to [email protected]. We may need enough information to verify that a request concerns your wallet account.

2. Public wallet and market data

TON wallet addresses, balances, transactions and smart-contract activity are public blockchain data. Gramium can request public account and market data from TON and third-party market services to render the Terminal, Swap and Portfolio interfaces. Connecting a wallet does not give Gramium the wallet seed phrase, private key or custody of funds.

3. Wallet authentication and sessions

For sponsor account sign-in, the backend issues a random, single-use challenge. The selected wallet can return a ton_proof containing the wallet address, network, public key, wallet state-init data, application domain, timestamp, signature and challenge payload. The backend checks the proof before creating a session.

The current code stores a SHA-256 hash of the challenge in Cloudflare D1 rather than the challenge value itself. After verification, D1 stores a user identifier, wallet address, network, public key, wallet state-init hash and verification timestamps. The browser receives a random session token in an HttpOnly, SameSite=Lax cookie; hosted HTTPS sessions also use the Secure flag. D1 stores only the SHA-256 hash of that session token.

The default code expires a challenge after five minutes and session access after seven days. Expiry stops authentication; it is not a promise that the corresponding database row is automatically deleted at that moment.

4. Sponsor account records

The dashboard can return campaigns linked to the authenticated user, including the selected listed project or advertiser-supplied project name, HTTPS URL, category, description and optional project logo, plus placement, selected UTC campaign weeks, status, server-locked price and duration, accepted sponsor-terms version, schedule and, when verified, a public transaction hash and explorer link. Sponsor checkout can also store a short-lived inventory hold and a payment intent containing the payer and recipient wallet addresses, TON network, amount, unique payment reference, payload hash, expiry and verification status.

For an optional custom-project logo, you can upload a PNG or WebP file directly to Gramium or choose to import the project's website favicon. For a favicon import, Gramium's server sends the public HTTPS origin of the project website to Google's www.google.com/s2/favicons service; this request does not include the website path, query string, wallet address or account identifier. Gramium validates the uploaded or imported image for file type, size and dimensions, then stores it in a private Cloudflare R2 bucket under a campaign-specific object key. The stored logo is served through a same-site Gramium image route when the campaign is active, with a public cache lifetime of up to one hour.

Campaign creation can require a Turnstile anti-abuse token. The token is sent to the backend for verification against the expected Gramium hostname and sponsor action; the current campaign record does not retain that token. This check helps limit automated abuse but does not replace wallet authentication or payment verification.

Payment uses two server-side stages. First, when a wallet returns a signed transaction BOC, Gramium structurally validates it, stores a hash of the submission, and binds it to the one-time payment intent. Wallet submission is not treated as payment confirmation. Second, an independent scheduled verifier checks the exact finalized incoming transaction on-chain, and a campaign activates only after that stage succeeds. Performance reporting starts only for an active, verified placement.

For an active sponsor card, Gramium counts a measured impression after at least half of the card remains visible for one second. Sponsor links pass through a same-site Gramium redirect so a click can be counted before the visitor reaches the advertiser's HTTPS URL. A random first-party HttpOnly cookie helps deduplicate short bursts and calculate daily unique activity; D1 stores only a SHA-256 hash of that random value, not the cookie value, IP address or user agent. Known bot and prefetch requests are excluded where they can be identified. Daily aggregates are shown only to the wallet account that owns the campaign.

The database schema includes an optional contact-email field for future operational messages or invoices. The current account interface does not collect or verify that email. Email is not a substitute for wallet ownership and is not an automatic wallet-account recovery method.

5. Swap confirmation records

When a wallet-authenticated user approves a swap prepared by Gramium, TON Connect can return a signed external-message BOC. Gramium decodes that BOC to calculate its normalized TON message hash and signed-message hash, then discards the BOC itself. D1 can store the authenticated account identifier, public wallet address, network, Omniston quote identifier, token pair, integer quote amounts, minimum output, quoted referral-fee units, exact expected wallet-message fingerprints, expiry, status and later the public transaction hash.

A scheduled Worker asks TONAPI for the transaction and complete trace identified by the normalized message hash. A swap is marked confirmed only when the finalized successful trace belongs to the verified wallet and its outgoing messages match the addresses, amounts and payload hashes prepared by Gramium. A wallet return, quoted referral amount or pending trace is not recorded as completed revenue. TONAPI processes the public message hash and blockchain transaction under its own policies.

Gramium Radar in Telegram

Radar stores your Telegram user and private-chat identifiers, tracked TON token contracts and selected pools, alert metrics, directions and thresholds, notification state and pending alert setup. It also stores Stars orders, invoice and charge references, amounts, subscription periods and renewal state, accepted terms versions and refund records. Incoming Telegram updates, queued messages, delivery status and support requests are stored to operate the bot, manage access and payments, retry delivery and investigate failures.

Radar does not require a wallet connection, phone number, seed phrase or private key. Market queries send the token contract to DEX Screener or GeckoTerminal without your Telegram user or chat ID. Trailing rules also store a percentage, observed price peak and baseline timestamp. Telegram processes bot messages and Stars payments under its own policies; Cloudflare hosts the bot and its D1 database. If you send a support request, its text and your Telegram user ID can be forwarded to Gramium's support chat.

Removing an alert disables it; the saved row remains. Confirming /erase first requests cancellation of active subscription renewal, then deletes your saved alerts and support records, clears pending alert setup and pending deliveries, and pauses notifications. It also clears earlier stored message and callback update payloads associated with your user ID. It does not delete your user record, subscription, payment or refund references, or every technical record.

Scheduled cleanup deletes completed incoming updates once they were processed more than 7 days ago. Delivery records that are no longer pending are deleted once their delivery expiry is more than 7 days old. Cached market snapshots with no active alert are deleted after 7 days without a refresh. Pending or failed incoming updates, saved alerts, user and support records, and subscription, payment and refund records have no blanket automatic deletion deadline in the current code.

Use /privacy for the bot's notice, /support for help, or [email protected] for a data request. Pausing notifications, cancelling renewal and erasing alerts are separate controls.

6. Analytics and service providers

Every generated Gramium page currently loads DataFast for product analytics and named interaction goals. DataFast states that its script can collect cookies, IP addresses and visitor activity. Browser or content-blocking settings may block that script.

Gramium's custom revenue goals send bounded product context such as a project key, category, result count or selection count. The text entered into the homepage search is not included in custom events or persisted in the share URL. Local revenue follows are stored only in this browser and do not require an account, email address or wallet.

The Settings page can set DataFast's supported datafast_ignore browser flag. Once excluded, later page loads and Gramium's programmatic product goals are skipped in that browser until the setting is re-enabled.

Gramium also uses DataFast's server-side crawler tracker on public content routes. When a recognized search-engine or AI crawler requests a page, crawler-facing file or sitemap, the middleware can report the requested public URL, crawler user agent, source IP and response context to DataFast so the provider, crawl category and verification confidence can be classified. The middleware is designed to ignore ordinary browser traffic, private API routes and static assets.

Paid-placement performance reporting is separate from DataFast. It uses Gramium's own Pages Functions and D1 tables to count measured sponsor-card impressions, tracked sponsor-link redirects and daily deduplicated activity. Raw deduplication records are short-lived; historical dashboard reporting is retained as daily aggregate counts with the campaign record.

The account code is designed for Cloudflare Pages Functions and D1, and sponsor campaign creation can load Cloudflare Turnstile for an anti-abuse check. That check may process browser, network and interaction signals under Cloudflare's policies. Local tests use local data; a hosted test processes account requests through the configured Cloudflare environment. TON Connect and the wallet selected by the user also process connection data under their own software and policies. These providers may operate infrastructure outside Switzerland.

7. Why the data is used

• to verify control of a wallet address and maintain an authenticated session;
• to show sponsor campaigns belonging to that account;
• to reserve sponsor inventory and verify a requested TON payment;
• to distinguish a wallet-returned swap message from its matching finalized on-chain trace;
• to report measured sponsor-card views, tracked link clicks and click-through rate to the campaign owner;
• to prevent automated sponsor-checkout abuse;
• to protect challenges and sessions against replay or unauthorized use;
• to understand aggregate product usage and improve the site; and
• to understand which public pages search engines and AI crawlers discover or request; and
• to answer messages sent voluntarily to the support address.

The current Gramium code contains no feature for selling wallet-account records.

8. Retention and control

Challenges and sessions contain expiry timestamps, and sessions can be revoked by signing out. Short-lived sponsor-event deduplication rows are cleaned on a bounded schedule, while daily aggregate performance counts can remain with the campaign record. Campaign, account and swap-confirmation records in D1, and an uploaded campaign logo in R2, may remain until they are reviewed or removed. No automatic deletion schedule for all of those records is promised in the current beta.

You can disconnect the wallet in the interface, sign out of the sponsor account, block analytics through browser controls, or contact Gramium about an account record. Disconnecting a wallet and signing out are separate actions.

9. Changes to this notice

This notice will need to change if Gramium starts collecting contact email, changes payment or analytics providers, or changes the data it stores. The date at the top identifies the version shown on this site.