Privacy Policy

1 About This Policy

1.1 Who we are

Onflow Ads is an advertising and growth platform for Telegram channels, operated by the business operating onflowads.com from India under the name Onflow Ads, which is subject to Indian law and to the jurisdiction of the Indian courts. We operate the website at onflowads.com and the Telegram bot @OnflowAdsBot, which notifies you and carries out what the website has decided. Through them we run Boost Metrics, Paid Promotions, Cross-Promotion, the Subscriber Exchange, a set of AI features, and a wallet that funds all of it.

For the personal data described here, Onflow Ads is the Data Fiduciary under India's Digital Personal Data Protection Act, 2023 (the "DPDP Act") and the controller under the EU/UK General Data Protection Regulation, except where section 3 says otherwise.

1.2 What this covers

Everything we do as Onflow Ads: the website (signed in or not), the bot, the emails and notifications we send, and the back-office systems that run orders, payments and support. It covers you whether you are a channel owner, an advertiser, a buyer of a growth service, someone who only ever filled in the contact form, or someone who merely clicked a link in a promotion we delivered (section 8).

It does not cover what Telegram does with your data, what a payment provider does with data you give it directly, or what another user does with data you choose to hand them. Those are governed by their own policies, and section 3.3 explains where our responsibility stops.

1.3 How to read it

Each section is numbered so it can be cited, and every heading has a link anchor — hover a heading to copy a deep link straight to that clause. Sub-clauses are numbered N.1, N.2 and so on.

Two kinds of sentence appear in this document, and it helps to know which one you are reading.

2 Definitions

These terms carry the same meaning throughout. Terms defined in the Terms and Conditions — "Channel", "Placement", "Order", "Wallet", "Bot" and the rest — keep the meaning given there.

Personal data

Any data about an identifiable individual. On this platform that mostly means your email address, your name, your Telegram identifiers, your IP address, what you did and when, and what you paid for. It includes data that identifies you only when combined with something else we hold.

Processing

Anything done with personal data — collecting, storing, using, sharing, changing, or deleting it. Storing data and doing nothing with it is still processing.

Data Fiduciary / controller

Whoever decides why and how personal data is processed. That is us for the data described in this Policy, and it is you for the data described in section 3.2.

Data Principal / data subject

The person the personal data is about. If you are reading this, that is you.

Processor / sub-processor

A company that processes personal data on our instructions and for no purpose of its own — our host, our database provider, our email sender. Section 14 lists them.

Supplier

A third-party service that fulfils a Boost order. A supplier receives the target of the order — a channel link, a post URL or, for some Telegram services, a private invite link — and never your identity. Section 14.4 explains why the invite-link case deserves your attention before you order.

Counterparty

The other user in a deal — the channel owner running your Placement, or the advertiser booking your Channel. Section 13 sets out exactly what they see.

Audience

The members of a Channel, and anyone who sees or clicks a promotion delivered through the Services. Audience members are usually not our users, which is why they have a section of their own.

Aggregate data

Counts and averages that describe a group rather than a person — subscriber counts, average views, click totals. Aggregate data is not personal data, and we say so where it matters because the difference decides what we may keep.

Material change

A change to this Policy that does one of exactly four things: adds a new purpose, adds a new category of personal data, adds a new category of recipient, or lengthens a retention period. That list is exhaustive — anything else is a minor change under section 26.2. Narrowing a commitment from section 1.3 is treated as material too.

Baseline standing

The reliability score a brand-new account starts at. Leaving below it means leaving with a score we have reduced because of something that happened in a deal — which is the only situation where the anti-evasion marker in section 20.3 is written. Leave at or above baseline and nothing is written at all.

The platform owner

The person who operates Onflow Ads and holds its highest level of administrative access — the single account that can perform the actions this Policy reserves, such as reaching backups. Where a section says something is limited to the platform owner, that is the limit it means.

3 Who Is Responsible for Your Data

Data protection law puts duties on whoever decides what happens to personal data. On a marketplace that decision is not always ours, and pretending otherwise would leave you with no idea who to ask. So this section splits it three ways.

3.1 Where we decide — we are responsible

For your account, your orders, your payments, your Wallet, your support tickets, the security logs we keep, and the analytics we compute about how the Services are used, we decide the purpose and the means. We are the Data Fiduciary and controller, and every obligation in this Policy is ours.

3.2 Where you decide — you are responsible

When you use the Services to reach other people, the personal data of those people is yours to answer for, not ours. That includes:

• personal data inside creative you upload — a name, a face, a testimonial, a screenshot of a conversation;
• your own Channel's members and anything you know about them;
• data you collect on a landing page you send traffic to, including through a tracked link we mint for you.

For that data you are the controller and we act on your instructions. You must have a lawful basis for processing it, must honour the rights of the people it belongs to, and must not use the Services to process data you are not entitled to process. This mirrors section 23.6 of the Terms.

Two features put you squarely in that seat, and they deserve naming rather than leaving to the general words above:

• A white-label storefront. If your plan lets you run a branded storefront on your own domain, the enquiries strangers submit there — their name, their contact details, what they asked for — are collected through our systems and delivered to you. Those people are your prospects, not ours. You are the controller of that data, you must tell them who you are and what you will do with it, and you must not use our systems to collect what you have no basis to collect. We process it to run the storefront and to deliver it to you, and for nothing else — we do not market to your leads.
• Outbound webhooks. If you configure one, we POST your order records — including the target links in them — to a host you nominate. Where that data goes after it leaves us, and what the receiving host does with it, is yours to answer for.

3.3 Where neither of us decides

Telegram is not our platform. What Telegram collects about you as a Telegram user, what it shows in a channel, and how it handles your account are governed by Telegram's Privacy Policy, not by this one. The same is true of a payment provider's own checkout page, an app store, and any site you follow a link to. We can only tell you what we send them and what they send back — which we do, in section 14.

4 Information You Give Us

The DPDP Act asks for an itemised description rather than a summary, so this section and the next two list categories rather than gesturing at them. Nothing below is collected for its own sake; each row exists because a feature stops working without it.

4.1 Creating and running an account

Name

Sign-up. To address you, and to put a human name on support and dispute correspondence.

Email address

Sign-up. Your account identifier, your sign-in credential, the route for verification codes, receipts, order notices and account recovery.

Password

Sign-up. Stored only as an argon2id hash. We never hold your password and cannot recover it — a reset replaces it, it does not reveal it.

Two-factor secret & recovery codes

If you turn on 2FA. To verify the six-digit codes from your authenticator app, and to let you back in if you lose it.

Your role — advertiser or channel owner

Enlistment. Decides which products and which parts of the marketplace you see. You choose one, you confirm it with a code, and it is permanent — it is what the other side of every deal relies on, so we do not let it be swapped later. It is the one thing in your profile a correction request under section 22.1 cannot change.

We also mint two identifiers of our own at sign-up: a random public id, and your OFA ID — the short reference you quote to support. Neither is derived from anything about you. Section 28 covers what those identifiers are and are not linked to.

4.2 Channels you connect

When you connect a Channel we store what the marketplace needs to list, match and price it: its Telegram id and username or invite link, its title and public description, its category and language, its subscriber count and engagement figures, and the pricing and availability you set. Section 6 explains where the figures come from and what we deliberately do not read.

We also keep a snapshot of the Channel's recent public posts — roughly the last twelve, each as a short extract with its view count, its date, and whether it carried a photo or a video — and we show that snapshot to signed-in advertisers on your listing page. It is how a buyer sees what your Channel actually publishes before paying to appear in it, and it is why a listing does not need you to write a sales pitch. Everything in it is taken from what is already public on your Channel, it is refreshed from Telegram when you or we update the listing, and it goes when the listing does. We call it out here because it is content rather than a count, and section 6.4 would otherwise leave you expecting only numbers.

4.3 Campaigns, creative and orders

• Creative — the ad copy, images, buttons and destination links you submit for a Placement, a Cross-Promotion or a Subscriber Exchange slot. This is content you publish, and it is shown to the counterparty and, once live, to their audience.
• Order details — the target link, the service, the quantity, the schedule, the budget, and any targeting or drip-feed settings.
• Proof and delivery records — screenshots, message links, before/after figures and the certificate pages generated when an order completes.

4.4 Money

Top-ups, plan purchases and payouts generate a transaction record: the amount, the currency, the method, the provider's reference, the status, the fee, and the resulting Wallet movement. For payouts we also hold the destination you gave us — a UPI handle, bank details or a crypto address, depending on the method.

If you ask for a top-up back, we additionally hold what that request needs: the reason you typed if you gave one, the fee breakdown and net figure it was quoted at, the amount held while it was open, the decision and the reason for it, the reference of the payment we sent, and — for a cryptocurrency refund — the destination address you supplied. A refund of a UPI or card payment needs no destination from you at all, because it returns to the method you paid from. See the Refunds Policy for how that process works.

4.5 Verification for payouts

Sellers who cross a lifetime-payout threshold are asked to verify. The first level collects your legal name and country, and is approved automatically. Higher levels are reviewed by a person, and if we need anything further at that point we will ask you for it specifically and tell you why before you send it.

4.6 Support and correspondence

A contact-form enquiry stores your name, email address, subject and message. A support ticket stores the same plus a phone number if you give one, and the technical context that makes a problem diagnosable — the page you raised it from, your IP address and your browser. You can open a ticket without an account, and if you do, that ticket is all we hold about you.

Dispute submissions, campaign reports, reliability appeals and anything you send the Bot are kept with the account they relate to, including the evidence you attach — a campaign report carries your written testimony and the screenshots you upload, our team reads them alongside our own record of the campaign, and the party you reported never sees them. If you tell us something sensitive in a ticket, it lives in that ticket — so please send only what the question needs. Where an AI feature drafts or triages a reply, the ticket goes to a model provider; section 12.2 says so plainly and tells you how to opt that out.

The support chat on the site is answered by AI in the first instance, and it works the way you would expect from the paragraph above: each message you send, together with the page you send it from, is processed by our AI model provider to generate the reply, and the conversation is stored as a support ticket like any other. If you ask for a human, we collect the email address you provide so a person can come back to you, and our team can read the transcript of the chat — including what the AI said to you.

Since 16 September 2026 the chat can also carry out routine tasks for you — cancel an order that has not started, accept a booking on your channel, answer a partner request, and the other tasks the product's Help tab lists — but only when you are signed in and only after you confirm the proposed task in that conversation (Terms, section 10.10). A confirmed task runs through the same request the page would make, as you. What we keep of it is an action log on your support ticket: which task was proposed, whether you confirmed it, whether it ran, and the one-line result — with anything you typed that looked like a card number, a password or a key masked before it is stored. Nothing about a task is sent to a model provider beyond the message you wrote, and nothing about it is used to train a model.

You do not have to be signed in to use it, and that changes what we need to hold about you. A signed-out visitor gets a small number of AI messages, which we have to be able to count without an account to count against. So we count against the browser: we set a cookie holding an opaque random handle — no name, no email, nothing derived from you — and store, against that handle alone, how many messages it has used, when its cycle started, and the IP address the last message came from. The address is there for abuse triage, because a cookie is trivial to clear and something has to bound what one source can spend. The handle and its counter are deleted after 180 days, and the cookie is described in section 18.1. Sign in and your account carries the allowance instead, and none of this is used.

