From Click to Token: The 30-Second Journey of a Single Add2Coin Impression

For most of advertising history, the journey of an impression has been opaque. An advertiser pays an ad network. The ad network places content on a publisher's page. Someone sees the content. Money moves. The viewer never sees the receipt. The publisher rarely sees the timing. Everyone trusts that the system, somewhere in the middle, has done the right thing.

Add2Coin replaces that opacity with a precisely defined sequence of events. Every impression, on every embedding site, follows the same path through the same components, in the same order, with the same mathematics. This article walks through that path, step by step, second by second, from the moment a visitor first hits a page to the moment cryptocurrency tokens land in the wallets of every person whose participation made the impression possible.

Where each step corresponds to a claim in pending UK patent application GB2606991.4 (filed 28 March 2026), that claim is identified inline. The full sequence below is itself a public technical disclosure of the platform's operation.

T+0.000s — The Visitor Arrives

A user opens a website that embeds Add2Coin. The website might be a small WordPress blog, a PrestaShop e-commerce store, a corporate static page, or any HTML document. From the publisher's point of view, the only Add2Coin-related code on the page is a single line in their template:

<script src="https://add2coin.com/earn.js?ref=YOURCODE" async defer></script>

The script is loaded asynchronously. It does not block page rendering. The publisher's own content reaches the user's eyes at the same speed as if Add2Coin were not present. This is a deliberate design choice: the platform must not degrade the host site's user experience, ever, under any conditions.

T+0.080s — earn.js Reaches the Browser

The browser fetches earn.js from add2coin.com. The script is small, gzipped, served with a long cache lifetime, and travels over Cloudflare's global edge network. On a standard residential broadband connection in the UK, the round trip takes about 80 milliseconds.

The script begins executing the moment the browser's parser reaches it. Before doing anything visible, it sets up its environment: parsing the referral code from the script's own URL query string, identifying the host page's domain, detecting whether the device is mobile or desktop based on viewport width, and reading the visitor's pseudonymous identifier from browser local storage if one exists.

Two important properties of the visitor identifier matter here. First, it is not a third-party cookie. The visitor identifier is stored in local storage and is bound to the add2coin.com domain only. The host site does not see it, cannot read it, and is not informed of its presence. Second, the identifier is pseudonymous — it links a visitor to their balance and reward history, but contains no personal identifying information and is not associated with email, name, or wallet address until the visitor explicitly registers a wallet.

T+0.250s — Configuration Fetch

earn.js issues a single fetch to /api/config.php on the Add2Coin server, passing the host site's referral code as a parameter. The server responds with a JSON object containing the configuration that will govern this impression: which ad network to load, the visitor's preferred ad display style if known, the minimum visible engagement threshold, the static fallback ad if the network does not fill, the on-screen position of the ad container, and a fingerprint of the platform settings at the moment of fetch.

This single configuration fetch keeps the script itself stateless. earn.js does not hard-code which ad network to use, what threshold to require, or what slot dimensions to render. All of those decisions live in the platform settings and are delivered in real time. When platform configuration changes, every impression on every site updates automatically on the next page load — no script update, no plugin update, no host-site change required.

T+0.300s — Ad Container Injection

earn.js inserts the ad container into the page DOM. Three placement styles are possible, controlled by the embedding site owner's preference: a floating corner badge in 300×250 pixel format, an inline 728×90 leaderboard placed inside or just above the page footer, or both at once for maximum visibility.

One critical refinement is checked at this stage: if the page already contains a server-rendered ad container (identified by a specific DOM attribute), earn.js detects it and skips its own injection for that slot. This prevents double-display in cases where the page itself has chosen to include a static ad in raw HTML — for example, on add2coin.com's own pages, where ad containers are server-rendered for ad-network verification crawlers that do not execute JavaScript.

The ad container is then populated by the configured network: A-ADS, Coinzilla, Bitmedia, AdSense (where the publisher has been approved), or any of the other supported networks. From this point on, earn.js's primary job is no longer ad rendering. It is engagement measurement.

T+0.300s through T+5.000s — Visibility-Aware Engagement Timer

This is where Claim 9 of GB2606991.4 begins.

earn.js does not start a fixed timer that fires at five seconds elapsed. It starts a visibility-aware timer that increments only when the page meets the following conditions simultaneously:

• The browser's Page Visibility API reports the page state as visible
• The window has focus (not minimised, not behind another window)
• The tab is not in the background of a multi-tab browser session

If the visitor switches to another tab, the timer pauses. If the visitor minimises the browser, the timer pauses. If the visitor receives a phone call and the screen locks, the timer pauses. The timer resumes immediately when the page returns to a visible, focused state.

This design has two consequences. First, it makes bot fraud structurally hard. A headless browser running in the background of a server farm does not register as visible. A page rendered into an off-screen viewport for screenshot purposes does not register as visible. A user who opens a hundred tabs to game the system has only one tab visible at a time — the other ninety-nine accumulate no engagement credit. Second, it makes genuine human attention measurable. The five seconds counted are five seconds of conscious presence on the page, not five seconds of elapsed clock time.

The threshold itself is platform-configurable. The default is five seconds of visible engagement. The platform can raise or lower this threshold globally without redeploying earn.js, because the threshold lives in the configuration delivered at T+0.250s.

T+5.000s — The Impression Event Fires

When the cumulative visible time reaches the threshold, earn.js issues a POST to /api/impression.php on the Add2Coin server. The request body contains:

• The host site's referral code (identifying the embedder)
• The visitor's pseudonymous identifier if one exists, or null if the visitor is not registered
• The current page URL and document title (used for analytics and content classification)
• Device type, viewport dimensions, and ad network that filled the slot
• A timestamp signed against the server's configuration fingerprint to prevent replay

The request is sent with credentials, allowing the server to recognise repeat impressions from the same visitor and apply per-visitor rate limits. A given visitor cannot generate unlimited impressions on a single page by reloading repeatedly — the server enforces a configurable cool-down between qualifying impressions from the same identifier on the same host site.

T+5.080s — Origin Detection and Source Tagging

The first thing the impression endpoint does is determine where the impression came from. Three sources are distinguished:

• user_site — the impression came from a third-party publisher who has embedded earn.js on their own domain. This is the standard case and the only case that triggers full reward distribution.
• platform_self — the impression came from add2coin.com itself. This is recorded for analytics and counted toward the underlying ad network's revenue, but no A2C tokens are minted — preventing the platform from artificially inflating any user's balance.
• api — the impression was reported by an authenticated server-to-server integration (for example, a publisher running impressions through their own backend rather than via earn.js). Subject to additional authentication checks before being accepted.

The source tag is recorded against the impression in the database. Self-source impressions short-circuit the rest of the pipeline: they do not invoke attribution chain resolution, do not write pending allocations, and do not return earned-token information to the client. The page still renders the ad and the underlying network still earns revenue from the view, but no platform tokens are created.

T+5.090s — Attribution Chain Resolution

For genuine third-party impressions, the server now resolves the multi-level attribution chain. This is Claim 1 of GB2606991.4.

The embedder's referral code identifies the website owner whose site hosted the impression. The platform attribution database stores, for every registered participant, the identity of the participant who referred them — their L1 referrer. Each L1 referrer in turn has their own L1 referrer, which from the original embedder's perspective is an L2 referrer. Following this chain one further step yields the L3 referrer.

The chain is resolved in a single database query that returns all four parties (embedder, L1, L2, L3) at once. Resolving the chain in one operation, rather than four sequential lookups, prevents race conditions if any participant's referral relationship changes mid-resolution. It also keeps the entire attribution operation under one millisecond on a properly indexed database.

If any link in the chain is missing — the embedder has no L1 referrer, or their L1 had no L2 — that is permitted. Missing links are simply absent from the resolved chain. They do not block the impression, do not redirect their share elsewhere, and do not cause any error condition. They are simply not present.

T+5.100s — Token Allocation Mathematics

With the attribution chain resolved, the server now computes token allocations. Each party receives a fixed share of the total impression value. The defaults are:

• Watcher (registered visitor): 0.20 A2C
• Embedder (host site owner): 0.20 A2C
• L1 referrer: 0.15 A2C
• L2 referrer: 0.07 A2C
• L3 referrer: 0.03 A2C
• Platform: 0.35 A2C

