DEV Community: Andrew David

Poltergeist: I made a browser extension that haunts the page you're reading

Andrew David — Sat, 31 Oct 2026 23:38:41 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Poltergeist is a Chrome Manifest V3 extension that literally haunts whatever web page you are reading.

Most AI browser extensions behave like polite corporate sidebars: you highlight text, click a button, and read a summary in a neat little drawer. Poltergeist does the exact opposite. It treats your browser as a physical, haunted environment.

When you click Possess this page, a purple-glowing ghost materializes directly over your screen. It reads the page's title, headings, and visible text, then whispers an eerie, hilarious, context-aware observation about that exact page in a floating speech bubble — spoken aloud with an authentic spectral voice while its mouth animates.

The Poltergeist mascot: a purple-glowing ghost that materializes over any page you haunt.

Features & Capabilities

Poltergeist doesn't stop at a single whisper. It comes packed with a full suite of mischievous interactions:

👻 Possess: Scans the page text (excluding sensitive inputs) and speaks an eerie, hyper-specific whisper with real-time typewriter text and an animated talking mouth.
🎃 Trick or Treat: An interactive Halloween button powered by a candy economy:
- Treats: Awards candy points into a glowing HUD, speaks eerie compliments ("This page is positively boo-tiful"), or delivers creepy fun facts.
- Tricks:
- Spooky Headline Mutation: Dynamically rewrites the page's headings into chilling alternatives with a glowing orange aesthetic (.pg-spooked).
- Screen Flicker: Glitches the entire webpage body via CSS hue-rotation and vibration (html.pg-flicker body).
- Flashlight Mode: Plunges the entire webpage into pitch darkness, revealing only a circular spotlight beam that dynamically tracks your mouse cursor (html.pg-dim::before).
- Cursor Follower: Spawns a mini ghost that lerps smoothly behind your cursor, flipping horizontally based on movement direction.
🎯 Ghost Hunt: An interactive mini-game. The open-weight model picks 5 words from the page text to hide in. Mini ghosts are embedded directly into the text at opacity: .12 (barely visible). A 30-second countdown timer starts in the HUD. You can hover to reveal them or click the Hint button to pulse an uncaught ghost. Catching a ghost triggers a poof vanish animation (pg-vanish), a voiced taunt, and +1 candy reward!
✝️ Exorcise: Absolute, clean reversibility. One click restores every mutated headline back to its original text (via WeakMap), unwraps all ghost hunt spans back to plain text nodes, removes HTML effect classes, silences audio, and unmounts the Shadow DOM root.

Demo

📺 Watch the Full Video Walkthrough: YouTube Demo
📁 Repository Video: poltergeist-demo.mp4 (1080p 60fps walkthrough showcasing popup activation, possession, typewriter speech, headline mutation, flicker, flashlight mode, cursor follower, ghost hunt, and clean exorcism).

Visual Walkthrough

1. Summoning the Ghost (Popup UI)

