EventChain: Decentralized Event Ticket selling platform

Project Name: Eventchain, Decentralized Event Ticket selling platform.
Project Track: Web3
Team Name: EventChain Team
Team Member(s): Joel (joel1234), David (dfornos), Gokarna (itsgorkiwiski)
HackerEarth Project Link: https://devpost.com/software/eventchain
Project Goal: EventChain is a decentralized platform designed to streamline event management and ticket sales. At its core, our project introduces a novel concept that transcends traditional ticketing systems. By leveraging blockchain technology, we aim to offer a unique and streamlined solution that not only enhances the experience for event organizers and attendees but also sets new standards for efficiency and security.

From a technical standpoint, our platform possesses cutting-edge features designed with scalability and user-friendliness in mind. With an intuitive interface, users, regardless of their familiarity with blockchain technology, can seamlessly navigate the platform and make use of its services. Our platform also aims at highly regulating the illegal resale of tickets and interchanging it with a secure, transparent marketplace. We regulate the illegal resale of tickets with a signature system that generates a temporary QR code. This QR code identifies the person who bought the ticket, and, as it is temporary, an illegal seller would need to arrange the resale in a very small window of time (i.e., 30 seg). A regular attendee just needs to click a button to generate the QR at the moment of entering the event to show it to the bouncer.

Furthermore, the business model we propose highly benefits all the stakeholders involved. First, event host/content creators/celebrities would increase their earnings through the resale marketplace, having the possibility to charge fees for the resale of their tickets. In the future, we envision EventChain as a whole ecosystem where merchandising, VIP events, exclusive content and exclusive event features are also sold. The event creators would highly benefit from having all of their experiential content in one highly-secure place that also validates ownership of the assets through blockchain. And users would receive much more value than they are getting through traditional event sites. In each of those transactions, EventChain would charge fees, which would be the main revenue stream of the company.

Interacting with the blockchain in our app is easy by connecting the TronLink extension to our website. This tool ensures that even those new to blockchain technology can easily interact with our program. By removing barriers to entry, we aim to attract a wide range of users and foster widespread adoption within the community.
Project Value:Our project addresses a genuine need in the community. In recent years, we have experienced a huge rise in demand for experiential products, showing that users are looking for more in-person events and experiences. This opens up a unique opportunity to build an ecosystem where creators and fans interact pre, during and post in-person events by offering innovative, secure ticketing systems and taking event organising to the next level. By using our system, event organisers and users will be secure against scams that arise in traditional ticketing schemes.
Project Info: Moving forward, we aim to further professionalize the website and enhance user experience. This includes refining the interface, optimizing performance, and incorporating additional features to provide even greater value to our users. Our end goal is to provide an efficient, secure, and convenient solution for both event organizers and attendees, where interaction between celebrities, content creators, event organizers, and their fans, is further improved and their relations strengthen. Our aim is to establish a digital platform utilizing blockchain technology, enabling event organizers to enhance the value they offer to their audience. Beyond merely ticket sales, we aim to build a platform with comprehensive user experience, including merchandise sales, digital assets, and VIP event features. Ownership rights are secured through blockchain, ensuring transparency and trust.
This approach opens up significant opportunities, transforming events into more than just short-lived experiences, where events will not only be a few-hours experience, but will have many more features aiming at improving the relation creator-fan. Moreover, creators gain control over the ticket resale market, providing them with additional revenue streams while empowering fans to securely sell or purchase tickets through authorized channels. This effectively eliminates common scams associated with traditional ticketing systems. Our vision goes further than just ticket sales to embrace a broader marketplace, where resale of exclusive event content or VIP features would be possible through our ecosystem. This holistic approach revolutionizes the event industry, fostering a more secure and engaging experience for all parties involved, and gives rise to novel opportunities and markets.
Project Website: https://event-chain.netlify.app/
Project Test Instructions: Utilize the website as if you were a user that wants to buy tickets for an event or to resell them at a later stage. See video below.

**To interact with the smart contract (i.e., buying tickets, creating events, etc.), you will need to use Tron Link extension. For example, when you press the buy button, the extension will pop up and ask you to sign the transaction. **

In the current version, two example events are shown. Those events were deployed on the Shasta test net for demonstration purposes only. Now, the project is deployed on mainnet, so to test the project’s full capabilities, you will need to create your own events, pay the corresponding fees, etc.

Project Details:


Video presenting the site:

Smart Contract links: Interaction with smart contracts is available through our website. However, have them here for reference. The following deployed smart contracts are test contracts in the Shasta network (please see the “Project Test Instructions” section above for further information). The user that uses our website can deploy smart contracts on-demand, according to the generation of events he/she requires. Example events (smart contracts deployed on Tron Shasta Testnet):

Accounts that deployed the contracts:

  1. Account that deployed SynthWave: TDswtsRGWwKNp3cxbXgUMsTjGKMfyCdanD
  2. Account that deployed Blockchain Hackathon: TAEXBVR2pBxYpFDEdsF3UXws7zMzZTfy9T