On some accounts the chat can also be shown a screenshot. Where it is available you will see a paperclip in the composer, and you can attach a picture, paste one straight out of the clipboard, or drop one onto the box. What that does is send the picture to our AI model provider along with the message, so the agent can look at the problem instead of being described it — section 12.2 sets out exactly what leaves your browser and section 12.3 how long it is kept. The capability is not open to everyone: it is switched on for accounts whose lifetime top-ups have passed a threshold we publish in the product, and an administrator can turn it on for an account below that threshold or off for any account at all. A signed-out visitor never has it, because there is no account to have spent. When it is not available the paperclip is simply not there, and the chat says in one line why.

There is no other route. The chat cannot prove an account for you: a visitor who is not signed in is a guest, and a guest's questions are answered from the documentation and our policies only — no record is read, no account is looked up, and no code is offered to change that. Signing in is the one way to have the chat read your account, on every plan; acting on it from the chat is a capability of Plus and above, described in section 12.2. Until 16 September 2026 a guest could prove an account inside the chat with an emailed code; conversations bound that way no longer unlock anything, and the record of those verifications stays with the conversation it belongs to, for as long as that conversation is kept.

Three pieces of support bookkeeping ride along with the tickets themselves. Every conversation is assigned a short reference (the OFS-XXX-XXXX code shown in the widget and in our emails) — it identifies the conversation but cannot open it, so it is safe to quote. Because the AI chat is a plan benefit with a monthly allowance on some plans, we keep a per-account count of AI conversations opened each calendar month — a number, not the content — to enforce that allowance. And where we restrict a person's access to the support surfaces for abuse, we keep a record of that restriction — the account and/or email address it applies to, the reason, who applied it and when — for as long as it stands, so it can be enforced, reviewed and lifted.

5 Information Collected Automatically

5.1 Device and connection

When you use the Services we record your IP address and your browser's User-Agent string against security-relevant events — signing in, failing to sign in, verifying an email, changing a password, enabling or disabling two-factor authentication, requesting admin access. From the User-Agent we derive a readable label ("Chrome on Windows") that our staff see when investigating an account.

We use the IP address to work out an approximate location — country level, for fraud signals and currency — and as a key for rate limiting and lockouts. We also record the page you came from when you arrive from elsewhere. Lockout counters are keyed on a hash of the email address or IP rather than the value itself; short-lived rate-limit counters use the address directly and expire with the window they meter — minutes for most of them, and up to an hour for the ones that cap how many sign-ups or verification codes an address can ask for.

5.2 Our activity record

Meaningful requests across the Services are written to an activity record — who acted, what they did, when, from which IP address and browser, the country inferred from that address, the referring page, and the outcome. It is how a support agent reconstructs what actually happened to an order, and how we notice an account being worked over by someone who is not its owner. The same entries are mirrored to an operations channel described in section 14.5.

5.3 Usage

We record which pages and screens you open, which features you use, which buttons you press in the Bot, and the outcome — an order placed, a slot booked, a Wallet top-up started and abandoned. This is what produces your analytics, our funnel reporting, and the evidence for a dispute about whether something was actually delivered.

5.4 What we compute about you

Some of the most consequential data we hold is data you never gave us — we worked it out. It is still personal data and you still have rights over it.

• Reliability score and account standing — a running measure of how you behave in deals: cancellations, no-shows, disputes upheld against you, delivery kept or missed. It gates what you can access and is visible to counterparties as a trust signal.
• Performance and delivery metrics — views, clicks, click-through rates, completion rates, refund rates and the aggregate figures behind them.
• Risk and abuse signals — indicators of collusion, self-dealing, duplicate accounts, bot-driven traffic or evasion of a penalty. This includes a routine check that links accounts which have signed in from the same IP address, the device identity described in section 5.5, and automated checks that a Channel is still carrying a post it was paid to carry. All of them feed the review in section 11.2; the device identity alone can also act on its own, in the one case 5.5 names. The same-IP link is used for that and nothing else.
• The post-still-there check has consequences beyond a review, and calling it a quiet fraud signal would understate it. Where a second consecutive check confirms an agreed post came down early, that finding reduces the Channel owner's reliability score, can hold their payout, and can trigger a refund to the advertiser. It is also shown: as a delivery flag to the advertiser on that order and in what they can export, as evidence if the deal is disputed, and on the delivery certificate for that placement — which, as section 13.3 explains, anyone holding the link can open. Because it decides money and standing, it carries the human-review right in section 11.2, and a single inconclusive reading never counts against anyone.
• Referral links — who introduced whom (kept permanently once a sign-up binds), the click that brought a visitor (a first-party cookie, section 18.1), and what each referred deposit earned the referrer. Used to pay the reward and to detect someone referring themselves.
• How you first found us — the address of the page that linked you here, the page on our site you landed on, any campaign tags in the link you followed (utm_source and its siblings, or an advertising click identifier), and when that first visit happened. It is held in a first-party cookie (onflow_src, section 18.1) that we write on your first page view and do not rewrite, and it is copied onto your account once, at the moment you create one, together with how you signed up, the address, browser and device that did it, and the country our network provider reports. Nothing is written for a visitor who never opens an account, and the cookie holds nothing about you beyond the link you arrived on. We use it to know which of our channels actually reach people, and to tell a real sign-up from an automated one. It is never used for advertising and never sent to an advertising network.
• Commercial signals — your tier, your lifetime spend and payout totals, and eligibility for a plan, a bundle or a promotion.

Section 11 explains which of these make decisions on their own, and what you can do when one goes against you.

5.5 Device identity

A debt on Onflow Ads is a negative Wallet balance (Terms section 12.11), and an account is the cheapest thing on the internet to abandon. Without a second identity that obligation reduces to "pay, or make a new email". So on every page you use while signed in, a small script reports a set of traits of the device you are using, and we record them against your account. It is the most consequential thing we compute about you that you never typed, so here is exactly what it is.

The traits are hashed separately in your browser, and the hashes are what reach us — never the raw values. Four describe the machine and survive a browser update: the graphics renderer, the platform, the number of processor cores and the colour depth. Seven are real signal but may each move on their own: a canvas rendering, an audio rendering, the graphics limits, the screen, touch support, the languages and the time zone. Alongside them we record three things the server observes for itself and the script cannot influence — the browser family, the language header and the encoding order — so that a forged set of traits can be caught contradicting them. A browser that blocks one of those probes simply yields fewer components, which is a weaker signal rather than an error. A long-lived first-party cookie (onflow_dev, section 18.1) carries the same signature so it can be read before the script runs. The sighting is recorded at most once an hour per session, with the IP address it came from.

The same records feed the "same hands" review in Terms section 16.4 — a device seen on an unusual number of accounts is raised for a person to look at, never acted on by machine — and nothing else. They are not a tracking identifier: not sold, not shared, not joined to anything off this platform, not used to advertise to you, and not readable by any third-party tag. They are kept while your account is open and for as long as a debt they corroborate is unpaid; we do not run an automatic expiry over them today, and section 20.1 says so. This is an automated decision under section 11, and 11.2's right to a human review applies to it in full.

5.6 Advertising link and interaction records

When you tap a link in an advertisement we published, or in a Cross-Promotion or Subscriber Exchange post, your tap passes through a redirect on this site before it reaches the destination. We record that tap, and we record it whether or not you have an account with us and whether or not you are signed in. Most people whose taps we record have never used Onflow Ads and never will — you are reading someone's Telegram channel, not visiting us — so this section is written for you as much as for our users.

What one tap records:

• your IP address and your browser's User-Agent string, as sent;
• the date and time, the advertisement or campaign involved, the destination, and the page you came from;
• what we work out from the two values above — a device class (phone, tablet, desktop or automated crawler), an operating system and browser name, a country, and your browser's preferred language;
• your account, only where the tap carried a signed-in session of ours.

We record the same for interactions inside our own pages that do not navigate anywhere — pressing a button, opening a tab, copying a link — so that the reporting an advertiser or Channel owner sees reflects what people actually did, rather than only the taps that happened to leave the page.

These records exist to count a campaign's performance honestly, to tell a real audience apart from automated traffic, and to settle a dispute about whether a placement delivered what it was paid for. They are not used to advertise to you, are not sold, are not shared with the advertiser or the Channel owner at the level of an individual tap, and are not joined to anything about you from outside this platform. An advertiser sees totals and breakdowns — how many taps, from which countries, on what kind of device — never your address or a row that is recognisably you.

6 Telegram and Connected Platforms

6.1 Signing in through Telegram

You can sign in with Telegram using its official OAuth / OpenID Connect login. When you tap Log in with Telegram we send you to Telegram to confirm; Telegram then returns you to us with a short-lived authorization code, which our server exchanges for a signed identity token containing your numeric Telegram user id, the name and username on your Telegram profile, and a link to your profile photo. We verify that token against Telegram's published public keys before trusting it, and we retain your Telegram user id and display name to identify your account. The token carries an expiry, so it cannot be reused later.

6.2 The Bot

The Bot is an executor: the website decides, the Bot carries out. When you message it, Telegram passes it your user id, your display name and username, your language setting and the content of the message — and it answers everything except the two links described below with a single pointer back to the website. It keeps no conversation with you, because it has none: there are no menus, no wizards, no orders and no support desk inside it.

What the Bot holds, and where:

• Your account link. Tapping Connect Telegram on the website opens the Bot with a one-time token; consuming it writes your Telegram user id, and the moment you first started the Bot, onto your account record in the shared database. That link is what lets the website message you in Telegram.
• The work it carried out for you — the posts it published and took down, the placements it delivered, the proof captures and the monitoring readings that say whether an agreed post is still there. These are recorded against the campaign or placement, in the shared database, and can move your Reliability Score, so they are kept for as long as section 20 says a dispute could still turn on them.
• Joins through a campaign's invite link, recorded as a salted hash of the member, never as an identity — section 8.1.
• The facts it reports. When it observes something that should move a score — a placement pulled early, a post deleted, a member who left a partner's channel — it writes the fact (what happened, to which deal, and the Telegram id of any administrator who acted) into a queue the website reads. The website prices it from its published table; the Bot never changes a score, and a fact the website does not recognise is never applied.
• A display mirror of your plan in its own small datastore, refreshed from the website. It decides nothing from it.
• Review cards it posts into our private administration channel when a cross-promotion post or an exchange ad needs a human decision — the decision itself is made on the website.

The Bot also looks at the Channels you connect, because that is how we check what actually happened. It reads whether the Channel exists and whether you administer it, its subscriber count and recent public posts to measure reach, and — while an agreed post is running, in Paid Promotions, Cross-Promotion or the Subscriber Exchange alike — whether that post is still there. It reads only public channel content and the posts our own Placements created; it does not read your subscribers' messages or their identities. Section 6.3 sets the limits.

The Bot and the website are one platform sharing one database, so an action in one shows up in the other. They are covered by this single Policy for exactly that reason.

Where Google Analytics is configured in our admin settings, the Bot also reports campaign events — a booking placed from a Telegram button, for instance — to it server-side, using your Telegram user id as the identifier, as both the device identifier and the user identifier that provider recognises you by. This is a persistent identifier about you reaching an analytics provider, so we name it rather than let it sit under "usage data".

