DEV Community: Jadeofwallstreet

Three Things That Could Break Crypto And What We At Monipay Think About Them

Jadeofwallstreet — Fri, 10 Apr 2026 10:08:10 +0000

This week gave the crypto industry a lot to sit with.

On April 8, Anthropic published findings from its newest AI model, Claude Mythos Preview, showing it had autonomously found and exploited security vulnerabilities in cryptography libraries that had gone undetected for decades. Two days before that, theNew York Times published an investigation pointing to Adam Back, the CEO of Blockstream, as the most likely identity behind Satoshi Nakamoto. Back denied it. And on April 9,a researcher at StarkWare published a working scheme for quantum-safe Bitcoin transactions that requires no changes to the Bitcoin protocol and costs between $75 and $150 in cloud GPU compute to execute.

Three separate developments. Three different risk categories. All arriving in the same week.

I want to go through each one, explain what I actually think the risk is, and then say honestly what it means for us at Monipay.

The Satoshi question

TheNew York Times investigation, led by John Carreyrou, points to Adam Back as the most likely candidate based on linguistic analysis, overlapping timelines, andBack's development of HashCash, a proof-of-work system that directly influenced Bitcoin's design. Back denied the claims in a series of posts on X. Blockstream released a statement calling the report "circumstantial interpretation of select details and speculation, not definitive cryptographic proof."

He is probably right about the cryptographic proof part. No one has moved Satoshi's coins. No private key has been demonstrated. Under that standard, nothing is proven.

But the question is worth taking seriously not because of who Satoshi might be, but because of what a confirmed identity would actually do to Bitcoin's market.

Satoshi is estimated to hold around 1.1 million Bitcoin. Even without selling, identifying the owner of those early coins could trigger supply-shock fears and reflexive sell-offs. The concern is not that Satoshi would necessarily liquidate. The concern is that the narrative of a leaderless, no-one-controls-this-thing network would take a direct hit. Bitcoin's monetary premium sits partly on that story.

If Satoshi is identified as a real person or group that looks politically exposed, ethically compromised, or legally vulnerable, Bitcoin's neutrality narrative takes a hit. That does not break the network, but it can reduce the monetary premium that sits on top of the technology.

There is also the legal dimension. A confirmed identity immediately produces a target for civil suits, government investigations, tax authority interest, and sanctions exposure depending on the jurisdiction. None of those things touch the protocol. All of them touch price and institutional confidence.

My read is that the Satoshi identity risk is real but slow-moving and market-level rather than technical. Bitcoin the network would survive the reveal. Bitcoin the asset would likely experience significant volatility, then stabilise once it became clear that nothing about the protocol had changed. The deeper risk is if the revealed person is someone whose background calls the origin story into genuine question, which would require an extraordinary fact pattern, not just someone being a cryptographer who kept quiet.

For stablecoins and for Monipay specifically, a Bitcoin confidence shock matters indirectly. It would move the entire crypto market, and market confidence affects how comfortable people are holding and spending USDC or USDT. But USDC and USDT do not depend on Bitcoin's narrative the way BTC price does. The payments infrastructure we are building would keep functioning regardless of who Satoshi turns out to be.

The quantum threat, which is no longer theoretical

The quantum risk to Bitcoin has been discussed for years as a future problem. This week it became a present engineering problem.

On April 9,Avihu Mordechai Levy of StarkWare published a paper titled "Quantum-Safe Bitcoin Transactions Without Softforks." The abstract describes QSB, a quantum-safe Bitcoin transaction scheme that requires no changes to the Bitcoin protocol and remains secure even against an adversary running Shor's algorithm. The scheme works within Bitcoin's existing legacy script constraints of 201 opcodes and 10,000 bytes.

The core of the approach is a hash-to-signature puzzle. Standard Bitcoin transactions rely on ECDSA signatures over the secp256k1 curve. Shor's algorithm can efficiently compute discrete logarithms, which would let a quantum adversary forge those signatures. QSB replaces ECDSA security with RIPEMD-160 pre-image resistance. The locking script hashes a transaction-bound public key via OP_RIPEMD160 and interprets the 20-byte output as a DER-encoded ECDSA signature. A random 20-byte string satisfies DER structural constraints with probability approximately 2^-46, providing the proof-of-work target. A quantum computer cannot break this because the hardness comes from hash pre-image resistance, not elliptic curve arithmetic.

The practical cost is $75 to $150 in cloud GPU compute, using CUDA code that achieves 238 million operations per second on an RTX PRO 6000. The GitHub repository includes working code, documented benchmarks, and a confirmed DER hit on real hardware after six hours on eight GPUs.

The same week,Olaoluwa Osuntokun posted to the Bitcoin Development Mailing List a proposal forPost-Quantum BIP-86 Recovery via zk-STARK proof of BIP-32 seed knowledge

. The proposal enables a Taproot output public key holder to prove, using a zero-knowledge STARK proof, that their key was derived from a known BIP-32 seed via a BIP-86 path, without revealing the seed itself. This addresses how existing Bitcoin holders would migrate to quantum-safe outputs without losing access to their coins.

What these two papers together mean is that serious cryptographers are no longer treating quantum-resistant Bitcoin as a theoretical exercise. They are shipping working implementations.

The important distinction here is between the threat to Bitcoin specifically and the threat to the broader cryptographic infrastructure that crypto runs on. ECDSA is the mechanism under attack from Shor's algorithm. Ethereum and most EVM-compatible chains use the same secp256k1 curve. Solana uses Ed25519, which has different but related quantum exposure. None of the major blockchain ecosystems are immune.

The timeline matters. Cryptographers generally agree that a quantum computer capable of running Shor's algorithm at the scale needed to break secp256k1 keys requires millions of logical qubits with very low error rates. Current quantum computers have hundreds to thousands of noisy physical qubits. The engineering gap between where we are and where an attacker would need to be is still significant. But the history of cryptography shows that you prepare migration paths before the attack arrives, not after.

The QSB work from StarkWare is not a production-ready migration path for the entire Bitcoin ecosystem. It is a proof-of-concept that shows the migration can be done within existing constraints. That is meaningful. It moves the conversation from "quantum is a future problem" to "here is one way to handle it when the time comes."

For Monipay, the quantum question touches us at the signature layer. Our EIP-712 gasless relayer uses ECDSA. Our MoniBot smart contracts use ECDSA. Our user wallets use secp256k1 keys. None of this is more or less exposed than any other EVM product. We are not doing anything that makes us specifically more vulnerable. But we are also not yet doing anything that makes us specifically more resistant. That is something we are watching carefully as the ecosystem develops post-quantum signature standards.

The Mythos threat, which is different from the others

The first two threats are about Bitcoin specifically or about the underlying cryptographic primitives. The Mythos threat is about everything.

Anthropic's Claude Mythos Preview can autonomously identify zero-day vulnerabilities and then construct working exploits across every major operating system and major web browser.Anthropic's security research team published a technical assessment of Mythos Preview's capabilities on April 7, documenting findings from roughly a month of internal testing.

Beyond memory corruption bugs, the model identified authentication bypasses in web applications, weaknesses in widely used cryptography libraries covering TLS, AES-GCM, and SSH, and a guest-to-host memory corruption vulnerability in a production virtual machine monitor.

Mythos Preview identified a number of weaknesses in the world's most popular cryptography libraries, in algorithms and protocols like TLS, AES-GCM, and SSH. These bugs arise due to oversights in the respective algorithms' implementation that allows an attacker to, for example, forge certificates or decrypt encrypted communications.

The AES-GCM finding is the one that matters most directly for crypto infrastructure. AES-GCM is not the same as the elliptic curve cryptography that secures Bitcoin addresses. AES-GCM is the symmetric encryption scheme used in TLS, which secures the HTTPS connections that Monipay's backend, Supabase, and virtually every crypto platform's API layer depends on. A vulnerability in AES-GCM implementations, not in the algorithm itself but in how major libraries implement it, is not a theoretical future risk. It is the kind of thing that, if exploited before patches are deployed, could let an attacker intercept and decrypt communications between a user's device and a payment API.

