Conditional stablecoin payments fire only when a defined trigger fires first: an onchain event, an oracle-fed data point, an off-chain webhook, or a time boundary. The protocol you pick depends almost entirely on where that trigger lives. A webhook-driven payroll release needs different rails than an oracle-settled claim or a second-by-second salary stream. This guide ranks seven protocols for conditional stablecoin payments by trigger coverage and settlement guarantees, so you can match the right primitive to your payment logic instead of bolting a general-purpose bridge to a Zapier flow. Each entry covers what it does well, what it misses, and where it fits in a trigger-source decision tree. You will also see how Eco Routes treats "intent expires unless filled" as a native conditional primitive, which removes an entire class of escrow plumbing from the integration.

Every conditional payment is three questions: what is the trigger, how is settlement guaranteed, and who holds the funds between authorization and release? Those three answers eliminate most of the market. If your trigger is a timestamp, a streaming protocol wins. If the trigger is an onchain event from a contract you control, an intent protocol with a deadline will be cheaper and more atomic than an oracle. If the trigger lives on your server (a webhook from Stripe, Shopify, a KYC vendor), you need a signed message path or a verifier that reads off-chain data. For a broader view of the automation landscape, see how stablecoin automation platforms categorize triggers and workflows.

Before the ranking, here is the decision tree in plain text. Picture a flow chart branching four ways. First branch: "Is the trigger onchain?" If yes, ask "Is it deterministic?" If yes, use an intent protocol with an expiry (Eco Routes) or an optimistic oracle for contested outcomes (UMA). Second branch: "Is the trigger an external dataset?" If yes, use an oracle that writes results onchain (Chainlink Functions). Third branch: "Is the trigger time-based?" If yes, use a streaming protocol (Sablier, LlamaPay, Superfluid). Fourth branch: "Is the trigger an off-chain business event like invoice approval?" Use a conditional invoice protocol that resolves the event off-chain and posts settlement instructions (Request Finance). If you need two triggers in one payment, you need a protocol that can nest them, and most cannot. Suggested alt text for this diagram: "Decision tree mapping four trigger sources to their matching conditional payment protocol with Eco Routes at the deterministic-onchain leaf."

Eco Routes treats every transfer as an intent: the user signs "pay X on chain A if Y on chain B by time T," and Solvers compete to fill it. Three pieces of that sentence are conditional by construction — the amount, the destination state, and the expiry. If a Solver does not fill before the deadline, the intent voids and the user's funds remain untouched. That makes "intent expires unless filled" a first-class conditional primitive rather than a feature bolted on with escrow. For developers moving USDC, USDT, or USDG across Ethereum, Base, Arbitrum, Optimism, Polygon, Solana, or any of the fifteen supported chains, the deadline replaces an entire custodial escrow layer. Read the step-by-step in the guide to publishing an Eco Routes intent. The architecture draws on the ERC-7683 standard, which has become the reference for cross-chain intents and is documented in the public EIP-7683 specification. For a conceptual primer, see what is a blockchain intent.

Chainlink Functions lets a contract call an arbitrary off-chain API (REST, GraphQL, anything your DON node can reach) and use the returned value as the trigger for a payment. If your condition is "pay the freelancer when Stripe marks the invoice paid" or "release the escrow when the shipment API returns 'delivered'," Functions is the canonical path. The tradeoff is latency and cost: every fetch pays decentralized oracle network fees, and the response is batched at block cadence rather than live. For high-frequency conditions you will want to debounce at the API layer. Chainlink publishes reference patterns in its official Functions documentation, and CoinDesk's launch coverage frames the product in context. Pair Functions with a downstream settlement protocol if you need atomic cross-chain payout, since Functions itself only triggers — it does not move stablecoins across chains.

UMA inverts the oracle model. Rather than pay for every read, a proposer posts an answer, and anyone can dispute within a challenge window. If nobody disputes, the answer is accepted; if someone does, a token-weighted vote resolves it. That is exactly the pattern you want for conditions that are humanly verifiable but expensive to pipe onchain: "did the marketing campaign hit 10k signups," "was the delivery accepted," "did the court ruling land." Payment is conditioned on the accepted answer, and the challenge window creates a natural grace period for refunds. UMA's protocol documentation walks through the request-propose-dispute loop. Use UMA when you accept minutes-to-hours latency in exchange for adjudicated truth. For stablecoin payouts tied to insurance or prediction-market resolution, nothing else covers the long tail of one-off conditions this cleanly. The design sits closer to an arbitration layer than an event bus.

Sablier streams a stablecoin balance linearly between two timestamps. The condition is time itself: the recipient can withdraw whatever portion of the stream has elapsed, and the sender can cancel what remains unvested. That covers a surprising number of real payment patterns — vesting, salary, subscription credits, milestone drip-feeds. Because the accounting is a single linear equation resolved at read time, no per-second transaction is needed; gas is paid only when someone actually withdraws. The model is documented in Sablier's protocol concepts. Combine Sablier with an onchain event trigger to get "stream only if condition held true at checkpoint," but note that Sablier itself does not supply the event layer. It pairs well with UMA for milestone vesting where release gates need human verification, and it pairs poorly with multi-chain flows because streams live on a single chain.

