The Ticketmaster Verified Fan system: queueing, identity, and bot defense

On 15 November 2022, the Verified Fan presale for Taylor Swift’s Eras Tour went live and the largest ticketing platform in the world fell over inside an hour. Ticketmaster later told the U.S. Senate that the site took 3.5 billion system requests that day, roughly four times its prior peak, against a tour with about 2.6 million seats to sell. The company had spent five years building a system specifically to stop this from happening: identity-gated registration, randomized queueing, device-bound tickets with barcodes that rotate every fifteen seconds. All of it ran, and it still buckled.

That gap, between an elaborate multi-layer defense and a presale that melted anyway, is the interesting part. The Verified Fan stack is one of the most-deployed anti-bot pipelines aimed at a single adversary class, the industrial ticket scalper, and almost none of it is publicly documented by the people who built it. What follows reconstructs the architecture from primary sources where they exist, from a careful reverse-engineering of the ticket format, and from sworn testimony about what broke. Where a detail is not public, it is flagged as inferred rather than dressed up as fact.

The post walks the stack roughly in the order a buyer hits it. First the registration gate and what “verified” actually verifies. Then the waiting room and why position is assigned randomly rather than first-come. Then SafeTix, the rotating-barcode format that turns a ticket into a moving target, with its real cryptographic mechanism laid out. Then the arms race itself, anchored on the Swift collapse and the testimony that followed. The through-line is that every layer solves a different problem, and the scalper economy adapts to each one on a cycle measured in months.

What “verified” verifies

Ticketmaster launched Verified Fan in 2017, after a stretch where automated brokers were routinely clearing the best inventory before a normal buyer finished loading the page. The pitch was an inversion of the usual on-sale. Instead of opening the doors at a fixed time and letting the fastest client win, the high-demand sale moves behind a registration wall. You sign up for a specific event during a registration window, days before tickets exist to buy. Registration is per-event and time-boxed, with an open date and a close date, not a rolling signup.

The word “verified” oversells what happens next. Ticketmaster has been explicit, under press scrutiny, that Verified Fan registration does not measure fandom and is not a fan-loyalty score. What it does is bind a request for access to an identity that costs something to fake at scale. You register with an account, an email, and a phone number, and the system decides, partly by signals it does not disclose and partly at random, whether to issue you a unique presale access code. For the Eras Tour, 3.5 million people registered in the United States and roughly 1.5 million received codes. The rest were waitlisted or turned away before a sale existed.

The economic logic is the point, not any single signal. A scalper running a thousand purchase bots needs a thousand plausible identities to register a thousand times, and each identity now needs a distinct phone number that survives a uniqueness check, an account with some history, and the luck of a partly-random selection. None of that is impossible. SMS-verification farms and aged-account markets exist precisely to supply it. But it converts a problem that used to be solved with raw request throughput into one that requires standing infrastructure, and that shifts the cost curve. The defense does not need to be unbreakable. It needs to make the marginal fake registration expensive enough that the return on a bot fleet drops.

The access code itself is the artifact that comes out of this stage. It is tied to the account it was issued to and is not meant to be shareable or resellable. In practice codes do leak and get traded, which is one reason the later layers exist. Verified Fan is the first filter, not the last. It thins the field of who is allowed to attempt a purchase; it does not by itself decide who completes one.

The selection logic is where Ticketmaster is least forthcoming, and any specific claim about it should be treated with suspicion. Press coverage describes selection as “partly random and partly based on activity” such as past purchases or streaming history, but the company has never published a feature list or a weighting, and the activity-signal claims trace to secondary sources rather than to Ticketmaster documentation. The honest summary is that registration produces a yes/no on access codes by a process that is deliberately opaque, and that opacity is itself a defense, because a published selection rule is a published target.

The waiting room and why position is random

Surviving the registration gate gets you a code. It does not get you tickets. When the sale opens, code-holders converge on a virtual waiting room, and this is where Ticketmaster’s queueing layer takes over. The mechanism is the same family of system covered in our piece on how virtual waiting rooms work: a buffer that sits in front of the real purchase path and admits users to it at a controlled rate, so the inventory system never sees more concurrent shoppers than it can serve.

*The waiting room decouples arrival from admission. Position is drawn randomly at sale open, then the room drains into the purchase path at a rate the inventory system can absorb.*

The design decision that matters most is the randomization. Ticketmaster’s own description is blunt about why. Without a waiting room, the queue would order on a first-come basis, and a first-come queue is a race, and in a race the bots win because they are faster than humans by orders of magnitude. So the room breaks the link between when you arrive and where you land. Joining the room early gets you into the room. It does not move you up the line. When the sale opens, the system shuffles everyone present into a randomized order and starts draining from the front.

