ERC-7439: Prevent ticket touting

An interface for customers to resell their tickets via authorized ticket resellers.


Metadata
Status: FinalStandards Track: ERCCreated: 2023-07-28
Authors
LeadBest Consulting Group (service@getoken.io), Sandy Sung (@sandy-sung-lb), Mars Peng (mars.peng@getoken.io), Taien Wang (taien.wang@getoken.io)
Requires

Abstract


This standard is an extension of ERC-721 and defines standard functions outlining a scope for ticketing agents or event organizers to take preventative actions to stop audiences being exploited in the ticket scalping market and allow customers to resell their tickets via authorized ticket resellers.

Motivation


Industrial-scale ticket touting has been a longstanding issue, with its associated fraud and criminal problems leading to unfortunate incidents and waste of social resources. It is also hugely damaging to artists at all levels of their careers and to related businesses across the board. Although the governments of various countries have begun to legislate to restrict the behavior of scalpers, the effect is limited. They still sold tickets for events at which resale was banned or did not yet own then obtained substantial illegal profits from speculative selling. We consulted many opinions to provide a consumer-friendly resale interface, enabling buyers to resell or reallocate a ticket at the price they initially paid or less is the efficient way to rip off “secondary ticketing”.that enables ticketing agents to utilize

The typical ticket may be a "piece of paper" or even a voucher in your email inbox, making it easy to counterfeit or circulate. To restrict the transferability of these tickets, we have designed a mechanism that prohibits ticket transfers for all parties, including the ticket owner, except for specific accounts that are authorized to transfer tickets. The specific accounts may be ticketing agents, managers, promoters and authorized resale platforms. Therefore, the ticket touts are unable to transfer tickets as they wish. Furthermore, to enhance functionality, we have implemented a token info schema to each ticket, allowing only authorized accounts(excluding the owner) to modify these records.

This standard defines a framework that enables ticketing agents to utilize ERC-721 tokens as event tickets and restricts token transferability to prevent ticket touting. By implementing this standard, we aim to protect customers from scams and fraudulent activities.

Specification


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Interface

The interface and structure referenced here are as follows:

  • TokenInfo
    • signature: Recommend that the adapter self-defines what to sign using the user's private key or agent's private key to prove the token validity.
    • status: Represent token current status.
    • expireTime: Recommend set to the event due time.
  • TokenStatus
    • Sold: When a token is sold, it MUST change to Sold. The token is valid in this status.
    • Resell: When a token is in the secondary market, it MUST be changed to Resell. The token is valid in this status.
    • Void: When the token owner engages in an illegal transaction, the token status MUST be set to Void, and the token is invalid in this status.
    • Redeemed: When the token is used, it is RECOMMENDED to change the token status to Redeemed.

The supportsInterface method MUST return true when called with 0x15fbb306.

Rationale


Designing the proposal, we considered the following questions:

  1. What is the most crucial for ticketing agents, performers, and audiences?

    • For ticketing companies, selling out all tickets is crucial. Sometimes, to create a vibrant sales environment, ticketing companies may even collaborate with scalpers. This practice can be detrimental to both the audience and performers. To prevent such situations, there must be an open and transparent primary sales channel, as well as a fair secondary sales mechanism. In the safeMint function, which is a public function, we hope that everyone can mint tickets transparently at a listed price by themselves. At that time, TokenInfo adds a signature that only the buyer account or agent can resolve depending on the mechanism, to prove the ticket validity. And the token status is Sold. Despite this, we must also consider the pressures on ticketing companies. They aim to maximize the utility of every valid ticket, meaning selling out each one. In the traditional mechanism, ticketing companies only benefit from the initial sale, implying that they do not enjoy the excess profits from secondary sales. Therefore, we have designed a secondary sales process that is manageable for ticketing companies. In the _beforeTokenTransfer() function, you can see that it is an accessControl function, and only the PARTNER_ROLE mint or burn situation can transfer the ticket. The PARTNER_ROLE can be the ticket agency or a legal secondary ticket selling platform, which may be a state supervision or the ticket agency designated platform. To sustain the fair ticketing market, we cannot allow them to transfer tickets themselves, because we can’t distinguish whether the buyer is a scalper.

    • For performers or event holder, they aren't willing to see bad news during ticket selling. A smooth ticketing process or no news that may damage their performers’ reputation is what they want. Other than that, what really matters is all the audience true fans who come. Tickets ending up in the hands of scalpers or entering a chaotic secondary market doesn't really appeal to genuine fans. We believe performers wouldn't be pleased with such a situation. Through the transparant mechanism, performers or event holder can control the real sales status at all times form cross-comparison of token mint amount and TokenInfo-TokenStatus.

      
      
    • For audiences, the only thing they need is to get a valid ticket. In the traditional mechanism,fans encounter many obstacles. At hot concerts, fans who try to snag tickets can run into some foes, like scalpers and ticketing companies. These scalpers are like pros, all organized and strategic in grabbing up tickets. Surprisingly, ticketing companies might actually team up with these scalpers. Or, they might just keep a bunch of freebies or VIP tickets to themselves. A transparent mechanism is equally important for the audiences.

  2. How to establish a healthy ticketing ecosystem?

    • Clear ticketing rules are key to making sure the supply and demand stay in balance.

    • An open pricing system is a must to make sure consumers are protected.

    • Excellent liquidity. In the initial market, users can mint tickets themselves. If needed, purchased tickets can also be transferred in a transparent and open secondary market. Audiences who didn’t buy tickets during the initial sale can also confidently purchase tickets in a legal secondary market. The changeState function is to help the ticket have good liquidity. Only PARTNER_ROLE can change the ticket status. Once the sold ticket needs to be sold in the secondary market, it needs to ask the secondary market to help it change to resell status. The process of changing status is a kind of official verification of the secondary sale ticket. It is a protection mechanism to the second hand buyer.

  3. How to design a smooth ticketing process?

    • Easy to buy/sell. Audiences can buy ticket as mint NFT. This is a well-known practice.

    • Easy to refund. When something extreme happens and you need to cancel the show. Handling ticket refunds can be a straightforward process.

    • Easy to redeem. Before the show, the ticket agency can verify the ticket by the signature to confirm if the audience is genuine. TokenStatus needs to be equal to sold, and expireTime can distinguish whether the audience has arrived at the correct session. After verification is passed, the ticket agency can change the TokenStatus to Redeemed.

    • Normal Flow Alt text

    • Void Flow Alt text

    • Resell Flow Alt text

Backwards Compatibility


This standard is compatible with ERC-721.

Test Cases



Reference Implementation



Security Considerations


There are no security considerations related directly to the implementation of this standard.

Copyright


Copyright and related rights waived via CC0.