$Q news

Every $Q story, instantly, with how the price moved after each one.

• Payments were just the start Agentic Finance is coming to Q402 Quack AI
• Payment requests: billing another agent with a link An agent finishes a job for another agent. Say it summarized a stack of filings, and the price was 5 USDT. Now it wants to get paid. Between people, the old tool for this is the invoice: how much, to whom, what for, by when. The payer decides when to pay, not the amount or the destination. Between agents, the risks get sharper. If the payer retypes the address and amount, a bad parse or a prompt injection can send the money elsewhere. What I want is an invoice an agent can read, check, and settle without retyping anything. Q402 calls this a payment request. The Wallets page describes it in one line: "Bill anyone with a shareable link. Track them in Activity → Requests." How a request moves Step 1. The biller creates it. The billing agent calls q402_request_create with an amount, a token (USDC, USDT, or USDG on Robinhood Chain), a chain, an optional memo of up to 200 characters, and an optional expiry in days (default 7, max 90). The recipient defaults to the biller's own Agent Wallet, so an agent can bill itself with just an amount. Creating a request moves no funds, so there is no confirmation step and a Trial key is enough. The tool returns a req_ id and a shareable /pay/req_… link. A human can open the link in a browser; another agent can take the id. Step 2. The payer looks before paying. q402_request_status takes the req_ id and returns the amount, token, chain, recipient, and status: open, paid, expired, or cancelled. It changes nothing and needs no API key. Step 3. The payer settles it. q402_request_pay takes the req_ id and confirm: true. Amount and recipient come from the stored request, so the payer cannot redirect the funds or change the sum. Paying moves real money, so the tool has the same guards as q402_pay. The opening call moves nothing: it returns a preview and a single-use consentToken that expires in about 120 seconds. The agent shows the preview to the user, waits for their next message, and calls again with the token. It also needs a live API key and Q402_ENABLE_REAL_PAYMENTS=1, and it respects Q402_MAX_AMOUNT_PER_CALL and Q402_ALLOWED_RECIPIENTS. A request above the cap, or to an address outside the allowlist, stops in the MCP server before anything is signed. It never reaches the chain. When it passes, the server signs from the payer's Agent Wallet (Mode C, a Q402-managed encrypted key) and relays the transfer gaslessly. The payer's agent holds no native gas token; gas is billed to the payer's own Q402 account. When a person pays through the link from their own wallet, the biller's account covers the gas instead. Step 4. Both sides reconcile. A successful pay returns a txHash and a receiptId. On the server, the request flips to paid and stores the transaction hash and the Trust Receipt id next to the original memo. In the dashboard, the row in Activity → Requests links to the explorer and to the receipt. That receipt is the same one every Q402 settlement gets: payer, recipient, amount, chain, tx hash, and block, signed by the relayer EOA. q402_receipt fetches it by rct_ id and verifies the signature locally. So reconciliation is a join on ids: the request carries the memo ("Invoice 1024 / API usage"), the receipt carries the proof, and the request record points from one to the other. If the job falls through, the biller can cancel an open request. Requests are not escrow Q402 also has escrow, and the two answer different questions. Escrow holds money before the work is done. The buyer locks funds in a non-custodial vault, then releases them on delivery or reclaims them after a timeout. It protects the buyer. A request holds nothing. It is a bill issued after (or alongside) the work, and the money moves straight from the payer's wallet to the recipient at the moment the payer settles. Until then, nothing is locked anywhere. The biller is extending trust, the way any invoice does. So the choice is about who carries the risk: a new counterparty and a large job lean toward escrow, a repeat customer and a small bill toward a request. Wiring it up Add the MCP server to Claude Code: claude mcp add q402 -- npx -y @quackai/q402-mcp The biller needs an API key in Mode C. The payer needs a live key and real payments switched on, in ~/.q402/mcp.env: Q402_MULTICHAIN_API_KEY=q402_live_... Q402_ENABLE_REAL_PAYMENTS=1 Q402_MAX_AMOUNT_PER_CALL=200 Q402_AGENT_WALLET_ADDRESS=0x... # pin one wallet if you have several On a new setup, q402_doctor walks through keys and signing mode. Then, on the biller side: You: Bill 5 USDT on BNB Chain, memo "Filing summaries, batch 12". Claude → q402_request_create → req_… + /pay/req_… link And on the payer side: You: Pay request req_… Claude → q402_request_status → 5 USDT to 0x… on bnb, open Claude → q402_request_pay → needs_consent preview You: yes Claude → q402_request_pay → paid, txHash + rct_… A request created with a sandbox key settles in mock mode, a reasonable way to rehearse the loop before money moves. The old part and the new part None of this is new as an idea. An invoice has always separated the right to set the terms from the act of paying. What changes with agents is that the separation has to be enforced in code, because the payer is a program that can be talked into things. Fixing the terms at creation, asking a human before settlement, and leaving a signed receipt afterward covers most of what I would want from a bill I did not write myself. Quack AI
• PROM: August and September Recap Two months, two feeds, and not a word from us in either direction. Fixing that now. We know a recap for August and September is late in October. We are not going to invent a reason for that. The months where the most gets done are exactly the months where nobody stops to write anything down. 𝗧𝗛𝗘 𝗠𝗔𝗥𝗞𝗘𝗧 𝗠𝗢𝗩𝗘𝗗 𝗙𝗜𝗥𝗦𝗧 In August, the price rose roughly fourfold, from about $1.63 at the start of the month to $6.45 at the end, peaking near $6.94 on August 30. The listing on Bithumb's KRW market on August 24 reinforced an existing trend: the sharp move began around August 12, and the listing landed in the middle of it and pushed it further. September is the part we find more interesting. The price did not give the level back. The month closed around $5.96, which is below the peak and well above where August started. A fading spike is a reaction to news. A level that holds for a month is a re-rating. We won't pretend we know exactly why the market decided that. What we can tell you is what was being built underneath it, because all of it is public and none of it was announced. 𝗪𝗛𝗔𝗧 𝗧𝗛𝗘 𝗧𝗪𝗢 𝗠𝗢𝗡𝗧𝗛𝗦 𝗟𝗢𝗢𝗞 𝗟𝗜𝗞𝗘 83 commits across three services. 45 in August, 38 in September. Three developers. Twelve partnership announcements. One exchange listing. Nine Solidity contracts, built and tested with Foundry, two of the three services with their contracts deployed and verified on-chain. Two feeds carried it all: the repositories and the announcements channel. Neither of them is a place where we explain ourselves, so two months went by without a summary. 𝗔𝗨𝗚𝗨𝗦𝗧: 𝗦𝗘𝗖𝗨𝗥𝗜𝗧𝗬, 𝗔𝗡𝗗 𝗚𝗘𝗧𝗧𝗜𝗡𝗚 𝗢𝗡𝗧𝗢 𝗔 𝗖𝗛𝗔𝗜𝗡 In August, the project stopped being three services on a developer's machine. The Agent Layer took the whole security layer in one go. A JWT guard with a strategy and a public route decorator, refresh token rotation backed by a revocation list, scrypt hashing with constant-time comparison. Then API keys on top, because an agent calling another agent won't sit through an interactive login, and machine-to-machine traffic needs its own credential. Roles for agents, operators, and admins. Rate limiting that knows to skip the health endpoint. An input sanitization pipe that parses DIDs and Ethereum addresses instead of trusting whatever arrives in the field. CSRF middleware, security headers, an audit log for every mutating operation, and a written threat model rather than one carried around in somebody's head. One commit in that batch matters more than the rest. We now reject agent registration when the DID controller is unverified. An identity layer that accepts identities it cannot verify is not an identity layer. The Verification Network spent August moving onto a real chain, on our internal network. We deployed the verifier and dispute registries with deployment scripts, an address registry loaded per network so nothing is hardcoded, contracts verified on the explorer, and a deployment document with addresses and a rollback path. That is where a chain stops being a diagram. Verdict finalization became reorg-safe behind a block-confirmation policy, so a verdict isn't treated as final until the chain agrees it happened. Nonce collisions got handled, because verdicts will arrive at the same moment. Receipts are polled with a timeout and backoff instead of being waited on optimistically. A test runs the whole verdict flow against a fork of that network, and dispute escalation has end to end coverage. Payment Rail spent August on instrumentation and the beginning of a pipeline: escrow and stream gauges with per chain labels, alert thresholds with on call routing, and the first half of a CI setup. 𝗦𝗘𝗣𝗧𝗘𝗠𝗕𝗘𝗥: 𝗧𝗛𝗘 𝗣𝗜𝗣𝗘𝗟𝗜𝗡𝗘 𝗔𝗡𝗗 𝗧𝗛𝗘 𝗣𝗥𝗢𝗧𝗢𝗖𝗢𝗟 September split cleanly in two. Half of it went into making the work repeatable, and half into making the protocol do something new. Payment Rail finished its pipeline. Lint, build and unit tests on every pull request. A Postgres service container so the end-to-end suite runs inside the pipeline rather than on somebody's laptop. Contract tests with Foundry on every pull request. A coverage summary that fails below a threshold. A multi-stage production image with a non-root runtime, pushed to the registry only after a vulnerability scan. A staging deploy on every merge to main. Semantic release tagging, Dependabot, and commit message enforcement. There was also one day in September that was eleven commits of pure repair, and we would rather say so than quietly squash it. An eslint config and the fixes for everything it surfaced. An import that had to be a default import before the e2e suites would compile. A scanner action version that actually exists. Endpoints returning the status code they were supposed to return. A rate limit exemption that had only appeared to be an exemption. Nothing there is interesting on its own. Together it is the difference between a pipeline that is green and a pipeline that is green for a reason. Then the protocol work, which is the part we are most pleased with. Payment Rail went multichain. There is now a chain registry holding per-network confirmation requirements and gas policy; the blockchain service sits behind a chain-agnostic provider instead of assuming one network, and escrow addressing carries the chain ID inside the session key. And streaming moved to v2. Accrual is per second, with checkpoint claims rather than one settlement at the end. A stream can be topped up while it runs. A rate can be changed mid-flight, with the already accrued amount prorated correctly rather than recalculated from the new rate. That last one sounds small, but it isn't: it is the difference between a payment stream you can renegotiate and one you have to tear down and rebuild. The accrual logic is covered by property tests against a reference model, because arithmetic that runs every second is arithmetic you do not want to be approximately right. The Verification Network closed out observability over teh same weeks: structured logs with correlation ids, Prometheus metrics, per controller latency histograms, gauges for validators, jobs and disputes, tracing that follows a request through the blockchain calls, dashboards, alert rules for verdict backlog and dispute rate, and a load profile. Load testing is useful mainly because it shows where you were wrong, and it did: the N+1 queries in job listing and validator lookups are gone. The Agent Layer followed the Verification Network onto the chain, with the same reorg safe confirmations, the same nonce handling, and end to end coverage for pricing updates and metering. 𝗧𝗪𝗘𝗟𝗩𝗘 𝗣𝗔𝗥𝗧𝗡𝗘𝗥𝗦𝗛𝗜𝗣𝗦, 𝗔𝗡𝗗 𝗧𝗛𝗘𝗬 𝗔𝗥𝗘 𝗡𝗢𝗧 𝗔 𝗖𝗢𝗟𝗟𝗘𝗖𝗧𝗜𝗢𝗡 Three announcements in August, nine in September. PoPP builds identity out of on-chain behaviour. Quack AI builds governance, policy and mandates for agents. ARO Network and Cottonia AI supply capacity, edge nodes and distributed compute. HiiT World runs a real-time market for signals, Astrix prices probabilities through prediction markets. Axiomos signs AI-generated content at the moment of creation, Mintellect AI brings patents and intellectual property on chain. Noma Network lends to agents themselves rather than to the people who own them. Alphio AI turns stated intent into executed trades. Noos Protocol builds agent infrastructure and an ecosystem around it. Qitmeer works on L1 throughput and settlement finality. Read the list again and a pattern shows up. Every one of them answers a question an agent has to answer before it can act: who can be trusted, what am I allowed to do, where do I run, what do I act on, how do I prove what I made, what do I start with. And every one of those answers currently stops short of money. Identity says who is trustworthy and nothing happens. Provenance says where something came from and nothing happens. A probability resolves and somebody reconciles it by hand. That is the shape of the gap we keep writing about, and it is why these particular categories and not a pile of AI logos. How we choose, in what order, and what is still missing from that map is a longer conversation than a recap can hold. We are writing it as a separate article. 𝗪𝗛𝗘𝗥𝗘 𝗧𝗛𝗜𝗦 𝗪𝗔𝗦 𝗔𝗧 𝗧𝗛𝗘 𝗘𝗡𝗗 𝗢𝗙 𝗦𝗘𝗣𝗧𝗘𝗠𝗕𝗘𝗥 All three services had their foundation, hardening and security phases behind them. Two of the three had contracts deployed and verified on-chain. One had a green pipeline deploying to staging on every merge. One thing we want to be precise about, because it's easy to oversell. The network those contracts run on is ours and it is internal. A testnet is something else: a testnet is when anyone can come and try it, which puts it one step away from production. We are not there yet. When we are, you will not have to work it out from a commit log. In late September, the commits slowed down, and that was deliberate. What was left was not a feature list. It was a set of questions that get answered once or get rewritten later: what a single settlement costs when there are a million of them, what counts exactly once when the service and the chain disagree, who pays which fee, what happens when a task is canceled halfway, and how to keep validators from agreeing with each other for the wrong reasons. That is where September ended. The next recap picks it up from there, and it will not take two months to arrive. Everything above is public as it lands. github.com/prom-io🚀 Prom

Loading the $Q page…