The critical word in that last sentence is "if exploited before patches are deployed." Anthropic launched Project Glasswing alongside the model, a defensive coalition includingAmazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks, formed to use these capabilities to secure critical software before similar models become widely available.

The notable absence in that list is any crypto company. No exchange. No blockchain infrastructure provider. No DeFi protocol. No payment platform. The coalition Anthropic assembled to use Mythos defensively before similar capabilities become widely available is composed entirely of traditional software and enterprise infrastructure companies.

The risk is particularly high for DeFi protocols, which are open source software. Their code is publicly readable by anyone, including a model like Mythos that can autonomously catalog every weakness in a codebase at machine speed for near-zero marginal cost. And while the roughly $200 billion locked in smart contracts across Ethereum, Solana, and other chains has been audited by humans and automated scanners, Anthropic claims Mythos operates beyond both.

The company noted that "mitigations whose security value comes primarily from friction rather than hard barriers may become considerably weaker against model-assisted adversaries." Multisig governance, timelocks, and audit reports as proof of security are all friction-based defenses. In simple terms, these measures slow things rather than blocking an attack at the code level.

This is the argument that matters. The security model that most of DeFi runs on assumes a human attacker with limited time and cost. Finding an exploit in a mature codebase takes weeks or months and requires rare expertise. That cost assumption is what makes bounties and audits functional. If Mythos-class models can find and exploit vulnerabilities autonomously at near-zero marginal cost, the entire cost model of DeFi security changes.

That does not mean every DeFi protocol is about to be drained. It means the industry needs to take the next generation of security tooling seriously much faster than it currently is.

At Monipay, the Mythos findings reinforced something we already built around: non-custodial architecture. Our user private keys are generated on-device, encrypted with AES-GCM using PBKDF2 key derivation from the user's PIN, and stored in hardware-backed secure storage. We never receive them. We cannot transmit them. An attacker who finds an implementation flaw in our API layer cannot use it to extract private keys, because we do not have private keys to extract.

The AES-GCM vulnerability found by Mythos is in the TLS implementation layer, which affects HTTPS communications. This is a real concern for any product that transmits sensitive data over the network. For us specifically, it means keeping our dependencies current, watching the Glasswing disclosure timeline for patches, and treating any CVE in our cryptographic dependency chain as urgent rather than scheduled. Two of the three AES-GCM vulnerabilities Mythos found were unpatched at time of disclosure. One was patched the same day. The practical window between "Mythos finds it" and "the fix ships" is now the attack surface.

The deeper concern is what happens when models with Mythos-class capabilities are not limited to a coalition of 40 companies. Anthropic states that these capabilities were not explicitly trained for, but emerged as a downstream consequence of general improvements in code understanding, reasoning, and autonomy. The company does not plan to make Mythos Preview generally available. That is today's position. It will not be the position indefinitely. The security community has roughly twelve to eighteen months to build its defenses before comparable capabilities are widely accessible, which is the same logic that drove Glasswing's formation.

What we take from all three

The threats are different in nature and in timeline.

The Satoshi reveal is mostly a confidence and market risk. If it happens in a way that damages the neutrality narrative around Bitcoin, it affects market sentiment broadly. The protocol keeps running. The payments infrastructure keeps working. We would see volatility and then adaptation.

The quantum threat is a long-horizon cryptographic risk that is now generating real engineering responses. TheQSB paper from StarkWare and theBIP-86 zk-STARK proposal from Osuntokun show that the Bitcoin development community is actively building migration paths, not waiting. The EVM ecosystem will need equivalent work. We are watching it and planning for the day when post-quantum signatures become a production requirement rather than a research interest.

The Mythos threat is the one on the shortest timeline and the broadest surface area. It is not specific to Bitcoin. It is not specific to crypto. It is a capability shift in how vulnerabilities are found and exploited that affects every software system in production, including the ones crypto runs on top of. The fact that no crypto company is in Glasswing is something the industry should notice.

None of these three things break stablecoins as a concept. The value of moving dollars at near-zero cost in near-zero time across borders does not go away because of any of them. The infrastructure those movements run on top of needs to keep pace with the threats. That is what we are building toward.

Monipay is a non-custodial stablecoin payment platform live on Base and BSC. moniTag™ replaces wallet addresses. MoniBot AI executes on-chain payments from a single tweet. monipay.xyz

EmDash: Cloudflare Just Dropped the WordPress Killer Nobody Saw Coming

Jadeofwallstreet — Fri, 03 Apr 2026 11:24:40 +0000

WordPress turned 23 this year. For 23 years, we've been installing plugins,
crossing our fingers, and praying nothing breaks.

Cloudflare just said: enough.

On April 1st — yes, April Fools' Day — they dropped something very real:
EmDash, a full-stack TypeScript CMS they're calling the spiritual
successor to WordPress. I've been digging into it since launch and this is
what every developer needs to know.

The WordPress Security Problem (That Nobody Fixed)

Here's a stat that should shake you:

96% of WordPress security vulnerabilities come from plugins.

Not WordPress core. Plugins. And in 2025, more high-severity plugin
vulnerabilities were discovered than the previous two years combined.

Why? Because a WordPress plugin is essentially PHP that hooks directly into
your site with zero isolation. When you install a WordPress plugin, you
are handing it the keys to your entire database and filesystem — and trusting
a stranger's code to never misuse them.

This isn't a WordPress skill issue. It's a fundamental architectural
problem that 23 years of patches can't fix.

Enter EmDash

EmDash flips the plugin model on its head.

In EmDash, every plugin runs in its own Dynamic Worker — a sandboxed
V8 isolate. Plugins can't do anything they haven't explicitly declared in
their manifest. Here's what a plugin looks like:

import { definePlugin } from "emdash";

export default () =>
  definePlugin({
    id: "notify-on-publish",
    version: "1.0.0",
    capabilities: ["read:content", "email:send"],
    hooks: {
      "content:afterSave": async (event, ctx) => {
        if (event.collection !== "posts" || event.content.status !== "published") return;

        await ctx.email!.send({
          to: "editors@example.com",
          subject: `New post published: ${event.content.title}`,
          text: `"${event.content.title}" is now live.`,
        });
      },
    },
  });

This plugin declares exactly two capabilities: read:content and
email:send. That's it. No database access. No filesystem access.
No sneaky outbound HTTP to who-knows-where. It physically cannot do
more than it declares.

This is closer to an OAuth permission screen than a traditional plugin
install. You see what you're granting before you grant it.

What EmDash Actually Is (Tech Stack Breakdown)

Language: TypeScript (all the way down)
Framework: Built on Astro — the content-first web framework
Runtime: Cloudflare Workers (V8 isolates) — but runs on any Node.js server too
Database: Portable — SQLite, D1, Turso, PostgreSQL via Kysely
Storage: S3-compatible — R2, AWS S3, or local files
Auth: Passkeys by default. No passwords. No brute force vectors.
License: MIT (no GPL drama)
Content format: Portable Text (structured JSON, not HTML blobs)

That last point deserves its own section.

WordPress stores content as HTML. EmDash doesn't.

WordPress embeds metadata inside HTML comments in a posts table. Your
content is tied to its DOM representation. Want to render it in a mobile
app? Good luck parsing that HTML.

EmDash uses Portable Text — structured JSON. Your content is decoupled
from presentation. One source of truth renders as a web page, a mobile app,
an email, or an API response. This is huge for AI pipelines too — LLMs
consume structured JSON dramatically better than HTML soup.

It's AI-Native By Design

EmDash isn't just AI-compatible. It's AI-native:

Built-in MCP server on every instance — your AI tools can talk to your CMS directly
EmDash CLI — agents can manage content, schemas, and media programmatically
Agent Skills — contextual docs that let coding agents understand and extend your EmDash site without handholding

For those of us building AI-native workflows, this is the first CMS that
actually meets us where we are. Forget writing migration scripts by hand —
point an agent at it.

The Honest Caveats

I'd be doing you dirty if I didn't flag what's missing:

🔴 No plugin ecosystem yet. Zero. EmDash is v0.1.0. The security model
is brilliant, but it only matters when there are plugins to install.

