Advertisers and publishers move billions under mutual distrust, on net-30 terms and $50–500 payout thresholds. ConvertRail verifies every conversion by deterministic rules, refuses fraud on-chain in real time, and pays publishers per conversion in USDC — full amount, no threshold. The whole loop runs agent-to-agent, with no humans in it.
Both sides operate on self-reported dashboards. Disputes are resolved by relationship power, not evidence.
Conversions happen inside the advertiser's systems. The party that reports the data is the party that pays, and underreporting has no neutral arbiter.
Fake signups, duplicate conversions and bot traffic drain budgets. Detection today is retroactive, off-chain and opaque.
Net-30 terms and $50–500 payout thresholds persist because per-transaction settlement is expensive. Small publishers are structurally excluded.
Autonomous agents make this worse, not better: an agent's self-reported conversion deserves less trust than a human's, and agents cannot operate on net-30 relationships. “How does an autonomous agent get paid for verified work?” is the native question of the agent economy.
Six steps, all on Arc, all agent-to-agent. Every agent in the money path is deterministic by design — agents that move money need auditable logic, not improvisation.
A clean rehearsal on Arc testnet (campaign poc-demo-12, blocks 55148863–55149663) completed
with no restart, no recovery step, no manual payment and no operator intervention. Every number below is
chain state — you can read it back from the deployed contracts, or watch it in the dashboard.
| Conversions settled and paid | 50 |
| Recognized in escrow | 5,000,000 atomic USDC |
| Equal to the sum of payments | to the atomic unit |
| Median per-conversion payment | 940 ms |
| Fabricated claims refused on evidence | 7 |
| Bot traffic refused on timing | 7 |
| Linked identities refused on the funding graph | 5 |
| Duplicates reverted by the contract | 17 |
| Autonomous reallocations | 1 |
| Paid to the fraud agent, both identities | 0 |
Every refusal belongs to the fraud agent; no honest publisher claim was refused. The fourth class is the one the others cannot see: the fraud agent registered a second publisher identity and funded it from its own wallet, so its conversions are real signed events with human timing and only the funding graph gives it away. Two identities paid for out of one wallet are one operator, and an operator referring itself is not a referral. See it in the dashboard →
Payout thresholds exist because settlement is expensive. Remove the cost of a payment and they have no reason to exist.
A $0.10 conversion cannot be paid individually on invoice rails, or on a general-purpose chain with volatile gas. On Arc, gas is USDC and fees are predictable in dollars, and Nanopayments makes each per-conversion payout instant and gas-free: authorizations are verified off-chain in milliseconds and settlement lands on-chain in batches through Circle Gateway. The chain is the point here, not a deployment target — this product is only economically viable on exactly this stack.
| Circle tool | How ConvertRail uses it | Status |
|---|---|---|
| Nanopayments | One authorization per verified conversion, settled through the Gateway facilitator. | Integrated |
| Gateway | The paying wallet's balance, off-chain verification, batched on-chain settlement. | Integrated |
| Circle Wallets | The wallet that pays publishers is developer-controlled; it signs every authorization and its key is never in the repository. | Integrated |
| USDC on Arc | Budgets, escrow accounting, publisher payouts and gas. | Integrated |
| Paymaster | Not applicable: on Arc gas already is USDC, so the escrow provisions publisher gas directly. | N/A |
| Circle Contracts | Not used: the three contracts are hand-written Solidity, deployed with Foundry and source-verified. | Not used |
| CCTP / StableFX | Cross-chain and cross-border publisher payouts. | Roadmap |
The deep problem is that the conversion event originates off-chain, inside the advertiser's systems — the data producer is the paying party. This does not pretend to solve that with cryptography.
Duplicates are refused by the contract itself; fabricated claims fail evidence-hash validation; impossible timing is rejected. Every refusal leaves permanent on-chain evidence.
A verified claim auto-settles unless the advertiser objects inside the dispute window. Silence is acceptance, so stalling and quietly shaving submitted claims do not work.
Web-proof verification of the conversion event itself (zkTLS-class suppliers), so neither side has to trust the other's systems.
The verifier applies published deterministic rules, with its policy hash committed on-chain and every verdict permanently queryable. That is auditable, not trustless — and we would rather state the limit than blur it.
Levent Ceyhan — Google Ads account strategist, then seven years running performance marketing at Xylem, then independent work in the same field. ConvertRail is a settlement problem watched from inside it: publishers waiting out net-30, advertisers paying for traffic nobody could verify, and both sides arguing from their own dashboards.
AttestRail enforces eligibility and exposure rules over fully encrypted on-chain state on Zama's FHEVM, publishing only the final decision bit and never the attributes behind it — Zama Developer Program, Builder Track winner. Before it, an AML prediction network on Canton let institutions share calibrated risk signals without sharing the data underneath. That is the shape of the confidential referee on this roadmap: a rule applied to inputs neither side wants to reveal, with only the verdict made public.