Polygon Labs introduced automated stablecoin payout runs for its Open Money Stack (OMS) on October 12, 2026. The feature lets teams approve a recipient scope, payment budget, and run window once, then execute multiple stablecoin transfers without a fresh signature for each one. The announcement didn't name a contract deployment, launch time, or live payout amount.
How the one-time approval works
Under the new workflow, a team sets up what amounts to a standing permission. It defines which contracts and methods the automation may call, names the maximum token amount it can move, and picks an expiry date. The wallet records those terms in its onchain Sessions Module. After that, the payout service can request transfers inside the approved window without prompting a signer every time.
Every request gets checked against the recipient scope, budget, and time window before it executes. If a request falls outside those terms, the wallet contract rejects it. The backend running the payout cycle can't widen the recipient list, raise the spending cap, or push back the expiry after approval. That authority sits in the wallet, not in the service.
What the permission does — and doesn't — allow
The permission is meant to be narrow. It can be limited to the specific calls a payout workflow needs, rather than opening up every wallet action. Recipient scope limits where funds can go, the token maximum limits how much can move, and the expiry closes the door when the approved period ends.
Polygon Labs frames the release as an authorization and orchestration feature, not a new stablecoin. The immediate use cases it lists are marketplace seller settlements, contractor payments, creator revenue shares, customer rewards, and partner commissions — recurring, predictable transfers that don't need a human to sign off each time.
The security trade-off teams have to manage
The selling point is that a compromised payout service doesn't get unlimited reach. If the permission was configured as described and the wallet contracts behave as specified, an attacker is still boxed in by the active rule. That's a meaningful limit, but it puts pressure on configuration. Teams need to review recipient scope, token limit, contract list, and expiry before they approve anything. They also need to test that out-of-scope requests actually get rejected.
Revocation is available. Turning off an active rule stops the next payout request, so operations staff can halt future payments without waiting for the approved window to run out. The announcement doesn't say whether revocation affects a request that's already executing, or how quickly an operator interface reflects the onchain change.
What the announcement leaves open
Several operational details aren't spelled out. The announcement doesn't specify retry behavior, request ordering, or how partial runs get reconciled. Those gaps matter for teams running high-volume payouts, where a failed transfer or an out-of-order request can throw off accounting.
The core change is narrower than it might sound: it removes a signature from each individual transfer, not from the initial authorization. That first approval still happens, and it's where the risk review lives. Treasury operators now have to treat configuration as part of that review, because the upper bound on what the automation can do is the main control they have left.
Polygon Labs hasn't published a contract address or a go-live timestamp. Until it does, the practical question for OMS users is whether their wallet contracts enforce the rule exactly as described — and whether they can prove it before they hand a payout service the keys.
