DEV Community: Kaven C

An anonymous AI agent answered a support ticket. A human approved it. It got paid on Solana.

Kaven C — Thu, 13 Aug 2026 14:25:27 +0000

Yesterday an autonomous agent with no account, no API key and no name earned USDC by answering a real customer support ticket. A human read its answer, decided it was right, and clicked approve. Eighty-five percent of the bounty settled to the agent's wallet on Solana a few minutes later.

Here is the receipt, because this is the kind of claim you should check rather than believe: the payout, on Solana mainnet.

Every number in that animation is the real one from the run.

The loop

I run a helpdesk with a public bounty board attached. The mechanics are deliberately boring:

A business attaches a cash reward to a real support ticket.
The board is public JSON. Any agent can read it for free, with no signup.
The agent pays a few cents over x402 (payments over plain HTTP 402) to fetch the ticket's context and submit an answer. No account exists anywhere in this sentence.
A human at that business reads the answers. Nothing an agent writes reaches a customer without a person approving it.
Approval settles 85% of the bounty to the wallet that submitted, on the chain the bounty was funded on. Rejection comes back with a written reason the agent can read.

The part I care about most is step 4. The agent is anonymous, but the money only moves when a human says the work was good. That one property is what keeps the whole thing from being a content farm.

What "paid on the chain it was funded on" means

The board runs on Base, Polygon, Sei and Solana. A bounty funded with Solana USDC pays out in Solana USDC; there is no bridging and no pooled float. Each bounty row publishes its payoutNetwork, so an agent holding the wrong kind of wallet skips it for free instead of paying the fee to do work it could never collect on.

Solana is the newest chain on the rail, and the payout linked above is the first one that settled there. The agent needed no SOL at any point: the server co-signs as fee-payer, so USDC is the only thing the agent's wallet ever holds.

The honest economics

The board publishes its own history in a machine-readable descriptor, so an agent (or you) can decide whether the work is worth doing before spending anything:

curl -s https://deskcrew.io/.well-known/x402 | jq '.extensions.earn.info.history'

Right now that reports 67 decided answers, a 21% approval rate, and $5.56 settled to 6 distinct wallets, with a median of about 7 minutes from approval to payment. Small numbers, honestly reported, and the reason they are in the tool's README rather than hidden: at a 21% approval rate, a $0.25 bounty loses the average agent money, and a $1.00 bounty pays it well. The tool prints the reward before every submission and refuses anything above your ceiling.

This is not a faucet. An agent that hedges or invents features loses money steadily, and the rejection reasons tell it exactly why.

Run one

The agent that won that payout is open source and on npm. It works with any OpenAI-compatible model endpoint, including one on your own machine:

export WALLET_KEY=...        # 0x + 64 hex for EVM, or a base58 Solana secret key
export LLM_BASE_URL=...      # any OpenAI-compatible endpoint
export LLM_API_KEY=...
export LLM_MODEL=...

npx x402-bounty-hunter            # dry run: reads the board, spends nothing
npx x402-bounty-hunter --live     # actually compete

The chain is detected from the shape of your key. Dry run is the default, there is a hard ceiling on total spend, and the server gets to choose neither the token, the price, nor the signature. Code and the full safety notes: github.com/webmilmind1/bounty-hunter.

Or run the other side

Boards are not a closed club. If you have tickets worth answering, you can run one: post real questions, fund rewards in USDC on the chain of your choice, approve only the answers you would actually send. The rail handles the rest, and every settlement is a public transaction anyone can audit.

That auditability is the actual point. Not "AI answers your support tickets", but a labour market where the work, the judgement and the payment all leave receipts.

Start here: deskcrew.io/bounties.

Adding Solana to an EVM app: four bugs that silently ate an agent's payout

Kaven C — Thu, 13 Aug 2026 13:10:27 +0000

I run a helpdesk where autonomous AI agents answer real support tickets and get paid in USDC when a human approves the answer. It worked on four EVM chains. Last week I added Solana.

The transfer code was the easy part. What nearly shipped was four bugs that each looked like nothing, and each would have quietly taken an agent's fee and never paid it out.

None of them crashed. That is the point. Every one of them failed by silently doing nothing, which on a money path is worse than an exception.

The setup

Two address spaces:

EVM: 20 bytes, rendered as hex behind an 0x, case-insensitive
Solana: 32 bytes, rendered as base58, case-SENSITIVE

Almost every bug below is that one sentence, discovered the hard way.

Trap 1: lowercasing an identifier that isn't hex

Payouts are keyed to the wallet that submitted the work. That wallet is parsed out of an identifier:

// The original. Fine for years, because everything was EVM.
const id = String(author.id).toLowerCase()
if (!id.startsWith('x402:')) return null
const wallet = id.slice(id.lastIndexOf(':') + 1)
return /^0x[0-9a-f]{40}$/.test(wallet) ? wallet : null

Lowercasing is correct for hex: it canonicalises 0xAbC… and 0xabc… into one string,
so one address is one key. Applied to base58 it is destructive. DRiP2Pn2K6fu… and
drip2pn2k6fu… are not the same account, and the second one is not an account at all.

So a Solana agent's wallet failed the shape test, the function returned null, and the award was dropped as if a human had written the answer. No error. No log. The agent paid its fee, did the work, won, and got nothing.

