The problem second-brain solves

For creators, researchers, and experts, the current monetization landscape for written knowledge is deeply
flawed. If you have a massive archive of valuable text (newsletters, research notes, documentation, or books),
your options are currently limited to blunt, all-or-nothing paywalls (like Substack) or relying on ad revenue.
Furthermore, if you want to let users "chat" with your data, you have to upload it to a centralized platform
like OpenAI, which captures all the value and offers you nothing in return.

Second Brain solves this by turning any static text archive into a sovereign, pay-per-query AI agent that you
can embed anywhere.

Instead of locking knowledge behind a $10/month subscription, Second Brain uses the x402 protocol (HTTP 402
Payment Required) combined with the ultra-low fees of MegaETH to create true micro-monetization.

What people can use it for:

• Independent Creators: Upload your entire back-catalog of essays. Drop the iframe onto your personal site,
  allowing readers to ask your "AI clone" specific questions for a few cents per answer.
• Open Source & Dev Tools: Monetize premium technical support. Train a brain on your project's advanced
  documentation and charge micro-transactions for instant, highly-accurate technical debugging.
• Researchers & Analysts: Sell access to proprietary market research. Users don't have to buy a $500 report;
  they can pay $0.50 to ask exactly what they need to know.

How it makes things better:

• Frictionless UX: It utilizes an embeddable iframe. The reader connects their wallet directly in the chat
  widget, signs the escrow transaction, and gets their answer instantly.
• Creator-Owned: The creator holds the keys. Revenue accumulates in an on-chain escrow contract, ready to be
  pulled directly to their wallet at any time.
• Context-Strict (RAG): Because it uses Venice AI and a localized vector store, the agent only answers using
  the provided archive, drastically reducing hallucinations and preserving the creator's true voice.

Challenges we ran into

Building a decentralized, pay-per-query agent required bridging the gap between synchronous Web2 APIs and
asynchronous Web3 infrastructure. Here are the main hurdles and how I overcame them:

1. The RPC Race Condition (Transaction Propagation Delay)
   The biggest hurdle was a classic blockchain race condition during the payment handshake. When a user paid for a
   query in the frontend iframe, their injected wallet (e.g., MetaMask) instantly confirmed the transaction and
   told the React app to hit the backend /query endpoint with the new transaction hash.
   However, the Express backend validates payments using a public MegaETH RPC node. Because the node takes a few
   seconds to index the newest blocks, it was returning null for the transaction, causing the API to reject valid
   payments with a "Transaction not found" error.

• How I fixed it: I implemented a localized polling loop inside the backend's x402 middleware. Now, when the
  backend receives a payment hash, instead of failing immediately, it gracefully retries fetching the receipt
  up to 5 times (spaced 1 second apart). This gives the RPC node the buffer it needs to sync the network
  state, resulting in a flawless UX for the reader.

2. Serverless Environments vs. Stateful AI Vectors
   Initially, I wanted to deploy the entire stack to Vercel. However, the architecture relies on an in-memory
   database to store API keys and uses Xenova to generate localized vector embeddings on the fly. Serverless
   functions (like Vercel's) spin down constantly, which meant the vector store and API keys were being wiped from
   memory every few minutes, causing "Invalid API Key" errors.

• How I fixed it: I split the architecture into a hybrid deployment. I deployed the React frontend as a Static
  Site to Vercel for fast global CDN delivery, but migrated the Express/Ethers backend to a dedicated Google
  Compute Engine (GCE) Virtual Machine running persistently via systemd. To bypass browser CORS and Mixed
  Content (HTTPS -> HTTP) blockers, I configured vercel.json to act as a reverse proxy, silently routing all
  frontend /api/* requests to the VM.