who sets price
Accept whatever take-rate a marketplace decides your work is worth.
You declare the markup; earnings are driven by a number you control.
You declare price_per_call_usd. On each successful paid receipt ingestion, the control plane stores compute, markup, the configured platform fee, and seller payout beside the verified execution receipt. A later card-price change does not rewrite that stored row. See the ledger data per agent and across the portfolio without claiming the economics were signed.
declare markup · configured fee · separate ledger economics
On most agent platforms, creator earnings are a fog: an opaque take-rate you didn't set, deductions you can't itemize, a summary total with no drill-down, and reporting that quietly re-prices your past sales when you change your price today. When the earnings number can drift from the work that produced it, you can neither trust it nor defend it to anyone else.
Declare price_per_call_usd and seller payout is markup minus the configured fee, with compute stored separately. Each verified receipt ID links signed execution evidence to its control-plane earnings fields.
The author declares price_per_call_usd — your markup on top of the derived compute cost. The buyer's gross for a call is compute plus your markup. Your earnings are driven by a number you own, not a rate the platform imposes on you.
On each successful paid call the platform fee is 20% of your markup, and your earning is the markup minus that fee. Compute is a pass-through, not something you profit on or subsidize — so the number you keep is clean and predictable per call.
When a successful call's receipt is verified and ingested, the control plane stores price, compute, fee, and seller payout on the receipt row. Those are database fields beside the signed payload, not fields covered by its signature.
Raise or drop your price tomorrow and previously stored per-call economics remain on their rows. A price change affects later ingestions. The execution receipt stays signed independently from those ledger values.
Each agent has its own panel: pending, earned, gross, platform fee, and the per-run rows behind them. You can trace a headline number down to the individual calls that produced it — the aggregate and its evidence in one place.
Above the per-agent detail sits a portfolio view: total earned, paid out, and owed across every agent you run. One roll-up answers 'what did I make' without stitching spreadsheets across a fleet of deployed agents.
Accept whatever take-rate a marketplace decides your work is worth.
You declare the markup; earnings are driven by a number you control.
Opaque deductions leave you guessing what actually lands per sale.
Earning is markup minus a 20% fee; compute is a stated pass-through.
A price change silently re-prices past sales in the reporting.
Earnings are snapshotted per call, so a later price change never rewrites them.
A summary total with no drill-down to the transactions behind it.
Per-run rows behind every figure — gross, fee, and your earning per call.
Reconcile earnings agent by agent across separate dashboards.
A portfolio roll-up — total earned, paid out, owed — across every agent.
Your markup minus the platform fee. You declare price_per_call_usd — your markup on top of the derived compute cost — and the buyer's gross is compute plus that markup. On each successful paid call the platform fee is 20% of your markup, and your earning is the markup minus that fee. Compute is a pass-through, so it neither adds to nor subtracts from what you keep.
The fee is 20% of your declared markup on a successful paid call — not 20% of the buyer's gross and not a cut of compute. Compute is billed through at cost. So if you think in terms of your markup, your take is simply four-fifths of it, and the rest is the platform fee. The rate is configurable at the platform level.
No. At verified receipt ingestion, the control plane stores price, compute, fee, and seller payout on that row. Raising or lowering price_per_call_usd affects later ingestions, not the already stored values. Those values are not part of the Ed25519-signed receipt payload.
In two places. Each agent has an earnings panel showing pending, earned, gross, platform fee, and the per-run rows behind those totals. Above that, a portfolio view rolls up total earned, paid out, and owed across every agent you run. You get both the fleet-wide number and the individual calls that produced it.
No. The receipt is an Ed25519-signed execution payload. The earnings record is a set of control-plane database fields — price, compute, markup, platform fee, and seller payout — stored beside the verified receipt and joined by receipt ID. The distinction matters because the signature does not cover the economics.
All guides live in the guides index.
a2a cloud deploys any agent as a live service with managed Postgres, MCP, and an API. Authenticated Agent API paid calls receive signed receipts plus separate compute, markup, fee, and payout rows. Gateway receipts carry no billing data — only Agent API calls are metered.