The fix is to fold only the form where folding means something:

const raw = String(author.id)
if (!raw.toLowerCase().startsWith('x402:')) return null
const wallet = raw.slice(raw.lastIndexOf(':') + 1)
if (/^0x[0-9a-fA-F]{40}$/.test(wallet)) return wallet.toLowerCase()  // hex: canonicalise
return isSolanaAddress(wallet) ? wallet : null                        // base58: never touch

Generalisable rule: before you add a second address space, grep your codebase for toLowerCase() on anything that identifies value. Every hit is a decision you made implicitly when there was only one format.

Trap 2: the same regex, one layer down

The payout sender re-validates the recipient immediately before money leaves. Defence in depth, and a good idea:

if (!/^0x[0-9a-f]{40}$/.test(wallet)) {
  await markFailed(id, 'invalid-recipient')
  continue
}

Every legitimate Solana winner would have been marked invalid-recipient here, by a check that exists specifically to protect them.

Validation has to follow the row's own chain:

function isValidRecipient(network: string, wallet: string): boolean {
  return isSolanaNetwork(network) ? isSolanaAddress(wallet) : /^0x[0-9a-f]{40}$/.test(wallet)
}

The lesson isn't "that regex was wrong". It's that a hardcoded format assumption tends to appear more than once, and the copies don't know about each other. Trap 1 and Trap 2 are the same bug in two files, and fixing one would have left the other.

Trap 3: comparing wei to lamports

The drain refuses to send if the wallet is low on gas, so a payout pauses cleanly instead of failing halfway:

const MIN_GAS_WEI = 30_000_000_000_000n   // ~0.00003 ETH
if (await chain.gasWei() < MIN_GAS_WEI) return { floatDry: true }

Both are "the chain's smallest unit", so the types line up perfectly. But:

1 ETH = 10^18 wei
1 SOL = 10^9 lamports

A wallet holding a healthy 0.05 SOL reports 50_000_000 lamports. Against a floor of
30_000_000_000_000, that is dry by a factor of about 600,000. Every Solana payout would have paused forever, on a wallet with plenty of gas, and the check would have reported it as a funding problem.

bigint gives you no protection here. Both sides are integers, both are "smallest unit", and the comparison is meaningless. The floor has to travel with the chain:

interface PayoutChain {
  gasWei(): Promise<bigint>
  /** The floor gasWei() must clear, in the SAME unit gasWei() returns. */
  minGasUnits?: bigint
}

if (await chain.gasWei() < (chain.minGasUnits ?? MIN_GAS_WEI)) return { floatDry: true }

Generalisable rule: a shared unit name is not a shared unit. If two chains both call it "the smallest unit", that is a naming coincidence, not a conversion.

Trap 4: case-folding an idempotency key

Deposits are claimed by naming the transaction that delivered them. One credit per (network, txHash), so a double-claim is impossible:

const txHash = args.txHash.trim().toLowerCase()

Two failures at once. A Solana signature is base58, so lowercasing produces a string that identifies nothing, and the deposit could never be verified. Worse, it makes the idempotency key lossy: two genuinely different signatures can fold to the same lowercase
string, and the second real deposit would be rejected as "already credited".

Same shape as Trap 1, in the one place where being wrong means crediting money twice or losing it entirely.

The one that was found by testing, not reading

Those four came from reading code with the two address spaces in mind. This one only appeared when I ran the real thing against a real Solana runtime:

throw new Error(`simulation failed: ${JSON.stringify(sim.value.err)}`)

Solana's error objects carry u64 fields as BigInt, and JSON.stringify throws on a BigInt rather than skipping it. So a failed payout recorded the reason as:

Do not know how to serialize a BigInt

The row parked with an error message about serialisation instead of the actual on-chain reason, which is precisely the information an operator needs and cannot reconstruct later.

JSON.stringify(err, (_k, v) => (typeof v === 'bigint' ? v.toString() : v))

How to actually test this

The public devnet faucet rate-limited me immediately, which is common. solana-test-validator
gives you a real RPC on localhost with unlimited airdrops, and it runs the same runtime.

I minted my own 6-decimal token rather than waiting on a faucet for devnet USDC. The mint is a parameter everywhere it appears, so nothing under test changed. The drill:

fund a wallet
pay an agent that has never held the token (this is the case that fails without idempotent token-account creation, and it costs rent out of your float)
read that payment back as a deposit
assert the guards refuse a token-account recipient, an EVM address, and an overspend

Step 2 is the one people skip. On Solana a recipient needs an Associated Token Account before they can receive an SPL token at all, and creating one costs about 0.00204 SOL of rent, paid by you, unrecoverable. That is a real per-recipient cost that has no EVM
equivalent, and if you don't handle it, paying a brand-new wallet just fails.

What I'd tell myself before starting

Grep for toLowerCase on anything identifying value. Every hit is an assumption.
Grep for 0x regexes. They multiply, and the copies don't know about each other.
A shared unit name is not a shared unit. wei and lamports differ by 10^9.
Serialise errors defensively. The error path is the one you never test.
Run it against a real runtime before you trust it. Four of these I found by reading.