Some of the contracts are no longer used in the website, as they were deployed early in the development process to test functionalities)

Contract addresses (used on the website, Shasta Network):

  • Blockchain Hackathon: TGm9uKL75C9d7j2FhE1cPqvv1zGbnKjPaD
  • SynthWave festival: TDdg1hVMjmMXLA2hJRrEQbectBJksqj9w2

Project Milestones by June 28th:

  1. Update website functionalities to meet user needs.
  2. Enhance user interface.
  3. Deployment to mainnet
  4. Authentication signature of the website by a CA.

Roadmap

image

9 Likes

Welcome to Grand hackathon season 6 wishing you all the best

2 Likes

Interesting idea.
What are next plans for your project ?

1 Like

Hello, and thanks!

Our next steps will involve including more and more functionalities and professionalizing the interface. We aim to create a secure and complete platform for user-event host interaction beyond merely ticket selling and reselling. This can include selling a wide range of products related to the event such as merchandise or providing different level experiences such as VIP, backstage access, among others.

This would allow event creators to create collections of items exclusive for each event, and even exclusive between the attendees of the event, controlling the number of items produced. For example, imagine there is a boxing event. The event creator/boxers could sell the boxing gloves within our ecosystem. This item is highly exclusive, as there are very limited units.

We would also add resale features for these products. It would be like a large marketplace where the attendees can commercialize any product within the event under the rules set by the host. In the example, the boxing gloves could also be resold within our event ecosystem. This way, all the event creator-user relations are produced in a controlled, trusted space, and new forms of value are created or made accessible to more people. It’s a win-win transaction since the host could earn a commission for each sale, and ownership rights could be always verified through the blockchain and very difficult to resell through unauthorized channels (using the changing QR code verification system already implemented, for example). Everything would be managed through our website but leveraging the TRON network to ensure that the transactions are transparent and decentralized.

Moreover, we want to expand our platform and create a mobile app that will make everything even easier and more appealing for the user. In summary, we want to enhance our product by making everything more professional, adding new marketplace features, and developing the mobile app.

1 Like

Welcome to Hackathon Season 6, this is quite interesting and from my read I can deduce that The EventChain project aims to revolutionize event management and ticket sales by leveraging blockchain technology.

How does the signature system for ticket resale ensure security against illegal sellers?

Welcome welcome welcome, please tell me more about the team roadmap, thank you

1 Like

Hello, and thanks for the question!

The process that regulates illegal selling consists of different steps that result in the generation of a secure QR that allows entrance to the event only to the client who bought the ticket for that event.

As in usual digital signatures, the authentication relies on the possession of a secret, in this case the private key of the TRON Wallet. When the access to the event happens, the person controlling access would ask for the QR access to the attendee. The attendee uses our mobile app to request a QR from his account by clicking a button. This QR is generated from the user’s signature (that is, the event smart contract address signed with the user’s private key), the ticket id for the event to which the user is requesting access, and a temporary random number generated by the server, which is valid for a certain time, in our case 30 seconds. Then, when the access controller at the event scans the QR, this information is sent to the server. In the server, each of the three steps is validated.

First, with the ticket id sent, the server retrieves the account (from the Blockchain) that bought that specific ticket id for that event. If it exists, it validates the signature with that account, and if the signature validation process is successful, that means the person holding the QR possesses the private key that is linked to the account that bought the ticket.

Finally, the temporary random number contained in the QR is checked by verifying that it is also possessed by the server. That ensures that the QR code was generated at most 30 seconds ago. Then, even in the case that an individual bought a ticket, and generated a valid QR for that ticket, then resold the ticket illegally and sent the QR code to that third party, the QR would not be valid when about to enter the event, as each QR is valid for 30 seconds because of that number. Then, for the illegal resale to be successful, it would have to happen within much less than a 30 seconds time window (take into account that within those 30 seconds, the access controller needs to scan the QR too). This makes illegal resale extremely difficult. Furthermore, this does not make the process of accessing the event cumbersome at all, as the process of scanning a QR code takes usually much less than 30 seconds, and in case of errors, the user can generate as many QR’s as necessary.

Right now, this is implemented in the website for testing. However, we have in mind implementing it in a mobile app.

Please ask any doubts you might have about the implementation of the QR functionality.

Thank you for your time and efforts put into the detailed explanation of the process for regulating illegal ticket resale, it’s fascinating to see how the platform utilizes digital signatures and temporary QR codes to ensure secure event access for ticket holders.

I’ve one question bordering on QR codes relating to my personal experiences;
How does the platform handle cases where attendees encounter technical issues or delays in generating their QR codes within the 30-second window? Are there contingency measures in place to accommodate such scenarios without disrupting the event entry process?

Hello and thanks for your question. Here you have a detailed roadmap. Don’t hesitate to ask any doubt you may have.

Hi! Impressive work on the project.