LlamaPay is Sablier's leaner cousin: one contract per payer, amortized withdrawals, and bare-metal costs. The design target is recurring payroll — DAO contributors, remote teams, retainer structures. Every withdrawal is a single ERC-20 transfer from a pre-funded balance, and the protocol's open-source code has kept its footprint minimal since launch. LlamaPay's documentation site publishes the contract addresses and integration flows. For teams paying 5 to 500 contributors in USDC or USDT every month, LlamaPay's per-stream gas cost tends to beat competitors by a meaningful margin at scale. Its weakness is the same as Sablier's: one chain per stream. If your organization holds treasury on Base but contributors hold wallets on Arbitrum, you need an execution layer in front of LlamaPay. That is where an intent protocol bridges the gap — contributors specify their preferred chain and a Solver delivers, with LlamaPay handling the vesting curve.

Superfluid extends streaming with programmable callbacks: when a stream starts, stops, or crosses a threshold, the protocol can fire a "super app" hook that executes other contract logic. That turns time-based streams into composite triggers. You can write rules like "if the monthly stream exceeds $10k, route 10% to a reserve address," or "if the stream stops, auto-claim a vesting cliff." The Superfluid documentation explains Super Tokens and the instant-distribution agreement, and The Block's coverage situates the protocol against traditional payroll stacks. Superfluid trades simplicity for expressiveness; super apps need audited callback code and careful gas budgeting. Use Superfluid when streaming is just the scaffold and the real logic lives in the hooks. For programmable treasury flows, this composability aligns with the programmable treasury compliance model that gates at the point of execution.

Request Finance connects invoice workflows — approval, PO matching, tax metadata — to stablecoin settlement. The condition here is a business event: "invoice approved by Finance," "milestone signed off by project lead," "expense receipt validated." Once the off-chain event lands, Request posts a payment instruction that the payer signs, and the stablecoin transfer fires. The platform supports multi-chain settlement across USDC, USDT, and EURe, and it emits accounting-grade records that feed ERP imports. Request's network documentation covers the conditional invoice patterns. The tradeoff is that Request is a hosted product with a trust assumption in its approval layer — the blockchain sees the result, not the decision. For enterprises that need auditability at the approval stage, this is a feature; for fully trust-minimized flows, combine Request's off-chain workflow with UMA for the verification step.

Real-world payments often need two triggers: a time window plus an event. Picture a grant that streams for six months but can be paused if the recipient misses a milestone. No single protocol on this list handles both. The pattern that works is to use a streaming protocol as the base and an oracle or intent layer as the gate — Sablier plus UMA, or Superfluid hooks plus Chainlink Functions. When stablecoins need to cross chains in that composition, an intent layer like Eco Routes plays the bridge-and-settle role without adding custody risk. For a wider map of how solvers and orchestration interlock, the cross-chain intent protocols comparison lays out the execution fabric under these patterns. If the condition gates regulated stablecoin flows, compliance at execution becomes a fourth axis — a conditional payment that clears KYC at authorization but fails at settlement is not compliant, it is unsettled.

Not all "conditional" protocols settle atomically. A few fire the trigger onchain but rely on a hosted relayer to move funds, which means a silent failure path if the relayer goes down. Before you commit, ask three questions. Does the protocol hold funds in an escrow contract or a multisig? Is there a refund path if the trigger never fires? Is settlement atomic with the trigger event, or is there a window where the trigger fired but the transfer is pending? Intent-based designs answer these cleanly because the Solver's bond guarantees fill or refund. Streaming protocols answer these cleanly because no custody is transferred until withdrawal. Oracle-triggered systems often do not, because the payment contract and the oracle are separate primitives that can desync. This is part of why crypto intents have taken ground in payment automation — the deadline and the fill are the same transaction.

For a two-person team wiring a single conditional flow, Sablier or Request Finance will get you to production in a week — hosted UIs, well-documented contracts, minimal custom code. For a platform team running recurring payroll across chains, LlamaPay plus an intent protocol is the lightest-weight pair. For a finance-ops team that needs audited approval gates, Request Finance covers the invoice half and a settlement layer covers the transfer half. For a protocol team building conditions into a product, Eco Routes plus Chainlink Functions gives you "trigger on external data, settle cross-chain with atomic guarantees" in one integration pass. The Routes CLI can be bootstrapped with a handful of commands — clone the repo, build, and call pnpm dev publish --source optimism --destination base — and the same interactive wizard supports chain selection, token selection, and configuration review. Pair it with a Functions subscription for the external-trigger step.

A conditional stablecoin payment only executes when a defined trigger fires — an onchain event, oracle data point, time boundary, or off-chain webhook. The protocol holds or schedules funds until the trigger resolves, then releases them, removing the need for a custodial escrow step.

Sablier, LlamaPay, and Superfluid are purpose-built for time-based streaming. Sablier suits vesting, LlamaPay suits high-volume payroll, and Superfluid suits composable flows where stream events fire other contract logic. Pick based on callback needs and gas budget rather than feature parity alone.

Every Eco Routes intent includes an expiry. If no Solver fills the intent before the deadline, it voids and funds stay with the user. That gives you "pay only if filled by time T" as a native primitive, with no separate escrow contract. The mechanic builds on the cross-chain intents standard described earlier in this guide.

Yes — many real flows need "time plus event." Use a streaming protocol as the base and layer an oracle or intent protocol as the gate. Composition patterns tend to hold up cleanly when each layer has its own settlement guarantee, rather than relying on a hosted relayer between them.

Escrow is one implementation of a conditional payment — a third party holds funds until conditions are met. Modern protocols can replace custodial escrow with smart contract expiry, oracle-triggered release, or intent-filled deadlines, removing a trust assumption. Smart-contract expiry removes the trusted third party without removing the guarantee, which is the shift that lets payment logic sit entirely in code.