How earn.js Works: The Technical Story Behind One Line of Code

The entire Add2Coin embedding experience for a website owner is a single line of HTML:

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

Paste this before the closing body tag on any page. That is all. From that moment, every genuine ad view on your page begins generating A2C tokens for you automatically.

But what actually happens when that script loads? How does it know whether an ad was really watched? How does it avoid rewarding bots? How does it attribute rewards across a chain of referrers it has never directly communicated with? This article explains the full technical story.

Step 1: Initialisation

When earn.js loads, it first checks whether a visitor has an Add2Coin account by looking for an authentication identifier in browser local storage. This is a pseudonymous identifier — not linked to any personal information, not readable by the website hosting the script, and not a third-party cookie. If an identifier exists, the visitor is a registered user and will earn their 0.20 A2C watcher share when the impression threshold is reached.

The script then parses the referral code from the query string (?ref=YOURCODE), fetches the current platform configuration (minimum engagement threshold, ad content, and the embedding site's attribution details) from the Add2Coin server, and injects the ad overlay into the page. The whole initialisation process takes less than 200 milliseconds on a typical connection.

Step 2: Genuine Engagement Measurement

This is where the patented technology begins (Claim 9 of GB2606991.4).

earn.js does not simply start a timer when the page loads. It monitors the page visibility state using the browser's built-in Page Visibility API. This API reports whether the page is actually in the foreground and visible to the user, or whether it is hidden behind another window, in a background tab, or minimised.

The engagement timer runs only when the page visibility state is "visible." If you switch to another tab, the timer pauses. If you minimise the browser window, the timer pauses. If you receive a phone call and lock your screen, the timer pauses. The timer resumes only when the page returns to the visible foreground state.

This design means cumulative visible time is measured, not elapsed time. A bot that loads the page in a headless browser in the background will never reach the engagement threshold because the page will never report as visible. A user who genuinely watches the ad but briefly switches tabs to check their email will have their session continued when they return — their progress is not lost. Only sustained, genuine, conscious attention generates rewards.

Step 3: Attribution Resolution

When the engagement threshold is reached, earn.js fires an impression event to the Add2Coin server. The server then performs the attribution chain resolution (Claim 1 of GB2606991.4).

The server looks up the referral code provided by the embedding website. This identifies the embedder (the website owner). It then looks up who referred the embedder to Add2Coin (their L1 referrer), who referred that person (L2), and who referred that person (L3). Each level is resolved from the platform attribution database.

All parties are identified before any token allocation occurs. The entire chain is resolved in a single database query. This simultaneous resolution is important: it means there is no sequential processing that could result in race conditions, partial attribution, or inconsistencies if one part of the chain changes state during processing.

Step 4: Token Allocation

Once the full attribution chain is resolved, token allocations are recorded simultaneously for all present parties. Each party receives their defined share: 0.35 A2C to the platform, 0.20 A2C to the embedder, 0.20 A2C to the registered watcher if one is present, 0.15 A2C to the L1 referrer if one exists, 0.07 A2C to L2, and 0.03 A2C to L3.

Crucially, absent parties do not receive zero that is then distributed to others. They receive zero and their allocation is permanently omitted. If no watcher is registered, 0.20 A2C is simply never created. This is the deflationary non-allocation mechanism (Claim 3 of GB2606991.4) that keeps actual circulating supply below the theoretical maximum.

All allocations are recorded in the database in "pending" status. The tokens exist as accounting entries but have not yet been minted on the blockchain.

Step 5: On-Chain Settlement

Each night at midnight, the Add2Coin cron system processes all pending allocations accumulated during the day. It batches them into a single batchMint() call to the A2CToken smart contract on Polygon Mainnet. This single transaction mints tokens for all recipients simultaneously — hundreds or thousands of individual allocations settled in one on-chain operation.

This batch settlement approach (Claim 7 of GB2606991.4) is highly efficient: gas costs are shared across all recipients rather than each requiring a separate transaction, making the system economically viable even at low per-impression token values. The two-phase architecture of immediate database recording followed by deferred blockchain settlement (Claim 12) ensures responsiveness for users while maintaining the on-chain verifiability that makes the whole system trustworthy.

The Result

From the website owner perspective, all of this complexity is invisible. You paste one line of code. Impressions appear in your dashboard. Tokens arrive in your confirmed balance each morning. The entire technical machinery — visibility measurement, chain resolution, deflationary allocation, batch settlement — runs automatically without any further action from you.

That simplicity of integration combined with the depth of the underlying mechanism is what makes Add2Coin genuinely novel. It is not a simple reward script. It is a complete, patent-protected infrastructure for redistributing advertising value to everyone who creates it.