This is the same fairness argument we take apart in designing a fair queue at scale, and it has a sharp consequence for the adversary. If position is random, raw speed stops paying. A bot that hammers the room a thousand times a second gets no better expected position than a human who showed up once and waited. What still pays is breadth: a thousand sessions each holding one random draw beats one session holding one draw, because expected best-of-N improves with N. So the waiting room does not kill automation. It changes what automation optimizes for, from latency to concurrency, from the fastest client to the largest fleet of plausible-looking sessions. That is exactly the pressure the identity gate upstream is meant to relieve, and it is why the two layers only make sense together.

Underneath, the room runs on the patterns common to every CDN-edge queue. There is a token or cookie that marks your place, a server-authoritative count of how many shoppers the purchase path can hold, and an admission loop that releases the next batch as slots free up. Ticketmaster has not published the token format, so the field names are not public; the behavior is consistent with the cookie-and-token designs documented for Queue-it and Cloudflare Waiting Room, where a signed token carries queue identity and the edge enforces the count. Treat any specific Ticketmaster cookie name you see quoted online as unverified unless it comes with a capture.

There is also a behavioral tripwire layered on the room. Ticketmaster warns, in its own help material, that manually refreshing the page during the queue can get a session flagged as a bot and ejected, because the room refreshes itself and a human-driven reload pattern reads as automation. That is a small, telling detail. It says the queue is not just a buffer but a sensor, watching the client’s interaction rhythm and feeding it into the same bot-scoring decision that the rest of the stack makes. The line between “waiting room” and “bot detector” is thin here by design.

SafeTix: the ticket as a moving target

The third layer does not gate who buys. It governs what a ticket is after the sale, and it is the one piece of the stack whose mechanism is genuinely public, because someone reverse-engineered it carefully and wrote it up. Ticketmaster introduced SafeTix in May 2019, rolling it out first to NFL stadiums for the 2019 season and to touring artists, pitched as an encrypted barcode that refreshes every few seconds and binds the ticket to the holder’s phone. The stated goal was killing the screenshot. A printed or screenshotted barcode is a static thing you can copy and sell twice. A barcode that changes every fifteen seconds is not.

The mechanism, as documented in conduition.io’s 2024 reverse-engineering writeup, is more interesting than the marketing. A SafeTix ticket on screen is a PDF417 barcode encoding UTF-8 text, and the text is four colon-delimited fields:

*The on-screen barcode carries a static bearer token, two rotating six-digit codes, and the timestamp they were generated for. The secrets that produce the codes stay on the device, fetched once from the API.*

The two six-digit numbers are time-based one-time passwords, the same RFC 6238 TOTP construction that drives a 2FA authenticator app: an HMAC-SHA1 over a shared secret and the current time window, truncated to six digits, stepped every fifteen seconds. There are two of them because there are two secrets. When the app loads a ticket, it fetches a JSON object from a Ticketmaster endpoint (the writeup gives the path as /api/render-ticket/secure-barcode), and that object carries the two hex-encoded twenty-byte secrets the reverse-engineering names ek, an event key tied to the ticket, and ck, a customer key tied to the account, alongside a static base64 bearer token t and a render type rt of rotating_symbology. The device generates both TOTPs locally from those secrets and the clock. The barcode is just the bearer token, the two fresh codes, and the timestamp, glued together and redrawn every fifteen seconds.

At the gate, the scanner reads the PDF417, splits it on the colons, looks up the ticket by its bearer token, then recomputes both TOTPs server-side from the stored ek and ck and checks them against what the barcode claimed, with the timestamp telling it which time window to verify. A screenshot fails this check the moment its window expires, because the codes it froze are no longer the codes the server expects. That is the whole anti-screenshot story, and it is a clean application of an old, well-understood primitive to a new problem.

It is worth being precise about what this does and does not stop, because the marketing blurs it. The sweeping blue animation across the barcode that you see in the app is, in the reverse-engineer’s words, a cosmetic CSS effect; it does nothing, because PDF417 has enough error correction that a partial obstruction still scans. More importantly, the rotation defeats a stored screenshot but not live sharing. Because the secrets live on the device and the web app will print the active token to the browser console, a holder who wants to share a ticket in real time can relay the live token to a second device, and the second device will render valid barcodes for as long as it keeps receiving fresh secrets. The writeup demonstrates this by attaching desktop Chrome DevTools to a phone’s browser and reading the token straight out of the console. SafeTix raises the bar from “copy a JPEG” to “run a live relay,” which is a real increase in effort and a real decrease in casual fraud, and it is not the impossibility the word “secure” implies. We do not publish the relay code, and the point here is the limit of the mechanism, not a recipe.

