Automating Recurring Payments with Chia Offers

• Chia Offers are single-use atomic swaps — each Offer is consumed on-chain the moment it is taken and cannot repeat automatically
• CHIP-0041 streaming puzzles enable continuous payments of XCH or CATs over a fixed time period, with built-in clawback protection for senders
• Singleton-based escrow patterns let merchants pull periodic payments from subscriber-funded on-chain vaults using custom Chialisp logic
• Automated Offer generation is the simplest path available today — wallet software creates a fresh Offer each billing cycle without locking funds upfront
• No native recurring payment primitive exists yet at the Chia protocol level, but all three workarounds are production-viable with the right trade-offs understood

Chia Offers cannot repeat automatically because each Offer is a one-time atomic swap that is permanently consumed when taken on-chain.¹ To build recurring payment systems on Chia today, developers use one of three patterns: CHIP-0041 streaming puzzles for continuous XCH or CAT flows, singleton-based escrow where merchants pull funds on a schedule, or wallet automation that generates a fresh Offer every billing period.²

If you’re building a subscription service on Chia Network, Offers might seem like the obvious tool. They handle peer-to-peer asset swaps without middlemen, they’re trustless, and they work for XCH, CATs, and NFTs.¹ But there’s an important limitation to understand: Offers are designed for one-shot trades, not repeating transactions. This tutorial walks you through three practical patterns for chia recurring payments, complete with code examples, honest trade-off breakdowns, and a clear picture of what’s coming next for the ecosystem.

What Are Chia Offers — And Why They Don’t Repeat

How Chia Offers Actually Work

A Chia Offer is an off-chain file that lets two parties swap assets atomically without trusting each other or going through an exchange.¹ When you create an Offer, you produce a signed trade file that says “I will give you X if you give me Y.” The trade completes in a single on-chain transaction — all at once, or not at all. Anyone who holds the Offer file can fulfill it from any compatible wallet.

The mechanism behind this is the settlement_payments puzzle. This Chialisp puzzle creates two types of on-chain conditions: CREATE_PUZZLE_ANNOUNCEMENT conditions that broadcast what payments are required, and CREATE_COIN conditions that produce the actual output coins when both sides are satisfied.³ Because the puzzle enforces that all conditions are met simultaneously, neither party can be cheated — if either side can’t pay, the entire spend bundle fails.

Why Chia Offers Can’t Auto-Repeat

The limitation is fundamental, not a bug. Once someone takes your Offer and the transaction confirms on-chain, those specific coins are spent — permanently consumed.¹ The Offer file itself becomes invalid immediately. Think of it like a paper concert ticket: once scanned at the door, it cannot get you into tomorrow’s show. You need a brand new ticket each time.

Chia Offers are one-shot atomic swaps by design, not recurring payment instruments. There is no “run this Offer again next month” setting at the protocol level. Building subscription services therefore requires either a different on-chain primitive, or off-chain automation that generates fresh Offers on a schedule.

Three Methods for Chia Recurring Payments

The Chia developer community has identified three viable patterns for recurring payments. Each has different trade-offs around capital lock-up, automation level, and implementation complexity. Here’s a quick-reference comparison before we dig into each one.

Method 1: CHIP-0041 Streaming Puzzles

The CHIP-0041 Streaming Puzzle is a Chialisp standard currently in Draft status (created February 3, 2025, authored by yakuhito and Michael Taylor).² It enables continuous payments of XCH or CATs to a receiver over a fixed time window — making it the most elegant on-chain solution for subscription-like payment flows once widely adopted.

How Streaming Puzzles Work

Imagine paying a contributor 12 XCH over a 12-month vesting period. With a streaming puzzle, you create a single streaming coin holding the total amount, set the duration, and lock in the receiver’s puzzle hash. As time passes, the receiver’s claimable portion increases proportionally to elapsed time. The receiver can spend the streaming coin at any point to claim their accrued share — at which point the puzzle automatically creates a new streaming coin holding the remaining balance, plus a payout coin for the claimed amount.²

A designated clawback puzzle can stop the stream early at any time. Critically, the receiver still receives all funds accrued up to the moment of clawback — the clawback simply prevents a new streaming coin from being created for the remainder.² This makes streaming puzzles fair to both sides: the sender isn’t locked in forever, and the receiver is always made whole for time already served.

