Ticketing Ecosystem Smart Contracts

This boilerplate smart contract template introduces the core ideas and implementations for tickets management. It showcases key opportunities that immutable distributed ledgers and Solidity smart contracts offer: profit sharing between all participants of the value creation and resales chain.

https://github.com/Applicature/solidity-ticketing-boilerplate.git

DISCLAIMER: THIS SMART CONTRACT SUITE WAS DESIGNED FOR DEMO PURPOSES; UNLESS EXPLICITLY INDICATED OTHERWISE, THESE SMART CONTRACTS HAVE NOT BEEN AUDITED FOR PRODUCTION USAGE.

dTicketing Smart Contract Description

dTicketing smart contract components are:

Management contract provides the owner with the ability to set permissions and register contracts. It includes a number of methods:

1. registerContract(uint256 _key, address _target) – registers the _target contract to the specified _key
2. setPermission(address _address, uint256 _permission, bool _value) – sets or unsets the _permission to perform certain actions for the _address

Managed is a parent contract for all platform-related smart contracts, except for Management. Its main objective is to store the actual Management contract address and interact with other contracts via the Management contract.

Constants is a contract that has been designed to store constant values indicating contracts and their permissions to perform specific actions.

EventTicketsRegistry is the ERC-721-based mintable-token smart contract extended with the TicketDetails structure for storing additional ticket information. Its main functionality includes:

1. initial ticket sale (minting tokens)
2. ticket resale (changing token owner)
3. burning tickets (“returning” a ticket to its initial seller)

Event is a smart contract, responsible for managing the list of events and all details of the corresponding event. Its functionality includes:

1. creating event (adding new elements to the event list)
2. updating event details (in case some of the circumstances of the event change)
3. ability to withdraw funds collected after the start of the event

FundsDistributor is a smart contract responsible for managing funds passing through the platform. Function distributeResaleFunds(uint256 _eventId, uint256 _ticketId) public payable receives ethers and distributes them between previous ticket owner and initial seller (sharing the profit with the event organizers).

Marketplace is a contract, that includes the functionality of all above-mentioned contracts and allows to perform only direct interactions with the system, via itself.

Use Flow and Roles

There are four major roles (represented by the ether address of the user) that interact with a smart contract:

• platform-related Ethereum address for signing a transaction
• platform’s owner address that can manage contracts and state variables
• ticket owner that can either use his ticket or resell it
• event organizer which is the address that receives the profit share from tickets resale

Screenshots of Interaction with SC

Each Ethereum address can add a new event to the registry through  Marketplace SC.

After this, the user becomes the owner (primary seller/organizer) of this event.

Along with this, a new instance of EventTicketsRegistry is created to mint new tokens (tickets for the specified event) for buyers upon request:

In order to get a ticket, the user should claim it with a hash generated by the platform.

The hash data contains a buyTicketFromOrganizer function with a signed sender’s address (a team member that will receive this ticket) and some details, including event ID, profit share percentage, seat details, and initial ticket price.

After receiving the ticket, the user can use it to participate in an event or to resell it.

The resale of a ticket takes a few steps. First, the current ticket holder should specify the resell price.

After someone purchases it using a buyTicketFromReseller method, funds are distributed between the primary seller who must receive shares of profit and the previous ticket owner.

To make a refund, the user just needs to claim it in a similar way as when buying a ticket.

However, in this case, the hash would contain refund function with signed sender address, event, and ticket IDs and refund percentage (according to the refund policy).

After the start of the event, the organizer can withdraw collected funds. The result of withdrawing would look as follows: