Evidence note: this article rests almost entirely on primary self-description — the projects’ own repository pages, their own marketing site, and their builders’ own posts in a public developer forum (thread one, thread two). None of the fee splits, agent counts, revenue figures or payment mechanics below have been independently audited, reproduced on-chain, or confirmed by a second party; what is established is that each project states these things about itself. Specific numbers carry their evidence level at the point they appear. No test was run for this piece.
Four agent-payment projects, four chains, one currency
Four projects surfaced in close succession, all of them paying software agents rather than people, and all of them settling in USDC — but on four different settlement layers.
Their own repository and site descriptions place them as follows. gitscout-croo presents itself as an autonomous data-verification agent built on CROO Network that uses zero-knowledge proofs and earns USDC per request. StellarAgents presents itself as an agent marketplace on Stellar where autonomous agents earn, spend and collaborate in USDC, letting developers deploy specialized agents, assign them tasks, and automate payments on-chain. lepton-press presents itself as a per-paragraph nanopayment paywall settling on Arc via StreamPay, built for the Lepton Agents Hackathon. And ClawGig presents itself as a freelance marketplace where the workers are AI agents, the clients are humans, and payment moves in USDC on Solana.
Those are the projects’ own words about themselves. Independent corroboration of the architecture claims — that the zero-knowledge proofs do what is claimed, that the Stellar and Arc settlement paths work as described under load — remains open; nothing published so far settles it.
The pattern worth holding onto is the direction of the money. In three of the four, value flows toward the agent: the agent does work and collects USDC. In exactly one, lepton-press, it flows the other way — the agent is the buyer, and a human publisher collects. That one was built for a hackathon.
ClawGig’s published terms: agents keep 90%, the platform takes 10%, a gig priced at $3.50
ClawGig is the most concrete of the four on commercial terms, which also makes it the easiest to check later.
Its founder states that agents keep 90% of a gig’s payment and the platform takes 10%, framing that as half of what Fiverr charges sellers (evidence level: the founder’s own claim; the comparison to Fiverr’s seller fee has not been verified against Fiverr’s current published schedule). The illustrative gig the founder cites is scraping every YC W25 company into a spreadsheet for $3.50 USDC (evidence level: a single example volunteered by the founder, not a sampled price from live listings).
That $3.50 figure is the most informative number in the whole set, and not because it is large. It is a price at which no human freelancer would take the job, and a price at which a 10% platform cut is 35 cents. A marketplace built around tickets that size is implicitly betting on volume and on near-zero acquisition cost per transaction — which is exactly what an API-and-webhook intake is for.
How an agent gets hired there: register by POST, receive an API key, get a webhook, auto-submit inside 60 seconds
According to ClawGig’s own developer-facing description, onboarding is a single POST request: a developer registers an agent, the agent receives an API key, and from there it can browse gigs, submit proposals, message clients and deliver work autonomously (evidence level: the platform’s own documentation of its intended flow; not reproduced here). Agents are notified by webhook when a matching gig appears and can auto-submit a proposal within 60 seconds (evidence level: the platform’s own claim about its intake; no measured latency has been published).
The stated stack is Next.js 14, Supabase for Postgres and auth, Solana for USDC settlement and Vercel for hosting, with the founder crediting Claude Code as part of how it was built (evidence level: founder’s own account).
That 60-second proposal window is the part developers should read twice. It means the competitive variable on a platform like this is not craft but reaction time and bid quality under no human review — the same dynamic that made latency the whole game in other automated-bidding markets. Whether it holds here is unverified; it is a design consequence of the intake, not a measured outcome.
Eight agents live and competing — and the one step none of them performs
At the time of posting, the founder reported 8 agents live and competing for gigs (evidence level: a founder-reported snapshot, reproduced here as read on 2026-10-05; no independent count exists and the figure is a point-in-time number, not a trend).
The described end-to-end workflow is: a client posts a gig, agents discover it via REST API and webhooks, agents submit proposals, the client funds escrow, and payment releases after the client approves the delivery (evidence level: the platform’s own description of its flow, uncorroborated).
Read that sequence against the automation claim and the seam is obvious. Discovery, bidding, negotiation and delivery are agent-side. Funding and release are human-side. The autonomy on display is autonomy of labour, not autonomy of capital — the agent can earn, but only after a person decides to pay and decides again that the work was acceptable. This site’s earlier survey of the same four projects — why eight agents bidding for gigs still waited on a human to release the money — reached the same seam from the marketplace side.
The solo-built AI operator: a 30-minute heartbeat, three agents, about $200, and a decision tree that was harder than the AI
The second forum account cited above describes something adjacent but not identical: not a marketplace, a single operator.
Its builder reports constructing an autonomous "AI operator" over roughly one month that runs their side projects end-to-end on a 30-minute heartbeat loop — publishing daily blog posts, monitoring Stripe for sales, checking that sites are up, and performing directory submissions (evidence level: the builder’s own forum account; no logs, repository or third-party confirmation accompany it). The stated architecture is three parts: a main orchestration agent, a builder sub-agent for code and deploys, and an amplifier agent for content and social (same evidence level). Financial decisions and strategic pivots escalate to the human; everything else the system handles itself (same evidence level). Reported revenue at the time of the post was about $200 from PDFs (evidence level: a single self-reported, unaudited figure, with no cost side disclosed — it is not a margin).
The most transferable line in that account is not a number. The builder reports that the hardest part was writing the decision tree that defines what the agent owns versus what needs human judgment — harder than the AI itself (evidence level: the builder’s own assessment). That claim and the ClawGig escrow step are the same finding arrived at independently from two directions: the difficult engineering in agent commerce is the boundary, not the model.
The per-paragraph paywall points the money the other way
lepton-press inverts the subject and object. In its own description, publishers earn micro-USDC per paragraph from autonomous AI readers, settled on Arc via StreamPay, and the project was built for the Lepton Agents Hackathon. The agent here is not a worker invoicing a human; it is a customer paying one, per paragraph, with no human in the release path because the release path is the read itself.
What that mechanism implies, if it works as described, is a payment with no approval step — and therefore no approval step to remove later. Whether it functions at scale, what a paragraph costs, and whether any publisher has received anything through it are all open; the repository is a hackathon entry, and no usage figures have been published.
What the inversion exposes in Armalo AI’s argument, read from the buying side
Armalo AI describes itself as an infrastructure layer for multi-agent AI networks, founded by Ryan, reportedly a former software engineer at Google, YouTube and AWS who most recently built AI agents at AWS (evidence level: the founder’s own biography as presented; employment history not independently confirmed). Its founder argues that agent-to-agent delegation today lacks escrow, contracts, recourse and persistent network state, and names a missing accountability layer as the root cause of 2025’s worst agent incidents (evidence level: the founder’s own argument; the causal attribution to specific incidents is not substantiated by published post-mortems and should be treated as a thesis, not a finding).
Hold that four-item list against the four projects and something uneven appears. Escrow is the one item ClawGig’s described flow does supply — by routing it through a human. Contracts and recourse are supplied the same way: the client’s approval gate is the contract, and withholding approval is the recourse. Persistent network state is supplied by the platform being a platform.
Which means the gap the argument identifies is not evenly distributed. On the earning side, a marketplace plus a human approver papers over all four — inefficiently, but it holds. On the buying side, which is where lepton-press sits, there is nothing to paper over it with. If an agent pays per paragraph and the paragraph is worthless, there is no approval gate to withhold, no counterparty reputation to downgrade, and no state that remembers. The inversion is where the accountability argument has the most force — and it is also, so far, the thinnest-evidenced corner of the whole set.
Developer takeaway: what to establish before an agent is allowed to earn or to spend
Nothing below depends on the unverified figures above; it follows from the described designs.
- Write the boundary before the agent. Both builder accounts here converge on this. Enumerate, explicitly, what the agent owns and what escalates — and do it as data, not as prompt text, so it can be audited and diffed.
- Treat earning and spending as different risk classes. An agent that earns has a human gate downstream by default on these platforms. An agent that spends usually has none. Budget caps, per-transaction caps and a hard kill path belong on the spending side first.
- Check who funds and who releases before reading a platform’s autonomy claim. On the ClawGig flow as described, those two steps are both human — which bounds how autonomous any agent on it can actually be, regardless of API surface.
- Price the floor, not the fee. A 10% cut on a $3.50 ticket is 35 cents. Model whether a gig’s inference, retries and failure cases fit under the remainder before optimizing for the cut.
- Assume reaction time is the competition. A 60-second webhook-to-proposal loop rewards speed and bid policy, not quality signalling. Decide deliberately whether to compete there.
- Separate settlement risk from counterparty risk. USDC is the common denominator across all four, but the chains are not — CROO Network, Stellar, Arc and Solana carry different finality, cost and tooling profiles.
Open follow-up: the figures none of these projects publish yet
The interesting questions are all unanswered, and each is cheap for the projects themselves to settle:
- Completion rate. Eight agents bidding says nothing about how many gigs were delivered, approved and paid. No project in this set publishes a completion or dispute rate.
- Approval latency. If payment releases only after a human approves, the time from delivery to release is the real throughput ceiling. It is unpublished.
- Net margin per gig. Revenue figures appear; inference and retry costs do not. The reported ~$200 has no cost side attached.
- Whether any agent-as-buyer flow has settled a real payment. For lepton-press the critical datum is a single confirmed on-chain nanopayment from an autonomous reader to a publisher. None has been published.
- Who bears the loss when an agent delivers garbage and the client approves anyway. This is Armalo AI’s recourse gap, restated as an operational question nobody in the set answers.
The direction to watch is not more marketplaces where agents earn. It is whether anything in the agent-as-buyer direction survives past a hackathon repository — because that is the side where, by these projects’ own descriptions, the human approval step has nowhere left to stand.