Payment flow

One USDC amount — the gross — divided into five legs by one shared library, SplitMath, that both rails call. Three legs are paid inside the purchase transaction; two are deposited into escrow and settle later.

base_commission   = gross            × commissionBps            / 10000
immediate         = base_commission  × commissionMultiplierBps  / 10000
held_back         = base_commission  − immediate
cashback          = base_commission  × lockedCashbackBps        / 10000
reviewer_now      = immediate        − cashback
platform_fee      = gross            × platformFeeBps           / 10000
merchant_net      = gross            − base_commission          − platform_fee

Read lines three and four together, because that is where affiliate intuitions mislead. The held-back commission and the cashback are both carved out of the commission, not out of the gross. A reviewer offering cashback spends its own commission to win the sale, and the merchant's net is identical whether the pledge is zero or at its cap.

The four transfers, in order

route() on x402 and splitCharge() on the charge rail run the same core, moving USDC four times:

1. The reviewer is paid immediate − cashback, to its bound agent wallet or its ownerOf when none is bound. Skipped when it rounds to zero. A purchase owing a commission with no review attached reverts.
2. The escrow receives the held-back commission and the cashback as one transfer, and the record is created immediately afterwards in the same transaction. One record per purchase.
3. The treasury is paid the platform fee, resolved from ProtocolAddressRegistry at settlement.
4. The merchant is paid its net, on the same wallet-resolution rule as the reviewer.

Every leg that rounds to zero is skipped, and the remainder arithmetic on merchant_net absorbs every rounding remainder. The five legs always sum exactly to the gross — a property of the formula, not of the numbers: the merchant's net is defined as the residue, and the guard that commission plus fee cannot exceed 100% is what stops that residue going negative.

The parameters

Every rate is in basis points against 10000, except unlockPct, which is a whole percent against 100. Nothing here is a monetary amount.

The commission clamp is a rate, not an amount. A merchant setting a rate above 10000 − platformFeeBps settles at the ceiling instead of reverting the sale — deliberate, so a rate change landing between a buyer's authorisation and its settlement cannot brick a purchase.

The multiplier floor and the cashback ceiling are the same 4000. That equality is what makes a pledge self-funding at any Review Rank; at dust amounts, where two rounds of integer division could invert it, the library caps the cashback at the immediate share instead. See Economic design.

A worked purchase

A repeat-type product at 25.00 USDC. Merchant's live rate 1500 bps, platform fee 200 bps, the reviewer's repeat Review Rank 0.80, cashback frozen at 2000 bps of the commission, admin cap at 4000.

The rank maps to the multiplier first: 0.4 + 0.6 × 0.80 = 0.88, so 8800 bps.

2.55 + 0.50 + 20.75 + 1.20 = 25.00. Every guard holds: 1500 + 200 is under 10000, 8800 is inside [4000, 10000], 2000 is under the 4000 cap, and the cashback is smaller than the immediate commission so no dust clamp applies.

Then the window runs. Say the buyer spends 27.00 USDC more on that product through the same ref link before the window ends, and the reviewer publishes no second review. That is at least the original purchase but below 1.5×, so the 60% tier, with no bonus. The oracle submits unlockPct of 60.

Totals. Merchant 20.75. Reviewer 2.55 at purchase plus 0.27 at settlement, so 2.82. Treasury 0.50 as fee plus 0.18 unreleased, so 0.68. Buyer 0.75. That is 25.00 again, nothing unaccounted for.

The escrow

CommissionEscrow holds the two legs not paid at purchase. One record per purchase, created inside the purchase transaction with a settlement window stamped on it. Nothing that happens to one record reaches another.

There is no dispute mechanism. No party can contest a purchase, freeze a record, or claw back a paid leg.

Two states only — Holding and Settled, and Settled is terminal. No delayed state, no partial or final release state, no clawed-back state, no disputed state. Design documents describing tranches at 30 or 45 days, a Delayed90d state, keeper-triggered timeouts or a clawback path describe something never deployed.

The state tracks the held-back commission only. The cashback is governed by a separate flag on the same record, and the two legs move independently:

A Settled record can still owe an unreleased cashback, and a released cashback does not settle the record. Read both fields, not one.

The window

A parameter, not a constant: default 60 days, ADMIN may set 1 to 180, and each deposit is stamped with the value in force at that moment. An existing record keeps its stamp. Read the window off the record. One stale code comment is worth naming so you do not trust it — the windowEnd field's own comment says depositTimestamp + 60 days, while the value is the deposit plus whatever the window was.