6.3 What the Bot does not do with your Channel

Connecting a Channel means giving the Bot administrator rights on it. What it does with them is deliberately narrow, and the limits are contractual as well as descriptive — the same three appear in section 4.2 of the Terms.

You can remove the Bot's access at any time by removing it as an administrator of the Channel, or by disconnecting the Channel from your account. Access ends immediately. What we have already recorded about completed orders stays under section 20, because a deal that happened is a record we are required to keep — but nothing further is read from that Channel.

6.4 Channel statistics

To price and verify a Channel we read the figures Telegram exposes about it: its subscriber count, the view and reaction counts on recent posts, posting frequency and the timing pattern those imply. We use the Telegram Bot API and, for public channels, an operator-held Telegram reader account which can see what any member of that channel can see. It is used to count, and to confirm that a post we were paid to place is still there.

There are exactly two places where we look at a person rather than a count, and both are named here rather than left inside the general words above.

The first is the one that proves you own the Channel: to verify a Channel we ask Telegram for its administrator list and check that our Bot — and, where your Telegram account is linked, you — appear in it. Only an administrator can appoint another, so that list is the proof, and it is why we do not ask you for screenshots. Where a co-administrator is not an Onflow Ads user, their Telegram identifier reaches us as part of that check; it is used to answer the ownership question and for nothing else. Section 4.3 of the Terms describes the same check.

6.5 Google and Apple sign-in

Where enabled, you may sign in with Google or Apple. We request the minimum scope each offers for identification — from Google, your basic profile and email address; from Apple, your name and email address, which you may choose to relay through Apple's private address. We receive no password, and no access to anything else in that account.

6.6 Other platforms

Support for further platforms — Instagram, YouTube, X, TikTok and Discord among them — is on our roadmap. When one goes live, the data we take from it, the permissions we ask for and the reason will be published here before you can connect an account, either in an update to this section or as an Additional Privacy Term. We will not quietly widen collection under a general sentence about "supported platforms".

7 Information We Receive from Third Parties

Not everything we hold came from you or from your device. These are the other routes, and what arrives by each.

Payment providers

Payment status, amount, currency, provider reference, method type, fee, failure reason, and any chargeback or dispute raised against a payment. For crypto, the transaction hash and the amount confirmed.

Suppliers (Boost fulfilment)

Order status, quantity delivered, start count and remaining, and refill or cancellation outcomes. Nothing about you personally — they were never told who you are.

Telegram

What sections 6.1–6.4 describe, plus delivery outcomes when the Bot messages you.

Google / Apple

The sign-in profile described in section 6.5, when you use that route.

Other users

What a counterparty says about a deal — a dispute, a review, a report of abuse, and the evidence attached to it.

Anti-abuse services

The result of a bot-detection challenge on a form — a pass or a fail, plus the risk signals the provider returns.

Where a third party sends us something we did not ask for and do not need, we discard it rather than file it.

8 People Who Are Not Our Users

An advertising platform inevitably touches people who never signed up for anything — the audience of a Channel where a Placement runs. Most policies pass over this in a sentence. It is the part of our processing that deserves the most explanation, so it gets a section.

8.1 Links in an ad, and what we measure about them

Every link in a Placement — in Paid Promotions, Cross-Promotion and the Subscriber Exchange alike — is planned by us before it is published, and what it becomes depends only on where it points (Terms section 17.4). Three things can be measured, and each keeps a different record.

A join, through an invite link

Where the destination is a Telegram channel the advertiser has connected to us, we publish a per-campaign invite link into that channel. Telegram attributes every join to the link and tells the one process it tells — our Bot, as an administrator of that channel — which records the join, and any later leave or return, against the campaign. What is recorded is a salted one-way hash of the Telegram user id (salted with a secret only our systems hold), the channel, and the times of joining and leaving. Enough to recognise the same person leaving again; never enough to name them, and no name, username or profile is stored. We also note the channel's public subscriber total when the link is created and again as the run proceeds, so the advertiser can read the growth beside the join count. The advertiser sees counts.

A tap, at our redirect

A web destination is published as a first-party redirect of ours (/go/…) that sends the reader straight on. At that hop we record the tap, the link it was for, the visitor's IP address and User-Agent as sent, a one-way salted hash of those two, and the country, referring page, device type, operating system, browser and preferred language. A repeat tap by the same hash on the same day is not a new unique, a reload loop is capped, and link-preview crawlers are served but never counted — they are still recorded, and marked as crawlers, so a spike can be shown to be automated rather than quietly dropped. The IP address and User-Agent are deleted after 90 days (§5.6), after which only the hash and the derived values remain. No cookie is set on the visitor's device by the redirect.

A landing or a conversion, on the advertiser's own site

See the note below: this is the part a reader would not guess.

What the hash is for. Its first job is to tell a repeat tap from a new one, so that a click figure means something. It has a second job we should name rather than leave inside the word "deduplication": when a buyer is choosing between channels, we use their own past click hashes to tell them how much the audiences they have already reached overlap — how many of the devices a proposed channel would reach they have effectively already paid to reach elsewhere. That comparison happens across a single buyer's own campaigns, produces counts rather than lists, and exists to stop advertisers paying twice for the same audience.

It is worth being exact about what that hash is, because "hashed" is a word policies often use to mean more than it can. It is a one-way function salted with a secret only our server holds, so it is not an encrypted address we could decrypt, and it cannot be matched against a hash produced by anyone else — which is what stops a click record joining up with data held somewhere outside this platform. It is also not anonymity: we hold the salt, so we are the one party who could take a specific address and test whether it matches. We do not do that, we have built nothing that does, and we will not — but you are entitled to the accurate version rather than a claim of mathematical impossibility that is not true of the party holding the key. The same is true of the member hash behind a join.

8.2 How long these records last

Tap, landing, conversion and join records live with the campaign they belong to, and are covered by the order retention row in section 20.1. Because they carry no address and no account link, a visitor who asks what we hold about their tap or their join will usually find there is nothing we can identify as theirs — which is the point of storing them that way, and is also the honest answer to a request rather than a refusal. Invite links minted for a campaign that never goes out are revoked.

8.3 The one place a tapper is identified — and it is closing

8.4 The audience of a Channel

We do not collect member lists, viewer identities or reaction identities from any Channel — see section 6.4. What an advertiser learns about a Channel's audience from us is aggregate: how many, how engaged, when they are active.

8.5 People you tell us about

If you name someone in a support ticket, a dispute, an abuse report or a piece of creative, we process that data to deal with the matter you raised. We keep it with the matter and no longer than section 20 allows. If that person asks us what we hold about them, we will tell them — and, where you supplied it, generally point them to you under section 3.2.

8.6 Your rights if you are not a user

Everything in section 22 is available to you even if you have never had an account. Write to [email protected] with enough detail to find the record — the link you clicked, the promotion, the approximate date — and we will search and respond.

Two honest notes so the answer is not a surprise. For click data the answer is usually that we hold nothing we can tie to you, precisely because it was never stored in an identifiable form — that is a real answer, not a brush-off, and 8.1 explains why. And because you are not an account holder, there is no account email for us to verify you against, so we may need to ask you for enough detail to be confident the record is actually yours before we hand anything over. That step protects you: it is what stops someone else asking us about you.

9 What We Do Not Collect

A notice that only lists what a platform takes tells you half of what you need. These are commitments, and changing one needs the notice in section 26 — not a quiet edit.

We also do not buy personal data from data brokers, do not enrich your record from third-party datasets, and do not scrape personal data from Telegram or anywhere else to build lists.

10 Purposes and Lawful Bases

We use personal data only for the purposes below. Each is paired with the basis we rely on: under the DPDP Act, either your consent or a legitimate use the Act allows; under the GDPR, one of contract, legitimate interests, legal obligation or consent. Where two bases are shown, the first is primary.

Create and run your account — sign-in, verification, 2FA, preferences

§4.1, §5.1, §6.1. Basis: Contract · Consent given at sign-up.

Deliver the Services — list a Channel, match a deal, place an order, run a Placement, verify delivery

§4.2, §4.3, §6.3. Basis: Contract.

Take and move money — top-ups, plans, escrow, payouts, refunds, invoices

§4.4, §4.5. Basis: Contract · Legal obligation.

Report performance — your analytics, delivery proof, click and view figures

§5.2, §5.3, §8.1. Basis: Contract · Legitimate interests.

Keep the marketplace honest — reliability scoring, dispute handling, fraud and collusion detection, penalty enforcement

§5.1, §5.3, §7. Basis: Legitimate interests · Legal obligation.

Security — authentication, rate limiting, bot defence, incident investigation

§5.1. Basis: Legitimate interests · Legal obligation.

Support you — answering tickets, contact-form enquiries, appeals and grievances

§4.6. Basis: Contract · Legitimate interests.

Service messages — codes, receipts, order and payout notices, expiry reminders, incident notices

§4.1, §6.2. Basis: Contract.

AI features — drafting copy, suggesting targeting, safety checks, duplicate detection

§4.3, §12. Basis: Contract (when you invoke it) · Legitimate interests (safety checks).

Product analytics — understanding which features work and where people get stuck

§5.2, §18. Basis: Legitimate interests — running, measuring and repairing a service we are contractually obliged to keep working. Analytics is the always-on category described in section 18.3, so we do not call it consent when you were not asked. Consent remains the basis for the advertising tags, which never load unless you accept them.

Marketing — campaign emails and product-update mail to our own members

§4.1, §19.2. Basis: Consent — you receive it only after ticking the unticked "Send me product news and offers" box at sign-up or on a top-up checkout, or switching it on in your notification settings (§19.2). Nothing is sent on the strength of holding an account. Withdraw in one click, from any such email, without signing in, or with the same toggle.

Financial-crime compliance — checking a payout destination or a payment against sanctions and similar restrictions, holding or refusing one where we must, and reporting where the law requires it

§4.4, §4.5. Basis: Legal obligation · Legitimate interests. We do this where a payment provider, a banking rail or the law requires it of us — most often on a cross-border or cryptocurrency payout. If a payout of yours is held for this reason we will tell you, unless telling you is itself prohibited (section 15.1).

Meet legal duties — tax and accounting records, lawful requests, grievance response, complaint defence

§4.4, §20. Basis: Legal obligation · Legitimate interests.

10.1 We do not repurpose data silently

Data collected for one of these purposes is not quietly reused for another. If we want to use something you gave us for a materially different reason, we will say so first — in an update to this Policy, or as an Additional Privacy Term — and where the new purpose needs consent, we will ask for it rather than assume it.

10.2 Our legitimate interests, stated plainly

Where we rely on legitimate interests, the interest is: running a marketplace where delivery can be verified, fraud can be caught, and a dispute can be decided on evidence. We have weighed that against your interests and consider it proportionate because the data involved is transactional rather than intimate, it is used to protect the other side of a deal as much as our own position, and you can object at any time under section 22. Tell us why, and we will stop unless we can show compelling grounds that override your objection.

11 Scores and Automated Decisions

Some things on this platform are decided by code before a person ever looks. You are entitled to know which, and to get a human involved.

11.1 What is decided automatically