Streaming Puzzle — Illustrative Setup

The following is pseudocode illustrating the conceptual structure of a streaming payment. CHIP-0041 wallet RPC commands are not yet standardized, as the CHIP remains in Draft status at the time of writing.

# Illustrative pseudocode — not a finalized wallet RPC
# Creates a streaming coin for a 12-month subscription payment

streaming_coin = create_streaming_coin(
    total_amount=12_000_000_000_000,  # 12 XCH in mojos
    asset="XCH",                       # Also supports CATs
    receiver_puzzle_hash=subscriber_address,
    start_timestamp=current_time,
    duration_seconds=31_536_000,       # 365 days
    clawback_puzzle_hash=your_address  # Lets sender stop stream early
)

# After 30 days: ~1 XCH is claimable by receiver
# After 180 days: ~6 XCH is claimable by receiver
# Receiver claims by spending the streaming coin at any time

Who Should Use Streaming Puzzles

Streaming puzzles are the right tool when you need guaranteed, continuous outflows without manual intervention after setup: token vesting schedules for investors and contributors, DAO payroll, or any scenario where a payer wants to commit funds to a receiver on a time-based release without running automation software. The main trade-off is that the full payment amount must be locked in the streaming coin upfront. Because CHIP-0041 is still in Draft, monitor the official CHIP repository for finalized specifications before building production systems against it.

Method 2: Singleton-Based Escrow Pattern

This approach flips the payment dynamic: instead of the payer pushing funds on a schedule, the subscriber locks funds in a singleton that the merchant can pull from periodically. A singleton is a unique on-chain object that maintains verifiable state — it proves it is one-of-a-kind and carries an auditable history of every spend.⁴ NFTs, DIDs, and pooling puzzles all use singletons under the hood.

How Singleton Escrow Works

The subscriber creates a singleton with a custom inner puzzle that encodes the subscription terms. They lock the full prepaid balance — say, 12 months of payments — into the singleton. The inner puzzle then enforces time-based release rules: the merchant’s automated software can only spend a defined amount per billing period, and only after the time lock condition passes. Each merchant spend recreates the singleton with updated state (payments remaining) and a reduced balance. If the subscriber wants to cancel, a separate path in the puzzle allows them to reclaim the unused balance once the current billing period ends.

Monthly Subscription — Conceptual Flow

# Subscriber deploys subscription singleton with terms curried in
# All values are illustrative

subscription_singleton = create_subscription_singleton(
    monthly_amount=10_000_000_000,      # 10 XCH in mojos
    merchant_puzzle_hash=saas_provider,
    subscriber_puzzle_hash=user_address,
    billing_period_seconds=2_592_000,   # 30 days
    prepaid_months=12,
    cancellation_allowed=True
)

# Merchant's automated node checks periodically
if time_lock_has_expired(subscription_singleton):
    new_singleton = spend_subscription_singleton(
        subscription_singleton,
        withdrawal_amount=10_000_000_000,
        merchant_puzzle_hash=saas_provider
    )
    # Singleton recreated with 11 months remaining
    grant_service_access(user_address)

Key Chialisp Conditions to Enforce

Your singleton’s inner puzzle needs four enforcement rules working together. First, use ASSERT_SECONDS_ABSOLUTE to prevent withdrawals before each billing period expires — this is what creates the time lock.⁵ Second, cap each withdrawal to the agreed monthly amount so the merchant can never over-withdraw. Third, update state in the singleton’s recreated version so the remaining balance and payment count reflect each spend. Fourth, include a cancellation path that the subscriber can invoke to reclaim unused prepaid funds after the current period closes. Getting all four right is where most of the custom Chialisp work lies.

Who Should Use Singleton Escrow

This pattern suits merchant-centric use cases: SaaS platforms, content subscriptions, or services where the provider needs to control payment timing without waiting for the subscriber to act each month. The subscriber must trust that the singleton logic is correct — which makes a thorough audit essential before deployment. Full upfront lock-up and the need for custom Chialisp development are the main costs. In exchange, you get on-chain proof of subscription terms that neither party can dispute.

Method 3: Automated Offer Generation

The simplest path available today requires no new Chialisp primitives: let wallet software automatically create a fresh Offer for each billing cycle. This is essentially the recurring billing model you already know — credit cards, direct debit — rebuilt on top of Chia’s standard Offer protocol.¹

