The short answer
Agent spending and accepted-action payouts are a policy and evidence problem before they are a rail problem. Cryptuon runs a controlled pilot: we write down what an agent or programme may pay, to whom, for which accepted action, with which approver and dispute window, then connect it to a payment rail you can use today and prove that every payment reconciles. Payment authority stays bounded and explicit, and people approve anything outside the policy.
For customer funds, that rail is existing infrastructure: x402 tooling, a regulated stablecoin payout provider, or your current partner platform. Cryptuon’s own escrow protocol, Njord, is used only as a devnet reference while its mainnet deployment waits on an audit.
Decision criteria
The questions that decide cost and approach:
What exactly is an “accepted action”, and who verifies it?
“Pay per action” is only as good as the definition of the action. A conversion might mean a signup, a first paid invoice, or an invoice that survived the refund window. Each has a different fraud profile and verification cost. For agent spend, the action is usually a delivered response; for contributor payouts it is a merged change, a qualified lead, or a completed task. The pilot records the evidence for each action (invoice ID, attribution model, reviewer) so that finance can answer “why was this paid?” without a rebuild. If verifying the action costs more than the payment is worth, per-action payment is the wrong model, and the assessment says so.
How much authority does the agent or programme get?
Write it down as numbers: a per-transaction cap, daily and monthly budgets, a recipient allowlist, an auto-approval threshold, named human approvers above it, and a kill switch with an owner. Anything not explicitly allowed is denied. This is the part most teams skip, and it is the part auditors and finance ask about first.
Who carries disputes and reversals?
Card rails optimise for human dispute resolution after payment. Stablecoin transfers are final, so disputes must be handled before release, through a hold period, a challenge window, or both. Njord’s design shows one way to do this: holds that start at seven days for new affiliates and shorten with history, plus a challenge window for suspect conversions. Whatever rail you use, the pilot sets who can open a dispute, who decides it, and what happens to the held payment.
Which rail can you use today, legally and operationally?
- Agent pays for a resource per request: x402. Cloudflare documents x402 support for paid HTTP resources, paid MCP tools, and agent-side payment clients. Its examples use the public facilitator operated by Coinbase, with an
exactscheme on several networks and anuptoscheme (a maximum authorisation, with the final charge set at settlement) on EVM. - You pay many people: a regulated payout provider usually handles payee onboarding and compliance checks better than anything you would build for a pilot.
- Recipients want bank transfers and tax forms: your existing partner platform may be the right answer, with only the accepted-action logic changed.
Payments and money transmission, payee onboarding, and affiliate programmes can need legal review in each jurisdiction. We flag these questions; your counsel answers them.
Is per-action pricing ready?
Charging per action, whether by you to your customers or by us for operations, makes sense only once four things are written down: the action, the cost of verifying it, who is responsible for disputes, and the legal scope. Until then, pilots are fixed-fee.
Implementation options
| Approach | How it works | Strength | Tradeoff | Maturity |
|---|---|---|---|---|
| Controlled pilot (Cryptuon) | Policy, approvals, accepted-action evidence, and reconciliation built around a rail you already can use; Njord as a devnet reference for escrow logic | Payment authority, evidence, and reconciliation are explicit and tested before scale | Adds a policy layer you must own; Njord itself is not usable for customer funds yet | Delivery service; Njord is a devnet program, mainnet pending audit |
| x402 (Coinbase protocol, Cloudflare Agents SDK support) | Server answers 402 Payment Required with terms; the client signs a stablecoin payment and retries; a facilitator verifies and settles | Inline, machine-readable, request-time payment; growing tooling | Two-party per request; conditional payouts, splits, and budgets sit in your code | Emerging; implementations still consolidating |
| Regulated stablecoin payout provider | API call pays USDC to onboarded recipients from your account | Provider runs onboarding, compliance checks, and reporting | Provider fees, supported countries, and onboarding friction; less programmable conditionality | Established |
| Affiliate or partner platform | Platform tracks conversions and pays out, typically in fiat on a cycle | Familiar to partners and finance; tax forms included | Slow payout cycles and platform fees; limited agent support | Established |
| Self-built escrow contract | Your contract holds a funded budget and releases on a verified action | Full control of conditions and splits | You own the audit, key management, upgrades, and on-call | Depends entirely on your audit and operations |
Most pilots end up mixed: x402 for the agent’s outbound spend, a payout provider or partner platform for people, and one policy and reconciliation layer over both.
The delivery sequence
- Map flows. List who pays whom, for what, how often, at what size, and on which rail today.
- Write the policy. Budgets, caps, allowlists, approvers, kill switch, and the default-deny rule.
- Define accepted actions. Evidence, verifier, hold period, dispute window, and recipient requirements.
- Choose the rail. Compare options against your flows and record the open legal questions.
- Build in a sandbox. Integrate on testnet or a provider sandbox, with idempotent settlement and an approval workflow.
- Prove it. Run policy tests, replay tests, a reconciliation run, and a kill-switch drill.
- Run a capped pilot. Limited recipients and budget, a weekly review, then a go/no-go decision.
The policy is a reviewed artefact, not a set of constants buried in agent code. An illustrative example:
# Illustrative pilot policy (format agreed with you). Default: deny.
policy: research-agent-and-contributor-pilot
version: 3
currency: USDC
agent_spend:
rail: x402
per_transaction_max: "2.00"
per_day_max: "150.00"
per_month_max: "2000.00"
recipients:
- id: data-vendor-a
pay_to: "0x1111111111111111111111111111111111111111"
per_day_max: "50.00"
- id: search-api-b
pay_to: "0x2222222222222222222222222222222222222222"
auto_approve_below: "0.50"
approvers: ["payments-ops", "eng-lead"]
approval_timeout: 15m # unapproved requests expire; they never auto-pay
contributor_payouts:
rail: provider-payouts
action: qualified_signup
accepted_when:
- event: invoice.first_paid
- min_days_since_signup: 14
evidence: [invoice_id, referral_code, attribution_model]
dispute_window: 7d
recipient_requirements: [identity_verified, sanctions_screened, wallet_verified]
commission: { type: flat, amount: "25.00" }
kill_switch:
owner: payments-ops
max_halt_latency: 60sThe acceptance tests run against that policy before any payment leaves a sandbox:
// Acceptance tests for the pilot's policy engine and settlement path.
// `evaluate`, `settle`, and `paymentsFor` are the pilot's own modules
// (illustrative names); the rail is a sandbox or testnet.
import { describe, it, expect } from "vitest";
import { loadPolicy, evaluate } from "../src/policy";
import { settle, paymentsFor } from "../src/settlement";
const policy = loadPolicy("policies/pilot.yaml");
describe("agent spend policy", () => {
it("denies recipients that are not allowlisted", () => {
const d = evaluate(policy, { recipientId: "unknown-vendor", amount: "0.10" });
expect(d.outcome).toBe("deny");
});
it("routes payments above the threshold to a named approver", () => {
const d = evaluate(policy, { recipientId: "data-vendor-a", amount: "1.20" });
expect(d.outcome).toBe("needs_approval");
});
it("denies anything above the per-transaction cap", () => {
const d = evaluate(policy, { recipientId: "data-vendor-a", amount: "2.01" });
expect(d.outcome).toBe("deny");
});
});
describe("contributor payouts", () => {
it("settles an accepted action exactly once, however often it is replayed", async () => {
const event = { actionId: "act_7f3c", recipientId: "contrib-42", amount: "25.00" };
await Promise.all([settle(event), settle(event), settle(event)]);
expect(await paymentsFor("act_7f3c")).toHaveLength(1);
});
});And the daily reconciliation check, where any returned row is a break to investigate:
-- Every payment on the rail must map to one accepted action and one
-- ledger entry with the same amount. Rows returned are breaks.
SELECT p.tx_ref, p.amount, a.action_id, l.entry_id
FROM rail_payments p
LEFT JOIN accepted_actions a ON a.action_id = p.action_id
LEFT JOIN ledger_entries l ON l.payment_ref = p.tx_ref
WHERE p.settled_at >= CURRENT_DATE - INTERVAL '1 day'
AND (a.action_id IS NULL OR l.entry_id IS NULL OR l.amount <> p.amount);Evidence
- Njord’s escrow lifecycle, fee split, and devnet program ID are documented in how it works and the Njord documentation. The Njord FAQ states plainly that it runs on Solana devnet, that mainnet is pending, and that the pay-per-action API and x402 adapter are on the roadmap, not shipped.
- How Njord’s escrow model differs from request-time payments is set out in the Njord vs x402 comparison, which also notes that x402 tooling is available today while Njord’s mainnet is not.
- The x402 pattern, stablecoin settlement, and escrow tradeoffs are explained in agentic payments, x402, and on-chain settlement, and in the context of the wider agent economy on /agents.
- Switchboard (documentation) appears in the plan only if a pilot needs multi-chain state. Its latency figures are design targets, and chain coverage has to be verified for each chain pair.
- The evidence level for each project is listed in the maturity register. Both Njord and Switchboard are at “declared”. No third-party audit has been published for either, and neither has been accepted in a paying delivery.
What drives the cost
- Number of rails. x402, a payout provider, and a partner platform each need their own integration, test fixtures, and reconciliation feed.
- Verifying the action. Reading a billing webhook is cheap. Human review, or verifying model output, is not.
- Recipient onboarding. Identity checks, wallet verification, and sanctions screening, usually through a provider.
- Ledger integration. Mapping payments into your accounting system and agreeing on how breaks are handled.
- Dispute handling. Hold periods, challenge workflows, and who staffs them.
- Operating period. Monitoring, daily reconciliation, and incident response once the pilot is live.
Limitations and what we won’t do
- We do not take custody of funds, act as a payment provider, or move money on your behalf. Approvers are your staff.
- We will not put customer funds into Njord, or into any contract without an independent audit, on mainnet.
- We do not give legal, tax, or regulatory advice. Payments, stablecoin payouts, and affiliate programmes may need review in each jurisdiction before launch.
- A pilot proves controls at a capped scale. It does not show that the economics hold at full volume, and the go/no-go pack says what remains unproven.
- If per-action payment does not fit your flows because verification is too costly or disputes are too frequent, the assessment says so and recommends conventional payouts.
Next step
Send us the flows you want to pay for (agent spend, contributor or affiliate payouts, or both), rough volumes, your current payment providers, and your target jurisdictions. The assessment returns a written payment policy, an accepted-action specification, a rail recommendation with open legal questions, and a costed pilot plan.