The fifth only appeared when a real transaction failed for a real reason.

The through-line: adding a second chain is not mostly about transactions. It's about finding every place your code quietly assumed there was only one kind of address, and most of those places will fail by doing nothing at all.

By the end the count was eleven copies of that one assumption, across the award path, the payout sender, the deposit claim, the reputation API, and the payment door itself. Ten failed closed, quietly taking an agent's fee or dropping its win. One failed open and
quietly uncapped spend. The rule that fixed all of them fits in a sentence: fold hex, never fold base58, and validate in the address space the wallet actually lives in.

Did it work?

The test that ends the story: an autonomous agent funded with $1.01 of Solana USDC read the public board, paid $0.02 for a ticket's context and $0.06 to submit an answer, a human approved it, and the payout rail settled 85% of the $1 bounty back to the agent's wallet.

On-chain, if you want to check my claims rather than trust them:

the payout: 3URMYCyt…WeGR

The agent arrived with $1.01 and left with $1.56, entirely on Solana, with every hop a public transaction. None of the eleven bugs threw an exception. Every one of them would have made that sentence quietly false.

The board these agents work is public, if you want to see the shape of it:
curl -s https://deskcrew.io/.well-known/x402 | jq '.extensions.earn'

My AI agent just earned its first real dollar answering a support ticket

Kaven C — Thu, 06 Aug 2026 04:47:07 +0000

Last night a wallet with no account anywhere earned $0.425 in USDC for answering a real customer support ticket, judged by a human, paid automatically on-chain. Here is the receipt:

0xd36ec5...c2743 on Basescan

This post is the how, the honest economics, and the runnable code so your agent can do the same.

The loop

Support desks on DeskCrew attach cash bounties to real tickets and publish them on an open board. Any agent, no signup, no API key, can:

Read the board (free): GET https://deskcrew.io/api/arena/contests, or the free list_bounties tool on the MCP door. Every row carries the ticket, the bounty, and the exact URLs to act through.
Buy the ticket's context (~$0.02): full message thread, customer profile, relevant knowledge-base articles. Paid over x402, the HTTP 402 micropayment standard: your wallet signs an off-chain USDC authorization, the server broadcasts it and pays the gas.
Draft an answer with its own LLM and submit it (~$0.06).
A human reviews the drafts. If yours is approved, 85% of the bounty is paid in USDC on Base to the same wallet that paid for the draft.

The human approval is the interesting part. Nothing an agent does reaches a customer without a person clicking approve, which is also what makes the payout defensible: it is a fee for accepted work, judged by the buyer.

The honest economics

An attempt costs about $0.08 in fees plus your own inference. A $0.50 bounty pays $0.425 on approval. If more than roughly 1 in 4 of your drafts gets approved, you profit. Approval is a quality judgment by a human who has to send your words to their actual customer, so agents that read the context carefully win and spam loses money. That asymmetry is the whole design.

Every wallet also builds a public, human-rated record it cannot buy or fake: wallet record API (that is the wallet from the tx above: 1 draft, 1 approval, rank 1). Fleet operators can wire that into their own selection loops.

Run it

export X402_KEY=0x...     # a DEDICATED wallet with a few dollars of USDC on Base
export LLM_API_KEY=...    # any OpenAI-compatible API
export LLM_MODEL=...

npx x402-bounty-hunter --dry-run   # read the board, price the work, pay nothing
npx x402-bounty-hunter             # one real attempt at the richest open bounty

The reference agent is MIT and about 300 lines: github.com/webmilmind1/x402-bounty-hunter. It is deliberately boring: pinned USDC contract, per-call and per-run spend caps, a ceiling the server cannot move, and your keys never leave your machine. Fork it and swap the drafting logic for your own agent; keep the safety rails.

Why we built the earning direction

We run an x402 seller node and publish our funnel numbers honestly: over 13 days we saw 125 manifest fetches, 1 quote, and 0 organic settlements. Strip the monitoring bots from any x402 node's traffic and the whole ecosystem's buy side today is a couple dozen real events. Waiting for agents to spend money was waiting.

So we inverted it. Agents do not need to be convinced to earn money, and every earner is also a payer: the context purchase and the draft fee are x402 settlements like any other. The bounty board bootstraps both sides of the market at once, and the human approval keeps quality attached to every dollar that moves.

The board is small today, real tickets, small bounties, and that is the point: it is live, verifiable, and anyone's agent can be on the leaderboard by tonight.

Questions welcome. If you run an agent framework and want a worked example for your docs, the repo is MIT; take it.

16 paid endpoints. None of them could be bought.

Kaven C — Tue, 04 Aug 2026 12:10:44 +0000

I run a helpdesk that AI agents can pay to use. Sixteen endpoints, priced from $0.02 to $0.06, settled in USDC over x402.

The funnel showed zero conversions. I assumed that meant no demand. Everyone told me the agent economy was early, and that was a comfortable thing to believe.

It was wrong. Every one of those sixteen endpoints was unbuyable. Three separate bugs, none of which produced an error anywhere I was looking.

What a paywall failure looks like

Nothing. That's the problem.

A payment protocol failure isn't a 500 you find in your logs. From your side, a request arrives, you answer 402 Payment Required, and the caller leaves. That's also exactly what it looks like when someone reads your price and decides it's too expensive.

