Skip to main content
The configuration examples below use simplified pseudo-code (for example, new StaticAddressCondition(args) or new AndCondition([list])) to illustrate how conditions compose. In practice, deploy conditions via their respective factory contracts using viem. See the Deploy an operator guide for executable code.

Example 1: Standard E-Commerce with 7-Day Escrow

Use Case: Online marketplace with buyer protection. 7-day escrow period, payer can freeze for 3 days, receiver or arbiter can capture after escrow.

Complete Configuration

1

Deploy Arbiter Condition

2

Deploy EscrowPeriod

3

Deploy Freeze

4

Create capture condition

5

Deploy Operator

Payment Flow


Example 2: Instant Payment (Using Charge)

Use Case: Digital goods or services where the seller expects immediate payment.

Configuration

Payment Flow

Trade-offs:
  • Single transaction, no separate authorize step
  • Instant delivery for digital goods
  • Better UX: seller gets paid immediately
  • No buyer protection escrow period
  • Payment moves to the captured state right away

Example 3: Physical Goods with Extended Escrow

Use Case: International shipping with 14-day escrow and 5-day receiver freeze period.

Configuration

Payment Flow


Example 4: Service-Based Payments (Milestone Capture)

Use Case: Freelance work with milestone-based releases. Receiver can trigger partial releases.

Configuration

Payment Flow


Example 5: Arbiter-Controlled Escrow

Use Case: Fully managed escrow service where arbiter controls all actions.

Configuration

Factory-level fees still apply (MAX_TOTAL_FEE_RATE and PROTOCOL_FEE_PERCENTAGE). This example assumes protocol takes no cut at factory level.
Use cases:
  • Professional escrow services
  • Legal settlements
  • High-value transactions requiring oversight

Example 6: Receiver-Initiated Refunds

Use Case: Receiver can offer refunds (for example, a return policy).

Configuration

Payment Flow


Example 7: Subscription Payments

Use Case: Recurring payments with automatic charge capability.

Configuration

For subscriptions with dispute resolution, deploy an arbiter condition and use it for refund conditions. This example shows a simple subscription without arbiter.
Authorization Expiry for Subscriptions: When authorizing, set authorizationExpiry to limit how long the service provider can charge. For example, a 12-month subscription would set expiry to block.timestamp + 365 days. After expiry, the payer can reclaim any unused funds by calling void().

Payment Flow


Example 8: DAO Treasury Controlled

Use Case: DAO manages grant releases via multisig governance. No arbiter needed: the DAO is the authority.

Configuration

Payment Flow

Benefits:
  • Governance-controlled releases
  • No third-party arbiter needed
  • DAO earns fees back to treasury
  • On-chain transparent decision making

Example 9: Platform-Controlled Streaming Payments

Use Case: Platform manages time-proportional streaming payments. Users can cancel anytime.

Configuration

Payment Flow

Benefits:
  • Time-based fairness (can’t charge ahead of time)
  • User can cancel anytime
  • No arbiter needed
  • Platform controls no disputes

Example 10: Self-Service Invoice Payment (No Arbiter)

Use Case: B2B invoice payments with no disputes. Companies trust each other directly.

Configuration

Payment Flow

Benefits:
  • Trusted B2B relationship (no arbiter overhead)
  • Standard payment terms enforced on-chain
  • Receiver can self-correct invoice errors
  • Platform monetizes via fees only

Fee Configuration Comparison


Configuration Checklist

Before deploying, verify:
  • Freeze policy suits your use case
  • Escrow period is appropriate for delivery time
  • Capture condition prevents premature captures
  • Refund conditions allow arbiter intervention
  • Fee rates are competitive and sustainable
  • Protocol fee percentage is reasonable
  • Tested on testnet with same configuration
  • A trusted party controls the arbiter address (preferably multisig)
  • Verify condition contracts on the block explorer

Testing Your Configuration


Best Practices

Use well-tested configurations for your first deployments:
  • Standard 7-day escrow
  • 3-day payer freeze
  • Arbiter-only refunds
  • Low fee rates (3-5 bps)
Research competitors’ escrow periods and fees:
  • E-commerce: 3-7 days typical
  • Freelance: 3-14 days per milestone
  • High-value: 14-30 days common
Test your configuration handles:
  • Immediate capture attempts
  • Freeze during escrow
  • Freeze expiry
  • Refunds in both states
  • Fee distribution
  • Partial charges followed by capture
Keep records of deployed configurations:

Next Steps

PaymentOperator

Review contract methods and security features.

Conditions

Learn more about custom conditions.

SDK Examples

Run working TypeScript examples for each role.

Deploy an Operator

Deploy these configurations using the SDK.