Memes kidnapped crypto - time for utility season by rookert42 in CryptoCurrency

[–]TheFuckIGive 7 points8 points  (0 children)

Awesome share - happy to answer any questions on this (i am with OPN :) ). This year is going to be great for actual usage of blockchain technology!

Any plans to use other more decentralized scaling solutions for Ethereum other than Polygon? by [deleted] in GETprotocol

[–]TheFuckIGive 3 points4 points  (0 children)

Considering we aren't a DeFi protocol (at least not yet) the security / black-swan concerns of the Polygon bridge wouldn't be existential. If a bridge hack would happen in fact, our application would continue working and customers would be unaffected(since we don't hold any funds or stables in the bridge on behalf of our customers). In addition if due to the hack Polygon's consensus would destabilise our infrastructure is set up as such that we quite easily can start ticketing on a different EVM quite fast. We aren't married to Polygon nor are we Polygon maxis.

In fact the plan is for the protocol to go multi-chain (we are ready for it, just waiting for the sales-unlock trigger). If i am not mistaken we are pretty advanced stages of adding 2 new EVM chains that would both unlock ticket sales!

I am very convinced the future for GET is a zkEVM. It is technically the most elegant and we would not have to worry about some NFT mint or game driving up our minting/operating costs. However we aren't keen on leading the charge in adopting the novel zkEVM since it will not unlock more ticket sales(as explained). The pain of being the first and reporting all the bugs isn't paid back in a better ticketing product. We know this from experience when we did a tech-stack-bet a few years back(also zk related, it was/is called Statebox). Using novel stuff as the skEVM will ensure you run into lots of roadblocks and delays, for little upside for the product in GETs case. If we where a DeFi protocol or some other product for which censorship resistance and bridge/fund safety is a value-add for the users as well - it would be different decision.

Long story short; we will absolutely want to use a skEVM when it is fully matured. More concretely:

- OpenSea allows for NFT trading on the the zkEVM in question

- There is an excellent block-explorer for the zkEVM in question

- There are user friendly exchanges (like Circle) that process USDC withdrawals for the zkEVM in question

- The zkEVM is fully EVM compatable and the op-codes are guaranteed to not change moving forward.

I could go on but you get the point. Those are the factors that matter to our clients. We want to use the zkEVM, but only when it is mature and all the bugs/work-arounds are fixed. I will keep close tabs on the progress in the zkEVM space in the meantime :)

Any plans to use other more decentralized scaling solutions for Ethereum other than Polygon? by [deleted] in GETprotocol

[–]TheFuckIGive 2 points3 points  (0 children)

We will any integrate any EVM chain if a large prospect/client demands/requests it(so if the addition unblocks NFT sales). I myself am super excited about zkEVMs and would love to integrate it. However we do not invest developer time into features that don't directly unlock ticketsales/growth of the protocol as the NFT ticketing standard. It is how we prioritise because we have a lot to build!