Skip to main content

Programmable payout rules

B2B payment policies are complex by nature. A single payout may depend on order data from a commerce platform, payment status from a processor, and attribution signals from a third-party service. Each is controlled by a different party, and none can fully trust the others.

AI alone doesn't fix this. Automating these payments or delegating them to an AI agent raises the stakes. Incorrect payments between companies are costly and reversible only with difficulty, and culpability is hard to assign for decisions made by agents.

Smart contracts don't fix this. Rules that depend on live external data can't be evaluated natively onchain. Publishing rules publicly exposes commercially sensitive logic, since a tiered commission structure or a fraud threshold is often as sensitive as the payments themselves. And when policy needs to change, smart contract upgrades are slow, risky, and themselves an attack surface.

delta guardrails provide a solution. Payment policies are defined as domain guardrails, evaluated against live data at settlement time, and proven via ZK proof so the result is auditable ("policy XYZ was satisfied") without the policy content or underlying commercial data ever being published. Policies can be updated when needed, and funds cannot move unless every condition is met.

Example: Affiliate Auto-Payout Domain​

An automated affiliate payout system that enforces merchant-defined policies (refund windows, spend caps, attribution requirements) and pays affiliates in stablecoins only when every condition is cryptographically verified.

Overview​

A merchant defines a payout policy: commission rate by SKU, refund hold period, daily cap per affiliate, self-referral exclusion. The domain pulls order, payment, and attribution data from external platforms, evaluates each conversion against the policy, and pays affiliates in stablecoins automatically.

If settlement should occur on external rails rather than delta, the same proof model still applies: the domain evaluates and proves policy compliance, and the settlement step is handed off. See extending guardrails to external payment rails for how to structure this.

Requirements​

  • Ingest order and refund data from Shopify or WooCommerce
  • Ingest payment status and dispute signals from Stripe
  • Ingest attribution data from a referral platform or UTM/clickstream service
  • Evaluate per-conversion payout eligibility against merchant-defined policy
  • Enforce spend limits, hold periods, and anti-replay per order ID
  • Settle verified payouts to affiliate wallets in stablecoins
  • Keep raw conversion and attribution data off the settlement layer

delta Architecture​

The domain has two components:

Payout application — a backend service that ingests conversion events from commerce, payments, and attribution APIs; evaluates each against the merchant's policy; and queues eligible payouts. It runs the delta Gateway as an embedded Docker container, which handles proof generation and submission to the settlement layer.

Guardrails — Rust rules encoding the merchant's payout policy. When the application submits a payout, the Gateway proves that every guardrail was satisfied. Validators verify the proof without seeing raw order data or attribution details.

Guardrails​

The following conditions must all be proven before a payout is authorized:

  • Attribution validity — a valid attribution signal is present from the designated platform; optional quorum across sources (e.g. order system and attribution platform must both confirm)
  • Refund/dispute hold — the order's refund window has elapsed with no refund or chargeback recorded
  • SKU and campaign eligibility — the order's SKUs and applied discounts fall within the merchant's allowlist
  • Spend limits — the payout does not exceed the affiliate's daily cap or the campaign's weekly budget
  • Recipient binding — the destination wallet is on the merchant's allowlisted affiliate registry
  • Anti-replay — the order ID has not been included in any previous payout run

Technical flow​

Setup: Merchant configures payout policy (rates, caps, hold periods, eligible SKUs), funds the payout vault, and commits a signed intent specifying the policy and amount.

Conversion ingestion: The payout application polls Shopify, Stripe, and the attribution platform continuously. Conversions are queued for evaluation; refunds and disputes update order status in real time.

Payout execution:

  1. A conversion clears the refund window with no disputes
  2. The application evaluates all guardrails against the live data snapshot
  3. The Gateway generates a ZK proof that every policy condition was satisfied — including that attribution is valid — without revealing the underlying order or attribution data
  4. The Gateway submits the proof and payout instruction to the settlement layer
  5. Validators verify the proof and release funds from the vault to the affiliate's wallet

What validators verify: ZK proof of policy compliance for each payout

What is finalized onchain: Stablecoin transfer to the affiliate wallet

What stays offchain: Order details, revenue figures, attribution signals, fraud scores