We’re also developing a project on Tron, by the way. Let me tell you a bit about us.

Strongcoin is a tap-to-earn game. In our game, there’s onboarding to the Tron ecosystem, where we publish partner quests. If you’re interested, we can arrange a collaboration.

Currently, we’re running a contest for the best question/suggestion with cool prizes! Come to our topic and read more.

Thanks for your response!

Different fault situations can arise with the system described above, and different measures could be taken. A list of possible failure scenarios with the respective possible contingency measures is given:

  1. Failure of the QR code generation/validation due to network delay: if this is the case, the user should always try to regenerate the QR code sometimes, as it is the best verification method. However, if the network connection is severely affected and regenerating is impossible, a more traditional approach will be taken. The user will be allowed to show an email that will be sent to him previously to the event (i.e., 12h before) together with the email address, and the person in charge of access control will have the list of emails that bought a ticket for the event. This can ensure that the event access is still smooth and possible.

  2. Crash of user’s mobile app: first, the user will be set aside and prompted to restart the phone/app as necessary. The access control process will keep taking place for other users. When the user has done as requested, the QR generation process will be tested again. If it keeps failing, a friend (if possible) will let the affected user log in on his device. If it is impossible/keeps failing, the email process described in point 1. will take place.

  3. Issues reading the QR, user takes long to generate the QR, etc: a general solution for making the access quicker if the user/access controller are slow and take more than 30 seconds to read the QR. The solution is regenerating the QR automatically every 30 seconds after the user clicks on the generate QR button. This automatic regeneration will take place until the verification process is finished. This slightly smoothes the process, as, if the user generates the QR before his turn to validate access, the 30 seconds would probably run out, and the user would need to regenerate the QR. With this, this time is saved.

Please ask any more questions you might have.

1 Like

Hi! Thank you very much for your offer, we will check it out!

Hi and thank you for sharing your roadmap with me

1 Like

This particular solution absolutely provide a thoughtful approach to handling potential failures in the QR code generation and validation process.

How is the email verification process secured to prevent unauthorized access? For instance, what measures ensure that only the legitimate ticket holder’s email is used for event entry?

Hello and thanks for your response!

Assuming our servers are completely out of service (no QR-secured authentication/signature-based authentication can be done), the email verification process would be carried out manually. That is, the access controller would check the list of allowed emails (emails from accounts that have bought a ticket) and check that the email shown by the user requesting access to the event is the same. In case of doubt or if email servers are also unavailable, the user will have to provide a valid government ID where the name is clearly visible, and the access controller will also check manually that the name in the ID matches the name of an account holder that owns a ticket to that event.

Note that these solutions are last resort solutions to cases where the other tech-reliant, more secure authentication solutions (such as the QR code) are unavailable because of a total failure of the network and/or servers, which will only happen in extreme cases. Those solutions are not to be used during nominal functioning of our system.

Please do not hesitate to ask more questions.

Your replies doesn’t fall short of your name; “Event Chain” as it almost seems like a series of calculated chain of replies lol.
Moving forward, your contingency plans for extreme cases where servers and network services are completely unavailable show a thorough approach to ensuring event access continuity.

I’m curious, what measures are in place to ensure the privacy and security of personal information when attendees present government IDs for verification?

Hello again!

I guess our name, Event Chain, represents our project and team strengths very well lol.

Discussing your question within our team, we have concluded that asking for a government ID to match the legal name does not offer a good trade-off between security and privacy, as the user would need to give us sensitive information, and this solution is actually not needed. Therefore, our last contingency measure in case everything else fails will be the email check we talked about in our previous responses. The access controller, in case of doubt, will not allow the entry of the user to the event. That is because if the access controller is doubting of the veracity of the email, that means the email does not match completely the correct email, and therefore the user should not be allowed in. If the email servers are down at the moment of entry, the user can still check his email inbox offline, and will be able to show the correct email for authentication.

Thanks for your question, it made us reflect on the fact that the ID solution was actually removing privacy to a certain extent and it is very important for us to maintain the data privacy of our users. Our email solution already ensures a secure contingency authentication procedure in the unlikely case our official, most secure authentication system (QR code explained in our other comments) and the previous contingency measures fail.

Please do not hesitate to ask more questions.

Like the concept od the project, is the project already live on mainnet ?

Hello!

Yes, there is an MVP of the project you can checkout in the following link: https://event-chain.netlify.app/

However, the MVP uses the testnet, not the mainnet.

Make sure to enable https requests to our server, as your browser might block them at first because the SSL certificate is self-signed. Also, make sure to have the Tron Link wallet extension to be able to interact with all the website’s features.

Please do not hesitate to ask any questions you might have.

Once again, I must commend how your reply doesn’t fall short of your name lol.
Moving forward, your decision to avoid using government ID for verification, prioritizing user privacy and focusing on email verification, is understandable.
Given the reliance on email verification in contingency scenarios, how will the system ensure scalability and efficiency, particularly for large events with thousands of attendees?

1 Like