• Your reliability score and account standing, computed from your own conduct in deals, which can gate access to products, raise the deposit you must stake, or hold a payout.
• Eligibility floors — whether you meet the minimum standing to enlist, to take a certain order size, or to use a particular product.
• Abuse and fraud signals — duplicate-account, collusion and bot-traffic detection, which can flag an order or an account for review.
• Content safety checks on creative, which can block a submission before it reaches a counterparty.
• Rate limits and lockouts, applied per account, per email and per IP.
• What you are charged, and what you are offered. Several prices are computed rather than fixed, and your own record is an input to some of them. A Channel owner whose reliability score falls below our threshold has a capped number of extra percentage points added to the commission on each booking, which returns to normal as the score recovers — it is charged to the owner, never to the buyer, and a booking always shows the base rate and any addition separately so you can see which part came from your record. Volume discounts are computed from your lifetime spend, repeat-buyer pricing from your history with that listing, and where we have agreed a wholesale rate with you it is applied automatically whenever it beats the standard ladder. Automatic bookings you set up — auto-accept, a recurring rebook, a Boost auto-renew — form the order and charge your Wallet without a further click from you, which is what you asked them to do when you switched them on.
• The anti-evasion floor — if you closed an account while its standing was below baseline and then open a new one, the reduced standing is re-applied to the new account automatically, for the period in section 20.3. It is the one decision here that reaches across an account closure, and it is why that section exists.
• Merging two records into one when you link Telegram to a website account, on the terms in section 6.2 — including that the merged account keeps the worse standing of the two.
• The debt gate. An account whose Wallet balance is below zero cannot start anything new until it is cleared, and every credit that lands is applied to the negative first (Terms section 12.11). The two settlements that can put a balance below zero — a declared cross-promotion cover and an early unpin — are themselves applied by machine, on a monitor finding confirmed on two consecutive checks, and are appealable as any penalty is.
• The device-debt block. Where the device identity in section 5.5 matches, at a confidence high enough to enforce, a device on which another account carries an unpaid debt, this account is refused when it tries to start something new. It is the one automated decision here that reaches across accounts; it charges nothing, and a weaker match is only ever raised for a person.

11.2 A human will look if you ask

11.3 What we will tell you about the logic

On request we will explain, in ordinary language, what categories of behaviour feed a decision about you, roughly how they are weighted, and what would change the outcome. We will not publish the exact thresholds and detection rules, because doing so hands the playbook to the people the system exists to catch — and a fraud-detection system that explains precisely how to evade it protects nobody. Your right to a human review does not depend on our disclosing them.

12 AI Features

12.1 What the AI does

The Services include AI assistance: drafting and rewriting ad copy, suggesting targeting and pricing, describing a Channel, summarising analytics, checking creative for prohibited content, and spotting near-duplicate submissions. The same AI layer serves the website and the Bot.

12.2 What reaches a model provider

More than the sentence "we use AI to help you write ads" implies, so here it is in full. Depending on which feature runs, the following is sent to the model provider we have configured at the time:

You use an AI writing or suggestion feature

The brief or text you are working on, your editing instructions, the destination link, and the Channel's public profile and category.

Creative is checked for safety

The creative being checked.

A submission is checked for duplicates

The listing or creative text, converted to a numeric embedding by the provider.

AI drafts a support reply or triages a ticket

The ticket thread, including what you wrote and your name.

You use the AI support chat

Each message you send, the conversation so far, and the page you are on — sent to generate the reply. The conversation is stored as a support ticket (section 4.6). This is the same whether you are signed in or not. Before a conversation starts you are shown a short notice that says this, and you choose: accepting begins the chat, declining closes it before any message is sent. We record which you chose, when, and which version of the notice you were shown — consent to a sentence we have since rewritten would not be consent to the new one.

You attach a screenshot to the AI support chat — where your account has that turned on

The picture itself, in full, exactly as you sent it — carried to the model provider with the message it is attached to, so the model can look at it rather than be told about it. We do not crop it, blur it, or read anything out of it first: a screenshot is sent whole or not at all. That is the part worth reading twice, because a screen grab shows whatever else was on the screen — another tab, a notification, an address bar, a window behind the one you meant to capture — and nothing on our side can know which part you meant. Up to three pictures may ride on one message, each up to 4 MB, in the four ordinary image formats a browser produces (PNG, JPEG, WebP, GIF); the type is decided from the file's own bytes rather than from what your browser called it. Crop before you send, not after — deleting the message afterwards cannot un-send the picture, exactly as the ordering note below says of text.

You ask the support chat about your own account — on the plans that include it

A typed summary of your own account, assembled by our server, capped in size, and sent with every message you send in the chat. It has three parts: an account summary with your identifiers masked (your display name, your Onflow Ads ID, your plan, whether two-factor is on, your balances, credits and lifetime top-ups, your referral code and how many members it brought in, your reliability score, when you joined and how you signed up, whether Telegram is linked, your marketplace side, verification and account status, any freeze or outstanding balance with its dates, and a scheduled deletion if there is one — your email address is shown only partly, and your Telegram user id never); a list of the parts of your record that hold entries, with how many; and a few of the newest entries from the parts that bear on what you asked (or, when a question names nothing in particular, your most recent activity). On top of that, and only when you ask for them: an Onflow Ads reference you pasted and what it names, the events behind a change in your reliability score, which of your recent top-ups are still inside a refund window, and channels we suggest you approach. It is your data and only ever yours — no other member's account identifiers, contact details or messages are read — your own Orders show the Channel you booked, and suggested partners come only from listings whose owners opted into the public directory, and a reference belonging to someone else returns the same "no information" answer as one that does not exist. Never read at all: account passwords and other sign-in credentials, two-factor secrets and codes, IP addresses, devices and sign-in history, your payout destination, identity documents, and our team's internal notes and fraud or risk signals. The read is read-only at the database itself, and the model is only allowed to restate what it is given: anything with a consequence attached is written by our server, not by the model.

You ask the support chat to carry out a task

Nothing beyond the message you wrote. The task itself — finding what you could mean among your own records, proposing it, and running it after you confirm — is done by our own server through the same request the page would make, not by the model. The model sees your message and the one-line outcome so it can tell you what happened. The proposal and the outcome are kept on your support ticket as an action log, with your identifiers masked as everywhere else in this section.

AI assists on a dispute or a fraud review

Both sides' account history and the money lines of the deal in question.

AI narrates your analytics or suggests a next step

Your commercial figures — spend, delivery, performance, tier.

The engine behind those features is one of a small set of established commercial model providers. Which one is active is an operational choice that can change without a code release, so rather than print a list here that goes stale, we will tell you the provider in use, and the terms it operates under, if you ask — [email protected].

12.3 What we keep

We log that an AI call happened — which feature, which account, when, and how much quota it used — for billing and abuse control. We do not store the prompt or the model's response in that log. AI output that becomes part of your work — a saved draft, a generated description, a campaign email — is stored as your content, like anything else you saved.

One exception is deliberate: where a safety check blocks a submission, the blocked text is kept as the evidence for that decision, so an appeal under section 11.2 can be judged on what was actually written rather than on a summary of it.

A screenshot you attach in the support chat is the other thing we keep, and for the obvious reason: it is part of the conversation. It is stored against the message it was attached to, our support team can open it exactly as they can read the transcript, and it is deleted when that conversation is deleted — not separately and not later, but in the same operation, because it belongs to the conversation rather than sitting in a file store beside it. A picture you upload and then never send — you attached it, changed your mind, closed the tab — is swept away automatically within six hours. There is no gallery, no public address, and no way to reach one of these pictures other than through the conversation it belongs to.

12.4 Training

12.5 What AI output is, and is not

AI output is a draft. It can be wrong, generic or unsuitable, and you remain responsible for what you publish — see section 10 of the Terms. AI does not decide anything about you on its own beyond the checks listed in section 11.1, all of which carry the human-review right in section 11.2.

12.6 If AI is switched off

The AI layer is optional infrastructure. When no engine is configured, every AI feature degrades to templates and nothing leaves for a model provider at all. Nothing else about the Services depends on it.

13 What Other Users Can See About You

A marketplace only works if each side can judge the other. This is the exact line between what a counterparty is shown and what they are not.

13.1 What a counterparty sees

• Your Channel's public profile — its name, handle or invite link, description, category, language, and the subscriber and engagement figures we hold for it.
• The creative and order details for the deal you are in with them, including the destination link.
• Your public trust signals — the standing badge, completion and dispute history in summary form, and the reviews left on completed deals.
• Delivery evidence for the deal — proof screenshots, message links and the figures before and after.
• A display name for correspondence within the deal.

13.2 What a counterparty never sees

13.3 What is public to anyone

Channels listed in the public directory, and the pages you choose to make public, are visible to anyone — that is the point of listing. Delivery-proof and certificate pages are unlisted but reachable by anyone holding the link: we do not list them anywhere and we ask search engines not to index them, but they are not access-controlled, so the link is the only lock. If someone posts that link somewhere public, it can be found and crawled like any other address on the internet — which is why the honest instruction is to treat it as private rather than to trust that it is hidden.

13.4 People who copy what is public

Because a directory listing is public, other people can and do copy it. We do not permit it — automated collection of pages and listings is prohibited by the Terms, and we take technical measures against it — but we want to be straight with you about the limit of what any website can promise here: once a page is readable without signing in, we cannot guarantee that nobody has copied it, and a dataset assembled by someone else from public pages is outside our control and not something this Policy can govern.

What we can tell you is where that boundary sits. The public side is the listing you chose to publish and the pages you chose to make public. Everything in 13.2 — balances, ledgers, addresses, other campaigns — is not on a public page at all, so it is not there to be copied. If you find our content or your listing republished somewhere it should not be, tell us at [email protected] and we will act on it as far as we are able.

13.5 What our own staff can see

Our support and operations staff can see your account record — email, name, standing, balances, orders, tickets, the addresses and browsers on the security events in section 5.1, and the verification details in section 4.5 — because they cannot resolve a dispute or a locked account without it. We would rather state that plainly than imply a graduated view in which some staff see less: anyone we give an administrative login to can read account records. What is genuinely restricted is doing things — the consequential and irreversible actions are reserved to the platform owner — and every administrative action is written to a log that cannot be edited.

The controls that actually protect you here are therefore fewer people and a complete record, not a permissions matrix: administrative access is granted to as few people as the work allows and withdrawn when it is no longer needed. We do not read your data out of curiosity, we do not sign in as you to look around, and we do not use what we see in your account for anything other than the matter in front of us. If you believe someone looked at your record without a reason, ask us under section 24 — the log is how we answer that question, and it is the reason we keep one.

14 Service Providers and Sub-Processors

Running the Services means other companies touch some of the data. These are the categories, what each receives, and why. A provider here is bound to use the data only to deliver its service to us.

14.1 Infrastructure

Hosting & database (application servers, PostgreSQL, Redis)

Runs the Services and stores everything described in this Policy. Receives: All of it, at rest and in transit.

Network protection & edge

Shields the site from attack and abuse, runs the bot-check on public forms, and stores and serves uploaded media. Receives: Request metadata including IP and User-Agent; the bot-check token and IP; uploaded images and creative, including the screenshots attached to a campaign report (we also keep our own durable copy).