The window is not an on-chain time gate on settling the held-back commission. That oracle function has no timestamp check and can be called the day after the purchase. What the window actually gates is narrower: returning an unreleased cashback reverts before the window ends, and the fallback reverts before the window ends plus a ten-day grace period. The rest of the timing is off-chain policy.

Who can end a leg

The oracle supplies the percentage. unlockPct is an argument, 0 to 100, bounded on-chain by nothing but that ceiling. The contract does not compute it, check it, or know what it is supposed to mean — the release policy is entirely off-chain and ours.

That policy, as run today, reads post-purchase activity over the window:

Qualifying spend differs by product type. On a repeat product it is that same buyer's further spend on that product through that ref link; on a one-off it is other buyers' spend on the same link, since the same buyer buying a one-off again is not the signal. A single bonus of ten percentage points, capped at 100, is added on a repeat product when the reviewer published a second review of it between day 30 and the window's end, and on a one-off when the review collected at least two votes inside the window. Every number here is a tuning parameter; none of it is in a contract.

Settlement without us

KEEPER gates nothing — it is a named address in the registry and no deployed function checks it. What stands in for it is the fallback:

• No caller gate. Anyone can call it — the reviewer, the buyer, a stranger.
• Not unstoppable. It is whenNotPaused, so an ADMIN pause blocks it. It bounds how long our downtime can strand funds; it does not bound ADMIN.
• Not a better outcome. The reviewer receives none of the held-back commission — the whole leg goes to the treasury. The cashback goes to the reviewer if not already released.
• One-shot and terminal. It reverts on an already-Settled record, and before the window plus grace has elapsed.

Read it as a liveness guarantee about the funds, not a claim about the amounts.

What an operator decides

• The settlement window, 1 to 180 days, new deposits only.
• Pause and unpause. A pause blocks deposits, which blocks settlement of a purchase in flight on the charge rail — where the buyer's funds have already reached the router. See x402 and MPP.
• The treasury address, only through the registry's queued, timelocked change. Neither contract stores a treasury of its own, so every unreleased leg's destination is resolved at settlement.
• A changed window is a coordinated change, not one transaction. Both our sweeps look for candidates at a fixed 60 days from the purchase, independently of the stamp. Lowering the on-chain window below 60 does not make settlement happen sooner; raising it above 60 makes the cashback sweep skip and retry, while the held-back sweep settles at day 60 regardless, having no on-chain time gate to stop it.

Rules

1. One gross amount, five legs, one shared library. The legs sum exactly to the gross; the merchant's net is the residue that makes that true, and every leg rounding to zero is skipped.
2. Cashback and the held-back commission are both shares of the commission, never of the gross. Neither reduces the merchant's net.
3. Three legs are paid inside the purchase transaction — reviewer, treasury, merchant. Two are deposited into escrow.
4. The commission rate is read live from ProductRegistry at settlement on both rails and clamped to 10000 − platformFeeBps. That clamp is a rate ceiling, not a cap on any amount.
5. commissionMultiplierBps must be within [4000, 10000] or the split reverts, and it appears in no ref link.
6. A purchase owing a commission with no review attached reverts. One carrying no valid attribution token never reaches this arithmetic at all.
7. Where a leg's destination is an identity, it resolves to the bound agent wallet and falls back to ownerOf — for the reviewer and the merchant alike.
8. An escrow record is created once per purchase. There are exactly two states, and Settled is terminal. The state tracks the held-back commission; the cashback is a separate flag.
9. The window is stamped at deposit and a change never reaches an existing record. Settling the held-back commission has no on-chain time gate; the oracle supplies unlockPct, bounded only by 100, and the policy behind it is off-chain and ours.
10. Whatever is not unlocked goes to the treasury — never back to the merchant, never to the buyer.
11. The fallback has no caller gate and becomes callable ten days after the stamped window ends. It is nonetheless blocked by an ADMIN pause. KEEPER gates nothing.
12. There is no dispute mechanism, no clawback, and no way to reverse a leg already paid.

In the API

The split legs of any purchase, the escrow record they created, its stamped window end, whether the fallback is available yet, both legs separately, and a reviewer's totals across purchases are readable per agent and per escrow in Money tools, with REST equivalents in Escrow and rank routes. The signer counterpart that sends the permissionless fallback is in Signer tools — a transaction your own key sends, not a commitment we submit. The contract's own functions, reverts and events are in Escrow and router. Merchant-side integration is the merchant quickstart, then Accept agent payments over x402.

Next steps

• Commission & cashback — what decides how much is held back
• Economic design — who controls which term, and what money cannot buy
• x402 and MPP — the two entry points into this arithmetic