One refresh detail grounds the design. Ticketmaster’s own integration documentation tells partners to refresh the token roughly twenty hours before the event starts and whenever the ticket is displayed. The secrets are not eternal; they are rotated on a schedule, which is why an offline screenshot taken days early is doubly dead, both its TOTP window and its underlying secret stale by showtime.

The 2022 collapse, read as a stress test

Put the three layers together and you have a defense that should, in theory, make industrial scalping uneconomic: an identity gate that taxes fake registrations, a random queue that nullifies raw speed, and a ticket format that resists casual duplication. On 15 November 2022 the Eras Tour presale ran all three at the largest scale Ticketmaster had ever attempted, and the result was a public failure severe enough to produce a Senate hearing.

The numbers come from the company’s own sworn account and from contemporaneous reporting. 3.5 million people registered for the U.S. Verified Fan presale. About 1.5 million got codes; the rest were meant to be held back. When the sale opened the site took on the order of 3.5 billion system requests in a day, against a prior peak nearer 875 million, and roughly 12 million entities, humans and bots together, hit the site. The waiting room froze, buyers were logged out mid-queue, and the experience degraded badly enough that Ticketmaster cancelled the general public on-sale three days later, on 18 November, while still reporting a record 2.4 million tickets sold in the chaos.

*The presale failure was a product event in November 2022 and a political one by January 2023. The antitrust suit that followed was about market power, not bots, but the collapse is what put it on the calendar.*

What broke is the load-bearing question, and the testimony is specific about it. Live Nation’s Joe Berchtold told the Senate Judiciary Committee on 24 January 2023 that the onsale drew “three times the amount of bot traffic than we had ever experienced,” and that the attackers went after the access-code infrastructure directly. In his account, the bots did not just try to buy tickets; for the first time in the program’s history they came after the Verified Fan access-code servers themselves, attempting to breach the very system meant to keep them out. He framed Ticketmaster as “the first line of defense against bots in this ever-escalating arms race” and conceded the company “could have done better,” including staggering the sale over a longer window. The attack, he said, forced the company to slow and pause sales, which is what produced the frozen queues that fans experienced.

Read structurally rather than as PR, the testimony describes a defense being attacked at its weakest joint. The identity gate had moved the contest from speed to scale, exactly as designed. The adversary responded by scaling, and then by attacking the gate’s own infrastructure. The access-code servers were a new target because they had become the thing worth attacking: in a system where a valid code is the scarce admission ticket to the queue, the codes themselves are the prize, and a bot that can mint or steal codes skips the entire registration tax. Whether or not the precise figures are generous to Ticketmaster, the shape is coherent. Harden one layer and the pressure moves to the next, and the layer that had never been hit before is the one that had quietly become the bottleneck.

It is also fair to note what the testimony elided. Berchtold’s bot-centric account was delivered to a committee whose actual subject was monopoly, and several senators treated the bot explanation as a deflection from a capacity-planning failure. The site took four times its prior peak, which is a fact about provisioning as much as about adversaries; a system can be both genuinely attacked and genuinely under-built for the load it invited by funneling 3.5 million registrants at a single moment. Both things are true. The defense worked well enough to reshape the attack, and the platform was not sized for the attack the defense reshaped it into.

The arms race the system lives inside

None of these layers exists in a vacuum, and none is static. The scalper economy is a real industry with real capital, and it adapts to each defensive move on a short cycle. The legal backdrop sets the stakes. The Better Online Ticket Sales Act of 2016, the BOTS Act, made it unlawful to circumvent the access controls and purchase limits that sellers like Ticketmaster put in place, and to resell tickets known to be acquired that way. For years it had no teeth. The first enforcement action did not come until January 2021, when the FTC, acting through the DOJ, brought cases against three broker operations that had bought more than 150,000 tickets using automated software, IP-concealment tools, and hundreds of fictitious Ticketmaster accounts and credit cards. The combined civil penalties were over 31 million dollars, suspended down to about 3.7 million for inability to pay.

That single enforcement record is the tell. The brokers’ toolkit, named in the FTC complaint, is precisely the set of capabilities each Verified Fan layer is built to tax. Hundreds of fictitious accounts defeat a per-account registration limit. IP-concealment defeats the queue’s traffic rules that block multiple sessions from one address. Automated buying software defeats the assumption that a human is at the keyboard. The defense and the offense are mirror images, each clause of the statute describing a control and each control describing an evasion. And the evasions sit downstream of the same commercial anti-bot machinery this blog documents elsewhere: the TLS and HTTP/2 fingerprinting that flags a non-browser client before it sends a byte of application data, the headless-Chrome tells that betray an automation framework, the residential-proxy and ASN reputation signals that price the IP-concealment layer the brokers depend on.