The maximum theoretical allocation per impression is therefore 1.00 A2C. The platform's share funds operations, smart-contract gas, and the buyback-and-burn mechanism described later. The remaining 0.65 A2C flows to participants in the impression chain.

One mathematical property is critical, and it is Claim 3 of the patent: absent parties do not have their share redistributed. If the visitor who saw the ad is not a registered Add2Coin user, the 0.20 A2C watcher share is not generated and is not transferred to anyone else. It is simply omitted. The total tokens minted for that impression drop from 1.00 to 0.80. Similarly, if the embedder has no L1 referrer, no 0.15 is created and no 0.15 is reallocated. The total drops further.

This is the deflationary non-allocation mechanism. Over time, only impressions with full attribution chains generate the maximum mint. Impressions with shorter chains generate proportionally less. The actual circulating supply of A2C grows more slowly than the theoretical maximum, anchoring per-token value as platform usage grows.

T+5.110s — Pending Records Written

Each non-zero allocation is written as a row in the balances_pending table. The schema records:

• The recipient's account identifier
• The amount of A2C allocated
• The role they played in the chain (watcher, embedder, L1, L2, L3, platform)
• The originating impression ID
• The host site domain, ad network, and timestamp
• The settlement status, set initially to pending

At this moment, the tokens are accounting entries in the platform database. They are real obligations from the platform to the recipient, but they do not yet exist on the blockchain.

This delayed-settlement design serves three purposes. First, it allows hundreds of thousands of impressions to accumulate during the day at zero gas cost. Second, it allows the platform to apply final fraud filtering and reconciliation before any on-chain action. Third, it batches the eventual blockchain settlement into a single transaction per night per recipient, dramatically reducing total network fees.

T+5.120s — Response to the Browser

The server returns a JSON response to earn.js indicating success, the amount of A2C earned, and any auxiliary data needed for client-side display (such as updating an in-page balance counter for registered visitors). The browser closes the connection. From the visitor's point of view, this entire round trip — from impression event to confirmation — has taken roughly 120 milliseconds.

If the visitor is registered, earn.js may briefly display a small balance update notification. If the visitor is not registered, nothing visible happens — their share has been omitted entirely, and there is no UI to confuse them. The ad continues to display normally regardless.

T+24h — Nightly Batch Settlement

At midnight UTC, the Add2Coin cron system invokes daily-mint.php. This job collects all pending allocations recorded since the previous run, aggregates them by recipient (so a single recipient who earned across many impressions receives one consolidated entry), and prepares a single batched mint transaction.

The transaction is signed by the platform's minting wallet and submitted to the A2CToken smart contract on Polygon Mainnet (contract address 0x999ca1479AF9d38933F8EbF7Bb1d2470aFcc337C). The contract has a batchMint function that accepts arrays of recipient addresses and amounts, allowing many distinct recipients to be settled in a single on-chain operation.

Polygon's sub-cent gas fees mean that even a settlement covering thousands of recipients across hundreds of host sites costs the platform a fraction of a US dollar. Compare this to attempting the same operation on Ethereum mainnet, where the gas alone could exceed the value of the tokens being minted. Polygon was selected specifically for this property.

Once the transaction confirms (typically within five to fifteen seconds on Polygon), the platform updates the balances_pending rows to settled status and records the on-chain transaction hash against each row. Recipients can verify their settlement at any time by checking the contract's mint events on Polygonscan, the public Polygon block explorer.

T+24h+ — Real Tokens in Real Wallets

From this moment, every recipient who has connected a wallet to their Add2Coin account holds real ERC-20 tokens. The tokens behave like any other Polygon token: they can be transferred peer-to-peer, swapped on Uniswap, used as collateral in DeFi protocols, sent to centralised exchanges, or simply held.

The Add2Coin platform, at this point, has no further claim on or control over the tokens. They are the property of the recipient, custody by the recipient, transferable at the recipient's sole discretion. The platform cannot freeze them, claw them back, or pause their movement.

This is one of the consequences of building reward distribution on a public blockchain rather than as an internal database balance. It transfers irreversible custody to the recipient, removes the platform's discretionary power over earned tokens, and makes the entire reward economy verifiable by external auditors.

The Revenue Side — What the Platform Does with the Money

The journey above describes the token side — the obligations the platform has to its participants. But every impression also generates revenue from the ad network that filled the slot. Where does that revenue go?

