Twitch Shield Mode and Paid Moments: A Lockdown State Machine for Your Queue

Shield Mode locks the chat door, and the tip page is a side door

Picture a bad night. A stranger drops a link in a few big communities, forty new accounts show up, and chat turns into a wall of the same hateful line. A mod hits /shield, chat tightens up, and everyone breathes. Meanwhile the paid queue is still cheerfully accepting a TTS message from one of those accounts, because the tip page never heard that anything happened.

That is the gap this post is about. Shield Mode is a chat safety tool. A paid TTS read, a sound alert, or a viewer upload gets someone's words, voice, or picture onto the stream without going through chat. If chat is locked to followers and the queue is not, the restriction has a hole in it, and that hole plays out loud on your broadcast.

So the queue needs its own rule for Shield: a small set of states with clear entry and exit conditions that a tired moderator can follow at 2 a.m.

What Shield Mode changes in chat

This part rests on Engadget's launch coverage and search snippets of Twitch's safety center article, not a full read of the Twitch page. The /shield and /shieldoff commands in particular come from the snippets only. Confirm the details in your own dashboard.

As described there, Shield Mode lets a streamer pre-set a bundle of protections and then switch them all on at once, by button or by the /shield and /shieldoff chat commands. The bundle can include followers-only or subscribers-only chat, a mode that blocks messages from first-time chatters, phone or email chat verification, and a stricter AutoMod level. Coverage also mentions banning people who recently used chosen terms. Both the broadcaster and their moderators can use it.

Twitch's developer reference adds one practical detail: when Shield Mode is activated it applies the overrides the broadcaster configured, and if the broadcaster never configured it, it applies default overrides. Nobody can assume what a given channel's Shield does until someone opens the settings.

• Open the Shield Mode settings before you need them and write down which restrictions are on.
• Tell the whole mod team, because those restrictions decide which viewers can still talk.

What the API and EventSub actually give a queue

Start with the method, because it is easy to get wrong. The Update Shield Mode Status endpoint in the API reference is a PUT to https://api.twitch.tv/helix/moderation/shield_mode, and plenty of people will tell you POST from memory. It takes broadcaster_id and moderator_id as query parameters, an is_active boolean in the body, and needs the moderator:manage:shield_mode scope. The moderator_id has to match the user in the token.

Get Shield Mode Status is a GET on the same URL, takes the same two IDs, and accepts either moderator:read:shield_mode or moderator:manage:shield_mode. It returns a data array with one object holding is_active, moderator_id, moderator_login, moderator_name, and last_activated_at. If Shield has never been used, the moderator fields and the timestamp come back as empty strings.

For push notifications, the EventSub subscription types page lists channel.shield_mode.begin and channel.shield_mode.end, both version 1, described as notifications for when the broadcaster activates or deactivates Shield Mode. Both require the moderator:read:shield_mode or moderator:manage:shield_mode scope, and the condition takes a broadcaster_user_id and a moderator_user_id. The example payloads carry the broadcaster and moderator IDs, logins, and display names, plus started_at on begin and ended_at on end.

One more wording point from the docs: the begin event means the broadcaster's moderation settings changed to the Shield configuration, and the end event means they changed back to the previous settings. Twitch's developer forum announced these endpoints and the EventSub types as an open beta, so recheck the reference before you ship and test against a real activation.

Four queue states, mapped to the two events

Shield gives you two signals, on and off. A queue that only mirrors them flips from silence straight back to a firehose, so use four states: the moment Shield ends is not the moment the room is safe. Transitions, as bullets.

• OPEN to HOLD: triggered by Shield begin, a manual /shield from a mod, or a mod pressing the queue's own hold control. Action: stop starting new TTS reads, sound alerts, and viewer uploads. New audio or image payments are either closed or accepted and labeled as held, per your written promise.
• HOLD to HOLD: more payments or chat commands arrive while Shield stays on. Action: they enter the backlog as pending and never play. Nothing is auto-approved.
• HOLD to DRAIN: triggered by Shield end, but only when a mod confirms in the mod channel. Action: no playback yet. A moderator reads through the backlog and marks each item approved, rejected, or text-only.
• DRAIN to RESUME: triggered by the lead mod saying the backlog is cleared. Action: play approved items in paced batches, oldest first, with the streamer present.
• RESUME to OPEN: triggered by the last batch finishing without a problem. Action: normal rules return, including any auto-approval you ran before.
• DRAIN or RESUME back to HOLD: triggered by a second Shield begin. Action: stop at the next gap between items and remember the cursor, so approved items are not lost.

