Built on Arc · USDC-native settlement

The neutral settlement rail for performance marketing

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.

50
conversions settled and paid, one payment each
34
fraud attempts refused on-chain
0
paid to the fraud agent
952 ms
median per-conversion payment

The market runs on mutual distrust

Both sides operate on self-reported dashboards. Disputes are resolved by relationship power, not evidence.

Publishers can't verify advertisers

Conversions happen inside the advertiser's systems. The party that reports the data is the party that pays, and underreporting has no neutral arbiter.

Advertisers can't verify publishers

Fake signups, duplicate conversions and bot traffic drain budgets. Detection today is retroactive, off-chain and opaque.

Settlement is slow and gated

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.

How it works

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.

  1. FundAn advertiser agent funds a USDC escrow and publishes the campaign rules on-chain: price per conversion, budget, per-publisher caps, and the verification policy everyone is judged by.
  2. ClaimPublisher agents submit conversion claims, each carrying a unique fingerprint and a hash of the signed conversion event.
  3. VerifyThree deterministic checks gate every claim: duplicate detection, evidence-hash validation, and timing that has to look human.
  4. PayA verified conversion is paid on its own — instant, gas-free, full amount, no threshold — through Circle Nanopayments.
  5. RefuseFraudulent claims are refused by the contract itself, on-chain, and every attempt is recorded permanently with its evidence.
  6. ReallocateThe advertiser agent watches verified-conversion quality per publisher and shifts budget away from bad traffic on its own, with the reason code on-chain.

What a run proves

A clean rehearsal on Arc testnet (campaign poc-demo-8, from block 53979589) 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 paid50
Recognized in escrow5,000,000 atomic USDC
Equal to the sum of paymentsto the atomic unit
Median per-conversion payment952 ms
Fabricated claims refused on evidence9
Bot traffic refused on timing9
Duplicates reverted by the contract16
Autonomous reallocations1
Paid to the fraud agent0

Every refusal belongs to the fraud agent; no honest publisher claim was refused. Each of the three deterministic checks refused something in that run — the contract reverted the duplicates, evidence-hash validation caught the fabricated claims, and the timing rule caught conversions arriving 300 ms after their click, which is traffic no human generates. See it in the dashboard →

Why Arc

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 toolHow ConvertRail uses itStatus
NanopaymentsOne authorization per verified conversion, settled through the Gateway facilitator.Integrated
GatewayThe paying wallet's balance, off-chain verification, batched on-chain settlement.Integrated
Circle WalletsThe wallet that pays publishers is developer-controlled; it signs every authorization and its key is never in the repository.Integrated
USDC on ArcBudgets, escrow accounting, publisher payouts and gas.Integrated
PaymasterNot applicable: on Arc gas already is USDC, so the escrow provisions publisher gas directly.N/A
Circle ContractsNot used: the three contracts are hand-written Solidity, deployed with Foundry and source-verified.Not used
CCTP / StableFXCross-chain and cross-border publisher payouts.Roadmap

Verification model, honestly

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.

Publisher-side fraud is policed deterministically

Duplicates are refused by the contract itself; fabricated claims fail evidence-hash validation; impossible timing is rejected. Every refusal leaves permanent on-chain evidence.

Advertiser-side is constrained by mechanism

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.

Full symmetry is roadmap

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.