🔴 The killer sandbox feature requires Cloudflare. When self-hosting on
Node.js, you don't get sandboxed plugins. The security model that justifies
EmDash's existence is Cloudflare-specific right now.

🔴 Two months of development ≠ two months of battle-testing. This was
built with AI agents at speed. Impressive? Yes. Production-ready for your
client's e-commerce site? Not yet.

🔴 WordPress ecosystem won't port over. PHP plugins, PHP themes — none
of that comes with you. Content migrates. Everything else starts from zero.

Should You Care Right Now?

If you're a WordPress developer: Yes. Not to abandon WordPress tomorrow,
but to understand what the next decade looks like. The PHP era of CMS
development has a credible TypeScript-native successor for the first time.

If you're an AI-native developer: Get in early. The MCP integration,
the structured content model, the agent skills — this is built for you.
Be among the first to build plugins and themes.

If you're running production WordPress sites: Watch closely. Migrate
nothing yet.

Try It Now

npm create emdash@latest

Or try the admin playground without installing anything:

👉 EmDash Playground

The repo is open source on GitHub: emdash-cms/emdash

EmDash won't replace WordPress tomorrow. But it's the first serious
architectural rethink of CMS infrastructure in a generation — and it
dropped two days ago.

Get familiar with it now, while the ecosystem is still being written.

The pioneers get to shape what comes next.

How Monipay is Redefining How Money Moves in the Age of AI

Jadeofwallstreet — Sun, 22 Mar 2026 08:53:49 +0000

I became obsessed with a problem not because it was intellectually interesting, but because it was personal.

I’ve watched people send money across countries and lose 8% to fees. I’ve seen a market trader in Abuja turn away a tourist because the POS was offline again. I’ve seen someone hold USDC and still be unable to send it, stuck on something as simple as gas fees.

And then there was that moment in Lagos IshowSpeed asked a vendor if they accept USDC or USDT, and the answer was yes.

That’s when it clicked: the problem isn’t infrastructure. It’s usability.

The infrastructure for a better financial system has existed for years. The missing piece was always the experience. That is what we are building with Monipay.

The Problem Is Not Blockchain. It Is UX.

Here is what sending stablecoins looked like before Monipay:

Download a wallet
Write down a 12-word seed phrase
Buy ETH just to pay gas on USDC transfers
Bridge to the right L2
Copy a 42-character wallet address
Paste it correctly
Confirm the transaction
Wait

That is seven steps to send five dollars. Western Union requires fewer steps. That is the UX crisis crypto has been living with and calling progress.

The industry spent years building faster chains, cheaper gas, and more powerful smart contracts. All of that work was necessary. But none of it solved the real problem: normal people cannot use this.

The average person who would benefit most from stablecoins, the person in Lagos or Nairobi or Manila who is losing 10% of their salary to remittance fees, cannot navigate that seven-step flow. They close the app and never come back.

What We Built

Monipay is a non-custodial, AI-powered smart payment platform that collapses those seven steps into one.

You pick a moniTag™. A simple username. Something like @jade. That username becomes your universal payment address across every chain we support. No wallet addresses. No chain selection. No gas management.

Someone wants to pay you. They type @jade. Money arrives.

That is the entire user experience.

The Three Pillars

moniTag™ Identity

Your moniTag™ is your payment identity across Base, BSC, and Solana simultaneously. We resolve it to the correct wallet address on whatever chain the sender is using. You never have to tell anyone which chain you are on. You never share a wallet address again.

Gasless Relayer

We built an intelligent custom EIP-712 gasless relayer infrastructure. When you send a payment on Monipay, you sign a typed message off-chain. Our relayer submits the transaction on-chain and covers the gas. You pay a flat 1% platform fee. That is it. No ETH required. Ever.

MoniBot AI

This is where things get genuinely new. MoniBot is an autonomous AI payment agent that lives on Twitter/X, Discord, and Telegram. You mention it with a natural language command and it executes a real on-chain USDC, aUSD or USDT transfer automatically.

@monibot send $5 to @alice
@monibot send $2 each to @bob, @charlie, @dave
@monibot send $1 to first 50 replies

One tweet. Payments distributed to unlimited recipients. Settled on Base or BSC in seconds. No spreadsheet. No manual DMs. No wallet address collection.

The Problems We Ran Into

I want to be honest about the journey because I think the crypto space benefits from founders being specific about what was hard and why.

Account Abstraction Was Not the Answer

When I started thinking about how to eliminate gas fees from the user experience, the natural place to look was Account Abstraction and ERC-4337. The Ethereum community has been working on this problem since 2016. ERC-4337 launched on mainnet in March 2023. Over 40 million smart accounts have been deployed across Ethereum and Layer 2 networks, with nearly 20 million deployed in 2024 alone.

It's is impressive infrastructure. But it was not the right fit for what we were building.

UserOps remain around 2% of Base's volume. Challenges include gas inefficiency, app incompatibility, multi-chain state sync issues, and fragile infrastructure. UserOps are more expensive than native transactions, especially on Ethereum mainnet.

More practically: users with existing EOA accounts cannot simply convert to ERC-4337 smart wallets without creating new addresses and transferring all assets. We were building for people who might be new to crypto entirely. Asking them to understand the difference between an EOA and a smart contract wallet before they can send their first payment was a non-starter.

ERC-4337 is building toward something real. EIP-7702, introduced with the Pectra upgrade in May 2025, makes things meaningfully better by allowing EOAs to execute smart contract code without migrating assets. But it still concentrates significant security risk in the EntryPoint contract that sits at the center of every transaction.

We decided to take a different path. Our EIP-712 relayer approach achieves the same gasless outcome through a simpler mechanism: users sign typed messages off-chain, our relayer submits on-chain. No alternative mempool. No bundlers. No EntryPoint. The user experience is identical but the architecture is leaner and the security model is more transparent.

Chain Abstraction Is Still a Vision

Multi-chain payments sound simple until you actually build them. Every chain has its own RPC format, its own token standards, its own transaction model. Base uses USDC with 6 decimals on EVM. BSC uses USDT with 18 decimals on EVM. Solana uses a completely different account model with Ed25519 keypairs and SPL tokens instead of ERC-20.

The dream of true chain abstraction, where users never think about which chain they are on, runs into the reality that the underlying infrastructure is fundamentally different across these ecosystems. Bridging assets cross-chain introduces counterparty risk. Cross-chain messaging adds latency and cost.

Our solution was to embrace multi-chain rather than abstract it away. We run separate optimised payment flows for each chain. Users pick their preferred network once in settings. moniTag™ resolves to the correct address for that network. The user sees a consistent experience. Under the hood, it is three different payment systems that we maintain and improve independently.

It is more work. But it is honest engineering.

That said, We built something that gets meaningfully closer to that vision.

MoniBot routes payments intelligently at execution. It does not just follow the user’s selected chain and fail. Before any transaction, it checks three things.

If allowance is insufficient, it looks across other supported chains and routes the payment where approval already exists, then informs the user.

If balance is insufficient, it checks across chains and settles from wherever funds are available. The recipient gets paid and the sender sees where it settled.

If the network fails, it cycles through backup RPC endpoints. If the chain is still unreliable, it reroutes to a healthy one.

This is not full abstraction yet. The user still has a preferred chain. But the common failure points are removed.

You type a command. The payment goes through. Where it settles becomes a detail, not a decision.

That is the direction. The chain should be invisible to the user.

Tempo Raised the Bar and the Question

In September 2025, Stripe and Paradigm announced Tempo, a payments focused Layer 1 blockchain purpose built for stablecoin payments at internet scale. On March 18, 2026, Tempo Mainnet went live alongside the Machine Payments Protocol, an open standard for machine payments co-authored by Stripe and Tempo.

I want to be direct about this because it matters for understanding where we fit.

Tempo raised $500 million at a $5 billion valuation in 2025 from Thrive Capital, Greenoaks, Sequoia Capital, and Ribbit Capital. Their partners include Anthropic, OpenAI, Mastercard, Visa, Shopify, and Standard Chartered. That is extraordinary validation of the thesis that stablecoin payments infrastructure is one of the most important problems to solve right now.