How Wallet Automation Works

The user signs up for a subscription and authorizes a wallet scheduler to create Offers on their behalf. The scheduler stores the merchant’s details — address, expected payment amount, service token type — and runs a background process that checks billing dates. When the next payment date arrives, the scheduler creates a standard Offer: “I’ll give you X XCH (or CAT tokens) in exchange for 1 unit of service.” That Offer gets posted to a DEX like Dexie or sent directly to the merchant, who accepts it to complete the swap.

Scheduler Implementation Pattern

# Wallet-side recurring Offer scheduler (pseudocode)
class RecurringOfferScheduler:
    def __init__(self, config):
        self.merchant_address  = config['merchant']
        self.monthly_payment   = config['amount']        # In mojos
        self.payment_asset     = config['asset']         # 'XCH' or CAT asset_id
        self.service_token     = config['service_token'] # What you're buying
        self.next_billing_date = config['next_billing']

    def check_and_create_offer(self):
        if datetime.now() >= self.next_billing_date:
            # Create a standard Chia Offer — no custom Chialisp required
            offer = create_offer(
                offer_asset=self.payment_asset,
                offer_amount=self.monthly_payment,
                request_token=self.service_token,
                request_amount=1  # 1 unit of service
            )
            post_offer_to_exchange(offer)           # Dexie, OfferPool, etc.
            self.next_billing_date += timedelta(days=30)

Month-by-Month User Flow

In practice, each month looks like this: the wallet scheduler fires, creates a new Offer spending fresh coins (not the same coins as last month — each Offer references newly selected UTXOs), posts the Offer, and the merchant accepts it. The user’s experience feels continuous even though each transaction is technically independent. The subscriber can cancel at any time simply by disabling the scheduler — no on-chain transaction needed.

Who Should Use Automated Offer Generation

This is the right starting point for teams building subscription MVPs today, or for users who want recurring payment convenience without locking capital upfront. Because it uses standard Offers, it works with any wallet that supports Offer creation and requires no custom Chialisp development. The main risks are that the user’s wallet must be online and funded at billing time, and the merchant must also monitor and accept each Offer — making both parties responsible for keeping the subscription running.

Full Comparison: Choosing Your Approach

Real-World Considerations Before You Build

Transaction Fee Planning

All three methods incur transaction fees at each payment event. For streaming puzzles and singleton escrow, these accumulate over the contract lifetime rather than all at once — but you still need to account for initial setup fees (creating the streaming coin or launching the singleton), periodic claim or withdrawal fees, and the possibility that network fee rates shift over time.⁶ For automated Offer generation, fees apply to every new Offer creation and acceptance. Budget conservatively and monitor the Chia mempool during periods of elevated activity.

Handling Failed Payments

Each method has its own failure mode. With streaming puzzles, a receiver may be unable to claim if transaction fees exceed the claimable amount at that moment — particularly early in a stream when accrued value is small. With singleton escrow, the merchant’s automated spend may fail if network congestion spikes fees above the expected range. With automated Offers, the subscriber’s wallet may be offline, or their balance may be insufficient when the scheduler fires. In all cases, build explicit retry logic and user-facing notifications so payment failures surface immediately rather than silently lapsing access.

Consumer Protection and Compliance

Recurring payments typically fall under consumer protection regulations in most jurisdictions — even on-chain ones. Before launching, ensure users receive clear disclosure of billing terms before committing funds, that cancellation is straightforward and results in refund of unused prepaid periods, that transaction records are accessible for tax reporting, and that your cancellation mechanism genuinely returns unspent funds rather than locking them. On-chain transparency is a strength here: every payment is verifiable, which helps both parties in any dispute.

As Chia Network CEO and President Gene Hoffman has noted about the Offers system: “Buyer and seller know immediately that the transaction is in flight and will be initially settled in under a minute and fully settled in about two and a half minutes without needing any third party or requiring that the buyer or seller trust the other party.”⁷ That same trustlessness is what makes all three recurring payment patterns viable — each one preserves the atomic settlement guarantee that makes Chia Offers powerful in the first place.

What’s Next for Recurring Payments on Chia