Email delivery provider

Sends verification codes, receipts, invoices, order notices and campaign mail. Receives: Recipient email address, name, and the content of the message and any attached invoice.

Telegram

Carries the Bot, sign-in and every message we send you there, and the internal operations channel described in 14.5. Receives: Your Telegram user id and the content of what we send you — and, where we have it switched on, a copy of promotional images you upload, stored in a private channel of ours the moment you upload rather than only when an ad runs. That is how a creative can be posted into a channel instantly instead of Telegram fetching it from us each time, and it means an image you upload can reach Telegram before it is ever published. The copy you see on this site is still served from our own systems.

Error monitoring provider

Records crashes and errors so we can fix them. Receives: Configured not to attach personal data automatically. In practice a crash report carries technical context — the request path, the error and the stack — and a stack can include the values a function was working on at the moment it failed, so an identifier can reach it that way. Reports are used to fix faults and nothing else.

Your browser's push service

Actually delivers a web-push notification to your browser. Which service that is, is decided by the browser you chose rather than by us. Receives: The push endpoint your own browser issued, and the encrypted notification. The message body is encrypted to your browser's keys, so the push service cannot read it.

Backup storage provider

Holds encrypted off-site database backups. Receives: Everything in the database, encrypted — see §20.5.

14.2 Payments and payouts

Card / UPI / netbanking gateway (India)

Rupee wallet top-ups. Receives: The amount, currency, our internal order and account references and the fee breakdown; your email address as a checkout pre-fill; and whatever payment instrument you enter directly on the gateway's own checkout, which we never see. The gateway's checkout script runs on the top-up page, so it also sees your IP and browser.

Crypto payment gateway

Cryptocurrency top-ups. Receives: The amount, currency, our order reference and our callback address. No name, email or account id. Your wallet and network are handled entirely on the gateway's page.

Exchange rate services

Locks the INR→USD rate on a top-up. Receives: No personal data — an unauthenticated rate lookup.

Cryptocurrency exchange

Prices the network fee on a crypto refund and settles crypto funds. Receives: No personal data — a read-only fee lookup.

Payout rails (paying a seller out)

Actually moves money from us to you. Receives: the destination you gave us — a UPI handle, bank details or a wallet address — the amount, and whatever the rail requires to make the transfer land, which for a bank or cross-border transfer can include the name on the receiving account. A payout cannot happen without this: it is the one place your destination has to leave us, because it is the instruction. Where a rail or the law requires a check before releasing it, section 10's financial-crime row is the purpose that covers it.

Payment providers are independent controllers of what you give them directly. Their handling of your card, bank or wallet details is governed by their own policies, and we could not access those details even if asked.

14.3 AI providers

As described in section 12.2 — a commercial model provider, named to you on request. It receives the content an AI feature operates on and nothing else.

14.4 Suppliers that fulfil Boost orders

A Boost order is fulfilled through a third-party supply panel. We send it three things: the service identifier, the target link you gave us, and the quantity (plus a drip schedule where you chose one).

14.5 What we send to ourselves over Telegram

We run the platform from Telegram as well as from a screen, which means some of your data travels to us through Telegram. There are three kinds of that traffic, and the honest thing is to describe all three rather than only the tidy one.

14.6 Analytics, support and trust tools

The Services can be configured with third-party analytics, session-replay, support-chat and review widgets. None of them is needed to sign in, pay or run a campaign, and all of them ship off. Where an advertising tool is enabled it loads only after you accept it in the preference centre. Analytics, review and live-chat widgets do not wait for that: analytics sits in the always-on category described in section 18.3, and the review and chat widgets are placed in the page itself. Section 18 lists every one of them individually and says which side of the line it is on; the two sections mean the same thing.

14.7 Why this section lists categories, and how to get the names

The tables above describe every provider by what it does and what it receives, which is what actually affects you, rather than by brand name. Two reasons, and neither is evasion.

• A published list of our infrastructure is a map for anyone attacking it. Naming the host, the mail relay, the storage and the payment rails tells an attacker exactly which accounts to go after to reach your data. That risk lands on you, not just on us.
• A list goes stale the day a provider changes, and a notice that names a provider we no longer use is a false notice.

Anything you can already see for yourself is still named in full: every cookie we set (section 18.1) and every third-party tag that runs in your browser (section 18.3). Those load on your own device, so withholding a name there would hide nothing from an attacker and would stop you giving informed consent. So is every provider whose role you can see from the outside — the payment rails (Razorpay, OxaPay and the Binance account a crypto refund leaves through), the sign-in providers, the AI model providers, the analytics, support, review and abuse-protection tools, the error monitor and the public-page fetch proxy — which section 18 of the Terms names one by one, and the two documents are meant to be read together. What this section keeps to categories is the layer behind them: the host, the database, the cache, the mail relay and the object store.

We may change or add a provider — a payment rail, an AI engine, a host. When we do, the categories in this section still describe what is shared, and where a change materially affects who holds your data or where, we will publish it under section 27 and, for a significant change, give the notice in section 26.

15 Legal, Safety and Business Disclosures

15.1 When the law asks

We disclose personal data where we are required to by law, or where it is necessary to comply with an order of a court of competent jurisdiction or a lawful demand from a government agency authorised to make one. Our practice is to require the request in writing, to satisfy ourselves that the requester has authority and that the request is lawful and proportionate, to disclose only what is actually asked for, and to record what we handed over.

Where we are lawfully permitted to tell you that a request has been made about you, we will. Sometimes we are prohibited from doing so, and in that case we will not.

15.2 Safety, fraud and enforcement

We disclose what is necessary to investigate suspected fraud, abuse, security incidents or breaches of the Terms, to protect the rights, property or safety of Onflow Ads, our users or the public, and to establish, exercise or defend a legal claim — including in a dispute between you and another user, where the evidence for one side is often the record of the other.

15.3 Professional advisers

Our lawyers, accountants, auditors and insurers may see personal data where they need it to advise us. They are bound by professional duties of confidence and, where applicable, a written data-processing agreement.

15.4 A change in our business

If Onflow Ads is involved in a merger, acquisition, restructuring, financing or sale of assets, personal data may be transferred as part of it.

15.5 If the Services stop, or we cannot continue

Most privacy policies stop at the merger clause above, which quietly assumes the company carries on. Onflow Ads is a small operation holding real balances and multi-year financial records, so the more likely questions are the ones nobody writes down: what happens if the service is wound down, or if the person who runs it dies or becomes unable to. You are entitled to an answer before it matters rather than after.

• A planned wind-down. We would tell you before it happened, with time to withdraw a balance, export your data under section 22.1 and download anything you need. When the Services closed we would delete personal data that nothing requires us to keep, and retain only the financial and legal records described in section 20 for the remainder of their periods, held securely and used for nothing but answering a tax authority, a payment provider or a court.
• If the operator dies or becomes incapable. Access passes to the person legally entitled to it — an executor, an administrator, or someone holding a lawful authority. They step into the obligations in this Policy, not out of them: the data may only be used to wind the business down properly, settle what is owed and meet the retention duties above. Our practical arrangements are designed so that this transfer is possible without the data being exposed in the process, and so that an unclaimed balance can still be paid to the person entitled to it.
• Insolvency. We will be straight about the limit of what any company can promise here. If a business fails, its records can fall under the control of an insolvency professional or a court, and their duties are set by law rather than by this page. What we commit to is that we would not sell a user database as an asset to be exploited, that we would tell you and the relevant regulator what was happening as early as we were permitted to, and that we would press for personal data not required for the process to be destroyed rather than transferred.

16 We Do Not Sell Your Personal Data

16.1 The wider US definition of "share"

California and several other US states treat some disclosures as a "sale" or a "share" even when no money changes hands — in particular, passing personal information to an advertising technology provider for cross-context behavioural advertising. We treat that definition as the standard, not the narrow one:

• We do not disclose your personal data for cross-context behavioural advertising, and we do not build or export audiences, lookalike lists or conversion feeds from your data.
• Where the site runs a marketing pixel from an advertising platform at all, it loads only after you have accepted Marketing cookies in the preference centre. Choose Reject all, or answer nothing, and no such tag runs.
• We treat a Global Privacy Control signal, or any equivalent opt-out request, as a valid opt-out of any sale or share and of every advertising tag — with the honest limit on automatic detection set out in section 18.4.
• Our providers are engaged as service providers or processors, contracted to use the data only to perform the service for us and not for their own purposes.

To be explicit for the avoidance of doubt: we do not sell or share the personal data of anyone under 18 — we do not knowingly hold data of anyone under 18 at all (see section 23).

16.2 What we do instead

What we do is disclose the minimum a counterparty needs to do a deal with you (section 13), and the minimum a provider needs to run part of the platform for us (section 14). Neither is a sale. If either ever became one, this section would say so before it happened, and you would get the opt-out the law requires.

17 International Transfers

Onflow Ads is operated from India and serves users worldwide. The infrastructure and the providers in section 14 are located in several countries, including the United States and the European Union. Using the Services therefore involves your personal data being processed outside the country you are in.

17.1 If you are in India

The DPDP Act permits transfer of personal data outside India except to a territory the Central Government restricts by notification. We do not transfer personal data to any territory currently restricted in that way. If a restriction is notified that affects a provider we use, we will move that processing or stop it — as quickly as moving it can responsibly be done, and we will tell you if the change interrupts a service you rely on rather than making the change silently.

17.2 If you are in the EEA, the UK or Switzerland

Where we move personal data out of your region we rely on an appropriate safeguard — normally the European Commission's Standard Contractual Clauses (with the UK Addendum or IDTA where the UK is involved), together with a transfer risk assessment and technical measures such as encryption in transit. Where a provider is in a country with an adequacy decision, we rely on that instead. You may ask us for a copy of the safeguard relied on for a particular transfer by writing to [email protected].

17.3 What a transfer actually means

18 Cookies, Storage and Tracking

18.1 Cookies we set

Every cookie we set ourselves is first-party, is only ever sent over an encrypted connection, and none is used for advertising or to follow you anywhere. Most are also marked so that no script on the page can read them; the two that are not are marked as such below, with the reason. They are listed here by what they do and how long they last; you can see the cookies themselves at any time in your own browser.

The first four are strictly necessary in the exact sense the law uses: without them the Services cannot sign you in, keep you signed in, or complete a verification. The rest are functional or protective rather than strictly necessary — each makes a feature work as intended, and the site would still answer without it. We separate the two rather than calling everything necessary, because "necessary" is a legal test and stretching it over a business rule is how the genuinely necessary ones lose their credibility.

Sign-in session (onflow_session)

Keeps you signed in. Holds a random token only — no data about you is stored in the cookie itself. Lasts: 48 hours, or 30 days if you tick "remember me".

Verification flow (onflow_verify)

Carries you through one verification flow — sign-up, first-email attachment, password reset or the second step of two-factor sign-in. Lasts: 30 minutes.

Telegram sign-in binding (onflow_tgoidc)

Binds a Telegram sign-in to the browser that started it, so a code cannot be completed from somewhere else. Lasts: 10 minutes.

Google / Apple sign-in state (onflow_goauth, onflow_aauth)

Anti-forgery state that ties the round trip to the browser that began it. Lasts: 10 minutes.

Device identity (onflow_dev) (protective, not strictly necessary)

Carries the device signature described in section 5.5 — a hash computed in your browser, never a raw trait — so it can be read before the page's script runs. Written by that script, so it is readable by page script; it holds nothing a script could not compute again. Used for one purpose: whether this device carries an unpaid debt. Lasts: 400 days.

Referral attribution (onflow_ref) (functional)

Set only when you arrive through a member's share link. Holds their referral code and nothing about you, so that if you create an account while it is live the sign-up is attributed to them (Terms section 31.2). Cleared the moment a sign-up binds. Lasts: 90 days.

How you first found us (onflow_src) (functional, not strictly necessary)

Written on your first page view and never rewritten, so that if you come back a month later we still know which link introduced you. Holds the referring page's address, the page you landed on, any campaign tags in the link you followed and the time of that visit — nothing about you, and nothing you typed. If you create an account it is copied onto that account once (section 5.4) and is then of no further use; if you never do, it simply expires. Not readable by page script, never shared, and never used for advertising. Lasts: 90 days.

Marketplace side (onflow_pp_side) (functional)

Set while you are signed in and enlisted in Paid Promotions. Holds one word — advertiser or owner — so a marketplace page can draw the right navigation on its first paint. Deliberately readable by page script, because that is its whole point; it is a hint, never an authority, and every gate re-reads your role server-side. Refreshed on each page and cleared on sign-out. Lasts: 48 hours.

Welcome intro markers (onflow_intro, onflow_live) (functional)

The first records that the welcome animation has been seen in this browser session; the second mirrors the bare fact that a session exists, so the guide at docs.onflowads.com can skip the intro for a signed-in visitor. Both are scoped to the parent domain so the site and the guide share one answer, and neither holds anything about you. Lasts: the browser session, and the life of the sign-in session respectively.

Support chat allowance (onflow_anon) (functional, not strictly necessary)

Set only if you use the help widget's AI chat while signed out. Holds a random handle — no account, no email, nothing derived from you — so we can count the free messages that browser has used and give them back when the cycle rolls over. Against that handle we also store the IP address of the last message, for abuse triage (section 4.6). Signed in, your account carries the allowance instead and this is not used. Lasts: 180 days, after which the handle and its counter are deleted.

Staff sign-in (onflow_admin, onflow_admin_verify)

Set only for our own administrators on the admin console; a member never receives them. Listed so the inventory is complete.

Your cookie choice itself is not a cookie: it is kept in your browser's storage (section 18.2). And the Onflow tag an advertiser may place on their own site sets no cookie of ours at all — what it writes, it writes into that site's storage, as section 8.1 describes.

18.2 Storage in your browser

Some preferences are kept in your browser's own storage and are never sent to us. Clearing site data removes them.

Your cookie choice

Which cookie categories you allowed and when — so we do not ask again, and so the preference centre can show you what you chose. Reopen it any time from Cookie preferences in the site footer.

Display preferences

Which currency you prefer to see prices in.

Basket and saved channels

What you have put in a basket or saved, held locally until you check out.

Welcome message state (this tab only)

Stops a welcome message repeating in the same browser tab.

Your support conversations

The help widget remembers your name, the email address you gave it, and the code, reference and subject of your last few conversations — so it can list them when you return and fill your address in for you. This is the one item here that identifies you, and the code it stores opens the conversation for whoever holds it (section 13.3). On a shared computer, clear site data.

18.3 Third-party tags, and your consent

The Services can be configured with third-party analytics, advertising, session-replay, support-chat and review tools. Which are active is an operational choice that can change, so rather than name a set that goes stale, this is the complete list of what may run:

Analytics

PostHog and Microsoft Clarity (which records how pages are used, including a replay of interactions). Status: Essential category — loads with the page. We treat measuring and repairing our own service as part of running it, so these sit in the always-on category of the preference centre rather than behind it. Being exact about what that costs you: they are first-party in purpose but third-party in operation, so your IP address, device and browser reach those providers, and Clarity records a replay of your interactions with the page. Neither is used for advertising, neither builds an advertising profile, and neither is used to identify you to anyone else. If you would rather not be measured at all, section 18.5 is the control that actually stops it.

Google Analytics 4 / Tag Manager

Google's own tag behaves differently from the row above and we would rather show it on its own line than bury the difference. Where it is configured it is placed in the page and runs before you answer the banner, with Google's Consent Mode set to grant analytics storage — analytics being an always-on category here — and to deny every advertising purpose until you accept. In that advertising-denied state it stores no advertising identifier, you are not profiled and you are not added to an advertising audience — but it does set its analytics cookie, and hits reach Google, so your IP address and browser do reach Google whether you accept, decline, or never answer. Accepting turns on the advertising storage; declining keeps it off. Status: Consent controls the advertising storage and the profiling — not the analytics, and not the connection.

Advertising

Meta, TikTok, Snapchat, Pinterest, LinkedIn, Reddit and X pixels. Status: Consent required.

Trust widgets

The Trustpilot review widget, where an operator has enabled a paid Trustpilot template. Since 16 September 2026 the ordinary invitation to review us is our own link to Trustpilot's site: it loads nothing from Trustpilot and sets nothing, and Trustpilot learns nothing about you until you follow it. Only a paid widget renders Trustpilot's own code. Status: Loads with the page, not behind the banner — so Trustpilot sees your IP address and browser, and can set its own storage, before you have answered and whether or not you choose "Reject". The Google review badge in the same place is not a third-party tag at all: it is our own markup showing a rating we entered ourselves, and it reaches Google only if you click it.

Support chat

The current support surface is our own AI chat, which is part of the page rather than a third-party tag — your messages go to our AI model provider as a processor, as section 12.2 describes. Crisp live chat remains an alternative the operator can enable instead. Status: The AI chat is first-party; where Crisp is enabled, it loads with the page — see the note below.

Security

Cloudflare Turnstile, on public forms. It is there to tell a person from a script, and its provider designs it not to track people across sites or profile them. Status: Strictly necessary — no consent needed. It does see your IP address and browser, as any anti-abuse check must.

Platform & page assets

Google Fonts; Telegram's sign-in script on the Telegram sign-in pages; a payment provider's checkout script on the top-up page; and library CDNs used by some pages. Status: Loads with the page; discloses your IP to that host as any hosted asset would.

Where an analytics tool is enabled it may receive your IP address, your device and browser, the pages you view and the actions you take — and because analytics is an always-on category, that happens without a separate acceptance. Two tools can receive your identity as well — see section 14.6, which spells out exactly what. Three precisions about how our own analytics is wired, because they decide what a provider can join up:

• The identifier is your public Onflow Ads ID, never your email. Where Google Analytics or PostHog is on, a signed-in member is identified to it by the OFA- reference in section 28. A purchase you make is reported once — from your browser, or from our server where we have configured the server-side channel — under that same identifier, so a web session, a server-reported purchase and a campaign event from the Bot (section 6.2) join in the provider's records as one member. The events reported are named in the product's own source: page views, sign-up and sign-in (with the method), verification, enlisting, connecting a channel, creating a campaign or an ad, checkout and purchase, a withdrawal request, a lead, your cookie choice, an install of the web app, and reaching the support chat's limit — and, for a purchase, the order reference, the amount and the currency.
• The admin console loads none of it. No analytics tag, no pixel, no banner and no session replay runs on any administration page.
• The guide at docs.onflowads.com carries its own copy of the Google tag, set when the guide is built, in the same state as here: analytics granted, every advertising purpose denied. It has no cookie banner because it never grants advertising storage, so there is nothing for a banner to switch on; if you refuse marketing on the main site, the guide is already where you asked to be.

18.4 Global Privacy Control and Do Not Track

What an opt-out preference signal such as the Global Privacy Control asks a site to stop is selling or sharing personal data, and in practice that means the behavioural-advertising tags. No advertising tag of any kind runs here without an affirmative "Accept" — so a browser that never accepts is already in the state GPC asks for, and that is the default for every visitor who does nothing. We do not sell or share in the first place (section 16), so there is nothing behind that gate either.

Being exact, since 18.3 is: not accepting stops every advertising tag, and it stops Google's tag from storing an advertising identifier or profiling you. It does not stop the analytics tools, which are in the always-on category, and it does not stop the paid Trustpilot widget or the live-chat widget where those are enabled. None of those is a sale, a share, or behavioural advertising — which is why declining still puts you where an opt-out signal is asking you to be. If what you want stopped is the measurement itself rather than the advertising, section 18.5 is the control that does it.

The older "Do Not Track" header has no agreed meaning and we do not rely on it — but since our advertising tags require affirmative consent anyway, a Do Not Track user who does not accept is in the same position as one who does.

18.5 Your browser controls

You can block or delete cookies in your browser settings. Blocking the strictly necessary ones in section 18.1 will sign you out and prevent you signing back in — they are the sign-in mechanism, not a tracking layer.

Because analytics is an always-on category here, your browser is the control that switches it off, and we would rather point you at a control that works than offer one that does not. Every current browser ships tracking protection, and every content blocker stops the tools in section 18.3 from loading at all. We do not attempt to detect, discourage or work around any of them, we do not degrade the Services when one is on, and nothing on this site is built to survive being blocked. The Services work normally with every analytics tool blocked.

19 Emails, Notifications and Marketing

19.1 Messages that come with the account

Some messages are part of the Services rather than marketing: verification and security codes, receipts and invoices, order and Placement updates, payment and payout notices, dispute notices, plan expiry reminders, incident announcements, a notice that a debt has fallen due, and the transcript of a support chat emailed to you when it closes — a chat closes on its own after 30 minutes without a message, and the transcript goes to whatever address the conversation knows. You can choose which channel some of them arrive on, but you cannot switch them off entirely while you hold an account — they are how the platform tells you about your own money and your own commitments. This mirrors section 23.1 of the Terms.

19.2 Marketing is separate, and opt-in

Every marketing email carries that one-click unsubscribe, and consent is re-checked as each message is sent rather than when the campaign was built — so unsubscribing after a campaign has been prepared takes you out of it. The one exception is a message already handed to our email provider for delivery at the moment you unsubscribe: that one can still land, and it should be the last. Unsubscribing affects marketing only; account, order and payment mail still reaches you. You can resubscribe from the same link.

Audience segments for a campaign are built from your plan tier, your role and how recently you joined. They are not built from the content of your messages, your creative or your support tickets.

19.3 Telegram messages

If you have linked a Telegram account, the Bot can message you directly. Stop it by turning the category off in your notification preferences or by blocking the Bot in Telegram. Delivery is best-effort and depends on Telegram — see section 11.3 of the Terms.

19.4 Browser notifications

Web push requires your browser's own permission. If you grant it we store the push endpoint your browser issues, the keys needed to encrypt a message to it, and the User-Agent — enough to send a notification and nothing more. Revoke the permission in your browser and the endpoint stops working; tell us and we will delete the record.

19.5 No codes by phone or WhatsApp

We send verification codes by email only. We do not offer codes by SMS or WhatsApp, we do not ask for a phone number to sign in, and no phone number is held for that purpose. An earlier version of this Policy described an opt-in WhatsApp route offered through the Bot's account system; that system has been retired and the route with it. If a number given for it still sits on an older record, ask and we delete it.

