Polygon introduced automated stablecoin payout runs in Open Money Stack on October 12, 2026. Before enabling a recurring run, decide how you will stop new requests and account for payments already submitted. Revoking permission for future activity should not be treated as a reversal of completed transfers.
What the new payout run controls
The launch explanation describes recipient scope, a spending limit and a run window checked through wallet permissions. The product requests payments within those terms. This makes the boundary of an approved run a useful starting point for review: which activity is authorized, and how does the team close that authorization?
The automated-payouts product page presents an off switch and payout history. Its illustrated companies and schedules are examples, not evidence of our own test or a real customer’s settlement time. Do not turn a tidy demonstration timeline into a delivery deadline for the next live run.
The stop procedure needs an unfinished-payment list
Suppose a fictional run contains three payments. Payment A has a confirmed outcome, payment B has been submitted but its outcome is unresolved, and payment C has not been requested. After deciding to stop, those three records need different treatment. A single run-level label such as stopped would leave the team unable to tell which recipient still needs attention.
| Payment at the stop decision | Record to retain | Next review action |
|---|---|---|
| A: outcome established | The instruction and evidence of the observed result | Keep it in the reconciliation; do not assume it was undone |
| B: submitted, outcome unresolved | The submission reference and latest status observation | Resolve the outcome before deciding on another payment |
| C: no request submitted | The intended instruction and the reason the run stopped | Keep it out of a fresh run until its authorization is reviewed |
This worksheet is an operational example, not a list of official API status names. It separates what the team intended from what it actually requested and what result it can prove. Without that distinction, someone reviewing the run later may treat every row as unpaid and accidentally create another instruction for a recipient already paid.
Read the revocation semantics precisely
The current Smart Sessions documentation says revocation prevents WaaS from using the affected session immediately; the onchain configuration entry is removed during a subsequent wallet execution. It also distinguishes revoking one session from retiring a backend credential and its sessions. Record which object you intended to disable rather than assuming every use of the word revoke has identical scope.
Ask the implementation team to demonstrate the supported stop path with an unspent example and to explain how it handles a request already in flight. The answer should identify the evidence used to resolve that request, not promise that a general stop button retrieves money from a recipient. Keep operational responsibility clear: who disables the permission, who checks the remaining records, and who authorizes any replacement instruction?
- Before the first run, identify the authorized session and the documented revocation path your implementation uses.
- Keep a per-payment record linking the intended recipient to the submitted request and its observed outcome.
- When stopping, record the decision time, affected permission and payments still unresolved.
- Check the outcome of submitted payments before creating replacement instructions.
- Review the remaining recipients and authority before enabling a new run; preserve the earlier reconciliation.
A recurring schedule still needs a new operational review
The next cycle may look similar while its recipient details or business obligations have changed. Review those changes deliberately. A permission that remains technically usable does not tell the team whether a particular supplier should still receive money. Likewise, a closed cycle is not a reason to discard the record explaining what happened to each of its payments.
For a separate exchange, check supported coins and networks, read the order process, and review the operation in the simple-swap form. Do not infer an OMS connection or a recurring-payment feature in KOT.CASH from this announcement. The useful habit is to link an instruction to its actual result before starting another movement of funds.
FAQ
What does a batch payment run mean in this Polygon OMS update?
The update describes requesting payouts within previously approved terms. Keep per-payment outcomes so the whole run’s label does not hide an unresolved recipient.
How long does a batch payment take after the run starts?
The announcement does not establish one delivery deadline for every live run. Check the observed outcome for each payment instead of copying times from a product illustration.
What should I review before enabling Polygon Open Money Stack payouts?
Agree who can stop the authorized activity and reconcile payments already submitted. Test the supported stop procedure without assuming it reverses earlier transfers.