The CHIP-0041 Streaming Puzzle is the most important near-term development to track. Once it moves from Draft to Final status and major wallets add support — the Chia Reference Wallet and Sage being the most likely early adopters — streaming payments will become a first-class primitive for both XCH and CAT subscriptions. Watch the CHIP-0041 pull request discussion for finalization timelines. Beyond that, expect DeFi protocols built on Chialisp to package these patterns into higher-level subscription management interfaces, reducing the custom development burden for most merchants.

Chia’s programmable coin model gives builders flexibility that traditional payment processors simply cannot match. You can encode cancellation rights, refund conditions, and fee caps directly into the on-chain logic — no terms-of-service disputes, no chargebacks, no intermediary. The ecosystem is early, but the foundations are real.

Conclusion

Chia Offers were not designed for recurring payments — but that limitation opens the door to three more powerful patterns. CHIP-0041 streaming puzzles deliver elegant continuous payments of XCH or CATs with minimal ongoing transactions, ideal for vesting and payroll. Singleton-based escrow gives merchants pull-payment control with on-chain enforcement of subscription terms. Automated Offer generation works today, requires no new Chialisp, and keeps funds in the subscriber’s hands until each billing date. Choose your approach based on whether you need protocol-level automation, can lock funds upfront, or need something you can ship this week. To go deeper on how Chia Offers work as a trustless trading primitive, read our guide on How Chia Offers and One Market are Transforming DeFi Transactions, and for the Chialisp fundamentals that power all three approaches, see ChiaLisp: Transforming Blockchain with Next-Gen Smart Contracts.

Chia Recurring Payments Offers FAQs

Can Chia Offers automatically repeat like a credit card subscription?

No — Chia Offers cannot automatically repeat because each Offer is a one-time atomic swap that is permanently consumed on-chain when taken.¹ To create chia recurring payments with Offers, you need either a streaming puzzle, singleton escrow, or off-chain wallet automation that generates a brand new Offer for each billing period.

What is the best method for chia recurring payments offers in 2025?

For teams building today, automated Offer generation is the most practical option because it uses the existing standard Offer protocol with no custom Chialisp required.¹ CHIP-0041 streaming puzzles are the best long-term solution for chia recurring payments but are still in Draft status, so production use should wait for finalization and wallet support.²

Does CHIP-0041 streaming support CAT tokens as well as XCH?

Yes — CHIP-0041 explicitly supports both XCH and CATs.² The streaming puzzle can stream any Chia Asset Token alongside native XCH, which makes it suitable for stablecoin subscription payments and token vesting schedules, not just raw XCH flows.

How do CHIP-0041 streaming puzzles handle cancellations?

CHIP-0041 includes a clawback puzzle that the sender can invoke to stop the stream at any time.² When the clawback fires, the receiver still receives all funds accrued up to that moment, but no new streaming coin is created for the remaining balance — the stream simply ends at the point of clawback.

Do chia recurring payments offers require locking up all funds upfront?

It depends on the method you choose. Both CHIP-0041 streaming puzzles and singleton-based escrow require locking the full subscription amount upfront, while automated Offer generation lets the subscriber pay period by period from their regular wallet balance.¹ If cash flow is a concern, automated Offers are the better fit for chia recurring payments today.

Chia Recurring Payments Offers Citations

1. Chia Network. “Offers — Primitives.” Chialisp Documentation. https://chialisp.com/offers/
2. yakuhito & Michael Taylor. “CHIP-0041: Streaming Puzzle.” Chia Improvement Proposals, GitHub, 2025-02-03. https://github.com/Chia-Network/chips/blob/59e90f00bb07445c07b6db8832f6cc105f860456/CHIPs/chip-0041.md
3. Chia Network. “Settlement Payments Puzzle — Offers.” Chialisp Documentation. https://chialisp.com/offers/
4. Chia Network. “Singletons.” Chialisp Documentation. https://chialisp.com/singletons/
5. Chia Network. “Conditions.” Chialisp Documentation. https://chialisp.com/conditions/
6. Chiatribe. “Chia Network Transaction Fees Explained: Mempool Dynamics, Common Issues and Solutions.” https://chiatribe.com/chia-network-transaction-fees-mempool-dynamics/
7. Gene Hoffman, CEO & President, Chia Network. Quoted in: Chiatribe. “How Chia Offers and One Market are Transforming DeFi Transactions.” June 2024. https://chiatribe.com/chia-offers-one-market-transforming-defi-transactions/