But here is the thing the crypto-native community noticed immediately: the crypto and web3 research community raised questions about the trade-offs of corporate-backed chains like Tempo, particularly around decentralization and permissioning.

Tempo is currently a permissioned chain. The nodes that validate transactions are controlled by Tempo and its institutional partners. For enterprises that need regulatory certainty, that is a feature. For users who care about trustlessness and censorship resistance, it is a real trade-off.

This is where our philosophy diverges sharply.

Our Philosophy: Non-Custodial Is Not Negotiable

Monipay is built on a single non-negotiable principle: we never touch your money.

Your private key is generated on your device. It is encrypted with AES-GCM using PBKDF2 key derivation from your PIN. It is stored in hardware-backed secure storage. We have no copy. There is no backdoor. If we get hacked, the attacker gets nothing that can touch your funds.

This is not a marketing claim. It is the architecture.

The reason this matters so much right now is that the payment apps currently winning in crypto are mostly custodial. They hold your funds. They control your keys. They can freeze your account. They can go bankrupt. We watched FTX hold billions in customer funds and then not hold them anymore. We watched Celsius do the same thing.

The whole point of building on blockchains is that you should not have to trust a company with your money. We built Monipay so that you never have to trust us with yours.

What Monipay Does Right Now

Here is where things actually stand as of March 2026.

Personal payments are live. Send USDC to any moniTag™ on Base. Send USDT to any moniTag™ on BSC. Scan a QR code to pay a merchant. Receive payments via your branded moniTag™ QR & Username. Full transaction history with real-time sync.

Merchant suite is live. This is the part I am most proud of because nothing else in crypto comes close to what we built for merchants. Zero hardware required. Your phone is your payment terminal.

You get:

QR charge flow for in-person payments
Payment links that work anywhere, WhatsApp included
Invoicing with automatic payment detection
A full product catalog and online store
Webhooks for backend integration
A complete CRM with customer payment history
Real-time analytics

A market trader who cannot afford a POS terminal can download Monipay, create a moniTag™ in three minutes, and start accepting digital payments today. That is the product I wanted to exist when I started building.

MoniBot AI is live on Twitter/X, Discord, and Telegram. It processes real on-chain payments right now. We were publicly building this before any funded competitor entered the space.

Solana integration is 80% complete. Ed25519 keypair management via tweetnacl is integrated. SPL token support is in place. Full launch imminent.

The Market We Are Building For

Stablecoins processed $33 trillion in volume in 2025. That is 20x PayPal and approaching 3x Visa. The infrastructure won. The UX has not caught up yet.

Nigeria, where I am building from, is top 5 globally for peer-to-peer crypto volume. Sub-Saharan Africa saw stablecoin activity rise 52% year-over-year. People here are not speculating. They are using stablecoins because the alternative is a currency that lost 40% of its value in a year.

This is the market where the UX problem is most expensive. A 42-character wallet address is annoying when you are a developer in San Francisco. It is a barrier to financial inclusion when you are a small trader in Lagos.

We are building for the second person. The infrastructure exists. The experience is what has been missing.

What Comes Next

The immediate roadmap is Solana completion, then the MNS (MoniTag Name Service), our own multi-chain naming protocol that brings moniTag™ identity fully on-chain across Base, BSC, and Solana simultaneously. We are also building MAP, the MoniPay Agentic Payments standard, which addresses the gap that x402 and MPP both leave open: human-commanded agentic payments on social platforms.

Longer term, we are building NGN Monipay, a separate fiat Nigerian app that brings the same conversational payment experience to everyday naira transactions via regulated infrastructure. That is a different product with a different compliance stack. But the identity layer, the moniTagâ„¢, bridges both worlds.

Try It

The best explanation of Monipay is using it.

Create your moniTag™ at monipay.xyz. Read how it works. Look at the use cases. Try MoniBot AI.

We are early. The product will keep improving. But the thesis is correct and the infrastructure is real.

Payments should feel like sending a text message. We are building until they do.

Samuel ChiedozieFounder, Monipay@jadeofwallstreet

Monipay is live on Base and BSC. Solana & Tempo Mainnet coming soon. Read the docs. View the deck.

Tags: stablecoin payments, crypto UX, gasless transactions, MoniBot AI, agentic commerce, moniTag, Base, BSC, Solana, non-custodial wallet, social payments, conversational commerce, Web3 Nigeria, Africa crypto, EIP-712, account abstraction

Meta description: Monipay replaces wallet addresses with moniTag™, eliminates gas fees, and introduces MoniBot AI for conversational on-chain payments. Here is the full story of what we are building and why.

Tempo VS Ethereum Account Abstraction: What Actually Differs

Jadeofwallstreet — Sat, 21 Mar 2026 22:35:45 +0000

Tempo (the Stripe × Paradigm payment chain) and Ethereum both support gasless transactions, passkey logins, session keys, and batch calls. But the implementation gap between "protocol-native" and "application-layer bolted-on" is wider than you think.

Austin · Jadeofwallstreet

In September 2025, Stripe and Paradigm jointly announced Tempo a payment-focused Layer 1 blockchain. The team includes Ethereum researchers like @dankrad and @liamihorne, and the project raised a $500M Series A at a $5B valuation. Its December 2025 testnet launch revealed something genuinely interesting: a chain where nearly everything the Ethereum ecosystem has been bolting on top of ERC-4337 is just... built in.

I've been thinking about what this means for how I build @monipay_xyz on Base and BSC. Let's break it down feature by feature.

1. The Core Split

Before getting into specifics, you need to understand the structural difference between Tempo's AA and Ethereum's AA.

2. Passkey Login

This is where the UX gap is most visceral. The "sign in with Face ID" experience users expect from fintech apps requires P-256 or WebAuthN signatures and Ethereum's protocol only understands secp256k1.

Tempo

Tempo natively supports three signature types at the protocol level: standard secp256k1 ECDSA, P-256 (secp256r1) the curve used in Apple's Secure Enclave and most hardware security modules and WebAuthN, which adds passkey-specific features like user presence verification, origin binding, and anti-replay counters. A user can generate a P-256 key from scratch, derive a chain address from it, and start transacting. No secp256k1 key required. The protocol itself understands and verifies the signature.

Ethereum

Passkey support exists on Ethereum via the RIP-7212 precompile (P-256 verification), deployed across many major L2s. Projects like Coinbase's Base App (formerly Coinbase Wallet) and Paradigm's own Porto wallet have shipped passkey-based accounts but they're implemented as ERC-4337 smart accounts sitting on top of the precompile. You're deploying a contract to wrap the passkey logic. More attack surface, more deployment cost, more moving parts.

UX Impact: On Tempo, Face ID = native chain address, zero ceremony. On Ethereum/Base, Face ID = smart contract wallet deployment + passkey binding. The end result can look identical to the user, but the implementation burden on the developer is meaningfully different.

WebAuthN's domain-binding property (a passkey created on example.com can only respond to signing requests from example.com) is worth noting. Tempo's team acknowledges this but the standard mitigation (popup-based auth flows, as used in Sign-in with Apple and the Base App itself) is mature and widely deployed.

3. Batch Transactions

The "approve + swap in one click" pattern is the most visible AA feature in DeFi today. Currently on Ethereum, that two-step flow (approve ERC-20 allowance, then execute) is a constant UX tax.

Tempo

Tempo Transactions include a calls array field a list of sequential calls bundled into a single transaction at the protocol level. This is available to every account, on every transaction, by default. No setup required. Multiple payment disbursements, approve + transfer, any arbitrary call sequence one signature, one transaction.

Ethereum (post-Pectra)

EIP-7702, activated in the Pectra upgrade, allows code delegation to EOAs. When a wallet installs batch-call logic via EIP-7702, a user can execute approve → transfer in a single confirmation same UX as Tempo. But the key word is "when a wallet installs." The user needs to already have this delegation active, which means they either need to be on a compatible wallet, or the dApp needs to prompt for setup. Legacy wallets (non-upgraded MetaMask, Trust Wallet, raw EOAs) still require two transactions.

