A ticket is a permission to enter. The job of any ticket, paper or digital, is to convince someone at a door that the person standing in front of them belongs on the other side of it. Everything else is decoration.
The thing that makes digital tickets harder than paper is that paper is hard to copy and digital is trivial to copy. A photograph of a screen takes one second. The image is identical to the original. If your ticket is a static QR code or barcode, you have just shipped a system where the original buyer can attend and so can anyone they accidentally sent the screenshot to. The door staff have no way to tell which is which. Most digital ticketing systems have lived with this for years by hoping it doesn't happen at scale.
It happens at scale, but it does not always happen maliciously. The honest case is more common than the fraudulent one. A buyer takes a screenshot to send to a friend who is meeting them at the venue, the friend forwards it to another friend by accident, and three people show up at the door with the same code. The first one in gets through. The other two have a bad night. The fraud case exists, but the design problem is dominated by ordinary human behaviour.
Four things a trustworthy ticket has to do
A ticket designed for trust has to do four things. It has to verify on scan, every time, against the original record of sale. It has to be hard to duplicate in a way that survives a screenshot. It has to handle transfer cleanly, so that when a fan legitimately gives their ticket to a friend, the new holder gets a working ticket and the original holder's copy stops working. And it has to communicate to the holder, in plain language, what they are looking at.
The first three are technical decisions. The fourth is a design decision, and it is the one most digital ticketing systems get wrong.
The refresh interval
A static QR code that doesn't change can be screenshotted once and used many times. A QR code that refreshes every 30 seconds is mildly annoying. A QR code that refreshes every five seconds is unusable, because the moment a holder has their phone out at the door, the code has already changed before the scanner has focused. The right interval is one that makes screenshots useless without making the ticket awkward to actually use.
Sixty seconds is the practical answer for most events. It is long enough that the holder can take their phone out, navigate to the ticket, and walk through the door without rushing. It is short enough that a screenshot taken now and shared in five minutes is already invalid.
No wallet addresses on the ticket
Then there is the question of what the holder sees on the ticket. The temptation, if your platform happens to use a public ledger underneath, is to show the wallet address. This feels transparent. It is also the wrong call. A wallet address means nothing to a fan who bought a ticket to see a band. It introduces a string of characters that the holder has no use for, that no door scanner needs to see, and that creates the impression the platform is built for crypto users rather than ticket buyers. The address is an implementation detail. The holder does not need it to attend the event, and showing it implies they should care, which they shouldn't.
The MINGO QR ticket reflects all of this. The QR code refreshes every 60 seconds. The wallet address is not displayed anywhere on the ticket. The verification happens on the back end. The holder sees an event name, a date, a venue, a seat or admission type, and a code that updates while they look at it. That is the entire surface they interact with.
Warning copy that actually works
The warning copy is the part that took the longest to get right. Most digital tickets have no warning copy at all, or have boilerplate text in small print that nobody reads. The MINGO ticket has a short, direct line on the front: do not share a screenshot of this ticket. It will not be valid at the door. The tone is intentional. It is not a legal disclaimer. It is a statement of fact that a fan can act on. People share screenshots because they don't know that they shouldn't, not because they are trying to commit fraud. The warning catches the honest case before it becomes a problem at the gate.
Clean transfer flow
The transfer flow is the other place where a lot of digital tickets fall apart. A holder transferring a ticket to a friend should not have to explain the platform to that friend, send them a wallet address, or walk them through onboarding. The friend should get a link, open it, see a ticket, and walk through the door. The MINGO transfer is built around this. The recipient does not need an account at the time of transfer. The original sender's ticket goes invalid the moment the new one is generated. There is no window in which both copies work.
Trust through subtraction
Fans do not need to know how the ticket works. They need to know it works. Most ticket holders have never thought about why a code refreshes, or what verifies it at the door, or what happens when they hit the transfer button. They expect the same experience they get from a boarding pass: open the app, hold up the screen, walk through. Anything more visible than that is something the platform has failed to hide properly.
What this comes down to, in design terms, is a discipline of subtraction. Every element on a ticket has to earn its place. Anything that doesn't help the holder get through the door is, at best, ornamentation, and at worst, an obstacle. A wallet address is an obstacle. Technical jargon is an obstacle. Lengthy legal disclaimers are an obstacle. They all reduce the chance that a fan looks at their ticket and feels confident about what to do with it.
This is why every decision in the MINGO ticket was made against one question: does this make the ticket easier to trust at the door? If the answer was no, it was cut. What is left is a ticket that has to do one thing and does it without asking the fan to think about anything else.