nsion Popup](https://raw.githubusercontent.com/emperorsixpacks/poltergeist/main/screenshots/02-popup.png)
Clicking the extension icon opens the 280px popup with our dark design system, glowing SVG mascot, and one-click 'Possess this page' trigger.

2. The Haunting: Contextual Whisper & Typewriter Animation

The ghost manifests inside an isolated Shadow DOM host (#poltergeist-root), typing out an in-character observation while its mouth animates in sync with ElevenLabs speech.

3. Trick or Treat: Spooky Headline Mutations & Screen Flick

Real page headings mutate into eerie alternatives with glowing orange text (.pg-spooked), while the page glitches via CSS animations.

4. Flashlight Mode: Dynamic Spotlight Tracking

The page plunges into darkness with a circular spotlight beam (html.pg-dim::before) and mini ghost follower lerping behind your cursor.

5. Ghost Hunt: Interactive Hiding Game

5 words are wrapped with translucent mini ghosts (opacity: .12). Hover to spot them, click the 'Hint' button to pulse an uncaught ghost, and catch them before the 30-second timer expires!

6. Architecture & Clean Reversibility

Exorcise cleanses the DOM completely. Zero API keys in the client, 100% Shadow DOM isolation, and open-weight LLMs on Groq.

Code

emperorsixpacks / poltergeist

Poltergeist

A Chrome Manifest V3 extension that haunts the web page you're reading. Built for the Hacktoberfest "Ghost in the Machine" challenge. AI text runs on open-weight gpt-oss via Groq, the voice is ElevenLabs, and both are proxied through a tiny Render service so users never provide their own keys.

Try it (30 seconds, no installs)

Grab poltergeist.zip from the latest release and unzip it.
Open chrome://extensions (or brave://extensions) → toggle Developer mode.
Click Load unpacked → select the unzipped poltergeist folder.
Open any website → click the Poltergeist icon → Possess this page.

No keys, no backend setup — the AI and voice run on the hosted Render proxy.

Features

Possess — extracts the page title, headings and ~1500 chars of visible body text (form, password and payment fields are skipped), asks the model for a short spooky whisper about the page, shows it…

View on GitHub

Core Repository Highlights

Zero Build Step / Zero Dependencies: Pure vanilla JavaScript, standard CSS3, and native Chrome MV3 APIs. No npm install, no bundler, no framework overhead.
100% Shadow DOM Isolation: All ghost UI elements (.pg-widget, .pg-bubble, .pg-hud, cursor follower) render inside an open Shadow DOM hosted at <div id="poltergeist-root">. Host page CSS cannot break the ghost, and ghost CSS cannot leak onto the page.
Zero External Image Requests: All visual assets (GHOST_SVG, MINI_GHOST_SVG, CANDY_SVG, PUMPKIN_SVG) are stored as inline SVG string constants in assets.js.

How I Built It

The AI Brain: Open-Weight gpt-oss-120b via Groq

Poltergeist is powered by gpt-oss-120b, OpenAI's open-weight model, served through Groq for sub-second inference speed.

The model acts as the ghost's subconscious. Through specialized system prompts, it receives sanitized text extracts and returns structured JSON responses for:

Whispers: Short, eerie, funny observations (max 25 words) grounded strictly in the page content.
Headlines: Rewriting existing page headings into spooky alternatives while preserving list order.
Ghost Hunt Words: Selecting 5 distinctive words that literally appear in the page text to serve as hiding spots.

flowchart LR
    A["Active Web Page"] -->|"Extracts visible text"| B["content.js"]
    B -->|"chrome.runtime.sendMessage"| C["background.js (Service Worker)"]
    C -->|"POST /api/generate & /api/tts"| D["Render Proxy (Zero-Config)"]
    D -->|"Open-Weight LLM Inference"| E["Groq (gpt-oss-120b)"]
    D -->|"Voice Synthesis"| F["ElevenLabs (Ghost Voice)"]
    D -->|"Audio Bytes + Text"| C
    C -->|"Base64 Audio + Typewriter"| G["Shadow DOM (#poltergeist-root)"]

System Architecture

Chrome Extension (Manifest V3):
- Service Worker (background.js): Coordinates API calls, caches the last generated response per URL (so repeat haunts on the same article are instant), and base64-encodes audio for injection.
- Content Script (content.js + content.css + assets.js): Extracts visible DOM text while strictly skipping sensitive elements (INPUT, TEXTAREA, SELECT, password fields, headers, and footers). Mounts the isolated Shadow DOM, coordinates typewriter rendering, animates the ghost's mouth during speech, and manages the undo stack.
- Popup (popup.html / popup.js): A sleek 280px popover adhering to our custom design system (--pg-bg: #120a20, --pg-purple: #a855f7, --pg-orange: #ff8a1f) with a floating ghost avatar and instant "Possess this page" button.
Backend Proxy on Render (server.js):
- A tiny, zero-dependency Node.js HTTP service hosted on Render (poltergeist-proxy.onrender.com).
- Keeps the Groq and ElevenLabs API keys securely server-side.
- Zero Configuration for Users: Anyone loading the extension unpacked in Developer Mode can use it immediately without pasting an API key or signing up for third-party services.
Voice Engine & Accessibility:
- Voice generated using ElevenLabs' eleven_multilingual_v2 model with a custom ghost voice ID.
- Graceful Fallback: If network drops or voice credits expire, Poltergeist automatically falls back to the browser's native window.speechSynthesis.
- Accessibility: Full @media (prefers-reduced-motion: reduce) compliance automatically disables screen flickering, ghost floating, and cursor followers while keeping static UI fully usable.

Why Does Open Innovation Matter?

Open innovation is the entire reason Poltergeist exists.

Model Sovereignty & Portability: The ghost's personality is defined by an open-weight model and a prompt. We originally prototyped Poltergeist using a local Ollama instance running Gemma. When we transitioned to gpt-oss-120b via Groq for instant cloud latency, we didn't have to rewrite proprietary SDKs or accept vendor lock-in. Open weights let you swap the brain freely.
Zero-Friction Distribution: In closed AI ecosystems, building a browser extension usually means forcing users into subscription paywalls or asking them to paste private API keys into an options page. With open-weight models hosted on open infrastructure like Render, we can distribute a delightful, free tool that works out-of-the-box.
Privacy & Trust: Browser extensions have privileged access to what you read. With open architecture, users don't have to trust a black box. The code is completely unbundled and readable in plain JavaScript: anyone can inspect how text is extracted, verify that forms and passwords are never touched, and confirm that only the generated whisper is ever sent to the text-to-speech engine.
Remixability: Anyone can fork this repository, swap in Mistral, Llama 3, or DeepSeek, alter the ghost's personality from a Halloween poltergeist into an Elizabethan poet or an 80s cyberpunk hacker, and run it locally or on their own server.

My Agent Session

This project was built and refined in collaboration with Antigravity, Google DeepMind's advanced coding assistant.

The agent session helped:

Architect the Shadow DOM isolation system to guarantee that complex CSS animations (@keyframes pg-float, @keyframes pg-talk, @keyframes pg-blink) and design tokens never collide with the host page.
Implement the WeakMap reversibility engine for headline mutations and text node wrapping during the Ghost Hunt.
Build the automated headless browser recording pipeline using Playwright, Chromium, and FFmpeg to generate the full-resolution synchronized demo video with real ElevenLabs audio.

The Spirit of It

The magic of Poltergeist lands in the unexpected moments.

When you open a dense, dry technical specification, a Wikipedia article on medieval architecture, or an obscure recipe blog, and press Possess this page, you don't get a generic canned Halloween sound effect. You hear a raspy, eerie whisper pointing out something absurdly specific from paragraph three that only someone reading along with you would notice.

It turns passive browsing into an interactive theatrical performance. That is the essence of "Ghost in the Machine": open-weight AI stepping out of the terminal and making the web feel playful, mysterious, and alive.

Prize Categories

Best Use of Render: Zero-dependency Node.js proxy deployed on Render (poltergeist-proxy), enabling serverless key management and zero-configuration extension usage.
Best Use of Groq: Ultra-low-latency inference using open-weight gpt-oss-120b on Groq, delivering sub-second ghost responses and real-time headline rewrites.
Best Use of ElevenLabs: Dynamic text-to-speech synthesis using custom voice profiles, synced with SVG mouth animations and fallback speech synthesis.

How to Implement In-Memory Caching in GoLang

Andrew David — Thu, 27 Nov 2025 13:18:15 +0000

The Why?

I recently worked on Airtable OAuth authentication for a project and needed a place to store state and challenge code for later request validation. The obvious solution is to use a third-party solution like Redis (Which I am a big fan of), but I wanted to try out in-memory caching. Yes, I reviewed other tools like MemeCache, but am I not an engineer?

The What?

When you start your Go app, Python app, or Node app, you can store certain data in the process, making it available throughout the program's lifetime. This data lives in the RAM (Random Access Memory), making it easily accessible by the program whenever it needs it. Most caching systems like Redis also store their data in RAM, but unlike Redis, an in-memory cache is not persistent.

A simple in-memory cache typically maintains a key-value store in memory, tracks when each item should expire (using TTL — Time to Live), and optionally uses an LRU (Least Recently Used) policy to remove older items when a maximum size is reached. The cache runs in the same process as your application, making reads and writes extremely fast. However, because everything is stored in memory, all data is lost when the application stops.

Less Talk, more code !!!

Before we code, let’s go over a few things I think you should know

LRU (Least Recently Used) → My phone has a bunch of apps that I do not use—apps that have been on my phone for the longest time, occupying good space. LRU is an eviction policy that removes the least-used item in a cache. Essentially, think of it as removing that app you haven’t used in months so you can make room for the new game you want to install. Essentially, you are removing the oldest unused item, regardless of whether it has been accessed a lot in the past.
LFU (Least Frequently Used) → Imagine this: your bag can only hold four books. If you get a new one, you'll need to remove a book to make room, and usually, you'll remove the book you read less. The same thing applies to an in-memory cache. LFU is an eviction policy that ranks items based on how often they’re used, and when space runs out, it removes the least-frequently-used item to make room for new ones.
TTL (Time To Live) → This defines how long we want an item to stay in our cache. It's like setting an expiry date — once the TTL has elapsed, the item is considered stale and no longer valid. Any future attempts to get that item will fail or trigger a refresh. TTL is useful for keeping data fresh and automatically clearing out old or irrelevant entries without needing manual intervention or cleanup.
Cache Hit, Cache Miss → Whenever we request an item from the cache, a cache hit occurs if the item exists and is still valid. A cache miss, on the other hand, happens when the item is not found or has expired.

So now we code, right?

Well, not just yet, there are still a few things we need to talk about, sorry :)

The Design

To build our cache, we’re going to keep things simple with just three components:

A map to store the items
The cache itself
A Janitor to clean up our mess

Now we code

Let’s start by defining a very simple struct to hold all the data. After that, I’ll walk you through what each part represents.

// Cache Items
type Item struct {
    value    interface{}
    duration int64
}

// Main cache struct
type cache struct {
    items   map[string]Item
    mu      sync.RWMutex
    janitor *Janitor
}

// handles clean up
type Janitor struct {
    interval time.Duration
    stop     chan bool
}

The Item struct contains two fields: Value and Duration. Normally, you might use time.Time for expiration, but here, Duration is stored as an integer timestamp—a design choice to keep things simple and flexible.

As for the Cache struct, you might notice that it's unexported (made private). This allows us to expose a global constructor to create the cache instance. The real reason behind this design, though, is that I implemented it using the singleton pattern—meaning I wanted to ensure that only one instance of the cache exists throughout the entire program.

One thing I may have forgotten to mention is that our cache needs to be thread-safe. This means it should prevent race conditions, where two processes or goroutines try to modify the state of the cache at the same time.

Go provides a solution for this through the use of a mutex—a locking mechanism that ensures only one thread or goroutine can access a resource at a time. By locking the cache during operations, we prevent data corruption and maintain consistency.

Another important component is the Janitor. This is a lightweight scheduler that periodically runs in the background to clean up expired items from the cache. It helps free up memory and makes room for newer items, keeping the cache lean and efficient.

Expanding Item

//Check if Item is expired
func (this Item) Expired() bool {
    if this.duration == 0 {
        return false
    }
    return time.Now().UnixNano() > this.duration
}

This method returns a bool indicating whether an item has expired by checking if its timestamp (Duration, remember) is less than the current time. But before doing that, it first checks if the Duration is 0. If it is, the method returns false, meaning the item should not expire.

This is intentional. Sometimes, you may not want certain items in the cache to ever expire—you want them to persist for as long as the program is running. In this design, any item with a Duration value of 0 is treated as having no expiration, and therefore is never evicted by the cleanup process.

Set

Now we can begin working on our cache. The first method we’re going to add is Set—this allows us to populate the cache with data that we can retrieve and use later.

// Store a value in cache with a defined ttl
func (c *cache) Set(key string, value interface{}, ttl time.Duration) {
    defer c.mu.RUnLock()
    var d int64
    if ttl == 0 {
        ttl = DefaultDuration
    }
    if ttl > 0 {
        d = time.Now().Add(ttl).UnixNano()
    }
    c.mu.RLock()
    c.items[key] = Item{
        value:    value,
        duration: d,
    }
    return
}

The Set method stores a value in the cache under a specific key, along with an optional TTL (Time To Live). If no TTL is provided, and the DefaultDuration is 0, the item will be stored without expiration, meaning it will stay in the cache indefinitely unless manually removed.

If a TTL is provided (i.e. greater than zero), it is converted to a Unix timestamp (int64) for efficient comparison during retrieval or cleanup.

Finally, the method locks the cache for writing to ensure thread safety, then inserts the item into the cache map.

Let’s do Get, Delete, Len, you get the gist now

// Get an Item from store using its key
func (c *cache) Get(key string) (interface{}, bool) {
    c.mu.RLock()
    item, ok := c.items[key]
    if !ok {
        return nil, false
    }
    if item.Expired() {
        c.mu.RUnlock()
        return nil, false
    }
    c.mu.RUnlock()
    return item.value, true
}

// Delete an item from store by its key
func (c *cache) Delete(key string) bool {
    c.mu.RLock()
    if _, ok := c.items[key]; !ok {
        return false
    }
    delete(c.items, key)
    c.mu.RUnlock()
    return true
}

// Return the lenght of items in store
func (c *cache) Len() int {
    c.mu.RLock()
    n := len(c.items)
    c.mu.RUnlock()
    return n
}

Alright, we’re almost done—I promise. The Get function retrieves an item from the cache using its key. First, it locks the cache for reading and checks if the key exists in the items map. If it doesn’t, it returns nil and false.

If the item does exist, the function checks whether it has expired using the Expired() method. If it has, it unlocks the cache and returns nil and false. Otherwise, it returns the item’s value along with true to indicate a successful cache hit.

The next function is Delete. This function removes an item from the cache by its key. It first locks the cache for reading and checks if the key exists in the items map. If it doesn’t, it returns false.

If the key exists, it deletes the entry from the map and then unlocks the cache. Finally, it returns true to indicate that the item was successfully removed.

And finally Len. This returns the length of items in the items map; nothing too fancy here.

But wait, there is one more thing

// Delete all expired items from store
func (c *cache) DeleteExpired() {
    c.mu.RLock()
    for k, v := range c.items {
        if v.Expired() {
            c.Delete(k)
        }
    }
    c.mu.RUnlock()
}

Remember when I mentioned we have a Janitor? The DeleteExpired function is part of that cleanup process. It loops over all the items in the store and checks whether each one has expired. If an item is expired, it calls the Delete function to remove it from the cache.

This helps ensure the cache doesn't keep stale data and frees up memory for new entries, keeping the cache clean.

The Janitor

Now let’s talk about how the Janitor runs.

// Run janitor clean up after intervals
func (j *Janitor) Run(c *cache) {
    ticker := time.NewTicker(j.interval)
    for {
        select {
        case <-ticker.C:
            c.DeleteExpired()
        case <-j.stop:
            ticker.Stop()
        }
    }
}

The Run method starts a ticker that fires at intervals defined by the user. On each tick, it calls DeleteExpired() on the cache — this is how we automatically clean up expired items without the user needing to call anything manually.

We also listen for a stop signal through the stop channel. Once that signal is received, we stop the ticker and exit the loop.

func stopExceution(c *cache) {
    c.janitor.stop <- true

}

func startJanitor(interval time.Duration, c *cache) {
    janitor := &Janitor{
        interval: interval,
        stop:     make(chan bool),
    }
    c.janitor = janitor
    go janitor.Run(c)
}

There’s also a stopExecution function that sends the stop signal to the janitor. This gives us a way to gracefully shut down the cleanup process when the program is closing or we no longer need the cache.

Finally, the runJanitor function wires everything together. It creates a new Janitor with a cleanup interval, assigns it to the cache, and runs it in a goroutine so it works in the background.

Putting it all together

func GetCache() *cache {
    items := make(map[string]Item)
    once.Do(func() {
        defaultCache = &cache{
            items: items,
        }
        runJanitor(DefaultCacheInterval, defaultCache)
        runtime.SetFinalizer(defaultCache, stopExceution)
    })
    return defaultCache
}

Now we can run our cache and see our little in-memory cache in action

Conclusion

This is a very small and maybe not production-ready cache, but I still remember the excitement I felt when it finally worked—and how it helped me with my little project (which I promise I did not abandon).

In my next article, we’ll look at how to expand this further by adding LRU support to the cache.

Now remember: just because you can build something yourself doesn’t always mean you should. It’s often a smart move to use existing tools, especially when caching isn’t the core of your project.

That said... I do think you should try building your own multi-auth system at least once. Until next time ✌🏽

x402: Pay-Per-Use Internet

Andrew David — Thu, 27 Nov 2025 13:07:09 +0000

We All Hate Free Trials (Well, I Do)

Sometimes I just want to test something new. Maybe it’s a new AI image tool, a premium API, pay for a digital content to a creator, some data service everyone won’t shut up about. But nope—the first thing I see is “Start your 7-day free trial!” Great… except now I have to hand over my card on day one. Then I spend the whole week stressing that I’ll forget to cancel and get slapped with a $99 charge for something I used only once.

Even worse: sometimes I want my AI agent (ChatGPT, Claude, Grok) to use that service for me. Which means what—give my card to the AI? I’m reckless, but an AI agent is probably ten times more reckless than me.

It’s dumb. We shouldn’t need credit cards just to test stuff. With x402, I load a single wallet once—with however much I feel like (even five bucks). From that moment on, me and any AI agent I control can tap into hundreds of services and pay only for what we actually use, down to the penny. No cards floating around. No surprise bills. No “don’t forget to cancel” alarms. I pay for what I use. My agent pays for what it uses. Everyone wins.

So what is x402 and Why?

The Evolution of Web Payments — and Why x402 Matters

The 402 status code has been around since the very beginning of HTTP. The idea was simple: if a resource needs payment before you can access it, the server would return a 402.

The problem: nobody actually used it.

Not because the idea was bad, but because there was no standard way to pay over HTTP. So developers defaulted to 403 Unauthorized, and everyone just built their own systems—subscriptions, one-time links, prepaid credits.

These solutions work, but they all live outside the actual web request. The big unanswered questions were:

How do we handle payments inside a request?
How do we send payments over HTTP?

Stablecoins Changed the Game

Then stablecoins blew up. Between 2021 and 2025:

Supply jumped from under $30B to over $280B
On-chain volume hit $27 trillion
Governments finally gave clear rules (EU’s MiCA, U.S. GENIUS Act, and similar laws)

Stablecoins basically became the first form of money that’s fast, global, cheap, programmable, and actually works online. Perfect for internet payments.

x402: Payments Directly Through HTTP

In May 2025, Coinbase introduced x402, a simple idea that unlocks a lot of possibilities. It revives the old 402 status code and gives it a real purpose.

With x402, if a resource requires payment, the server can return a 402 Payment Required response that includes:

how much you need to pay
where to send the payment
optional details about what you're buying

The client—your browser, app, or even an AI agent—can then pay instantly on chains like Solana, Base, or Polygon, and the server delivers the requested content in the same connection. No accounts, no signups Just pay-and-go.

Perfect Timing for AI Agents

AI agents are exploding in popularity, and they constantly make requests, pull data, call APIs, and use computational resources. With x402:

Agents can pay for exactly what they use
MCP servers can charge per request automatically
Digital systems can trade with each other without any human setup

This allows for more robust agentic systems and true agentic commerce

Microtransactions Finally Make Sense

One of the best things about x402 is that tiny payments—stuff like a few cents or even fractions of a cent—actually become practical. With credit cards, fees make this impossible. But with fast crypto networks:

Pay 1¢ to read an article
Pay per API call
Pay by the second for compute
Pay per kilobyte of data

This means companies can finally drop the free trial and allow test the product without having to worry about remembering to cancel another subscription.

So how does It work?

At its core, x402 involves three main players:

The Seller – the server or service hosting the resource you want
The Buyer – you (or your app, agent, or browser)
The Facilitator – the service that verifies signatures and settles payments on-chain

1. The Buyer

You (the buyer) send a regular GET or POST request to the server, but with one extra header:

X-Wallet header, which includes:

your wallet address
the payment methods/networks your client supports

This basically tells the server:

“Hey, I have a wallet. If this costs money, I’m ready.”

2. The Seller

If the resource is paywalled, the server returns a 402 Payment Required response containing an invoice.

Example:

{
  "maxAmountRequired": "0.01",
  "resource": "/api/video/generate",
  "description": "Access requires payment",
  "payTo": "0xABCDEF1234567390ABCDEF1234567890ABCDEF12",
  "asset": "0xA0b86991C6218236c1d19D4a2e9Eb0cE3606EB48",
  "network": "base-mainnet"
}

This tells the buyer exactly what needs to be paid, in what currency, and where.

4. Gasless payments using EIP-3008

x402 uses EIP-3008: TransferWithAuthorization to enable gasless transfers.

Instead of sending a transaction on-chain, the buyer:

Signs a payload authorizing the payment
Sends that signed payload back to the seller in an X-Payment header

Example:

X-Payment: <signed EIP-3008 payload>

No gas. Just a signature.

5. The Seller forwards the signature to the Facilitator

The seller never posts anything directly on-chain.

Instead, it forwards the signed payment to the facilitator, who:

verifies it
settles the payment
confirms everything succeeded

Once payment is settled, the seller returns the requested resource—all in the same request flow.

Why Not API Keys?

x420 shines by allowing users to make transactions without needing API keys or even accounts on the services they interact with. This means a single wallet can grant access to premium services across multiple platforms.

The major advantage is that AI agents can independently compose and pay for API requests without any user intervention. Imagine you have an AI agent that needs to publish posts every day based on what’s trending in the country. Your agent will need:

A search tool to find what’s currently trending
Access to Twitter/X to gather up-to-date news and topics
The ability to publish a post on your Twitter/X account

Normally, this requires API credits and API keys for platforms like Google and Twitter. While manageable for a small project, the number of API keys quickly becomes overwhelming as your system grows and you integrate more services.

With x420, one wallet covers the cost of all transactions, regardless of the number of services involved. All you need to manage is the balance in that single wallet. And you can even set spend limits so your AI agent doese’t spend above a certain threshold.

Now The problem

x402 is impressive—really impressive—but it still carries challenges that are common across the entire crypto ecosystem. The most significant concern is that crypto transactions generally cannot be traced back to a specific individual or organization. While this privacy is a feature, it also creates the potential for x402 to be misused for money laundering or online fraud. These concerns are not unique to x402; they apply broadly to most blockchain-based systems and projects.

Another important issue currently being worked on is transparency. Even though the origin of an agent’s transaction may be private to the service provider, the transaction itself is still publicly visible on the blockchain. This means that, despite appearing anonymous, your agent’s actions can still be tracked, and most users do not want their agent’s financial activity to be publicly exposed.

Addressing this would require privacy-preserving transactions, along with selective disclosure—allowing only authorized parties (such as auditors or regulators) to view transaction details when necessary.

Another concern with x402 is the lack of chargebacks or refunds. Because transactions are irreversible, victims these of scams cannot recover lost funds. This raises the risk of an increase in crypto scams.

One proposed solution is the introduction of reputation systems. Services can be rated by users and agents, and poor ratings reduce the likelihood that others will trust or interact with them. While this improves accountability, it does not fully solve the chargeback problem, as victims still cannot retrieve their money.

The conclusion

So yeah—that’s x402. This article isn’t meant to be highly technical, but it gives you a broad overview of what x402 is and its potential impact on online payments. One user even described it as “the next big thing after sliced bread.”

Innovation around x402 is moving fast, and version 2 is already on the way with even more improvements. One of the most exciting aspects of x402 is that it’s simply a set of rules for moving money over HTTP. Although crypto is currently being used as the payment layer, the standard itself is not limited to crypto. This means x402 has the potential to move even fiat currency over HTTP.

Experiments have already been conducted using services like Stripe—not yet public, but promising—which shows just how far-reaching the potential of x402 could be. The future of online payments built on this standard is genuinely exciting.

DEV Community: Andrew David

Poltergeist: I made a browser extension that haunts the page you're reading

What I Built

Features & Capabilities

Demo

Visual Walkthrough

1. Summoning the Ghost (Popup UI)

2. The Haunting: Contextual Whisper & Typewriter Animation

3. Trick or Treat: Spooky Headline Mutations & Screen Flick

4. Flashlight Mode: Dynamic Spotlight Tracking

5. Ghost Hunt: Interactive Hiding Game

6. Architecture & Clean Reversibility

Code

emperorsixpacks / poltergeist

Poltergeist

Try it (30 seconds, no installs)

Features

Core Repository Highlights

How I Built It

The AI Brain: Open-Weight gpt-oss-120b via Groq

System Architecture

Why Does Open Innovation Matter?

My Agent Session

The Spirit of It

Prize Categories

How to Implement In-Memory Caching in GoLang

The Why?

The What?

Less Talk, more code !!!

So now we code, right?

The Design

Now we code

Expanding Item

Set

Let’s do Get, Delete, Len, you get the gist now

But wait, there is one more thing

The Janitor

Putting it all together

Conclusion

x402: Pay-Per-Use Internet

We All Hate Free Trials (Well, I Do)

So what is x402 and Why?

The Evolution of Web Payments — and Why x402 Matters

Stablecoins Changed the Game

x402: Payments Directly Through HTTP

Perfect Timing for AI Agents

Microtransactions Finally Make Sense

So how does It work?

1. The Buyer

2. The Seller

4. Gasless payments using EIP-3008

5. The Seller forwards the signature to the Facilitator

Why Not API Keys?

Now The problem

The conclusion

Links