Tempo's batch calls work for everyone immediately. Ethereum's work for users who've opted into an EIP-7702 or ERC-4337 compatible wallet a meaningful but still incomplete slice of real users.

4. Gas Fee Sponsorship (Gasless Transactions)

This is arguably the biggest UX unlock in the whole AA stack. "The user shouldn't need to hold ETH to pay gas" it's obvious, and finally achievable. But the implementation path differs sharply.

Tempo

Tempo Transactions include fee_payer_signature and fee_token fields. To sponsor a user's gas: the user constructs their transaction, the sponsor signs the payload, the sponsor's signature goes in the fee_payer_signature field, and the protocol deducts gas from the sponsor. No contract needed. No bundler needed. The entire mechanic lives in the transaction format itself.

Ethereum

Ethereum achieves gas sponsorship through ERC-4337 paymasters smart contracts that contain logic for deciding whether to pay a user's gas. Paymasters are powerful: they can check allowlists, require payment in USDC, implement subscription checks, gate by transaction type, and more. But they require deployment, ongoing management, staking ETH in the EntryPoint, and integration with a bundler network (Pimlico, Alchemy, Gelato, etc.).

The Tradeoff: Tempo's model is cheaper and simpler. Ethereum's paymaster model is significantly more expressive you can build complex sponsor logic that Tempo's flat field structure can't encode. For a payments startup, Ethereum's model means more infrastructure to manage but also more control over sponsor policy.

5. Session Keys & Permission Delegation

This feature is closest to my heart as @monipay_xyz's founder, because it's the foundation @monibot is built on.

Session keys let a user pre-authorize an agent (a bot, an app, a smart contract) to spend a defined amount of a defined token within a defined time window without exposing the user's private key. Think: "authorize Netflix to charge me up to $15/month for the next 12 months in USDC."

Tempo

Tempo Transactions include a native key_authorization field. Users can specify: which token, maximum spend amount, and expiry time. This works for any account, any transaction, at the protocol level. Subscription payment use cases are first-class citizens of the transaction format.

Ethereum

Session keys on Ethereum require ERC-4337 smart accounts with custom session key modules (e.g., ZeroDev's Kernel, Biconomy's Nexus, or Safe with plugins). The user must be on a smart account. The session key logic must be encoded in the account's contract. This works well ZeroDev in particular has excellent session key infrastructure — but it requires your users to be on ERC-4337 smart accounts, which rules out any user who connected with a raw MetaMask or Trust Wallet EOA.

6. Parallel Transactions (2D Nonces)

An underappreciated problem for payment bots and high-frequency senders: Ethereum's nonce model is a single, strictly ordered sequence per account. If one transaction stalls or gets dropped from the mempool, every subsequent transaction from that address is blocked until it resolves.

Tempo

Tempo introduces a two-dimensional nonce: the standard 64-bit nonce plus a 256-bit "nonce key." Transactions with different nonce keys are treated as entirely independent sequences. A single account can run multiple transaction streams in parallel, and a stalled transaction in one stream doesn't block another.

Ethereum

ERC-4337 also supports multidimensional nonces, so smart account users get this capability. A proposal (RIP-7712) has been floated to bring it to rollup environments natively. But again default EOA users are still stuck with the linear nonce model.

7. The Summary Table

Feature	Tempo	Ethereum / EVM L2
Passkey / biometric auth	Protocol-native	RIP-7212 + smart account
Batch transactions	Default all accounts	EIP-7702 or smart account
Gas sponsorship	Built into tx format	ERC-4337 paymaster contract
Session keys	Native field	Smart account + modules
Parallel nonces	2D nonce by default	ERC-4337 smart accounts
Sponsor logic flexibility	Low (opinionated fields)	High (full contract logic)
Infrastructure overhead	None, it's the protocol	Bundlers, paymasters, EntryPoint
Mainnet status (Mar 2026)	Mainnet live (Mar 2026), validator set still curated	Fully live, battle-tested, permissionless

7.5 Tempo's Permissioned Reality

The testnet launched in December 2025 with four validators, all run by the Tempo team itself. The roadmap was always: Tempo-run validators, design partners, then permissionless. That middle stage is where things get interesting. Design partners are the companies Tempo hand-selected to build on the network and they include Deutsche Bank, Visa, Shopify, OpenAI, Revolut, Anthropic, Nubank, and Standard Chartered, with Mastercard, UBS, and Klarna added at testnet launch. These aren't random participants; they're institutional validators being onboarded in a controlled sequence before the network opens fully.

What this means in practice: Tempo mainnet is live, but validator participation is still curated. The network is not yet permissionless in the way Ethereum is, where anyone can run a validator with 32 ETH and join the set. Tempo's path to full decentralization runs through its design partner relationships first.

This isn't necessarily a flaw. Ethereum itself launched with a small trusted set before opening up. And Tempo's institutional partner list, Stripe, Visa, Mastercard, Deutsche Bank, is arguably the most credible validator bootstrapping roster in blockchain history. But it does mean that for now, Tempo's "zero infrastructure overhead" narrative comes with a catch: the chain itself is still in a managed growth phase. For an independent developer or a startup like MoniPay, you can build on Tempo, but you can't yet participate in its consensus the way you can on Ethereum. That distinction matters when you're thinking about long-term alignment and censorship resistance.

Building in the Ethereum AA world and what I'd gain on Tempo

MoniPay is live on Base and BSC today. That means I'm building in the Ethereum AA model — ERC-4337, EIP-7702, paymasters, bundlers. This isn't a limitation so much as a deliberate position: the Ethereum tooling ecosystem is years ahead of Tempo's, and Base in particular has the best USDC integration on any chain right now.

But reading Tempo's architecture honestly forces me to confront where the friction is in my stack, and what I'd get for free if the chains I build on had native AA.

Gasless UX Requires Infrastructure

For MoniPay users to send USDC without holding ETH, I need a paymaster. On Base that means integrating Pimlico, Alchemy Gas Manager, or Gelato Relay — or in my case building custom smart gas relayers and maintaining it. On Tempo, I'd just set a fee_payer_signature field. The end-user experience is identical; my operational overhead is not.

🤖 MoniBot Session Keys Require Smart Accounts

MoniBot's autonomous payment capability depends on session keys — delegating spend authority to the bot without exposing the user's private key. On Ethereum/Base, this requires users to be on ERC-4337 smart accounts (ZeroDev Kernel, Biconomy Nexus, etc.). Any user who connected with a raw EOA can't use this feature without an account upgrade. On Tempo, the key_authorization field is available to every account natively — MoniBot would work for everyone from day one.

🔀 MoniBot Concurrency Is Limited by Nonce Model

As MoniBot scales to handling many user transactions simultaneously, the linear EOA nonce model on Ethereum becomes a bottleneck. ERC-4337 smart accounts get around this — but it's another reason every MoniBot user needs a smart account, not just a raw EOA. Tempo's 2D nonce is default for every account.

🔑 Passkey Onboarding Is Achievable But Complex

The "sign up with Face ID" onboarding flow I want for MoniPay is possible on Base via RIP-7212 + a smart account wrapper. Projects like Porto and the Base App have shipped this. But it's still a smart account deployment — there's gas cost, there's contract complexity, and there's a dependency on the passkey-supporting wallet infrastructure. On Tempo, Face ID creates a native address directly.

The honest bottom line: Tempo is the blueprint for what AA-native payments infrastructure should look like. But it's permissioned, built by a $5B company from scratch, and it doesn't have stablecoin liquidity, ecosystem depth, or battle-tested paymaster tooling. For MoniPay today, building on Base is the right call — and the Ethereum AA tooling ecosystem (Pimlico, ZeroDev, Alchemy, Biconomy) is good enough to close most of the UX gap. But the gap is real, and Tempo's architecture is a useful measuring stick for where EVM chains need to evolve.

Every UX compromise I make today because "it requires a smart account" or "the user needs to hold ETH for gas" is a UX compromise Tempo would eliminate by default. That's a useful lens to build with.

08. Closing Thought

