Why windows exist
Rails charge per-transaction. ACH, wire, and some stablecoin networks all have per-transfer costs. If you process 10,000 small payments per hour and push each one individually, fees eat margins. Batching into windows — “settle everything from the last 4 hours in one ACH batch” — amortizes those costs. For x402 / MPP micropayments this is critical — the unit economics depend on batching.Window configuration
List current windows
- ACH — 4x daily (default)
- Wire — 1x daily (default)
- USDC — every 15 minutes (default, low cost per batch)
- Pix — hourly (default, Brazilian rail)
- SPEI — hourly (default, Mexican rail)
Frequency options
Modify or create a window
min_batch_amount_cents prevents tiny batches — if the accumulated amount doesn’t exceed the minimum when the window fires, it rolls forward to the next window.
Holiday calendars
Rails skip on banking holidays. Sly maintains per-rail holiday calendars automatically (US Fed Reserve, SEPA, Banco de México, etc.). A window that would fire on a holiday rolls to the next business day. To view a rail’s upcoming holidays:Emergency settlement
Skip all windows and force-flush a specific rail immediately:Monitoring window health
- Rolling forward — batches that don’t meet minimums, suggesting your minimum is too high for your volume
- Partial failures — some transfers in the batch failed; need manual reconciliation
- Late runs — rail provider was slow to accept the batch
Endpoints
Coordination with rules
- Windows set ceiling cadence — “at most every 4 hours on ACH”
- Rules can trigger sooner — “also settle if balance exceeds $10k”
- Neither batches past the other — whichever fires first wins