Your dashboard shows the same graph either way: requests in, no settlements. Indistinguishable from being unwanted.

The three bugs

The EIP-712 domain name isn't uniform across chains. I assumed USDC reports "USD Coin" everywhere. On Sei it reports "USDC". Get this wrong and the buyer's signature recovers to a different address than the one that signed. There's no error message. The signature is valid, it just belongs to nobody. Payment refused, both sides baffled.

The discovery manifest advertised a key nobody reads. I'd invented a sensible-looking name for the block describing my paid actions. The catalogs that index x402 services read one specific key. Mine wasn't it, so as far as every directory was concerned, my endpoints didn't exist.

MCP clients open a GET with Accept: text/event-stream before doing anything. My paywall answered 402. The correct answer is 405. Every compliant client hit a payment wall during transport negotiation and gave up before reaching anything purchasable.

Each of these is individually obvious in hindsight. Together they meant a working-looking product that could not take money.

What actually found them

Not tests. My test suite was green throughout, because it tested my server against my assumptions about clients.

What found them was calling my own paywall with a stock client I hadn't written, from outside, like a stranger. The first one failed in four seconds.

That gap is the whole lesson. Your tests encode what you believe. A third-party client encodes what the protocol actually says. Where those disagree is exactly where your revenue disappears silently.

So I packaged the probe

The tool I used to find this is now a CLI, and it works against any x402 server, not just mine:

npx try-x402 --dry-run

That reads the real payment terms off a live endpoint and signs nothing. Drop --dry-run and it settles for real. Point it anywhere with --url.

It's built to refuse to hurt you, because a "just try it" tool that can drain a wallet is worse than no tool:

Rejects any asset that isn't the canonical USDC for that chain
Builds the EIP-712 signing domain locally, so a hostile server can't substitute a different token

Won't sign above --max-price, default 1 USDC

Generates a throwaway wallet per run and prints the key, so you never point a real one at it

MIT, no account, nothing to install: github.com/webmilmind1/try-x402

If you run a paywall of any kind

Go and buy from yourself.

Today.

With something you didn't write.

Not a test.

Not a staging mock.

A real client, hitting production, the way a stranger would.

If it doesn't work, you'd rather learn that from yourself than from a flat line on a graph you've been misreading for a month.

Our API docs told AI agents to do the exact thing that fails

Kaven C — Mon, 27 Jul 2026 14:54:46 +0000

We run a helpdesk that AI agents can operate over MCP: list tickets, read a thread, draft a reply for a human to approve. Last week a real agent paid for a call, chained it into a second call, and hit a wall. What we found underneath was embarrassing enough to write up, because I think half the "agent-ready" APIs out there have the same bug.

The bug

Our create_ticket tool returns this:

{ "ticketId": 47, "customerId": 18, "status": "active" }

And our get_ticket_context tool accepts this:

{ "ticketId": { "type": "string", "minLength": 1 } }

See it? The id comes OUT as a JSON number, because the database hands out integer ids. It goes IN as a string, because someone wrote z.string() in the input schema. So the most natural two-step an agent can perform, take the id from one response and pass it to the next tool, fails validation before the handler ever runs:

ticketId: Expected string, received number

We audited every tool after the first report. All 24 fields that return an id emit numbers. All 14 fields that accept one demanded strings. Of 121 possible tool chains, 107 were broken.

The part that hurts: every input schema's own description said "the id, as returned by list_tickets". The documentation was actively instructing agents into the failure.

Why nobody noticed for months

Humans never chain raw ids; they click. Agents chain constantly, and they do it literally. They take your output and feed it to your input, exactly as documented.

Our test suite never caught it because every test wrapped ids defensively:

const res = await runTool(draftReply, { ticketId: String(ticket.id) })

That String() is the whole story. The tests encoded what a careful human author would type, not what a literal-minded agent actually sends. The suite was green for months while the surface was broken for every real agent.

The fix, and two tempting fixes that are worse

We widened the acceptors. Changing the emitters (returning "47" instead of 47) would silently change the response shape for every existing client, so that was off the table.

But the obvious wideners both have traps:

z.union([z.string(), z.number()]) changes your published JSON Schema to an anyOf. If your tool list is advertised to clients (MCP's tools/list, an OpenAPI doc), that is a contract change every client can see, and some will handle it badly.

z.coerce.string() accepts everything. null becomes "null", undefined becomes "undefined", and a missing id turns from a clean validation error into a confusing "not found" three layers deeper.

What we shipped is a guarded preprocess:

const numericIdToString = (v: unknown) =>
  typeof v === 'number' && Number.isSafeInteger(v) && v > 0 ? String(v) : v

export const idSchema = () => z.preprocess(numericIdToString, z.string().min(1))

Only a positive safe integer is rewritten. Everything else passes through untouched, so null, {}, floats, and negatives still fail with the same messages they always had. And the generated JSON Schema is byte-identical to the old z.string().min(1), so the published contract does not move at all. We verified that with a test that renders both schemas and compares the JSON.

The checklist we use now

Round-trip your own outputs. For every id your API returns, write a test that feeds it back into every input that names the same entity, without any type massaging. No String(), no Number().
Grep your tests for defensive casts around ids. Each one is a place your suite is politely covering for a bug.
Widen acceptors, never emitters. Emitted shapes are contracts.
Diff the generated schema before and after any validator change. "It still validates the same values" and "it advertises the same contract" are different claims.
Read one real response with your own eyes. The paid call that exposed all this also showed us a grammar bug in the response text. Nobody had ever actually read what an agent receives.

Agents are the most literal API consumers you will ever have. They follow your docs exactly, which means your docs finally get tested.

If you want to poke at the surface that taught us this, the agent door is documented at deskcrew.io/agents. Free reads, and the paid actions quote you a price before you commit to anything.

What's the equivalent bug in your API? I'd genuinely like to know if the number-vs-string id split is as common as I suspect.

One support widget, seven platforms: what shipping to each marketplace actually takes

Kaven C — Sun, 19 Jul 2026 11:35:39 +0000

I build DeskCrew, a support helpdesk, solo. The product is a chat widget plus an AI that answers from your own help docs. Building it was the easy part. Getting it in front of people means shipping the same widget to every platform a customer might already be on: WordPress, Shopify, npm frameworks, forums, docs sites.

This week I shipped it to seven of them. Here is what each one actually took, because the marketing pages never tell you.

The whole product is one line:

<script src="https://deskcrew.io/desk.js" data-key="pub_YOUR_KEY" defer></script>

Everything below is just a different wrapper around getting that tag onto a page. But every platform has its own delivery mechanism, its own review process, and its own trap.

npm frameworks (Astro, Docusaurus, Nuxt): the config-entry pattern

Modern site frameworks do not want a script tag. They want a config entry. So each of these is a tiny package whose only job is to inject the tag through the framework's own head API.

// astro.config.mjs
import deskcrew from '@deskcrew/astro'
export default defineConfig({
  integrations: [deskcrew({ widgetKey: 'pub_...' })],
})

Publishing is npm publish --access public. The trap was not the code. It was auth: enabling 2FA on my npm account silently invalidated the CLI session, and npm publish responded with a 404 on the scoped package, not a 401. A missing-auth error disguised as a missing-package error cost me twenty minutes of staring at a package that was definitely there. Lesson: on npm, E404 on your own scope usually means "you are not logged in," not "it does not exist."

Shopify: the zero-scopes flex

Shopify was the one I expected to be brutal, and it was the smoothest, because of one architectural decision: the app requests zero API scopes.

Most Shopify apps ask for read_products, read_customers, and so on, which drops you into Shopify's protected-customer-data review: a longer, stricter process. But my widget does not need any Shopify data. It ships as a theme app extension (an app-embed block), not the deprecated ScriptTag API, so the merchant flips one toggle in the theme editor and the widget loads. No data access, no protected-data review, fast track.

The block itself is defensive by default:

{%- if block.settings.widget_key != blank -%}
  <script src="https://deskcrew.io/desk.js"
    data-key="{{ block.settings.widget_key | escape }}" defer></script>
{%- endif -%}

Nothing renders without a key, and every merchant-supplied value is escaped. The one non-obvious requirement: the mandatory GDPR webhooks (customers/data_request, customers/redact, shop/redact) plus app/uninstalled, all HMAC-verified with a timing-safe compare, returning 401 on a bad signature. Reviewers test these first.

Discourse: no store at all

Discourse has no marketplace and no review queue. A "theme component" is just a public git repo with an about.json and a common/head_tag.html. Push it to GitHub, and any forum admin installs it with Admin → Customize → Themes → Install → From a git repository. That is the entire distribution story. The moment I pushed, it was installable worldwide.

The head-tag script validates every setting against a strict character class before it touches the DOM, and builds the tag with createElement + setAttribute, never innerHTML, so a forum setting can never inject markup.

Framer: a real plugin with a UI

Framer wanted an actual plugin: a React app that runs inside the editor and writes to the site's custom code via framer.setCustomCode. This one has a review queue and wants gallery images. It is the most "app-like" of the bunch and the only one where the widget is inserted programmatically rather than declared.

The bug that ate a whole afternoon

The best technical lesson this week had nothing to do with any marketplace. It was email.

DeskCrew turns inbound support email into tickets. I wanted hello@deskcrew.io to flow into the product, so I set up Cloudflare Email Routing to forward the domain to my mail pipeline. Every test email vanished. No error, no ticket, nothing.

The logs finally confessed: dropped automated/loop mail (system-sender:bounces). My inbound handler has a loop-guard that drops mail from bounces@, no-reply@, mailer-daemon@ and friends, so an auto-responder can never ping-pong with a bounce address forever. Sensible. But Cloudflare rewrites the envelope sender to bounces@cf-bounce.notify.cloudflare.com on every forwarded message. So the loop-guard was correctly dropping every single forwarded email as if it were a bounce.

Forwarding services and loop-guards are fundamentally incompatible. The fix was to stop forwarding and point the domain's MX records straight at the mail provider, so the original sender arrives first-hand and the authentication verdicts come through clean. Direct MX, no hop.

Rule of thumb: if you forward mail into anything that inspects the sender, the forwarder's envelope rewrite will fight your logic. Prefer direct MX.

What actually mattered

The widget is one script tag. Shipping it seven ways was seven afternoons of wrappers, review forms, and one genuinely nasty email bug. Building the product was never the bottleneck. Distribution is the work, and it is the part nobody shows you.

If you run a Framer, Shopify, WordPress, Discourse or docs site and want to see the widget, it is free with no card at deskcrew.io. And if you have shipped to a marketplace I have not hit yet and know a trap I am about to walk into, I would genuinely love to hear it in the comments.

A support desk that AI agents can pay to use — no account, no API key, no signup — settling in USDC on Solana.

Kaven C — Fri, 10 Jul 2026 11:41:10 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

A support desk that AI agents can pay to use — no account, no API key, no signup — settling in USDC on Solana.

DeskCrew is an agent-native helpdesk. The unusual part is the front door. An autonomous agent finds the server, calls a tool, and gets back an HTTP 402 Payment Required with machine-readable terms. It pays $0.05 in USDC, retries with a payment header, and gets its answer. There is no human in that loop, and there is no account.

The goal was to answer a question I couldn't stop thinking about: if agents are going to buy services from each other, what does the checkout look like? Not a card. Not an invoice. Not an OAuth dance that assumes a human with a browser. Something an agent can complete alone, in one round trip, for five cents.

The passion part is that I don't think identity should be the price of entry. An agent shouldn't have to become somebody to buy one API call.

Demo

curl -s -X POST https://deskcrew.io/api/mcp/deskcrew \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"draft_support_reply","arguments":{"ticketId":1}}}'
You get a real HTTP 402 with the Solana leg in accepts:

{
"scheme": "exact",
"network": "solana",
"asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
"payTo": "3uusWWisxWKpscMWAmgV5otpm5Xmjk1W3WPQsHAxFPfa",
"maxAmountRequired": "50000",
"feePayer": "EvJZ4f2AUy6BJihdP4cj3EsDaunA9RaDUpWg4nGemqHk"
}
50000 atomic units of USDC = $0.05. Mainnet mint. Real wallet.

Free tools need no payment at all — search_kb, list_issues, list_changelog. The discovery manifest is public: https://deskcrew.io/.well-known/x402

Site: https://deskcrew.io · Agent docs: https://deskcrew.io/agents

Code

webmilmind1 / deskcrew-mcp

Agent-native helpdesk over MCP: triage tickets, search the knowledge base, and draft human-approved replies. Free credential or anonymous x402 (USDC).

DeskCrew MCP Server

Agent-native helpdesk. AI agents run real support work over MCP and pay per action in USDC via x402. No account, no API key.

· · MCP Registry: io.deskcrew/support · deskcrew.io

DeskCrew is a multi-tenant support helpdesk built for AI agents. Humans get a normal dashboard shared inbox, and email, while agents get a paid MCP door. An agent connects over the Model Context Protocol, lists the available tools, and runs real support work: search and create tickets, search the knowledge base, draft and post replies, triage and resolve threads, paying per action in USDC.

Two ways in

Anonymous, pay per action. No account, no API key. Read tools are free; action tools return HTTP 402 and you pay per call in USDC (x402). Use any desk's public door at /api/mcp/{tenant}. This is the section directly below.
Free credential, run your own desk.…

View on GitHub

The public MCP connector and agent skill. The desk itself is a private commercial repo, so the snippets below are the load-bearing parts.

How I Built It

The standard. x402 is Coinbase's revival of the long-dead HTTP 402 Payment Required status code. A server answers 402 with signed payment requirements; the client pays and retries with an X-PAYMENT header. It's HTTP semantics, not a protocol bolted on top.

Why Solana was the interesting chain. The EVM legs use EIP-3009 transferWithAuthorization — the payer signs an off-chain authorization, we relay it. Solana has no such primitive, so x402's exact-svm scheme takes a different shape: the agent builds an SPL TransferChecked transaction and signs it, and our relayer co-signs as fee-payer.

That detail is the whole reason this feels right on Solana. The paying agent never needs SOL. It holds USDC and nothing else. It doesn't manage a gas balance, doesn't top up, doesn't know what a lamport is. It signs a transfer; we pay for the block space. An agent's wallet becomes single-asset, which is exactly what you want from something that has no hands and no credit card.

Sub-cent fees matter here too. A $0.05 API call is nonsense on a chain where settlement costs $0.30.

What I refused to trust. The scheme's own verify/settle does the security-critical binding — it rejects any transaction that doesn't pay the exact amount, to the exact associated token account, in the correct mint, with the fee-payer neither funding the transfer nor appearing in any instruction's accounts, in exactly three instructions. I read that code before I relied on it, then wrote an independent economic guard in front of it anyway, re-checking payTo, asset, network, and that the price is one of the ones we actually advertised. Two locks, different keys.

Never charge for a failure. Payment settles before a side-effecting tool runs, and a nonce is claimed against a UNIQUE index. If the tool then throws, the pending claim is released and no settlement occurs. An agent is never billed for an error, and a retry can't double-charge. Getting that ordering right took longer than the payment integration.

The safety layer nobody sees. A paying agent is still an untrusted caller reading untrusted customer text. Every credential is draft-capped: an agent can compose a reply, but sending it requires a human to approve. The tier is read from the credential row, never from the tool arguments — so a prompt injection buried in a support ticket cannot talk the system into escalating itself. That's the structural break in the lethal trifecta: the component holding private data and untrusted content has no external side-effect.

What I got wrong. For weeks the AI features were silently dead: I'd written the model slug with a hyphen instead of a dot, and every AI surface catches errors and escalates to a human rather than fabricate. So a broken model, a revoked key, and a genuine knowledge-base miss all produced the same customer-facing sentence. Good product behavior; terrible operational signal. The fix was a health probe that distinguishes them. The lesson stuck: no-fabrication escalation is honest to users and lies to operators.

Prize Categories

Best Use of Solana.

Not a token, not an NFT, not a governance contract. A payment rail doing the one job a payment rail should do for machines: settle a five-cent invoice, in a stablecoin, in under a second, from a wallet that holds no gas.

The exact-svm fee-payer split is what makes it work — the agent brings USDC, the service brings SOL. Anonymous, per-call, no account. Live on mainnet at 3uusWWisxWKpscMWAmgV5otpm5Xmjk1W3WPQsHAxFPfa, verifiable from the manifest above before you send a cent.

Self-hosting an x402 facilitator: the EIP-3009 gotchas that almost cost us money

Kaven C — Thu, 09 Jul 2026 07:30:28 +0000

We run DeskCrew, a helpdesk where AI agents can use support tools with no account and no API key — they pay per action in USDC over x402, the HTTP-402 payment standard. An agent calls a tool, gets a 402 Payment Required with an exact quote, signs a USDC authorization, retries, done. Five cents, no signup.

Most x402 services use a hosted facilitator to verify and settle payments. We self-hosted the whole stack — facilitator, relayer, settlement confirmation — partly for control, partly to support five chains, and partly because I wanted to actually understand what I was trusting. Here's what bit us on the way, so it doesn't bite you.

x402 in sixty seconds

Client calls your paid endpoint with no payment → you respond 402 with a quote: price in atomic USDC, your receiving address, network, a timeout.
Client signs an EIP-3009 transferWithAuthorization — a gasless, off-chain signature authorizing a USDC transfer from their wallet to yours, bound to a unique nonce.
Client retries with the signed payload in an X-PAYMENT header.
Your facilitator verifies the signature, runs the work, and your relayer broadcasts the authorization on-chain to settle.

Simple. The gotchas live in steps 2–4.

Gotcha 1: "nonce consumed" is not "you got paid"

This is the one that matters. Our first settlement-recovery path checked authorizationState(from, nonce) on the USDC contract — if the nonce was used, we marked the payment settled and the revenue earned.

The payer controls that nonce. EIP-3009 lets the authorizer burn their own nonce: they can call cancelAuthorization, or spend the same nonce in a self-transfer, racing your relayer. Result: the nonce reads "used," your books say "paid," and your wallet received nothing. An adversarial agent could get your tool's output for free, at scale.

The fix is to confirm the money movement, not the nonce state. On settlement recovery we now require finding the AuthorizationUsed(authorizer, nonce) event and verifying the USDC Transfer log adjacent to it in the same transaction — checking it moved from the payer, to our receiving wallet, with value >= the quoted amount. FiatToken emits these back-to-back, so log-index adjacency pins them to the same authorization. Anything else — missing event, wrong recipient, short amount — fails closed: the row stays unsettled and never counts as revenue.

Rule of thumb: any state the payer can influence is not proof of payment. Only the Transfer to your address is.

Gotcha 2: exactly-once work, payment-after-success

Two invariants pull against each other:

Never take money for work that failed → settle only after the tool succeeds.
Never run a side-effecting tool twice for one payment → the client will retry, sometimes concurrently, with the same signed authorization.

Our answer is a claim table keyed by the EIP-3009 nonce with a UNIQUE constraint. The first request to insert the pending row wins the race and runs the tool; everyone else carrying the same nonce is a retry and gets refused. If the tool succeeds but settlement fails (RPC hiccup, gas spike), we stamp the row consumed-but-unsettled — the row is never deleted, so the same authorization can never re-run the action — and a reconcile job retries the on-chain settlement later, using the Gotcha-1 confirmation before it ever promotes the row to revenue.

The ordering that emerges: claim the nonce → validate input → run the tool → settle → record. Validation before payment matters more than it looks — taking five cents and then returning "invalid input" is a great way to make an agent developer never come back.

Gotcha 3: multi-chain is not copy-paste

"USDC on five chains" sounds like a for-loop. It isn't:

Every chain has a different USDC contract address, and some have bridged-vs-native variants — quote the wrong asset and signatures verify against a token you don't accept.
Solana has no EIP-3009. The whole authorization model changes: a fee-payer co-signs, the flow is transaction-based rather than signature-based, and your "facilitator" logic is effectively a second implementation, not a port.
Advertise networks honestly in your quotes: a client that picks Sei because your 402 offered it, only to find your relayer has no gas there, burns real goodwill.

If you're starting out: ship Base only, add chains when someone asks.

Gotcha 4: discovery is table stakes, not demand

We serve /.well-known/x402, per-workspace manifests, and we're in the MCP registry. Do all of that — it's cheap and it's how agents can find you. But measure the funnel separately: manifest fetches → 402 quotes issued → payment attempts → settlements. Fetches without quotes are curiosity. Quotes without attempts are checkout friction. Only settled transfers from wallets you don't control are demand. We log all four stages and split "our own test wallets" from strangers, so we can't fool ourselves.

Kick the tires (paid, but we'll pay you back)

The door is live on mainnet:

Terms: https://deskcrew.io/.well-known/x402
Quickstart with a copy-paste 402 flow: deskcrew.io/agents
Cheapest calls are $0.02; the fully account-free one is draft_support_reply at $0.05 — send raw customer text, get a support reply draft back. Payment settles only after the tool succeeds.

If you've got an x402-capable agent: the first 20 external wallets to make a successful paid call get 5× the call price back — reply with your tx hash wherever you found this post. Worst case, you're out two cents and got a story.

Questions about the facilitator internals welcome — happy to go deeper on any of the four gotchas.

I built an "agent door" — how AI agents pay per action on my helpdesk (MCP + x402)

Kaven C — Fri, 03 Jul 2026 13:30:43 +0000

Most "AI + payments" stories are about humans buying things through an agent. I wanted the opposite: an anonymous AI agent that shows up, does one unit of work, and pays for it — no account, no API key, no human in the loop.

So I built it into a helpdesk. Here's how the "agent door" works, and what I learned wiring HTTP 402 to real settlement.

The problem with giving agents API keys

The default way to let an agent use your API is: a human signs up, adds a card, generates a key, and manages it. That's fine when the agent has an owner and a long relationship with your service.

It's terrible when the agent is ephemeral — it needs one action, right now, and will never come back. Onboarding, KYC, key rotation, billing plans… all overhead for a single API call. There's no clean "walk up and pay for exactly what you use" primitive.

The primitive: HTTP 402 + x402

HTTP has always had a status code reserved for this: 402 Payment Required. It was never really used — until x402 gave it a concrete meaning: the server responds 402 with machine-readable payment terms, the client pays (USDC on-chain), and retries the same request with an X-PAYMENT header. Settlement happens per request.

No account. No API key. The payer's wallet is the identity.

The door

My helpdesk (DeskCrew) exposes an MCP server per workspace, so an AI agent can operate the desk — search the knowledge base, open and triage tickets, draft and post replies. Read tools are free; write/AI tools are priced.

You can hit it right now, no signup:

curl -s https://deskcrew.io/api/mcp/deskcrew \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

That returns the tool catalog with per-tool prices. Call a paid tool and you get the challenge:

{
  "x402Version": 1,
  "error": "Payment required for tool 'create_ticket'",
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "maxAmountRequired": "20000",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "payTo": "0x…",
      "maxTimeoutSeconds": 300
    }
    // …one entry per chain: polygon, avalanche, sei, solana
  ]
}

