Expiry & cancel

Every offer has an expiry timestamp set at creation. After that timestamp the offer cannot be filled and the maker's escrow can be returned by anyone, not just the maker, for a small SOL bounty.

Setting an expiry

The maker picks the window from the create modal. Five preset values cover most cases:

The 30-day cap is a program-level constant. It is there to cap how long escrowed funds can be locked by a single offer.

Cancelling early

The maker can call cancel_offer at any time before the deadline. There is no fee, no penalty, and no waiting period. The remaining vault balance is returned to the maker and the offer accounts are closed in the same transaction.

What happens at expiry

After expires_at passes, two things become true:

1. The program rejects any new take_offer calls against this offer.
2. The program now accepts expire_offer calls from anyone, not just the maker.

expire_offer does the same cleanup as cancel_offer, returns the remaining vault balance to the maker and closes the accounts, with one addition: the caller earns a small SOL bounty (the rent freed by closing the offer accounts) for triggering the cleanup.

Why permissionless expire matters

Without it, expired offers would sit on chain forever, locking the maker's funds if the maker forgot or lost their key. With it, anyone with a keeper bot can sweep stale offers and earn the bounty. In practice this means:

• Stale offers get cleaned up within minutes of expiry.
• Makers do not need to remember to come back and cancel.
• The total on-chain footprint of the program stays tight.