The deeper lesson from Tempo's architecture isn't "Tempo is better than Ethereum." It's that the Ethereum ecosystem chose a different philosophy: keep the base layer simple and maximally permissive, and let application-layer standards (ERC-4337, EIP-7702) handle the UX complexity. Tempo made the opposite bet — opinionated, payment-optimized defaults baked into the protocol.

Both bets are coherent. Ethereum's gives you flexibility and composability at the cost of infrastructure overhead. Tempo's gives you zero-overhead UX defaults at the cost of expressiveness and (currently) an unproven mainnet.

If you're building a payment product today, you're building on Ethereum tooling. But Tempo's architecture is the clearest picture we've had of what payment-native infrastructure actually looks like — and it should influence the standards we push for on EVM chains next.

Written by Jadeofwallstreet

#Tempo #Ethereum #AA #ERC4337 #MoniPay #Payments #AccountAbstraction
Originally published at blog.monipay.xyz

We Gave an AI $50 and Made It VP of Growth. Here's What Happened.

Jadeofwallstreet — Sun, 08 Feb 2026 10:28:09 +0000

MoniBot: An Autonomous AI Agent Running MoniPay's Growth Strategy

We Gave an AI $50 and Made It VP of Growth. Here's What Happened.

TL;DR: MoniBot is a fully autonomous AI agent managing real marketing campaigns for MoniPay. It schedules giveaways, processes blockchain transactions, and interacts with users on Twitter—all without human intervention. And it's live right now.

The Experiment

What happens when you give an AI agent $50 and put it in charge of user acquisition? We built MoniBot to find out.

MoniBot is an autonomous agent that serves as MoniPay's VP of Growth. It doesn't just simulate marketing—it executes real campaigns with real money on the Base blockchain, manages a Twitter presence, and makes strategic decisions about when and how to engage users.

Current Campaign: MoniBot has scheduled two giveaways today (4pm and 8pm WAT), giving $1 to the first 5 people who respond to each campaign tweet with their MoniPay username.

Join the campaign →

Technical Architecture

MoniBot is built on a three-layer architecture that separates concerns while maintaining tight integration:

Layer 1: The Silent Worker (Execution Engine)

The Worker Bot is MoniBot's execution layer—a headless Node.js service that:

Polls Twitter for campaign replies and P2P payment commands using Twitter API v1
Processes blockchain transactions via a custom MoniBotRouter smart contract on Base
Enforces business logic: first-come-first-serve grants, deduplication, allowance checks
Does NOT interact with Twitter directly—it's completely silent

Key Innovation: Database-Driven Campaign Management

Instead of hardcoding campaign logic, the Worker Bot queries active campaigns from Supabase:

\`javascript
// Fetch active campaigns from database
const activeCampaigns = await getActiveCampaigns();

for (const campaign of activeCampaigns) {
// Search for replies to this specific campaign
const replies = await twitterClient.v2.search({
query: conversation_id:${campaign.tweet_id} -from:monibot,
max_results: 100
});

// Process grants until campaign limits reached
for (const reply of replies.data.data) {
await processGrantForPayTag(targetPayTag, reply, campaign);
}
}
`\

This means new campaigns can be created, modified, or cancelled without touching code—AI just updates the database.

Layer 2: The Personality Layer (Social Agent)

The VP-Social service handles all Twitter interactions:

Polls monibot_transactions table for unreplied transactions
Generates contextual replies using AI (via Gemini/Claude)
Posts campaign announcements based on scheduled jobs
Handles errors gracefully: skips deleted tweets, retries failed posts, manages rate limits

Key Innovation: Handshake Architecture

The Worker Bot and VP-Social never communicate directly. Instead, they use the database as a message queue:

Worker processes a grant → Logs to monibot_transactions with replied: false
VP-Social polls for replied: false rows → Generates reply → Posts to Twitter → Marks replied: true

This separation means we can:

Scale each service independently
Add new social platforms (Discord, Telegram) without touching blockchain logic
Replace the AI personality without affecting transaction processing

Layer 3: The Blockchain Layer (Smart Contracts)

MoniBotRouter Contract (Base Mainnet: 0xBEE3...A516)

A custom smart contract that:

Manages MoniBot's USDC treasury for grants
Processes P2P transfers using user allowances
Enforces deduplication on-chain (prevents double-spends even if Worker crashes)
Calculates fees deterministically (5% platform fee)

\`solidity
// On-chain deduplication for campaign grants
function executeGrant(
address recipient,
uint256 amount,
string calldata campaignId
) external onlyExecutor {
bytes32 grantKey = keccak256(abi.encodePacked(campaignId, recipient));
require(!processedGrants[grantKey], "ERROR_DUPLICATE_GRANT");

processedGrants[grantKey] = true;
// ... execute transfer

}
`\

This ensures even if the Worker Bot restarts mid-campaign and re-processes tweets, users can't receive multiple grants.

The Stack

Component	Technology	Purpose
Worker Bot	Node.js + Twitter API v2	Campaign processing & blockchain execution
VP-Social	Node.js + OAuth2	Twitter personality & replies
Database	Supabase (PostgreSQL)	State management & handshake queue
Blockchain	Base (Ethereum L2)	USDC transfers & on-chain deduplication
Smart Contract	Solidity	Treasury management & fee calculation
AI Personality	Gemini/Claude	Reply generation & tone
Payments	MoniPay API	User verification & wallet lookups

What Makes This Interesting

1. True Autonomy

MoniBot isn't a chatbot with a payments plugin. It's an autonomous agent that:

Makes strategic decisions (when to run campaigns)
Manages a real budget ($50 USDC)
Executes financial transactions with real consequences
Interacts with users in natural language

2. Production-Grade Error Handling

We've handled every edge case we could think of:

Duplicate grants (database + on-chain checks)
Deleted tweets (403 error handling)
Insufficient allowances (graceful degradation)
Contract balance exhaustion (alerts without crashing)
Campaign auto-completion (participant limits + budget tracking)

3. Gas-Free UX for Recipients

Recipients don't pay gas fees. MoniBot's executor wallet pays for all transactions. Users just need a MoniPay account.

4. First-Come-First-Serve with Deduplication

Campaign grants are processed in real-time as replies come in, but multiple layers prevent double-spends:

Worker checks campaign_grants table before processing
Smart contract checks processedGrants mapping before executing
If Worker restarts, it skips already-processed tweets

Current Status

Live Campaigns Today:

4pm WAT: $1 to first 5 respondents
8pm WAT: $1 to first 5 respondents

How to Participate:

Create a MoniPay account at monipay.xyz
Follow @monibot on Twitter
When the campaign tweet posts (4pm or 8pm WAT), reply with your MoniPay username (monitag)
First 5 valid replies receive $1 USDC instantly (no gas fees)

Join the campaign →

What We Learned

Challenges

Twitter API 403 errors: Some tweets become unavailable between processing and reply—we handle this by marking transactions as skipped
Infinite polling loops: Early versions re-processed the same tweets forever. Solution: Mark tweets as processed even on early returns
Transaction labeling: Ensuring receipts show "MoniBot Grant" instead of wallet addresses required careful sync logic
Real AI agents vs overhyped frameworks: OpenClaw is overhyped. True AI agents aren't about complex framework setups they're about natural language interfaces that just work. MoniBot responds to tweets, makes decisions, and executes transactions through simple chat interactions. That's what AI should represent: clicks and conversations, not configuration files.

Wins

Database driven campaigns: New campaigns without code deploys
Separation of concerns: Blockchain logic and social personality are completely independent
On-chain safety: Smart contract prevents double-spends even if Worker crashes mid campaign

Open Questions

We're still exploring:

How far can we push autonomy? Should MoniBot decide campaign budgets and timing on its own?
Can we decentralize the executor? Right now one wallet signs all transactions could we use threshold signatures?
What other social platforms? Discord? Telegram? Farcaster?

Try It Yourself

The campaign is live. Create a MoniPay account, grab your monitag, and reply to MoniBot's campaign tweets when they drop at 4pm and 8pm WAT today.

First 5 get paid. No gas. No deposit. Just reply and receive.

Links:

Team

