Mainnet
Launching the on-chain economics of GET Protocol
Today is a good day for many reasons, one of them being that today is the day we close our 'Mainnet' epic. We can say with confidence that the NFT mints are humming along, the on-chain economics is well documented and flowing correctly, and not only that but we're open-sourcing some tooling to help access and visualise this data. These aren't just demo projects, but these are the same production-ready code that we use as our own building blocks to build products and tooling for our integrators.
Our mission at GET Protocol is to be the Open Data Standard for ticketing and today we'll be focusing in on those first two words; 'Open Data'. To push us further in that direction we've released our subgraph implementation for reading aggregated historical data useful for building charting and analytics applications, as well as a websocket server for receiving real-time information on all usage within the protocol - a great foundation for building bots and data feeds.
Introducing the GET Protocol Subgraph
The Graph is quickly emerging as the industry standard for indexing on-chain data in a decentralised manner and supports many of the projects you may already use and be familiar with. If you've used the analytics site of a top decentralised exchange recently then there's a good likelihood that the data you're seeing on your screen is powered by a Graph node.
The subgraph is now available to be queried by yourself using The Graph Explorer.
What can I find?
The on-chain data has been broken down into three categories; cross-sectional, aggregate, and time-series. Cross-sectional data is the static (or compiled) output after all the updates are complete. Aggregate data is the all-time aggregated usage data across the protocol and each relayer, and time-series is this same aggregate per-day.
In slightly less developer-speak you have Event Metadata that gets updated continually to its latest info, and you also have access Usage Data that is aggregated all-time and per-day.
We want to make it as simple as possible for everyone to query for the on-chain data. Some examples of this could be:
I am a community member, and I want to see how many tickets have been aggregated on the protocol from all-time.
I am an integrator and I want to see my usage metrics for the protocol by day.
I am a GET Protocol developer and I want to build products that customers can use - that's right, we're going to be building on top of this too.
You can head over to the GET Protocol Subgraph Playground and start to query data. Some GraphQL knowledge may help, so here are some queries to get started with:
{
protocol(id: "1") {
mintCount
averageGetPerMint
}
}
{
relayerDays(
orderBy: day,
orderDirection: desc,
where: { relayer: "0x383f07ecce503801f636ad455106e270748bde05" }
) {
day
mintCount
invalidateCount
scanCount
checkInCount
claimCount
getDebitedFromSilo
}
}
{
ticket(id: "209049") {
id
basePrice
event {
id
currency
shopUrl
startTime
ticketeerName
}
usageEvents(orderBy: orderTime, orderDirection: asc) {
orderTime
txHash
type
}
}
}
Real-Time Usage Data
The historical data is great and will likely be what most people are interested in, but what of those that want to create bots, data feeds, and real-time alerts? You'll want to take a look into the websocket server. Connect this to a Polygon node and return nicely formatted messages back to the connected websocket clients instantly.
We've been careful to design the UsageEvents used within the websocket to be as type-safe as possible with the UsageEvents from the subgraph to allow the data to overlap. We'll aim to keep these aligned to allow builders to hot-swap the real-time data from the websocket and the historical subgraph data.
What We're Building: Integrator Dashboard
But we must be doing something with these tools, right? We're currently pushing to deliver the Integrator Dashboard to allow our integrators to manage their GET balance, see usage statistics and estimated remaining balances - and in the future manage their events.
Building this on top of the open foundation has a number of benefits:
As we improve the data models, this will be available publicly by default.
Contributions from the community also improve our own foundation and reliability.
We commit to decentralisation at the very foundation layer of our products.
The dashboard will allow customers of GET Protocol the ability to market-buy GET and top up their Relayer Address directly from within the interface without having to deal with the custody & compliance headaches of managing cryptocurrency accounts themselves. More will be revealed as we move closer to the release.
Open Data, Open Source
Our commitment to open data would not be complete if the source for this aggregation wasn't also open, so from today you can also now find the subgraph available on our GitHub. We've included a simple barebones React.js starter application to demonstrate queries and to help bootstrap any projects wishing to build on top of the subgraph data.
Likewise you can take a look at the usage-socket repository and start to use this as a foundation for real-time and event-driven data feeds.
Contributions are of course more than welcome. So feel free to submit issues or raise PRs if you see any areas you wish to get involved with. We're keen to continue expanding our coverage so if there's some data you wish to see that isn't already indexed then this can be requested through the GitHub issues.
For discussion and more informal support then join us over on the #technical-discussion channel on Discord.
The GET Protocol Foundation
Since 2016 we have been building ticketing infrastructure powered by the latest technology to upgrade the experience for all in the ticketing chain.
Ticketing companies of all sizes use our infrastructure to get clearer insights, generate greater revenue and maximise the connection through their tickets.
A parting note
Keep up to date with GET Protocol on social media via our Twitter.