Items already approved or mid-play when Shield begins

Shield can start in the middle of a read. The cleanest rule is to let the item currently playing finish if it is a short text read, and cut it if it is long, if it is an upload, or if a mod says so. Cutting a half-spoken sentence is awkward, but awkward beats harassing.

The harder group is approved but not yet played. A moderator approved those items before the wave started, and in hindsight one from a freshly created account may look different. Move them to a held-approved status. They keep their place in line, but a person glances at each one again during DRAIN.

Example: three reads were approved at 8:40 and Shield started at 8:44, and one came from an account made that evening. Nothing says it is bad, but a mod can decide in five seconds during DRAIN, which beats deciding live on air.

What viewers see, and what to copy

Silence reads as a bug. If TTS simply stops, supporters assume the bot is broken and pay again or ask in chat. Put a plain status where people are about to pay: the tip page and the reward description.

Keep it dull and free of accusation. Do not mention raids, hate, or individual accounts. Adapt this line to your voice: Chat is in a temporary safety mode, so paid TTS and uploads are saved for review and will play in order once it lifts.

Decide before the stream what money does in HOLD. Either keep taking payments and queue them with the status above, or close audio and image formats and leave text-only receipts open. Write the choice in the reward description, because the worst version is a viewer paying into a queue nobody told them was frozen.

Paid items from viewers who just got restricted

Here is the uncomfortable case. Say your Shield turns on followers-only chat and a new viewer, who cannot type in chat, pays for a TTS message. Their paid message would say something that Twitch's own restriction is currently stopping them from saying. That is the bypass, and it is why HOLD should cover paid text and not only uploads.

The stricter default is to hold every paid audio and image item regardless of sender, because your queue usually cannot tell whether the payer would pass the Shield rules. That is only knowable if the payer signed in with Twitch.

If your setup does link submissions to Twitch accounts, a narrower lane is reasonable: a subscriber during a sub-only Shield could go to the front of the DRAIN review. Keep that as a review priority, never an auto-play. If your paid uploads already pass a human check before they air, that check is where the DRAIN review belongs. Nothing here claims any particular tool reads Shield events on its own.

Resume ordering, pacing, and who flips the switch

The end event tells you Twitch loosened chat. It does not tell you the harassers left. Wait through a cool-off before DRAIN even begins: a few minutes is a reasonable example, longer after a heavy wave. Watch whether the same pattern returns.

When you resume, go oldest first and cap each batch. Example: three items, a pause where the streamer talks, then the next three. Put uploads last and one at a time, since mixed batches of audio and images are harder to react to.

On roles, give three jobs to three people when you can. One mod owns Shield in Twitch, one owns the queue state, and the streamer owns the go-ahead to resume. Because Shield events carry which moderator changed the state, your log can show who flipped it. If you only have two people, the queue owner should also be the one who confirms DRAIN, since they are the one looking at the backlog.

A drill, plus the edge cases

Run this once in a quiet channel before you need it. Activate Shield by hand, send a test TTS and a test upload from a second account, and tick through the list below. Warn your mods first so nobody mistakes it for a real incident.

Two edge cases to settle on paper. First, Shield toggled twice in a few minutes: treat every begin as a fresh HOLD, never as a resume, and keep the DRAIN cursor so approved items survive. Second, a missed event: if your tool disconnects, nothing tells it that Shield ended. On reconnect, call Get Shield Mode Status and trust is_active over your own memory. Note that last_activated_at records the last activation, so it cannot tell you when Shield ended.

• Pass: Shield begin or a manual hold stops all new audio and image starts within one item.
• Pass: the status line shows on the tip page and in the reward description.
• Pass: an approved-but-unplayed item shows as held-approved and needs a second look.
• Pass: Shield end does not start playback by itself.
• Pass: resume plays in small paced batches, oldest first, uploads last.
• Fail: any item auto-plays during HOLD, or a second Shield begin during RESUME loses the cursor.
• Fail: after a simulated disconnect, the queue stays in HOLD forever or opens without checking Get Shield Mode Status.