*Each control taxes a specific scalper capability, and each capability has a market that supplies it. The 2022 attack added the bottom row by going after the code servers directly.*

The pattern repeats at every layer. Tighten the registration identity check and the market responds with better-aged accounts and cleaner phone numbers. Randomize the queue and the bots stop racing and start fielding fleets. Block an IP and the request reappears from a residential proxy a subnet away. Rotate the barcode and the fraud shifts from selling screenshots to relaying live tokens. The defender is never finished, because the system is not solving a puzzle with an answer; it is running a market intervention against a counterparty with a budget. The honest measure of success is not whether bots get through. Some always do. It is the clearing price of a fake registration and the margin left in a resold ticket after the controls have taxed every step.

There is a structural reason ticketing is harder than most anti-bot problems, and it sits underneath everything above. A normal bot defense can fail safe by being slightly too aggressive, blocking a few real users to stop many bad ones, because a blocked scraper is cheap and a blocked shopper just comes back later. A ticket on-sale cannot. Inventory is fixed, demand spikes to a single instant, and every false positive is a real fan permanently shut out of a thing that will never be for sale again at that price. The defense has to be accurate under the worst possible load, at the exact moment the adversary has concentrated all of its resources, with no margin to be wrong in either direction. That constraint, more than any clever cookie or rotating code, is why the system is built in layers and why it still breaks.

Closing

Strip away the branding and the Verified Fan stack is a sequence of cost-shifting moves against an adversary with money. Registration converts a throughput problem into an identity problem. The random queue converts a latency problem into a concurrency problem. SafeTix converts ticket fraud from copying a file into running a relay. Each move is individually sound, grounded in primitives that work, and each one relocates the attack rather than ending it. The 2022 collapse was what relocation looks like when the platform under-provisions for the very contest it set up: the defense pushed the bots toward scale and toward the code servers, and the code servers were the thing nobody had load-tested for an assault.

The most durable lesson is in what is and is not public. The piece of this system whose mechanism we can state with confidence, SafeTix, is the piece an independent researcher took apart and documented down to the field names. The pieces Ticketmaster controls end to end, the registration selection logic and the queue token, remain opaque, and that opacity is load-bearing, because a published rule is a target. So the reference you can actually cite is the ticket format, an HMAC-SHA1 TOTP over two twenty-byte secrets, redrawn every fifteen seconds, and described not by the company that built it but by the person who reverse-engineered it. The most studied layer of the most-deployed ticketing defense in the world is the one its owner never explained.

---

Sources & further reading

• conduition (2024), Reverse Engineering TicketMaster’s Rotating Barcodes (SafeTix) — the definitive technical teardown: PDF417 payload structure, the ek/ck secrets, the TOTP construction, and the live-token relay limitation.
• Hackaday (2024), Ticketmaster SafeTix Reverse-Engineered — accessible summary of the conduition writeup, noting the 15-second rotation and the 20-hour refresh window.
• TechCrunch (2019), Ticketmaster put an end to screenshots with new digital ticket technology — the May 2019 SafeTix launch, the NFL rollout, and Ticketmaster’s stated anti-fraud rationale.
• Wikipedia (2026), Taylor Swift–Ticketmaster controversy — registration counts, the 3.5 billion request figure, the November 2022 timeline, and the litigation that followed.
• U.S. Senate Judiciary Committee (2023), Testimony of Joe Berchtold, “That’s the Ticket” hearing — the sworn account of “three times” bot traffic and the attack on the Verified Fan access-code servers.
• Fox Business (2023), Live Nation exec blames record number of bots for ticket debacle — verbatim Berchtold quotes on the bot arms race and the paused sales.
• Federal Trade Commission (2021), FTC Brings First-Ever Cases Under the BOTS Act — the 150,000-ticket broker cases, the evasion toolkit named in the complaint, and the civil penalties.
• Ticketmaster (n.d.), How the Ticketmaster Queue Works — the company’s own description of randomized queue position and why a first-come line favors bots.
• Ticketmaster Business (2025), Harness the Power of SafeTix — vendor description of SafeTix as an anti-resale, account-bound control.
• NBC News (2023), Ticketmaster says ‘Verified Fan’ registration doesn’t measure fandom — the company walking back the implied meaning of “verified.”
• Digital Music News (2017), 95% of Taylor Swift’s ‘Verified Fans’ Just Got Shafted — early coverage of the 2017 Verified Fan launch and its selection ratios.