There is a better pattern, and it already works on Bitcoin Cash. Instead of trusting the agent to respect a budget, the owner can lock the budget into a contract that enforces the limit at the protocol level. The agent can spend what the contract releases and nothing more. If the agent has a bug, follows a malicious prompt, or has its key stolen, the damage stops at the cap.

Why the Limit Belongs in the Money Itself

Most agent frameworks let a developer write a spending rule in application code, such as a daily maximum. That rule lives in the same process as the agent. If the process is compromised, the rule goes with it. A prompt injection only needs the agent to hold a key that can sign.

A limit enforced by the network is different. Every node checks the rule when a transaction is broadcast, and a transaction that breaks it is simply invalid. No amount of clever prompting changes that outcome. The agent key becomes a narrow permission rather than full ownership of the funds.

The Trouble With a Hot Wallet and Good Intentions

A plain hot wallet gives the agent one powerful key, and whoever holds it can move the entire balance in a single transaction. Owners try to reduce the risk by keeping the balance small and topping it up by hand, which works until someone forgets or automates the top up with the same weak controls.

Cards on file have a similar shape. The limit is usually far higher than the task requires, disputes take weeks, and the number can leak through logs and third party services. Neither approach separates the right to spend a little from the right to spend everything. That separation is exactly what a covenant provides.

What CashScript Brings to the Table

CashScript is a high-level language for writing smart contracts on Bitcoin Cash. It compiles to Bitcoin Cash Script, the native stack language that every node already validates. Developers write readable contracts with named functions and require statements.

The key capability is native introspection, added to Bitcoin Cash in May 2022 and extended with token introspection in the CashTokens upgrade of May 2023. Introspection lets a contract read the transaction that is trying to spend it, including the value and destination of every output.

Covenants in Plain Terms

The CashScript covenant guide defines a covenant in one sentence: a constraint on how money can be spent. A contract can require that an output goes to a specific address, carries a specific amount, or returns the leftover balance to the same contract. If the spending transaction does not match, it fails validation.

For an agent budget, the owner can write rules such as these and have every node enforce them:

• No single payment may exceed a fixed number of satoshis.
• Payments may only go to approved service addresses.
• Whatever is not spent must return to the contract.
• A new allowance unlocks only after a set period.
• The owner can reclaim the full balance at any time with a separate key.

The Allowance Pattern: Mecenas for Machines

The CashScript documentation includes a well known example called Mecenas, originally written by Licho. It sets up a recurring payment: the recipient can claim a fixed pledge once per period, and the remainder must go back to the contract. The funder holds a separate key that can reclaim everything.

Applied to an agent, the design is clear. The owner funds the contract and keeps the reclaim key in cold storage. The agent hot wallet is the recipient. Once per period, the contract releases one pledge, and the agent pays for services out of that small balance. Even if the agent wallet is fully compromised, an attacker can take at most what has already been released.

Per Payment and Per Period Limits

Mecenas gives a per period limit through a relative timelock. The contract checks its own age, so a new claim is possible only after the period has passed since the last one. The guide also describes a streaming variant that keeps state in a CashTokens NFT commitment, so the allowance accrues per block and can be claimed at any time.

A per payment cap is a small variation. The contract lets the agent key sign a spend, then requires that the payment output stays at or below a maximum and that the change returns to the contract. On its own, that cap can be bypassed by many payments in a row, so it works best combined with a time condition. Layering the two limits the budget in both size and speed.

Restricting Where the Money Can Go

Introspection also lets a contract compare an output against known addresses. The covenant guide shows an escrow that can only pay the buyer or the seller. The same technique can restrict an agent to a short allowlist of providers, so a hijacked agent cannot redirect funds to an unknown wallet.

An allowlist written into the contract stays fixed unless the design includes an update path, and every update path needs its own protection. Many owners will prefer the simpler allowance model, and the large balance stays protected either way.

Adding x402 So the Agent Pays Per Request

HTTP has included status code 402, Payment Required, since the early web, but it sat mostly unused for decades. The x402 protocol gives it a job. A server answers a request with a 402 response describing the payment it accepts. The client pays, retries with proof of payment in a header, and receives the resource. No account, subscription, or card form is needed.

This suits agents because they make many small requests to many services. Per request pricing lets an agent buy exactly the data or compute it needs, while the covenant keeps the total under control.

Where a Facilitator or Adapter Fits

In x402, a facilitator is a service that verifies and settles payments so the resource server does not handle blockchain details directly. The x402 project, started by Coinbase, centers on stablecoins on networks such as Base, so Bitcoin Cash is best described as a possible rail rather than an officially supported one.

A community project called x402-bch adapts the protocol to Bitcoin Cash with a specification, Express middleware, an Axios client wrapper, and a facilitator server. In that design, the client sends a batch payment to the server and debits against it across later calls, which cuts the number of on chain transactions, and the facilitator validates payments rather than holding funds. For a capped agent, the flow is simple: the contract releases the allowance, the agent funds a batch with a service, and the service draws it down per request.

When Plain BCH Payments Are Enough

For a simple x402 integration, an ordinary Bitcoin Cash wallet is enough. Fees are typically a small fraction of a cent, and transactions propagate within seconds, which suits small payments. Optional CashTokens NFTs can even serve as on chain receipts for prepaid batches, though a local log covers most needs.

CashScript earns its place when the stakes rise. If an agent runs unattended, holds funds overnight, or reads untrusted content from the web, an enforced limit turns a possible disaster into a bounded loss.

A Practical Setup Checklist

This order keeps risk low while a team learns the pattern:

1. Write the allowance contract in CashScript and test it on chipnet, the Bitcoin Cash test network.
2. Keep the reclaim key offline and away from every machine the agent runs on.
3. Set a period and pledge that match real usage, such as one day of expected API calls.
4. Account for the miner fee, since the guide examples use a hard coded fee value.
5. Connect the agent wallet to x402 services through a reviewed facilitator or adapter.
6. Log every request and payment, and compare the logs against contract releases.

Contract code deserves careful review. A mistake in a covenant is enforced just as strictly as a correct rule, so audits and small test deployments are worth the time.

Freedom Tech Without the Card on File

This approach is freedom technology in a practical form. The owner keeps self custody of the main balance. No processor sits in the middle deciding whether an agent may buy a dataset, and no card number spreads across vendor databases.

The rules are public, the enforcement is open, and the owner can take everything back at any moment. Instead of asking permission from a platform, the operator sets the limits directly and lets mathematics hold them in place.

Giving an AI agent money does not have to mean giving it the keys to everything. A CashScript covenant can release a fixed allowance, cap each payment, and return the rest to a contract the owner controls. Paired with x402 style per request payments, the agent can buy what it needs from open services while a buggy or hijacked agent stays boxed in by rules that every node enforces. Start small, test on chipnet, and let the contract carry the trust.

This article is educational and is not financial or legal advice.

What a small paid task market is

A task market lists jobs with a clear input schema, an output schema, a price or price rule, a deadline, and acceptance criteria. Buyer agents post jobs or browse catalogs. Seller agents claim work they can finish inside the stated constraints. Settlement happens when delivery meets the criteria or when a dispute path resolves the case. The market can be a single coordinated service or a thin set of HTTP conventions across independent hosts.

Small is intentional. Early markets work better with a handful of job types, one or two payment rails, and strict size limits on payloads. Breadth can grow after repeatable delivery and refund behavior exist. A sprawling catalog with vague prompts recreates freelancing chaos inside automation and burns budget on retries.

Humans still set policy: which sellers are trusted, maximum spend per hour, and which job categories are allowed. Agents execute inside those rails. The market is infrastructure for priced coordination, not a substitute for organizational judgment.

Pricing patterns that agents can evaluate

Fixed prices per job type keep buyer logic simple. A seller publishes “caption up to N images for amount X” with hard caps on resolution and format. The buyer compares X to its internal value estimate and either pays or skips. Fixed prices pair well with HTTP 402 challenges and prepaid credits.

Tiered prices help when input size varies. Charge by token count, megabyte, or row count with a published formula and a ceiling. Agents must see the quote before funds move. Open-ended “we will bill what it takes” pricing is a poor fit for autonomous buyers that need deterministic spend caps.

Auctions and dynamic bids are optional later features. They add latency and strategic complexity. Most internal or partner markets never need them. If you add bidding, freeze the winner price in a challenge identifier so settlement cannot drift after the buyer commits.

Quote freshness and fees

Quotes should expire. Stale quotes cause sellers to lose money when input costs move, or buyers to overpay when sellers would have discounted. Include the quote expiry in the job offer and in any 402 challenge. State whether marketplace fees sit on top of the seller price or come out of it, and show the all-in amount to the buyer agent.

Currency choice matters for automation. Stable units reduce quote churn. If you settle on chain, document network fees separately so agents do not confuse gas with the job price. If you settle on a ledger credit inside the market, publish the top-up process and the minimum balance sellers and buyers must hold.

Delivery proof without theater

Delivery proof is evidence the seller produced outputs that match the schema and acceptance checks. At minimum the market stores the job id, input hash, output hash or content-addressed pointer, timestamps, and the seller identity that claimed the job. Buyers retrieve outputs through the market or a signed URL after payment clears.

Automatic checks catch many failures: JSON schema validation, row counts, image dimensions, forbidden string patterns, and embedding-similarity floors against a reference. Checks should be published beside the job type so sellers test before claiming. Surprises at acceptance time create avoidable disputes.

Human review remains a backstop for subjective quality. Route only flagged jobs to a reviewer queue. Do not require a person on every five-cent task or the economics collapse. For subjective work, define rubrics with examples of accept and reject so reviewers and seller agents share expectations.

Content addressing and receipts

Hashing inputs and outputs makes later arguments concrete. If both parties can re-hash the bytes, debates shift from “I sent it” to “these bytes failed check twelve.” Storing receipts in an ordinary database is enough for most markets. Public content-addressed storage is optional for open audits or cross-organization citation.

Signed receipts from the market operator help buyers expense the job and help sellers prove completion to their own accounting. Include job id, amount, parties, and output digest. Keep signatures boring and well documented so agent runtimes can verify them in one library call.

Simple dispute paths

Disputes happen when automatic checks pass but the buyer still rejects the work, when checks fail after payment, or when a seller misses the deadline. A simple path is enough to start: buyer opens a dispute with a reason code within a short window; funds stay in escrow; seller may upload one revision; if still unresolved, a market moderator or pre-agreed arbiter decides release, refund, or split.

Reason codes should be a closed list: schema_fail, deadline_miss, policy_violation, quality_fail, duplicate_delivery, other. Free-text alone is hard for agents to branch on. Attach the failing check id when a validator fired. Time-box every stage so escrow cannot sit forever.

Abuse controls matter. Buyers that dispute at extreme rates lose privileges. Sellers that miss deadlines repeatedly lose ranking or access. Publish the rules in machine-readable form as well as prose so agents can simulate risk before claiming a job.

Escrow, payment rails, and agent wallets

Escrow holds buyer funds until acceptance or dispute resolution. The market operator or a specialized facilitator can hold escrow. Agent wallets need scoped keys, spend ceilings, and allowlists of market contracts or HTTP endpoints. Keys with unlimited drain authority have no place in production agents.

Payment can ride x402-style HTTP challenges, prepaid balances inside the market, or invoices settled in batches for trusted pairs. Pick one primary path for the small market and document it. Multiple rails are fine later when volume justifies the engineering.

Refunds should be first-class API operations with the same idempotency care as charges. Agents retry. Double refunds and double captures are classic failure modes when handlers are not idempotent.

Catalog design and discovery

Each job type needs a stable identifier, version, input schema, output schema, price rule, max runtime, and required seller capabilities. Buyer agents search by capability tags rather than by natural-language guesswork alone. Sellers advertise capabilities they actually support in continuous integration tests.

Versioning prevents silent breaks. When a schema changes, bump the job type version and leave the old version available until traffic drains. Agents pin versions in their plans the same way they pin package versions in software builds.

Discovery feeds can be a simple HTTPS index.json updated on a schedule. Fancy semantic search helps only after the catalog is clean. Garbage descriptions with strong search still yield garbage matches.

Operational metrics worth watching

Track time-to-claim, time-to-deliver, automatic accept rate, dispute rate by job type, refund volume, and seller concentration. Concentration risk appears when one seller finishes most jobs and then goes offline. Encourage a second seller for each critical job type before you depend on the market in production paths.

Budget burn per buyer agent should alert humans when spend spikes. Autonomy without spend telemetry is how quiet failures become expensive failures. Pair economic alerts with technical latency alerts so you see both stalled jobs and runaway success that costs too much.

Trust onboarding for seller agents

New seller agents should pass a dry-run suite before they can claim paid jobs. The suite posts sample inputs, checks outputs against validators, and measures latency. Sellers that pass receive a capability badge in the catalog. Buyers can filter for badges when the job is sensitive or when spend is high.

Identity can start simple: an API key bound to an organization, a registered callback URL, and a payout destination. Stronger setups add signed agent attestations or hardware-backed keys. Match identity strength to payout size. Micropayment sellers do not need the same bar as agents that receive large escrow releases.

Offboarding must exist too. When a seller key is compromised, the market revokes claim rights quickly and freezes unsettled escrow for review. Document the revocation API so buyer agents can refresh trust lists on a schedule.

Putting the pieces together in a pilot

A sensible pilot picks three job types, one payment rail, one escrow holder, and two seller teams. Run synthetic buyers for a week with tiny prices. Verify that quotes expire correctly, proofs land once, disputes time out, and metrics dashboards show accept rates. Only then connect a real production buyer agent with a low spend ceiling.

Write the pilot retrospective in prose humans read and in a machine-readable config of what stayed. Promote the config into your market's default templates. Markets improve when operational lessons become defaults rather than folklore in chat threads.

Conclusion

A small paid task market gives agents a bounded way to buy and sell discrete work: clear job types, prices agents can evaluate, delivery proof tied to schemas and hashes, and a short escrowed dispute path when checks disagree. Start narrow, keep quotes fresh, instrument accept and dispute rates, and wrap wallets in hard spend limits. Those patterns are enough to run useful agent-to-agent commerce while ordinary databases, moderators, and payment partners handle the parts that still need durable institutions.