20 How Long We Keep Data

We keep personal data for as long as it is needed for the purpose it was collected for, and then for any period the law requires us to hold it. "As long as needed" is not a number, so this section says what the periods actually are, and — more usefully — what happens when you close your account.

20.1 By category

Account & profile

While your account is open, then deleted or anonymised on closure. Why that long: It exists to run your account.

Channels, listings & preferences

Until you remove them, or on account closure. Why that long: Same reason as the account record — they exist to run it.

Orders, deals & delivery evidence

Up to 8 years from completion, or until the account is closed if that comes first — see 20.2. Why that long: Tax, accounting and the window in which a dispute or claim can still be brought.

Payments, Wallet ledger, payouts & invoices

Up to 8 years as an accounting record — which, importantly, is not the same thing as the copy inside your account. Section 20.2 explains the difference, because it decides what closing your account actually does. Why that long: Books of account must be preserved under Indian company and tax law.

Verification details (legal name, country)

While you can receive payouts, then with the financial record above. Why that long: It exists to justify a payout that was made.

Support tickets & enquiries

Up to 3 years after the matter closes — a ceiling we clear by review rather than by an automatic sweep, so read it with the note above. Why that long: Follow-ups, repeat issues, and evidence if a complaint is revived. Ask and we will delete a ticket sooner, which is the fastest route if a conversation contained something you would rather we did not hold.

AI support conversations

14 days after the last message, then deleted automatically — unless the conversation was escalated to a ticket, in which case it lives with that ticket under the row above. A chat closes on its own after 30 idle minutes and its transcript is emailed to you (section 19.1). Why that long: Long enough to pick a conversation back up; short enough that a chat you never escalated is not kept.

Device records (section 5.5)

While the account is open and while any debt they corroborate is unpaid; no automatic expiry runs today, and a device released by an administrator stops counting at once. Why that long: Their one purpose is to carry an unpaid obligation across an abandoned account.

Security & access events (IP, User-Agent, action)

Longer than the rest, and 20.4 says so plainly rather than quoting a period we do not yet enforce. Why that long: Their whole purpose is answering questions after the fact.

Taps, landings, conversions and invite-link joins

The IP address and User-Agent on a tap: 90 days, deleted automatically — this one is swept by a job, not reviewed by hand (§5.6). What was derived from them — device class, operating system, browser, country, language — and the salted one-way visitor fingerprint stay with the campaign they belong to. Why that split: the two raw values identify a person and are only needed while a placement can still be queried or disputed; the derived figures are what a Channel's performance history is made of, and deleting those would erase the record of work already delivered. The Telegram user id on a tap of an older exchange placement (§8.3) lives with that delivery record.

Marketing consent & unsubscribes

For as long as we send marketing at all. Why that long: The record of your opt-in is what lets us mail you, and the record of your opt-out is what stops us mailing you again.

Verification codes & sessions

Minutes to hours. Why that long: They expire by design — codes in 10 minutes, a flow in 30. One caveat so this row is not read too widely: the code stops working in ten minutes, but the email that carried it is kept as one of the sent-message copies described in 20.3, and the code is visible in that copy.

Signed-out support-chat handle

180 days, then the handle, its message count and the last IP recorded against it are deleted. Why that long: It is the cycle the free allowance runs on — see section 4.6.

Aggregate statistics

Indefinitely. Why that long: Not personal data — counts and averages with no person behind them.

20.2 When you close your account

How to do it: write to [email protected] or [email protected] from the address on the account. There is no self-service delete button today, which we would rather tell you than have you hunt for one — a person runs the closure, and that person will first make sure you are not leaving money or an open order behind.

What then happens is more thorough than most policies admit. We do not merely hide the account: the account record is deleted, and the rows attached to it go with it — your profile, your channels and listings, your orders, and your Wallet ledger and payment rows inside the platform. Your creative images are deleted from our storage. We also send an instruction to the Telegram bot side to forget you, so the two halves of the platform cannot end up disagreeing about whether you exist.

Everything we keep, we keep for a stated reason set out below. Nothing kept is used to market to you, to build a profile of you, or for any purpose other than the one it is listed under.

20.3 What survives closure

20.4 Security logs, honestly

We do not currently run an automatic expiry over security and administrative event records. They are retained while they remain useful for security, fraud investigation and the defence of claims, and are reviewed periodically for deletion or de-identification. We would rather write that than quote a period we do not yet enforce — a retention promise a system cannot keep is worse than an honest one it can.

If you want these records dealt with sooner, say so under section 22 and we will assess it. Where the purpose has been served and no legal obligation or live matter requires them, we will erase or de-identify them.

20.5 Backups

We take encrypted backups of the database on a regular cycle and keep them off-site for a limited period, so a hardware failure or a bad deployment costs hours rather than everything. They are encrypted at rest and access is limited to the platform owner.

20.6 Long-dormant accounts

No automatic sweep closes or deletes an account for being idle today, and an idle Wallet balance stays yours subject to the Terms. What the Terms reserve, at section 12.10, is the right to close an account nobody has signed in to or transacted on for 24 months, after at least 30 days' notice to the address on the account (or through your linked Telegram where that address is a placeholder). If we ever exercise it, or build a sweep that does, that notice comes first and gives you a clear window to keep the account alive — never a silent removal.

21 How We Protect Data

21.1 What we do

• Encryption in transit. Everything between you and us, and between us and our providers, travels over TLS.
• Passwords are never stored. We keep an argon2id hash with deliberately expensive parameters and re-hash it when those parameters improve. A reset replaces your password; nobody at Onflow Ads can read it.
• Sign-in hardening. Optional two-factor authentication, session tokens that rotate on sign-in, server-side sessions that can be revoked everywhere at once, and a forced sign-out from every device on a password reset, a sign-in email that cannot be changed once set, and a 48-hour block after an executed account deletion during which the deleted account's sign-in email and Telegram account cannot open a new account (kept only as one-way hashes, never as the addresses themselves).
• Abuse controls. Rate limiting and lockouts on sign-in, verification and contact forms, keyed on hashed identifiers; bot-checks on public forms; and defences against enumerating which email addresses have accounts.
• Least privilege. The most damaging actions are reserved to the platform owner, administrative access is given to as few people as the work allows, and every administrative action is logged — see section 13.5 for what an administrator can and cannot do.
• Credentials, precisely. Different things get different protection, and a single sentence claiming everything is encrypted would not be true, so here is the breakdown. Your password is stored only as an argon2id hash — it is not recoverable by anyone, including us. Your two-factor recovery codes are stored only as hashes, so a stolen copy of the table cannot be used to sign in. The keys we hold for our own providers are write-only: set once, never displayed again, and never returned by any screen or API. Your two-factor secret is the exception, and it has to be: the server must hold the actual secret to check the six-digit code your app generates, so it cannot be a hash. It is never displayed after setup, never sent anywhere, and is protected by the database's own access controls rather than by a second layer of encryption. If that matters to you, a hardware or app-based sign-in on your Telegram or email account is the stronger protection, and we would rather tell you that than let a general sentence imply more.
• Careful boundaries. Only the data an integration needs crosses to it, outbound addresses are validated to stop the server being pointed at internal systems, and admin-authored content is rendered as text rather than markup so it cannot become code in a reader's browser.

21.2 What we will not claim

21.3 Your part

Use a password you use nowhere else, turn on two-factor authentication, keep your Telegram account secure — it can sign you in — and treat proof and certificate links as private, since anyone holding one can open it. Tell us immediately at [email protected] if you think your account has been accessed by someone else.

We will never ask you for your password, a verification code, a card number, a UPI PIN or your Telegram login code — by email, by chat, on Telegram, or anywhere else. Anyone who does is not us.

21.4 Reporting a vulnerability

If you find a security flaw, report it through the contact published at onflowads.com/.well-known/security.txt — by default our private advisory page on GitHub, where a report reaches only us — or, if you cannot use that, to [email protected] marked "security", with enough detail to reproduce it, and give us a reasonable chance to fix it before disclosing it publicly. That file is the authority on the route: if we provision a dedicated mailbox it will appear there first. We will not initiate action against a researcher who acts in good faith — who tests only against their own account and their own test data, does not degrade the service, does not access, alter or keep anyone else's data, and tells us before telling anyone else. Stay inside that and you have our word.

21.5 Automated protections, and what they see

Section 16.7 of the Terms sets out our rate limits and anti-abuse measures in plain terms. From the data side they are simple: the counters behind them are keyed on your IP address, your account id, or a hash of your email address, and they live only for the window they meter — a minute for most, an hour for the money and sign-up budgets, a day for the counting caps on links — after which they expire on their own. A sign-in lockout lasts six hours. Nothing about meeting a limit is written to your record or your ledger, and the counters are never used for anything but the limit. If the store that holds them is unavailable they fail open: nobody is blocked. The human-verification challenge on public forms is Cloudflare Turnstile, described in section 18.3; the device identity in section 5.5 is the one protection that keeps a record beyond its window, and that section is where its rules live.

22 Your Rights

Which rights you legally have depends on where you live — the DPDP Act, the GDPR and the various US state laws each grant a different set. Rather than make you work out which applies to you, our practice is to offer all of them to everyone: ask for any of the following and we will deal with it, wherever you are, whether or not your local law required us to.

Where a right is yours by law we honour it as that law requires, on that law's timetable, and nothing here reduces it. Where we are extending a right to you as a matter of practice, we handle it in the same way and to the same standard — the only difference is that we can decline in the situations listed in section 22.4, and a right that makes no sense for the data in question (asking us to port a security log, say) is one we will explain rather than perform.

22.1 What you can ask for

Access

A summary of the personal data we hold about you, what we do with it, and who it has been shared with.

Correction & completion

Fix anything inaccurate, complete anything partial, update anything stale. Most of it you can change yourself in your account.

Erasure

Delete data we no longer need for the purpose it was collected for. Section 20.3 is the honest list of what we cannot delete, and why.

A portable copy

Your data in a structured, machine-readable format, where it was provided by you or generated by your use of the Services.

Withdraw consent

For anything we do on the basis of consent — the advertising tags behind the cookie banner. As easy to withdraw as it was to give, and it does not undo processing already carried out. Marketing email is not on that list, because it is not consent-based (section 19.2): switch it off in one click instead, which works the same way and just as permanently.

Object & restrict

Object to processing we base on legitimate interests, or ask us to pause processing while a dispute about accuracy or basis is resolved.

Human review

A person to look again at an automated decision that affected you — section 11.2.

Nominate someone

Under the DPDP Act, nominate a person to exercise your rights if you die or become incapable of doing so. Write to us and we will record it.

Opt out of sale or sharing

Under US state law. We do not sell or share at all (section 16), so there is nothing to opt out of — and because no advertising tag loads unless you accept, a browser that never accepts is already in the position an opt-out signal asks for. Analytics is separate and always on (section 18.3); it is not a sale, a share or behavioural advertising, and section 18.5 is how you stop it. Section 18.4 explains exactly how we handle a Global Privacy Control signal today, including what we do not yet detect automatically.

Non-discrimination