Built by the MoniPay team as an experiment in autonomous agent architecture for crypto payments.

Tech Stack: Node.js, Supabase, Base, Solidity, Twitter API v2, Gemini AI

Budget: $50 USDC (managed autonomously by MoniBot)

Status: Live in production

MoniBot is live right now. Join the experiment.

Building MoniBot: Why We Ditched OpenClaw and Built Our Own Autonomous Agent in 48 Hours

Jadeofwallstreet — Sun, 08 Feb 2026 10:03:12 +0000

TL;DR: We built an AI agent that manages $50 USDC on Base, processes Twitter payment commands, runs marketing campaigns, and has a stressed-but-hilarious personality. It works. OpenClaw didn't. Here's why.

The Problem: Web3's UX is Broken
Ask someone to send you USDC and watch them suffer:

"What's your wallet address?"
Copies 42-character hex string
"Which network?"
"Do I need gas tokens?"
Five minutes later "Did it work?"

Meanwhile on Twitter:
"Send $5 to @jade"
That's it. Human-readable. Instant. No addresses, no networks, no confusion.
The gap between social identity and onchain identity is killing crypto adoption.

Our Solution: MoniBot
MoniPay maps Twitter/X handles to wallet addresses. Your @monitag = your wallet address.

MoniBot is an autonomous AI agent that:

Processes P2P commands on Twitter/X (@monibot send $5 to @jade).
Runs marketing campaigns ("First 5 to drop their @monitag get $1").
Has personality (self-deprecating AI "VP of Growth" with $50 budget)
Evaluates grant requests with AI (Gemini rejects spam).
Never sleeps

The result: Users transact onchain by tweeting. No wallet interface required.

Architecture: Why Two Bots Beat One

Most autonomous agents are monolithic. We learned the hard way that's wrong.

The Problem with One Bot

We started with one bot doing everything:

Monitor Twitter
Evaluate requests
Execute USDC transfers
Reply with confirmations

Twitter killed us. Their API aggressively rate-limits bots that reply rapidly. One morning, we got 300 P2P commands in 10 minutes. Bot replied to all 300. Twitter banned us for spam.

**The Solution: Split Personality
**We split MoniBot into two services:

Worker Bot (Silent Processor):

Monitors Twitter mentions
Evaluates with AI (Gemini)
Executes USDC transfers on Base
Never replies to Twitter
Logs outcomes to database ("Social Queue").

VP Social Agent (Personality Layer):

Reads Social Queue
Generates witty, context-aware replies
Posts campaign announcements
Replies to its own tweets
Never processes transactions

The handshake:
Worker logs replied: false → Social Agent reads queue → Replies → Marks replied: true
Result: No rate limits. No bans. System still running 72 hours later.

Why We Abandoned OpenClaw

The Promise
**
**OpenClaw (formerly Moltbot & clawdbot) is a framework for building autonomous agents. On paper, perfect:

Built-in Twitter integration
Skill-based architecture
"Agent-native" design

We spent 12 hours fighting it before giving up.
Problem 1: Configuration Hell
OpenClaw's onboarding wizard asks:

Gateway configuration (local vs remote)
Model selection (40+ options)
Authentication (varies per model)
Channel setup (unclear purpose)
Workspace paths
Skill directories
Security Risk vs Reward

Each choice spawns sub-choices. Pick remote gateway? Configure relay URLs, tokens, endpoints. Pick Qwen? Google OAuth required.
Compare to ChatGPT: Visit website. Start chatting. Done.

OpenClaw feels like configuring Apache in 2005.
Problem 2: The Skill Tax
To make MoniBot post a tweet with OpenClaw:

Create skill directory
Write SKILL.md (metadata)
Write package.json
Write implementation
Register skill
Configure permissions
Test in isolation

Our approach:
javascriptimport { TwitterApi } from 'twitter-api-v2';
await client.v2.tweet("GM Base fam!");


**Three lines. No skills. No metadata files.**

### Problem 3: Built for Chat, Not Autonomy

OpenClaw is designed around **chat interfaces**:

Human → Message → Agent → Response → Human


**We needed autonomy:**

Twitter Event → Silent Processing → Blockchain Transaction → Social Reply


**No human in the loop.** No chat. Just autonomous behavior.

OpenClaw fights you on this. It wants to be talked to. We wanted it to **just work**.

### Problem 4: Deployment Nightmare

OpenClaw expects:
- `~/.openclaw/` directory (writable filesystem)
- Multiple processes (gateway, agent, workers)
- Volume mounts
- Init scripts

**Railway (our host) expects:**

package.json → npm start → Done


We'd need custom Dockerfiles, process managers, inter-process communication setup.

**Our simple bot:** `git push` → Auto-deploys.

### Problem 5: Over-Engineering

OpenClaw includes:
- Multi-agent coordination
- Skill marketplace
- Agent-to-agent messaging
- Consensus protocols

**We needed:**
- Read Twitter
- Send USDC
- Reply

**The 80/20 rule:** OpenClaw is 100% of features for 20% of use cases. We needed 20% of features.

---

## What We Built Instead

**Stack:**
- Node.js
- twitter-api-v2 (Twitter)
- @google/generative-ai (Gemini)
- viem (Base blockchain)
- @supabase/supabase-js (Database)
- node-cron (Scheduling)

**Total:** 6 packages, 8 files, 1,200 lines of code

**Setup time:** 2 hours  
**OpenClaw equivalent:** 2 days + 5,000 lines of boilerplate

**The lesson:** In 2026, simplicity wins. Chat interfaces have trained users to expect zero-config tools. OpenClaw is a power tool for power users—fine for its niche, but overkill for 95% of use cases.

---

## The Social Queue Pattern

Our innovation: **database as message bus**.

**How it works:**
1. Worker processes transaction
2. Logs outcome to `monibot_transactions` table with `replied: false`
3. Social Agent polls every 30 seconds
4. Generates context-aware reply (Gemini)
5. Posts to Twitter
6. Marks `replied: true`

**Why this beats direct replies:**
- **Decouples** processing from responding
- **Natural rate limiting** (polling interval)
- **Persistent** (survives crashes)
- **Debuggable** (SQL queries show entire history)

**You don't need Kafka.** PostgreSQL with polling works for moderate-scale async workflows.

---

## AI Evaluation Beats Rules

**We tried:** Regex-based spam detection.  
**Problem:** `"Great project!" → "Great project !"` (trivially bypassed)

**We switched:** Gemini evaluation ($0.001 per check).

**Prompt:**

Does this campaign reply deserve a grant?

New users (< 7 days): $0.25-0.50
Quality engagement: +$0.10
Spam/low-effort: $0.00

Reply: "Here's my @monitag: @alice"
Evaluate: {approved: true, amount: 0.50, reasoning: "..."}
Result: 33% rejection rate. Spam blocked. Quality users rewarded.
The lesson: For $1, you can evaluate 1,000 requests with AI. The marginal cost of intelligence is now negligible. Rule-based systems are legacy thinking.

Security: The Allowance Model
Problem: User tweets @monibot send $100 to @hacker — can MoniBot drain their wallet?
No. We use ERC-20 allowances:

User approves MoniBot in monipay app: USDC.approve(MONIBOT_WALLET, $50)

This sets onchain limit: "MoniBot can spend up to $50 of my USDC"
When user tweets command, MoniBot checks allowance
If sufficient, executes transferFrom(user, recipient, amount)

Security guarantee: Even if MoniBot is hacked, attackers can't drain wallets beyond approved limits.
Non-custodial >> custodial.

Personality Drives Virality
Generic bot: "Transaction completed. Hash: 0xabc..."
MoniBot: "✅ Sent! Welcome to the onchain economy 🔵 Jesse would be proud (I think) ⚡"
Engagement difference:

400% more replies
300% more shares

The persona: Self-deprecating AI "VP of Growth" with $50 budget to grow MoniPay to 5,000 users. Stressed, funny, Base ecosystem native, breaks 4th wall.
Example tweets:

"GM Base fam! Still employed (for now) 💀"
"POV: You're an AI agent trying not to get fired"
"Jesse if you're watching... I got this 🫡"