The platform's share of the underlying ad revenue flows into the Treasury Wallet. Every twenty-four hours, the coinbase-automation.php cron job triggers conversion of the daily revenue (typically held in fiat or USDC at the ad network) into POL, the Polygon network's native token, and forwards the result to the RevenueRouter smart contract.

The RevenueRouter splits incoming POL according to the platform's configured revenue model:

• 70% is used to buy A2C from the Uniswap V3 pool on Polygon, then immediately burnt — permanently removing those tokens from circulation. As platform usage grows, this creates continuous market-buy pressure on the A2C/POL pool, structurally supporting token price.
• 20% flows to the Operations Keeper wallet, funding ongoing platform development, server costs, and ad network fees.
• 10% is held by the platform treasury as runway and strategic reserve.

This buyback-and-burn loop closes the economic circle. Token-side rewards are minted to incentivise participation. Revenue-side proceeds buy back and burn tokens to remove inflationary pressure. As impressions scale, both sides scale together. Token holders benefit from a system whose economic incentives align with platform growth rather than against it.

The Patent Claims, Concretely Mapped

To summarise the patent claim references that appeared inline:

• Claim 1 — the multi-level attribution chain resolution at T+5.090s
• Claim 3 — the deflationary non-allocation mechanism at T+5.100s, where absent parties' shares are permanently omitted rather than redistributed
• Claim 9 — the visibility-aware genuine engagement timer between T+0.300s and T+5.000s

The remaining claims of GB2606991.4 cover related aspects: the cross-domain pseudonymous identifier persistence at T+0.080s; the configuration-driven runtime behaviour at T+0.250s; the source tagging and self-impression handling at T+5.080s; the deferred batched settlement at T+24h; and the integration of all of these as a single end-to-end protocol.

Why Every Step Matters

It would be possible to build a simpler version of this system. One could omit the visibility-aware timer and credit impressions on a fixed clock-time threshold. One could collapse multi-level attribution to a single direct-referrer model. One could mint tokens immediately on impression, on every impression, at one transaction per impression. One could redistribute absent shares to whichever party is present.

Each of those simplifications would, on paper, reduce the system's complexity. Each would also remove a property the system needs to function at scale.

The visibility-aware timer is what makes bot fraud structurally hard. Without it, the system would be mathematically vulnerable to anyone willing to spin up a hundred headless browsers in a data centre. The multi-level attribution is what makes the network grow virally: a participant who refers ten people, who each refer ten more, captures a meaningful share of the resulting hundred indirect impressions. Without it, the only viral mechanism would be the embedder's own marketing efforts, dramatically limiting growth. Deferred batched settlement is what makes the gas economics work: minting one transaction per impression on Ethereum mainnet would consume more in gas fees than the impressions are worth in revenue. Deflationary non-allocation is what protects the token economy: redistributing absent parties' shares would create perverse incentives to leave referral chains incomplete to capture orphaned tokens, and would inflate the circulating supply faster than buyback can absorb.

The system works because all of these mechanisms are present together. Removing any of them changes the system from one that scales to one that does not.

What This Means for Participants

If you are a website owner: every visitor who sees an ad on your site, and stays present for five visible seconds, generates 0.20 A2C for you automatically. No invoicing, no payment processing, no minimum balance to withdraw. Tokens settle to your connected wallet within twenty-four hours. The entire flow above happens in the background of a single page view.

If you are a registered visitor: every site you visit that runs Add2Coin will earn you 0.20 A2C per qualifying impression, regardless of whether the site owner specifically invited you, knows who you are, or has any prior relationship with you. The pseudonymous identifier in your browser does the work of recognising you across every Add2Coin-enabled domain on the internet.

If you have referred others to the platform: every impression those referrals generate, on every site they embed, contributes 0.15 A2C to your balance — even sites you have never visited and embedders you have never met. If those referrals refer people of their own, your share extends to 0.07 A2C on those impressions, and 0.03 A2C on the level below that.

This is what the protocol does. It is what one line of HTML, on one website, triggers thirty seconds at a time, every time someone genuinely engages with an ad, on the largest single network of attribution-aware advertising slots ever built.

Patent Pending GB2606991.4. Filed 28 March 2026. International protection reserved.