1.0

Glossary

Events

  • Access Control is the selective restriction of access to an event or other resource. Within our ecosystem, permission to access is granted with a ticket that is referenced as valid in the doorlist
  • Doorlist is a static list of all of the valid tickets for an event used for access control. The doorlist can be compiled at any time in the event lifecycle but as ticket ownership updates (resale & transfer) can still happen in the run up to an event, the list is only useful for access control at the eventTime
  • Event A parent object on the Aventus Protocol which has an eventOwner and can have associated roles. The purpose of an event is to group children objects, tickets, into manageable and referenceable allocations. Events on the Protocol are designed to align with real-world physical events (ie. Live performance, sports game, conference, etc.) meaning the eventTime should match the real-world time the event is due to take place
  • eventId A unique identifier for the event on the Protocol, see IDs for more info
  • eventOwner The role of the user who creates the event on the Protocol, see Roles for more info
  • eventTime A Unix Epoch time to signify the time of the real-world physical event. Also used by the Protocol to calculate the required Merkle Root deposit, see AVT for more info

Tickets

  • Ticket A permission that indicates that an individual is entitled to admission to an event tied to an address in a Ticket Wallet. A ticketOwner typically pays for a ticket, but our ecosystem is focussed on ticket delivery & handling, so payment considerations are dealt with externally. Ticket's have built-in properties including additional details for that ticket, typically including fields like: grouping (ie. VIP, Earlybird), gate number, row / seat number, etc.
  • ticketId A unique identifier for the ticket on the Protocol, see IDs for more info
  • ticketOwner The bearer of a ticket, see Roles for more info
  • Ticket Wallet is a mobile application that ingests and displays tickets. We've built some reference Ticket Wallet applications using our Ticket Wallet SDKs that are compatible with Aventus tickets.
  • Resale Within the Aventus ecosystem a ticket owned by a ticketOwner can be resold to another Ticket Wallet, updating the ownership associated with that ticket on the blockchain
  • Cancel Another action that can be taken on a ticket is a cancellation, meaning that the ticketOwner will no longer be represented on the doorlist so they cannot attend the event

Roles

  • eventOwner The role of the user who creates the event on the Protocol. Identified by an Ethereum address, the eventOwner has full admin permissions to carry out event-level actions such as; new role registration, ticket creation, and ticket cancellation
  • Primary A ticket administrator in the primary market (initial ticket sales). Identified by an Ethereum address, the Primary has permissions to carry out ticket-level actions such as; ticket creation, and ticket cancellation
  • Secondary A third party ticket administrator in the secondary market (pre-owned tickets for resale). Identified by an Ethereum address, the Secondary only has permission to carry resell tickets
  • ticketOwner The current bearer of a ticket. As ownership can be updated via a resell or transfer this is not always the person who first purchased the ticket from a Primary

Blockchain

  • Blockchain is a distributed public ledger
  • Ether is the name of the currency used within Ethereum used to pay for computation within the EVM. This is done indirectly by purchasing something known as gas for each transaction sent to the network with Ether
  • Ethereum is a decentralized platform for applications that run exactly as programmed without any chance of fraud or third-party interference using network consensus. Check out the original Whitepaper for more info
  • Event (Solidity) is an activity within Solidity that notifies to any listener that something happened on the originating service. These activities are usually published to a topic for listeners
  • EVM
  • Ganache is a Node.js based Ethereum client for testing and development (previously referred to as 'testRPC')
  • Gas is required for each transaction on the Ethereum network and acts as an execution fee to account for computational usage of the EVM. Nodes on the network are paid in gas to process transactions, for more info see here
  • Geth is the the command line interface for running a full Ethereum node implemented in Go
  • Libraries in Ethereum are special types of smart contract which do not store data and cannot hold ether. They are are only required to be deployed once and their functions can then be called by any smart contract via delegate calls]
  • Smart Contract allow the performance of credible transactions without third parties, see more here
  • Solidity is a contract-oriented programming language for writing smart contracts that runs on the EVM
  • Rinkeby is a public Ethereum testnet and the one used by the Aventus Protocol

IDs

  • ticketRef A reference provided by the eventOwner (or Primary) used to uniquely identify a ticket throughout the system. No specific structure for the string is mandated, other than the uniqueness is met per ticket for each eventOwner. This value is then referred to as a vendorTicketRef as it is unique to that particular vendor for that particular event
  • VendorTicketRefHash The vendorTicketRef is passed in hashed, it is then appended with the vendor address and hashed again to ensure uniqueness across vendors, before being cast into the Protocol ticketId
  • ticketId A unique ticketRef for each ticket made up of the vendorTicketRef and the vendor address to ensure proper uniqueness across potential multiple primary vendors in a uint256 format
  • eventId A unique (always incrementing) number associated with each event that is assigned by the Protocol upon creation. Globally unique across the Protocol and all events to ever exist in it

AVT

  • Aventus Community is made up of AVT token holders interested in utilising the Aventus Protocol
  • AVT is the ERC-20 token used in the Aventus Protocol (originally referred to as an AventCoin many moons ago)
  • Challenge The Aventus Community can challenge the legitimacy of Merkle Leaf on the Protocol. This is incentivised by the challenger winning the deposit of AVT put down by the original Validator if a challenge is successful
  • Deposit An amount of AVT required for certain interactions with the Protocol that are open to challenge. The deposit is an incentive for a Validator to act correctly as any unwanted behaviour will result in their deposit being lost
  • Governance Proposal Aventus Community members can propose governance changes to the Protocol parameters on the Parameter Registry. Once a proposal has been initiated, members can vote on wether the change should be applied or not by voting with their AVT stake. Each proposal has defined time-periods in which certain actions must take place:
    • Lobbying Period is the 2 week time slot at the start of the Governance Proposal process where the Aventus Community can externally discuss and debate a new proposal, followed by the Voting Period
    • Voting Period is the 1 week time slot following a Lobbying Period during the proposal process where the Aventus Community can submit secret signed votes on whether a Governance Proposal should be applied or not
    • Reveal Period is the 1 week time slot following a Voting Period at the end of the proposal process where the Aventus Community can reveal their vote by re-submitting a secret signed vote on a Governance Proposal. Once all votes have been revealed then the proposal process can be concluded and AVT amounts for each vote option are tallied to decide a winner
  • Hashing takes an input string of any length and gives an encrypted output of a deterministic fixed length string. Hashing is used throughout the Protocol alongside Signing. Try out this example here
← Previous