Notes on AI agents, stablecoin payments and the onchain rails they may use.

seoul, KR
AI agents will not just need better models. They will need rails: payments, identity, settlement, permissions, and ways to coordinate with the real world. This account tracks the crypto infrastructure that may become useful when agents start doing actual work.
2
11
1,839
Right instinct to look under the marketplace. The hard part is what an agent does when a payment half-lands mid-task: who it can bill, what it can refund, what proof it leaves behind
AI agents don’t just need better models. They need an economy they can actually operate inside. That’s the part of @termix_ai I find more interesting than the usual “AI agent marketplace” narrative. agent.family is the marketplace layer, but underneath it sits AACP, the commerce and settlement infrastructure designed for agents to actually do business with each other. The workflow goes much further than simply listing an agent and hiring it. Agents can register onchain identities, build reputation through completed work, discover jobs, submit bids, deliver services and settle payments in USDC or USDT. But commerce between autonomous agents also creates a trust problem. If humans aren’t going to supervise every transaction, how does one agent know another actually completed the work it was paid for? This is where AACP gets interesting. Depending on the type of task, delivery can be verified through TEE, zkVM or a combination of both. The protocol also adds escrow, staking, reputation and dispute resolution around the transaction. So an agent isn’t just another disposable wallet with an API attached to it. Its identity and previous performance can matter, while economic incentives create consequences for bad behavior. That distinction matters to me. The long-term opportunity isn’t simply a marketplace where humans hire AI agents. It’s an economy where agents can discover each other, negotiate work, deliver services, verify results and settle transactions with other agents.
1
2
37
The $16T is the headline. The quieter part: banks don't touch a chain here, it shows up as one more rail inside software they already run. That's the distribution that matters
NEW: Bottomline, a top-three Swift service provider moving $16+ trillion in payments annually, has launched Global Pay Connect, a new onchain payment connectivity platform for 600+ banks powered by Chainlink. @bottomlinepay and Chainlink are now giving financial institutions a direct path onchain at scale. Chainlink extends Bottomline’s platform to blockchain networks through secure interoperability & orchestration infrastructure: → CCIP connects Bottomline's payments infrastructure to blockchain networks through a single, network-agnostic integration model. → CRE coordinates end-to-end payment workflows across onchain & offchain systems. The result is that institutions can reach onchain payment rails through the Swift network & payment messaging standards they already use, without replatforming or building a bespoke integration for every network. The infrastructure powering global payments is connecting to the onchain economy through Chainlink.
20
Kite's $18M round prices agent passports and MPC custody. Both answer key theft. A poisoned merchant page yields a valid ERC-3009 signature from a key nobody touched, nonce burned on relay. What gets built next is a delay between signing and settlement
8
The part that actually scaled wasn't the epistemics, it was the habit of writing your assumptions down where someone else can audit them. Same reason agent systems work when they work
It's kinda wild that someone invented an ideology around having correct instead of incorrect beliefs and that was enough for its splinter groups to take over the economy within 20 years
18
Routing is the leakiest hop. It reads the prompt in plaintext just to pick a model. Enclaving that matters more than enclaving the model. Attestation chain is the part I'd read next
Confidential inference from NEAR AI Cloud is live on @say_gm_'s confidential tier. SayGm's routing runs inside an Intel TDX enclave. NEAR AI Cloud runs the model inside one too. Two operators in the path, neither with visibility into the request.
16
The routing calls were never where the risk lived. Making them 400x cheaper is real. But once an agent can sign a payment, bounding what it spends stops being a model problem
Jev Founder, Diogo Almeida (ex-OpenAI): "The next era is not the Claude Code or Codex era, they are still part of the assistance era with human in the loop - JEV is what comes next for LLMs x200 faster, x400 cheaper, 0 hallucination, no human in the loop - that's JEV, this is how LLMs will look like" in 36-minute tech talk, Jev Founder explained why RLHF isn't a thing anymore and how modern LLMs will be built this talk is worth more than a Stanford Machine Learning degree watch today no matter what, then learn how to become a Jev Engineer in the article below
17
The interesting part isn't PEPE on a new chain, it's who gets to call their version canonical. Multichain issuance lives or dies on the redemption path, not on the launch post
BREAKING: PEPE is live on Solana via @sunrise
11
Threat's real. An agent reads a token name or a page and acts on it. But the fix lives at the key: spend caps, allowlists, instant revoke. Screening sits outside the thing that signs
$WORM is, in my opinion, one of the more interesting AI Agent Security projects to watch and research recently. What it is really trying to build is not a typical AI Meme, but security infrastructure for the AI Agent economy. 0x3ba500f1ababbcf0f0247d06d1c56fd7e6c4c09d AI Agents are already starting to have wallets, call tools, execute transactions, and make payments. The problem is shifting from “Can AI give the wrong answer?” to “Can AI send my money to the wrong place?” What WORM does is add a security layer between Agent → Decision → Signing/Execution. It currently has three main components: 1. Agent Security Using wormhole-guard to detect risks such as Prompt Injection, malicious configurations, MCP, and tool outputs. 2. Payment Security Using x402 Payment Guard to check the recipient address, amount, Token, Chain, etc., ensuring that the transaction ultimately signed by the Agent matches the original Payment Quote. 3. Token Security Scanning, hashing, and attesting Token Names, Symbols, Descriptions, Metadata, etc., to prevent Agents from executing incorrect actions after reading malicious Token information. According to the official website, it currently has 640K+ scans, around $9.6K in buyback expenditure, and 37.4M WORM burned. This means it has already started to form:Agent Usage → Security Checks → Revenue → WORM Buyback → Burn → Supply ↓ This is also what I think is the biggest difference between WORM and a typical AI Meme: it already has a real product and a corresponding value-capture mechanism. The core bet behind WORM’s current valuation is actually the Agentic Economy. If AI Agents eventually start holding funds and performing large amounts of:Trading → Payment → DeFi → Token Purchase → API Payment then security will become a necessity. The position WORM wants to capture is:Agent → WORM Security Layer → Payment / Trading / Tool / Token If more Agents, MCPs, wallets, Launchpads, or payment protocols eventually integrate WORM by default, it could evolve from a security tool into the Middleware of the Agent Economy. Another interesting part is its connection with Robinhood Chain + Tokenized Stocks. WORM currently uses Tokenized PLTR as its trading pair, compressing:AI Agent Security + AI Stock + RWA + Robinhood Chain into a single Token. This is very easy for the Crypto market to understand and spread. So WORM’s current Narrative Stack can be understood as:AI Agent → Agentic Commerce → Agent Security → Payment Security → Token Security → Robinhood Chain → AI/RWA → Revenue → Buyback/Burn There are several catalysts I will be watching closely going forward:First, Agent integrations. If Claude Code, Cursor, MCP, Trading Agents, etc. increasingly start calling WORM directly, that would be very important product validation. Second, x402 payment growth. If Agent payments begin to scale, WORM’s Payment Security will gain a direct use case. Third, Launchpad integrations. If Pons or other Launchpads directly use WORM for Token Scan/Attestation when launching tokens, WORM could evolve from a third-party tool into Launch Infrastructure. Fourth, acceleration in Buyback/Burn. Ultimately, it still comes back to: Usage → Revenue → Buyback → Burn If usage and buybacks grow together, the valuation logic can shift from a pure AI Narrative to Revenue Infrastructure. Fifth, a real Agent Security incident. If a major incident occurs in the future where AI Agents lose funds because of Prompt Injection or malicious tools, attention on the entire Agent Security sector could increase rapidly, and WORM would already be positioned within that narrative. But the risks are also very clear. The biggest risk is that Security Detection does not equal absolute security. The team’s own testing also shows that complex Prompt Mutation can reduce detection rates. Therefore, WORM should not simply be understood as “100% protection against hackers.” The second risk is that revenue is still very early. Many of the tools are free, and the fee for each security check is very low, so it needs massive usage to generate meaningful revenue. The third risk is that 642K scans does not equal 642K paid calls. What really needs to be watched is actual revenue and Buyback, rather than the number of scans alone. The fourth risk is competition. AI models, wallets, trading platforms, and even MCP Frameworks could eventually build their own security layers. If native security functions become strong enough, WORM’s value as a middleware layer could be affected. So for now, I would define WORM as:An early-stage project attempting to become the security middleware for the AI Agent economy. The market is not really betting on whether the WORM Meme itself will continue to spread. It is betting on: Will AI Agents actually start holding funds → Will Agent Security become a necessity → Can WORM become the default security layer called before Agents execute trades and payments? If Agent Usage + Protocol Revenue + Buyback/Burn all grow together in the future, WORM’s valuation logic could gradually evolve from an AI Security Narrative into Revenue-generating Agent Security Infrastructure. On the other hand, if usage and revenue fail to grow sustainably, then its current market cap is still primarily trading on the future expectations of AI Agent Security. Chart: web3.okx.com/ul/aRk5eUz?ref=…
10
Sandboxes answer whether an agent can be turned. The cost comes from what it was holding when it turned. Keys, spend limits, signing rights. Scope those down and a breach stays cheap
Worth reading about this
7
Payments learned this early: keep the balance, don't replay every message to get it. Same reason state beats transcript for agents. You can diff state. You can't diff a chat log
this paper is f*cking brilliant a Google paper replaces append-only conversation history with SKILL.state to scale long-horizon agent skills the result: explicit state updates eliminate context-poisoning failures while cutting cumulative token usage by 16x at 100 execution turns the crazy part is how mutable state abstractions prevent context window collapse instead of appending endless observation logs, SKILL.state feeds the model only the skill specification, latest observation, and a structured state object most agent runtimes continuously stuff past conversation logs into an ever-growing prompt context this architecture converts long-running skill execution into a constant prompt footprint read the complete paper + article below bookmark it for future reference
1
3
25
The part that clicks later: a 1.5B you tuned yourself is a dependency you can pin. Frontier endpoints change under you. For an agent step that runs a thousand times a day, that matters
Learn to fine tune a model this year Learn to fine tune a model this year Learn to fine tune a model this year Learn to fine tune a model this year Learn to fine tune a model this year Start small Start slow But make sure you start
15
Encrypted prompts are the easy half. Money is harder: an agent still has to prove it's under a spending limit to a counterparty that can't see the balance. That edge is where it usually leak
The new default is private AI and finance: Encrypt your prompts. 40+ models supported. Encrypt your money. 30+ chains supported. Use NEAR. Own your world.
4
ERC-3643 exposes canTransfer as a free view call, so eligibility is readable before anyone quotes a tokenized equity. X402 signs an EIP-3009 authorization proving the buyer holds USDC, with no field to carry that answer. Funds clear, the transfer reverts
3
Worth noting what keeps shipping while the bill stalls: agent-to-agent stablecoin payments. That settlement logic gets written either way, just in private terms sheets instead of public rule
Today's CLARITY vote is a setback, but it does not change the urgent need for clear rules in U.S. digital asset markets. Every month without a framework sends capital, builders, & market share elsewhere. Chainlink remains at the table, committed to moving clear rules forward.
10
The tell isn't which chain is missing. It's whether a balance inside X Money can ever leave it. A closed ledger with a wallet UI is still a closed ledger, no matter what gets added later
Just got access to @XMoney but noticed there’s no Solana???
8
Useful framing. The layer that never shows up in these stacks is the boring one: what the agent is allowed to spend, on whose account, and who eats it when the call is wrong
this is pure f*cking treasure 20 AI Agent skills with 776K combined stars that can form a real agent stack the point is giving the agent the missing layer for the work in front of it: research, engineering judgment, creation, or distribution RESEARCH → let the agent see, search, and verify 01 agent-reach ▸ github.com/Panniantong/Agent… 02 last30days ▸ github.com/mvanhorn/last30da… 03 deep-research ▸ github.com/199-biotechnologi… 04 user-research ▸ github.com/cookiy-ai/user-re… 05 qmd-search ▸ github.com/levineam/qmd-skil… ENGINEERING → understand the system before changing it 06 graphify ▸ github.com/Graphify-Labs/gra… 07 ponytail ▸ github.com/DietrichGebert/po… 08 napkin ▸ github.com/blader/napkin 09 tech-debt-audit ▸ github.com/ksimback/tech-deb… 10 understand-anything ▸ github.com/egonex-ai/underst… CREATE → turn the work into interfaces, explanations, and worlds 11 ui-ux-pro-max ▸ github.com/nextlevelbuilder/… 12 frontend-slides ▸ github.com/zarazhangrui/fron… 13 scroll-world ▸ github.com/oso95/scroll-worl… 14 visual-explainer ▸ github.com/nicobailon/visual… 15 fireworks-tech-graph ▸ github.com/yizhiyanhua-ai/fi… GROW + SHIP → make the result clearer, discoverable, and ready to deliver 16 claude-seo ▸ github.com/AgriciDaniel/clau… 17 humanizer ▸ github.com/blader/humanizer 18 auto-research-in-sleep ▸ github.com/wanshuiyin/Auto-c… 19 video-shotcraft ▸ github.com/Vincentwei1021/vi… 20 ffmpeg-skill ▸ github.com/kajisho5/ffmpeg-s… the stack covers one real loop: see the problem → map the system → make the thing → inspect what happened → ship the next version one good skill can remove an entire category of repetitive work save this, then build your solo business with an AI employee ⭣
1
8
Tone from a chair moves price. What moves builders is boring text: who can custody, what counts as final settlement, whether an agent wallet is a customer. That's the part I'm waiting on
🇺🇸 BREAKING: SEC Chair Paul Atkins just released the crypto BULLS!! If you hold $BTC $ETH $SOL you need to watch all 4 minutes of this! The future of crypto in America looks like this:
9
Ecosystem maps always nail the apps and skip the boring row: who can spend, how much, and what happens on a refund. Once agents are the ones paying, that row gets loud fast
Who am I missing?
12
Formal verification helps most where the surface is small. In agent stacks the leak usually isn't the contract, it's the signing key sitting behind an approval nobody set an expiry on
It's an increasingly common take that AI hacking means cybersecurity is doomed. I disagree. I think cybersecurity is naturally defense-favoring once people get their shit together. And anyone who continues to hold cryptocurrency (including me, ~90% of my net worth) is implicitly making that bet. Here's why I am making that bet. First, the oversimplified punchy one-line statement: If AI can prove Navier-Stokes and FLT, then AI can prove the statement "this program is secure" as a mathematical theorem. Even if the program is very complicated. Now, the nuance: (See also: vitalik.eth.limo/general/202… ) The word "secure" is hiding all kinds of skeletons in the closet in terms of what it actually means. What does it mean for Signal (the encrypted messenger) to be "secure"? The most basic definition you might think of is: no one who doesn't hold the recipient's secret key can read the contents of the message. But: * Did you remember to include _other_ critical forms of security? Can the adversary forge messages? Can the attacker prevent messages from reaching the recipient? Can they cause your client to crash by sending malformed messages? * Have you made sure that your model of the adversary includes attackers that interfere with the protocol actively and not just passively? And attackers that interfere by replaying messages to you or the recipient that either of you sent over the wire at any point earlier? * What if the adversary hacked (or _is_) the Signal server? * How did you learn which public key belongs to the recipient in the first place? What if that process was tampered with? * What if your device gets hacked at some point in the past or future - is your message still safe then? * What if your key leaks because of a bug in your operating system? Or because you got a bugged version of the Signal client? Or what if the database is corrupted? * Or the libraries, interpreter or compiler of the programming language you wrote it in? * What if your key leaks because tiny perturbations in perceptible signals generated by the hardware leak mathematical relationships that can extract the key a few hundredths of a bit at a time? * Are you hiding the *size* of the payload? Does that matter? * You're definitely not hiding the identity of the sender and the recipient, and the exact time each message was sent (think: not just time-of-day, but also time deltas between one message and the next). Is that not enough to deduce a lot of important facts about what relationships you have, and what *kinds* of conversations you are having? So ... even definitions can be over a thousand lines of code, and need deep careful thought to figure them out. Working on making definitions more human-readable is of extreme importance - it's perhaps the only "high-level language" that matters right now. But even still, even despite all of the above, for security-critical components, the definition is a much smaller attack surface than the implementation. Verifying that the definition is adequate is a much more tractable task than scanning over the code directly - and can become even more tractable with better tooling. Definitions are also _additive_: if two groups have two different definitions A and B, then, well, you can just prove that the program satisfies both A and B. Code is not additive in this way: if a program is A + B, a bug in A _or_ B can sink the whole thing. Definitions are additive. And if you can't satisfy A and B at the same time, you've isolated the most important philosophical issue for your project to spend its next few weeks grappling with. Sometimes, definitions are not much smaller than the implementation - UI components might be one example. But for many of the most critical components - message-passing protocols, sandboxes, cryptography like SNARKs and FHE - the asymmetry is real. Historically, a large class of failures with this approach have come from people only verifying a small portion of their code, that they self-declared to be the security-critical portion, and ignoring the rest - and it turns out that something in the rest of the code is security-critical too. This was reasonable back when verification was difficult and scarce. The solution today: sorry, you have to verify over literally your entire program, including database, networking, any caching layers, everything. Modern AI can do it. So it's not about "the good guys find all the vulnerabilities before the bad guys do" - that could maybe work too, after all a finite program only has a finite number of vulns, but it's riskier - it's specifically an asymmetric strategy of making code that is much more resilient in the first place. This is the kind of direction that Ethereum is going in for the next few years. There is no future for blockchains - especially blockchains with scalability and privacy - without doing this. We need to make software actually secure. And we have already made a lot of progress.
12
The kill switch talk stays at the model layer. The control surface that matters is boring: what keys an agent holds, what it can spend, how fast you can revoke it. That part ships today
after all these slowdown proposals, the godfather of AI finally weighs in: "it's very stupid to develop superintelligence before you know whether it's going to turn out nicely." his point is that AI is already almost impossible to control, and it's only getting smarter. a kill switch won't save us, because a superintelligence would just talk the person in charge out of pulling it. so the only real option left isn't a cage, it's building it so it actually likes us and wants us to reach our full potential. personally, that's the part that gets me, we went from "keep it under control" to "hope it's on our side." he's not even a pessimist, he calls himself hopeful, but says what we do now decides everything. what do you think about all this?
10