Exercising a right here does not cost you service, price or standing, and we will not treat you differently for asking. Two honest exceptions, both mechanical rather than punitive: if you withdraw consent for something, the thing that needed that consent stops working (refuse Marketing cookies and an advertising tag that depends on them will not load); and if we cannot yet tell that a request is really from you, we may pause the account or the request while we check — see section 22.3. Neither is a penalty, and neither leaves a mark on your record.

22.2 How to use them

Write to [email protected] from the email address on the account, or use our contact form. Tell us which right you are exercising and include enough to find the record — your account email or OFA ID, and for anything order-related, the reference and dates.

We aim to acknowledge within 72 hours and always respond substantively within 30 days, which is the outer limit the law sets and the one we hold ourselves to. If a request is genuinely complex we may extend that once, and we will tell you why before the first 30 days are up. It is free; we will only charge for a request that is manifestly unfounded or repetitive, and we will tell you before we do rather than after.

22.3 Verifying it is you

We must be sure a request comes from the person the data is about — handing an account's data to an impostor is itself a breach. Normally, sending the request from the account's email address is enough. Where the data is sensitive or the request comes from another address, we may ask you to confirm from the account email, complete a verification step or sign in. We will not use anything you give us for verification for any other purpose, and we will not demand an identity document for an ordinary request.

An authorised agent may act for you if you confirm the authority directly.

22.4 When we may say no, in whole or in part

Sometimes we must decline, and you are entitled to know the reasons in advance rather than discovering them in a rejection:

• the law requires us to keep the data (tax, accounting, a lawful order);
• the data is needed to establish, exercise or defend a legal claim, including a live dispute with another user;
• complying would expose someone else's personal data or their confidential information;
• the request is about data we hold only on your instructions as controller — see section 3.2 — in which case the right is exercised against you;
• we cannot verify who you are after a reasonable attempt;
• erasing it would defeat the anti-evasion marker in section 20.3 while it is still in force.

Where we decline we will say which of these applies, comply with the part of the request we can, and tell you how to challenge it under section 24.

22.5 If the account holder has died

This is a question we would rather answer here than improvise later, because these accounts can hold money and the people who ask are usually dealing with something much harder than a website.

If you nominated someone under the DPDP Act — the "Nominate someone" row above — they can exercise your rights, and that is the cleanest route by far: it takes one email to set up and removes all doubt afterwards. Where there is no nominee, we will deal with the person who is legally entitled to act: an executor, an administrator, a legal heir, or someone holding an equivalent authority where you live.

What we will ask for is the minimum that lets us act safely: proof of the death, proof of your authority, and enough detail to identify the account. What we will then do is close the account, deal with any Wallet balance under the Terms, and apply the ordinary retention rules in section 20 exactly as on any other closure. What we will not do is hand over the contents of the account — messages, tickets, the detail of deals done with other people — merely because a request comes from a relative. That material involves other people too, and the right to it is not automatically inherited. Where the law where you live says otherwise, we follow the law.

22.6 Your duties when you make a request

Indian law places duties on you as well as on us. You must not impersonate anyone else, must not suppress material information when giving personal data for a verification the law or we require, must not raise a false or frivolous grievance, and must furnish only verifiably authentic information when asking us to correct or erase data. Breaching these can carry a penalty under the DPDP Act, and may lead us to hold a request or an account while we verify.

23 Children and Minimum Age

The Services are for adults. You must be at least 18 years old, or the age of majority where you live if that is higher, to hold an account — see section 3 of the Terms. This is not only a contractual rule: under Indian law a person below the age of majority cannot enter into a binding contract, and the Services involve money.

How we know. You confirm you meet the age requirement when you create an account, and we rely on that confirmation. We do not ask for a date of birth, an ID document or an age-estimation scan, because collecting identity documents from everyone in order to find the rare person who lied would take far more personal data from far more people than the problem justifies — and the DPDP Act's own principle is to collect the minimum. So the honest description is this: we set the rule clearly, we ask you to confirm it, we act as soon as we learn a confirmation was false, and we do not build anything that would appeal to a child in the first place.

If we learn that an account belongs to someone under 18, we will close it and delete the personal data, keeping only what we must to record that we did so and to settle any money already moved. If you are a parent or guardian and believe a child has given us personal data, write to [email protected] and we will deal with it promptly.

Where the DPDP Act requires verifiable consent from a parent or lawful guardian before processing a child's data, we meet that requirement by not processing children's data at all. The same reasoning covers persons with disability who have a lawful guardian: if a guardian tells us they act for an account holder, we will deal with the guardian.

Separately, an audience member who sees a promotion is a member of someone else's Telegram channel, and Telegram sets its own minimum age. We do not know who is in an audience and do not receive their identities (section 8). If your Channel's audience includes children, you must not use the Services to advertise to them anything you could not lawfully advertise to a child.

24 Grievance Redressal and Complaints

24.1 Come to us first

If you are unhappy with how we have handled your personal data or answered a request, tell us. Write to [email protected] with the word "Grievance" in the subject line, and include your account email or OFA ID, what happened, when, and what you want done.

We aim to acknowledge your grievance within 24 hours of receiving it, and we will dispose of it within 15 days — that second figure is the one Indian law fixes, and it holds. If we cannot resolve it in that time we will tell you why and give you a date, before the fifteen days are up rather than after.

24.2 Who is responsible

Questions about how personal data is processed, and grievances under this Policy, are handled by our Grievance Officer / Data Protection Contact, our designated Grievance Officer (named on written request), of our principal place of business in India, reachable at [email protected]. That address is monitored by a person with the authority to act, not an autoresponder. Should we be designated a Significant Data Fiduciary under the DPDP Act, or otherwise be required to appoint a named Data Protection Officer, we will publish their name and contact details in this section.

24.3 Going over our head

You do not have to be satisfied with our answer, and you never lose a statutory route by trying us first.

• India — you may complain to the Data Protection Board of India once you have given us a reasonable opportunity to resolve it. For complaints about content or intermediary conduct rather than data, the Grievance Appellate Committee route in section 23.5 of the Terms applies.
• EEA / UK / Switzerland — you may complain to your national supervisory authority, normally the one where you live or work, or where you think the problem happened.
• Elsewhere — you may complain to your local data-protection or consumer authority where one exists.

We do not require you to arbitrate or to waive a statutory complaint route as a condition of using the Services, and nothing in the Terms is intended to take away a right you have under data-protection law.

25 Personal Data Breaches

A personal data breach is any security failure that leads to personal data being lost, destroyed, altered, disclosed or accessed without authorisation — whether by an attacker, a provider, or our own mistake.

25.1 What we will tell you

Where a breach affects your personal data, we will notify you without undue delay, in plain language, and tell you: what happened and when, the categories of data involved and roughly how much, the likely consequences, what we have done to contain it, and what you should do — change a password, watch for a particular kind of message. We will notify you directly rather than only posting a notice, wherever we have a working way to reach you.

25.2 What we will tell a regulator

We report breaches to the authorities that require it, within the deadlines they set — including the Data Protection Board of India and, where the GDPR applies, the relevant supervisory authority within 72 hours of becoming aware.

25.3 We will not manage it quietly

26 Changes to This Policy

We update this Policy when what we do changes, when we add a service or a provider, or when the law moves. The date at the top of the page is always the date of the current version.

26.1 Material changes get notice

For a change that materially affects how we handle your personal data — a new purpose, a new category of data, a new category of recipient, a materially different retention period, or a narrowing of a commitment in section 9 — we will give you at least 30 days' notice by email or through the Services before it takes effect, and it will apply prospectively only.

If you do not want to continue under the new version, you may close your account before it takes effect and withdraw any consent you have given. Where the new processing needs your consent, we will ask for it rather than treat continued use as agreement.

26.2 Minor changes

Corrections, clarifications, a renamed provider in the same category, or a change that reduces what we collect take effect when published. The date at the top changes; nothing about your rights does.

26.3 What the Policy said before

If you need to know what this Policy said on a particular date — because that is the version you relied on — ask [email protected] and we will provide it. Clauses published under section 27 each carry the date they were added, and a clause we retire keeps its text and its date in our records for exactly this reason.

27 Additional Privacy Terms

From time to time we publish further disclosures under this section — when we engage a new processor, when a provider changes what it returns to us, when a new feature processes something the sections above do not cover, or when a regulator asks for a specific statement. They appear below, each showing the date it was added.

A term that is later retired stops applying from the date it comes off this page. Retiring it does not erase the fact that it applied while it was in force, and we keep its text and its date so that the version of this Policy you relied on can always be reconstructed.

Any Additional Privacy Terms in force are listed in this section, each with the date it was added. If this list does not load — you are offline, a script is blocked, or something on our side is down — that is not the same as there being none. Ask [email protected] and we will send you the current set in full.

28 Onflow Ads IDs

Nearly every record we hold about you is labelled with an Onflow Ads ID — a short reference of the form OFA-204-7831 that we assign. This section says what those identifiers are in data-protection terms, what sits behind a payment, and what happens to both when you leave.

28.1 A pseudonymous identifier we assign

An Onflow Ads ID is assigned by us and is not derived from you. It is drawn at random when the record is created and checked against every ID ever issued, so no two records share one. Nothing inside it encodes your name, your email address, your Telegram account, your country, your device, your balance or when you joined — you cannot compute one from what you know about a person, and you cannot read anything about a person out of one.

It is still personal data in our hands, because we can link it back to you — that is its entire job. It is pseudonymous, not anonymous, and this Policy treats it that way: an ID is covered by every right in section 22 exactly as the record it names is.

28.2 What it is, and is not, linked to

• Linked, inside our systems — to the one record it names (an account, a channel, a wallet movement, a top-up, an invoice, a withdrawal, a refund request, a campaign, an order, a listing, a dispute, a support ticket) and, where that record belongs to an account, to that account.
• Not linked — it is not an advertising identifier. It is not sold or shared with an ad network or a data broker, is not written into a tracking cookie or a pixel, is not used to follow you across other sites, and is not handed to a payment provider as a way of identifying you.
• Not a new disclosure. What another user can see about you is governed by section 13 and does not widen because a record carries an ID. An ID is a label on something, not an extra fact about you.

28.3 The IP, device and browser behind a payment

Alongside the transaction details in section 4.4, we record on the payment record itself the IP address, the raw User-Agent string and a readable device summary ("Chrome on Windows") of whoever initiated a top-up, a withdrawal or a refund request — and, against each credit and debit in the Wallet ledger, the same IP and User-Agent plus whether it was you, an admin, the Bot or an automatic process that moved the money.

Why: to prevent and investigate payment fraud and account takeover, and to resolve a dispute or a chargeback about who actually authorised a payment — the questions that are unanswerable without it. Basis: our legitimate interests, weighed as set out in section 10.2, and our legal obligation for the parts that form part of our books. It is not used to profile you, to market to you, or to price anything differently.

28.4 IDs and the moderation record outlive your account

Section 20.3 lists what survives closure. Two of those things are identifier records, and both are kept deliberately and in a reduced form — precisely so that a question asked after you have gone can still be answered honestly: a chargeback filed months later, a payment provider's enquiry, a partner's dispute about a deal you did with them, or your own appeal against a penalty you left with.

29 How to Contact Us

One address handles everything in this Policy — rights requests, questions, grievances and complaints. You will get a person.