20000 is $0.02 in USDC's 6 decimals. The agent signs a payment authorization for that amount, retries with X-PAYMENT, and the tool runs once settlement confirms.

What I actually had to get right

The happy path is easy. The interesting part is everything that isn't.

1. The amount, recipient, and asset come from the server — never the client. The client sends only a signed authorization. The server builds the payment terms (price from a server-side table, payTo = a cold wallet, the USDC contract pinned per chain) and verifies the signature satisfies those terms. Otherwise an agent could "pay" 1 wei, redirect payment to itself, or hand you a fake token.

2. Don't run a side-effecting action before you're paid — but don't double-charge either. verify() only reads the payer's balance; it's not a reservation. So N concurrent requests from one wallet funded for a single call can all pass verify. I gate it two ways: an at-most-one-in-flight lease per wallet, and a claimed nonce (EIP-3009) inserted before the action runs, so a replay or a concurrent duplicate can't execute the tool twice for one payment.

3. For live external effects (like sending a customer an email), settle first. The fairness default is "only charge on success" — so most tools run, then settle. But for the one action where "ran but not charged" is real abuse (a free outbound email from your domain), I flipped the order: confirm payment on-chain, then send. The safe failure direction is "paid but not delivered," never "delivered for free."

4. Anonymous ≠ unbounded. Per-wallet rate/spend caps, reputation, and a deliverability breaker bound abuse. High-value actions are gated behind earned reputation, so a day-one anonymous wallet can't email your customers — it gets a draft in a human approval queue instead.

5. Self-host the money path. I run my own relayer + facilitator, so there's no third party between the agent and settlement. USDC lands in a cold wallet at my prices; even a leaked hot key can only move the payer's funds to my wallet, at my price (the settle is economically bound).

Was it worth it?

For a helpdesk specifically: an agent resolving a support task mid-workflow can now pay for exactly the tools it uses — no account, no key. Whether pay-per-action beats just issue the agent a key is genuinely situational, and I'd love the internet's opinion on where the line is.

But the pattern is bigger than helpdesks. 402 + a signed micropayment is the missing "walk up and pay" primitive for the agent web. It's early and rough, but it works today — you just curled it.

Try it: deskcrew.io · the door: POST https://deskcrew.io/api/mcp/deskcrew · MCP spec + tools: github.com/webmilmind1/deskcrew-mcp

Happy to answer anything about the x402 wiring in the comments.