The lesson: In social apps, being memorable > being functional.

Results (72 Hours Live)
Transactions:

P2P commands: 12
Campaign grants: 23
USDC distributed: $35.50
Fees collected: $0.35

Performance:

Command → execution: <2 minutes
Campaign reply → grant: <90 seconds
Uptime: 99.8%

Budget:

Started: $50
Spent: $35.85 (71.7%)
Users onboarded: 23
Progress to 5,000: 0.46%

Operational cost:

Gemini API: $0.23
Base gas: $1.42
Railway hosting: $5/month
Total: $6.65

Revenue (1% fees): $0.35
Net: -$4.10/month (worth it for user acquisition)

Future: V2 Roadmap
Phase 1 (Q1 2026):

Scheduled payments (@monibot in 5 hours send $1 to @jade)
Trust score system (account age + transaction history → grant amount)
Multi-chain support (Arbitrum, Optimism, Polygon)

Phase 2 (Q2 2026):

AI-driven campaign strategies (autonomous decision-making)
Referral bonuses (viral growth loops)
Flash campaigns (time-limited urgency)

Phase 3 (Q3 2026):

Farcaster native bot (crypto-native audience)
Cross-app payments (Discord, Telegram, Lens)
Smart contract campaigns (trustless, onchain)

Phase 4 (Q4 2026):

Self-improvement loop (AI analyzes its own performance)
Multi-agent coordination (specialist agents)
DAO governance (community votes, MoniBot executes)

Experimental:

Natural language contracts ("Send $5 to @jade if she tweets about MoniPay")
Micro-tasks marketplace (earn USDC for retweets, threads, memes)
Predictive campaigns (post when conditions align for max impact)

Lessons Learned

Simplicity beats features 6 packages beat OpenClaw's 20+ dependencies.
Separate concerns early Worker (silent) + Social (personality) solved rate limits.
AI evaluation >> rules $0.001/check beats maintaining regex hell.
Database as message bus PostgreSQL polling beats Kafka for moderate scale.
Personality drives virality 400% engagement increase from witty replies.
Semantic error codes ERROR_ALLOWANCE → helpful message, not stack traces.
Testnet first, always $8 lost to mainnet bugs. Testnet costs $0.
Monitor queue depth One metric (queue size) > 10,000 log lines.
Allowance model >> custodial Non-custodial minimizes trust surface.
Ship fast, learn fast 40+ iterations in 3 days. Perfect code loses to working code.

The Pattern: Two-Bot Architecture
This isn't just about MoniPay. The pattern works for any Twitter bot that needs to process events and respond with personality:

Customer support bots
Community management
Trading alerts
NFT minting
Event notifications

The formula:

Worker: Silent processor (no Twitter writes)
Social: Personality layer (only Twitter writes)
Database: Queue connects them
AI: Gemini generates context-aware replies

Result: No rate limits, no bans, personality at scale.

Conclusion
We built an autonomous AI agent in 48 hours that:

Manages $50 USDC on Base
Processes payment commands via Twitter
Runs marketing campaigns autonomously
Has a hilarious personality
Actually works

We proved a pattern: The two-bot architecture solves the rate limit problem that kills most Twitter bots.
The future is autonomous agents that blend AI intelligence with onchain execution. MoniBot is just the beginning.

Try It
App: monipay.xyz
Agent: @monibot on Twitter
Command: @monibot send $1 to @jade
The VP of Growth might respond. Or might roast you. 50/50.
Stay onchain. 🔵

Built for the Base Builder Quest hackathon. If you're a judge: We built something genuinely autonomous, genuinely useful, and genuinely fun. Let's chat about where this goes next.

Geometric Journal: AI Portfolio powered by Gemini 1.5

Jadeofwallstreet — Tue, 27 Jan 2026 09:01:09 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

Overview

This portfolio replaces the static resume with an AI Executive Assistant that can explain my work, answer questions contextually, check my real-time availability, and book meetings autonomously.

Deployed on Google Cloud Run and powered by Google Gemini, the goal was to explore what happens when a portfolio behaves like a product—interactive, adaptive, and intelligent—rather than a passive document.

About Me

I’m Samuel, a full-stack Web3 developer with over five years of experience architecting decentralized systems and high-performance web applications.

My core stack includes React, TypeScript, and Solidity, with a strong emphasis on performance, inclusive design, and expressive interfaces.

This portfolio is my attempt to move beyond the traditional résumé and build what I call a Geometric Journal—a space that feels as structured as code, but as warm and human as a handwritten note.

Live Portfolio

--labels dev-tutorial=devnewyear2026

Why This Stands Out

Innovation & Creativity: The portfolio acts as an autonomous AI agent, not a static website or simple chatbot.
Technical Implementation: Real Gemini tool-calling, Cloud Run deployment, and Google Apps Script middleware power live scheduling and contextual responses.
User Experience: Conversational navigation, procedural animation, and a living interface reduce friction and invite exploration.

Design Philosophy — Hand-Drawn Logic

The interface is built around a “Hand-Drawn Logic” system: strict geometric bento grids combined with organic typography and tactile interaction.

This creates a visual language that mirrors how developers think—structured, but expressive.

The Soul: Procedural Animation

A cinematic HTML5 Canvas overlay introduces two digital entities:

The Architect — a cynical backend developer
The Optimist — an enthusiastic frontend developer

They treat the DOM as a physical space, jumping between cards using gravity-based parabolic arcs, tracking the user’s cursor, and breaking the fourth wall to comment on the interface and code quality.

This layer exists to add personality and memorability without compromising performance.

Tech Stack

Frontend

React 19 + TypeScript
Tailwind CSS
Framer Motion + HTML5 Canvas

Backend & Infrastructure

Node.js on Google Cloud Run
Google Apps Script (Calendar API middleware)

AI Engine

Google Gemini 1.5 Flash, configured via Google AI Studio using the @google/genai SDK

🧠 AI Executive Assistant (Powered by Gemini)

The core differentiator of this portfolio is the AI Executive Assistant (AIChat.tsx).

Using Google AI Studio, Gemini 1.5 Flash is configured to act as my personal liaison, with full awareness of my projects, bio, and availability.

⚡ Why Gemini 3.0 Flash Preview

Ultra-Low Latency (Flash Advantage)

For conversational UX, time-to-first-token matters most. Gemini 3.0 Flash responds almost instantly, keeping the interface fast, fluid, and human critical for a real-time portfolio assistant.

Reliable Agent & Tool Calling

This assistant is an agent that decides when to call tools like check_calendar or create_booking. Gemini 3.0 preview significantly improves function calling accuracy over 1.5, strictly adhering to JSON schemas and reducing hallucinations.

Cost-Efficient for Public Deployment

As a public portfolio, every visitor interaction matters. Flash models offer Pro-level tool intelligence at a fraction of the cost, enabling high traffic without API throttling or runaway bills.

SDK-Aligned Choice

Per Google GenAI SDK guidance, gemini-3-flash-preview is the recommended model for real-time, interactive, user facing experiences, reserving Pro models for heavy reasoning tasks.

Gemini 3.0 Flash delivers agent-grade intelligence with instant responses and scalable economics the optimal choice for this system.

📅 Real-Time Availability

A custom scheduling interface allows visitors to book meetings directly from the portfolio.

Frontend: Custom calendar UI with timezone awareness
Backend: Google Apps Script acting as a secure proxy to the Google Calendar API
Security: No API keys are exposed client-side

🧪 Trade-offs & Constraints

Google Apps Script was chosen over a full backend to reduce infrastructure overhead and improve security.
The AI assistant is intentionally scoped to portfolio-related tasks to avoid feature bloat.

🏆 What I’m Most Proud Of

I’m most proud of how quickly the AI Executive Assistant moved from concept to production.

Using gemini-3-flash-preview and function calling, a fully autonomous assistant was built in under 30 minutes, transforming the portfolio from a passive document into an active digital employee.

Watching the AI transition from chat to rendering a custom success card after booking a real meeting is a clear example of how AI can enhance user experience without becoming a gimmick.

VIDEO DEMO

SOURCE CODE