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.
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 components are:
Management contract provides the owner with the ability to set permissions and register contracts. It includes a number of methods:
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:
Event is a smart contract, responsible for managing the list of events and all details of the corresponding event. Its functionality includes:
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.
There are four major roles (represented by the ether address of the user) that interact with a smart contract:
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: