Skip to main content

3 September 2026

A written-up summary of one day's release, for readers of the guide. The live feed on What's New carries the same changes as individual notes.

  • One rule for every link, on every engine. Whether a post is published by a paid booking, a cross-promotion or an exchange placement, each link in it is planned by the website before it goes out. A destination that is the advertiser's own connected channel becomes a per-campaign invite link, so Telegram itself counts the joins. A web destination becomes a first-party hop that names the site in its own address — onflowads.com/go/yoursite.com/… — where the tap is counted once per reader per link per day, with crawlers excluded and a ceiling of 20 raw taps per reader per link per day, before the reader is sent straight on with the campaign tags. Any other Telegram address, and any bare URL typed into the text, is published exactly as written.
  • The bot asks first. Before it publishes a cross-promotion post or an exchange placement, the Telegram bot sends the creative to the website and publishes what comes back. If the website cannot be reached, the post goes out with its links exactly as written, uncounted — never with a broken link.
  • Joins are heard by the bot, recorded for the website. Telegram tells only the admin bot in a channel about a join through an invite link; the bot writes each join and leave into the website's ledger, one row per member per link, and decides nothing about what it is worth.
  • Legacy rails keep working. Posts already live keep their older signed /c/ links, /r/ redirects and bot-chat hops until they come down. Nothing new is minted on them.
  • The Onflow tag counts landings and conversions on the far page as a separate ledger, and the conversion pixel is bounded: at most 20 conversions per visitor per link per day, 500 per link per hour, and a reported value capped at ten times the placement's charge (never below $1,000 or above $100,000; $100,000 when the charge is unknown).
  • Where it shows. Cross-promotion results now report joins beside ad opens; exchange campaigns show a Joins tile.

Reliability ledger hardening​

  • The bot never moves a score. What the Telegram bot observes — a hosted placement pulled early, a cross-post taken down, a member who left the partner channel, a placement that served its term — is written as a fact into a queue the website owns. The website prices each fact from its published table, applies it through its one mutator and writes the ledger row, usually within a minute. A fact carries no delta and can be priced at most once, however many times it is re-reported. The bot's messages now say what was recorded and that it is applied on onflowads.com — never a new score.
  • Two cross-promotion changes. Ghosting a join now costs −0.30 on the reliability score, once per campaign, alongside the existing strike and cooldown. Leaving a partner's channel before the run ends has its own entry, −1.00, distinct from the −1.50 for removing the post.
  • Credits and rewards are minted by the website. Subscriber Exchange hosting credits (10 base, scaled by the host's plan) and the cross-promotion clean-completion Boost credit (by the creator's plan, capped at 30 a month) are granted by website sweeps from the facts the bot records. Cross-promotion campaign insurance is settled by the website from the cover the party at fault declared; the flat $0.05 bot payout is gone.
  • Exchange moderation is decided on the website. An admin's Approve, Decline or appeal tap on a Telegram review card is relayed — signed and replay-protected — to the website, which makes the decision, refunds a delivery charge on a decline exactly once, and notifies the member.
  • Fairer outcomes. A fraud concern can now be dismissed as inconclusive: nobody's score moves, the stake is returned and the freeze lifts. A booking that reaches an owner who is under review or below the Paid Promotions floor is declined for them at once, with a full refund and no ghost penalty. Cancelling a deal before go-live carries no reliability penalty on either side.
  • Reversals and merges keep their history. A partial restore, a later full restore and an undo all point at the original entry and can never return more than the penalty took; a merged Telegram account keeps its full ledger. Members can appeal at most 3 penalties a day.

Rate limits and page hardening​

  • Every state-changing request is rate-limited by default: 90 per minute per IP address and 240 per minute per signed-in account, with tighter buckets for sign-in, sign-up, one-time codes, passwords and two-factor (10 per minute per IP); wallet, checkout, purchase, withdrawal, payout, bid and subscription endpoints (30 per minute per account); uploads (20 per minute); the two payment webhooks (600 per minute per IP); and bot relay endpoints (600 per 5 minutes per IP). A limited request answers HTTP 429 with a Retry-After header. Limits fail open — if the limiter's store is unavailable, nobody is blocked. Static assets never count against the 300-per-minute per-IP ceiling.
  • Sign-in and password reset cannot be locked from outside. Five wrong sign-in attempts per 15 minutes per email-and-IP pair; after 40 attempts on one email a Turnstile challenge is required where configured. Forgot-password: 3 per 15 minutes per pair, and after 12 per email the generic "if an account exists…" answer is returned without sending a code. A third party can no longer lock an account out by hammering its email address.
  • Two-factor: 10 attempts per 15 minutes per account and 20 per minute per IP; ten wrong codes within an hour lock the email and IP for 6 hours.
  • Web Push subscriptions are accepted only for HTTPS endpoints on the browser vendors' push services, at most 20 browsers per account.
  • Bot-to-website relay protocol. Every signed body carries a timestamp and a single-use nonce; the website rejects a request more than 300 seconds old or a nonce seen within 900 seconds, refuses bodies over 64 KB, and both sides fail closed when the shared secret is unset.
  • Master-admin destructive actions (database wipe, restart) are limited to 3 per hour and require the Master password to have been entered within the last 10 minutes.
  • Telegram bot throttles: 20 updates per 10 seconds per user, with tighter buckets for deep links, post previews, review taps and campaign clicks. Deep-link payloads are shape-checked before any database is asked.

See Security and rate limits for the full table.

Analytics coverage​

  • One event catalogue, from sign-up to purchase, on the website and mirrored to the bot's server-side events, keyed on the member's public OFA id — never an email.
  • Wallet top-ups are recorded server-side from the single credit path, so a purchase is counted once whether the credit came from the provider's webhook or the browser's return.
  • Sign-in with Google, Apple or Telegram records one sign-up or login event and then cleans the address, so a bookmark or refresh cannot re-fire it.
  • The admin console loads no analytics at all — no tags, no pixels, no cookie banner.
  • Global Privacy Control is honoured: marketing storage is refused and the banner is not shown; the preference centre remains available.
  • The docs guide can carry the same analytics tags as the site, with the same consent defaults, and has no cookie banner.

Responsive and performance work​

  • Stamped assets are cached for a year and swapped the moment a deploy changes their stamp; guide search and images cache sensibly; HTML pages are never cached.
  • Every page declares safe-area insets and a dark colour scheme, so installed-app and Safari layouts respect the home indicator and native controls render dark.
  • The site header switches to the menu sheet at 900px and below, so portrait tablets get the mobile menu; the support launcher steps aside while a compare tray, bulk-action sheet or boost compare bar is open, and never appears inside the Telegram Mini App.
  • On touch devices every text field renders at 16px or more (no focus zoom on iOS), and close, remove and toggle controls have larger hit areas.
  • Dashboard hub endpoints run their queries concurrently, so the channels and stats panels load in a fraction of the round trips.
Last updated on