AMA Transcript: Road to v1 w/Oliver Gale & Saif Akhtar
Table of Contents:
This is a transcript of Panther’s AMA session with CEO Oliver Gale and Head of Product Saif Akhtar. The AMA was conducted with questions collected from Twitter, Discord, and Telegram.
This article is an edited version of an automatic transcript generated from the live session, so we have included exact times for answers in case you want to visit the video below to listen to a specific section.
Here’s the AMA’s audio in case you want to check it out:
When will it be possible to clone the $ZKP token from GitHub? ZKP token is still a private repository, but it is needed as a dependency.
Saif Akhtar - 2:41
In the docs, it does mention that the rest of the repositories are going to be opened up progressively. So I think they’re due, and they will be. However, I do want to mention that the token contract itself it's a dependency because everything works together with the token contract.
However, from a dev perspective, and from trialing out perspective, you can pretty much deploy any token, and attach that token contract address and the rest of the places and pretty much test that stuff.
So for a dev, it shouldn't be a blocker. But in general, if the questions about opening up all the other repositories, I think they are a work in progress. It's just that it wasn't part of the advanced staking itself. It might have been overlooked, but they will be progressively opened up.
What are the potential risks and drawbacks associated with using zkSnarks technology, and how does the project mitigate or address these risks?
Oliver Gale - 4:22
I think one of the well-known risks of zkSnarks is the trusted ceremony setup phase for the Snark itself, and so how that works when it goes right is if one party in this essentially multi party, trusted setup ceremony, is honest, then you have assurances that the zkSnark has no backdoor. However, if all of the parties are dishonest, then the Snark itself has a backdoor: They can recreate the keys and decrypt the information.
So, generally, what you find with snark-based projects is they will seek a relatively large, trusted ceremony and also include actors who have a reputational stake in the privacy space or, in this case, in the blockchain space.
So, I think Saif can share more information on our trusted ceremony setup. Other drawbacks of zkSnarks versus say, Starks are: Starks are more scalable as transaction types, and they don't have a trusted setup. But the Starks themselves have a much higher gas cost for verification of proofs which makes them good for different use cases and bad for other use cases.
One of the interesting things with the zkSnarks space, and both STARKS and SNARKS are progressing rapidly. There's a lot of research and activity around it. But there are things like Halo which may provide the early validation that zkSnarks can also operate using recursive proofs which removes the need to have a trusted setup.
So, there's a lot of promising technology. Obviously, it's been put into production by multiple players in the web three space for different use cases. I think, for what Panther is building. Our team has chosen the right technology, and zkSnarks are more appropriate than a Stark-driven approach, given where Starks are today.
Carlos - 6:57
Would you would like to add anything to that Saif?
Saif - 7:00
No, I think that was well said. Just one point. I think the question also says: what are we doing to mitigate?
I mean, we're using Groth16, which is kind of the standard SNARK system used today. It's proof size, and verification time are the best from the perspective of what it does.
Although, Oliver mentioned the pre-processing setup, and the ceremony that is done. In other words, what we have been thinking of is the eventual movement to PLONK, which increases a little bit on the proof size. The verification time also increases a little bit as compared to Groth16.
But the advantage is there’s a universal set up, rather than a setup for each circuit. So that's a big advantage of PLONK. However, I wouldn't say this is the exact next step for us, or that this is in the roadmap. For us, the most important part is to deliver with Groth16. And then look at how things evolve and how new STARKs systems evolve. Then the community decides, from a technical front, how things should move for Panther.
When it comes to DAO and community proposals, users could use coins and NFTs to vote. How can Panther protect voters’ privacy in governance proposals?
Saif - 9:26
Private voting is a good use case for the ZK technology in general. And proving membership from a set is one of the applications of ZK, where private voting can be, can be utilized. You basically prove that you are one of the DAO members and you're voting, but you don't disclose which member it is exactly, and how much voting power he had.
So, it's a good concept. From a Panther perspective, this is not on the roadmap. Again, I would say these are the adjacent solutions that are good to have. I really want to focus on delivering what is on the roadmap in the next six to nine months. And then we evaluate, and the community evaluates, what adjacent technologies could be built around it.
Oliver - 10:26
I think -- just to add on the adjacent technology component. You know, our focus is to deliver what we committed to, which is the primary use case that what we think is the primary driver of utility for the protocol. That’s the multi-asset shielded pools and the ecosystem of DeFi integrations and bridges.
That said, yes, the core Panther protocol technology can enable things like private voting. For those who have been in this community From the earlier days, we actually had a sub-protocol called LaunchDAO, which was used to vote on whether or not Panther protocol should be launched with basic staking. We utilized a zero-knowledge private token scheme, which also had implicitly built into that some identity functions as well.
So we do recognize that the building blocks are there. And it's an exciting opportunity to explore in later iterations of the protocol. I think also, just to add a comment – my view on identity standards and trying to tackle the identity space is that you have to create the use cases for the identity first. Identity sort of emerges as a byproduct. It would, in my view, not be an advisable strategy to tackle things like digital identity, and to a lesser extent, voting, head-on when the primary driver should be to create utility, grow the user base of Pather Protocol. From that user base, we can then assess implementing additional products or features.
Carlos - 12:17
Yeah, great answer. Especially when it comes to private voting, people can, in fact, look at LaunchDAO and the way Panther was launched, as an example of some private voting mechanism. Although I reckon, if we implement private voting, it will be with a different style.
Will zSwap be available in v1. And when will v1 be launching?
Saif Akhtar - 13:01
Short answer is yes. The work has been started and is in progress. Whether it will be included in v1 is a good question. I think it depends on a lot of other things that are being done from a core v1 perspective and the compliance tech. However, if you ask me, I would love to have it on v1.
Carlos - 13:28
Yeah, we're also preparing more content related to zSwap. Because, as we have started to show the community, a lot of the UI components of it are ready for production or are in the near-final stage, although they're still pending some minor changes. So we will continue to introduce stuff related to it because it's very important for Panther's mission of private DeFi access.
Which DeFi protocol will be the first integrated into Panther? Or will it just bridge different blockchains?
Carlos -
I would like to just quickly clear the second part of the question there. Panther's vision is to enable private DeFi access, not just enable a cross-chain ecosystem. So yes, we want to integrate with DeFi protocols. As for which ones will be the first to be integrated, I'll let Saif answer that.
Saif - 14:31
Yeah, I mean, it will be. Again, these are the parts where the community will come out and make suggestions. However I will say the testing is being done on Polygon as we speak, with three major top three DeFi protocols: Uniswap, Quickswap, and I believe, Curve. And those three integrations’ work is in progress.
However, I expect that there is some discussion going on. And people come up and say, you know, these discussions or these integrations make more sense. And also the pair. I mean, for me, and for testing the product, the obvious choice is, hey, let's look at the top three by TVL. Let's look at the top 10, or top 20 pairs. That makes more sense from Panther’s perspective. And then put it out there, let the community also contribute to those key decision-making process and go from there.
Carlos - 15:39
Anything that you'd like to add, from your perspective, related to v1 or to zSwap, Oliver?
Oliver Gale - 15:47
I mean, no, not really. The first principle of target liquidity is target where there is demand and serve that. It’s a fairly logical conclusion to come from, or come to, and that's what we are aiming to do to tap into protocols that have TVL.
And so I'm just commenting on the issue of bridging into different chains. Here's the issue. The issue is, there are many L1 and L2 chains who are competing with one another for developers and for locals to deploy on their L1 or L2.
The bottom line is, what is the organic reason to deploy on anyone else's smart contract protocol? The answer is because there is an active user base there, there's liquidity there, there is value locked on these chains. And it makes sense for us to participate in and add to this ecosystem.
So you can sort of look at the top protocols by these types of metrics. And those are the protocols that Panther is most inclined to build bridges and DeFi adapters and shielded pools on to.
Then on the other side, there's, of course, the token incentive mechanism, which usually comes in the form of grants. So, whenever we see ambitious protocols which are willing to subsidize – and it's usually a subsidy and not a full coverage of development costs – subsidize the cost of deployment and other chains, then we are happy to deploy on those chains and support them in their vision and their growth.
One other metric which we don't see but which is important, is really the Ecosystem Development Partnership. Some protocols and their foundations or teams take a more proactive approach to actually fostering partnerships. So when we see, L1 and L2 chains that propose that they will make introductions and help Panther Protocol partner with other players – CeFi or DeFi players – we find that to be a compelling reason as well. But again, obviously, those additional incentives. It's really just a function of “where is the activity?”. That's where Panther protocol should be.
How far are we from launching on different additional chains? If Panther is close to v1, what about Avax, Belux, Aurora, NEAR, or even other blockchains?
Carlos - 18:40
I reckon the question should be thought about in terms of not how far we are, but of the overall rollout strategy for different chains. Saif, could you enlighten us on that?
Saif - 19:26
Yeah, the overall strategy is: work with these partners and align/agree on what is the best time for them and for Panther.
Having said that, the goal is that Panther should be launched on multiple chains at v1 as individual solutions. In the future then, those individual solutions or individual MASPs are integrated through our ZK bridging technology and that's how the interchain starts to work.
So the Flare discussion is ongoing. Again, we have sent a complete, detailed task list to Flare.
Like I said before, I think there's a lot of dependency on other chains. So that's one. The second part about BNB is, I think the BD team just recently submitted a grant application for Binance. If that is approved, then obviously, we will prioritize Binance.
So two things there. In short, one is the prioritization from a grant perspective. And then the second one would be, if there is no grant, then we will prioritize based what makes sense for Panther.
I would like to deploy on one chain, make sure it's battle-tested, make sure everything is where everything works well, and then continue to expand on other chains, rather than dumping everything on multiple chains and having to deal with multiple problems. So there will be technical decisions versus also commercial decisions that come to play in terms of how it will be integrated.
When will we have more liquidity on Polygon and Ethereum?
Carlos - 21:26
I reckon we may have an interesting perspective now that the DAO has also experimented with centralized exchange listings.
Oliver - 21:50
Yeah, well, so the answer is, we are right now amid discussion about a proposal coming to the DAO to add liquidity to Uniswap.
There are also some, you know, Uniswap v2, Uniswap v3, potentially on ETH, as opposed to purely just on Polygon. There are questions of, do you want to build utility directly onto the trading pair? Or is there also benefit in providing access to new users to come into the ecosystem liquidity onto Ethereum. These are valid utility drivers in both cases.
There's also some evaluation of v3 active liquidity managers, by way of protocol-to-protocol partnerships that we're exploring. You know, with the recent uptick in the market, this is a good time to be evaluating these. I'm looking forward to seeing how the MEXC listing resolves itself, and then the next priority will be taxability.
What costs will be on the protocol itself?
Carlos - 23:06
So, for example, how much ZKP it will cost to turn one ETH into one zETH. I know that there has been some progress on the design of fees that is not final, because anything related directly to the protocol will have to go through a DAO proposal, but what can you tell us about the fee mechanism design, Saif?
Saif - 23:45
For that specific question, I will say there is no fee, or there is no fee in the design structure to convert an asset into a zAsset. Nothing other than the gas costs or the transaction, which again, is something that is being considered on how to handle that.
Carlos - 24:10
Okay, yeah, we're speeding up the pace a little bit, because we have 15 minutes left, more like 10 right now, at most. So yeah, let's say –
Saif - 24:20
Just to add there, I would refer all the “fees and rewards” questions – I don't know if we have docs already out there – but as we are finalizing the coding and as the testing is coming into play, there should be a good set of docs available to understand how fees impact, you know, what transaction include fees and things like that.
Oliver - 24:51
Panther’s shielded pools are a DEX type infrastructure. So the idea is you don't really make money on way-in and way-out. That will be the case on v1 because there are no fees inside of the shielded pool. The shielded pool operates like a same-type, same-asset swap mechanism.
So, Panther protocol will be looking into things which are equivalent to the fees charged on DEXes. That's the core service. Charges and fees will be DAO governed but will be determined on the basis of the comparable costs for bridging assets across chains. And then, because its privacy and computation costs are higher, there will be some premium on that. So that's how you figure out how fees work.
What makes ZKP distinct from other ZK technology, such as a zkEVM. How is ZKP different and what is the better ZK solution?
Saif - 26:16
Well, if you're talking about Panther in itself, you know Panther is not zkEVM. And the question is, how is $ZKP different? I'm trying to understand where the reference to ZKP is ZKP proofs in general or if $ZKP means Panther in this question.
Oliver - 26:36
I would say answer it as Panther. I think that's the question.
Saif - 26:42
Yeah, so zkEVMs are dedicated blockchains, where the zero-knowledge proving happens inside the EVM itself. Panther is chain agnostic. It's a smart contract, utilizing the zero-knowledge libraries to create these circuits that prove the zero-knowledge aspect. Basically, we use zSNARKs and Grant 16, in that respect, to be precise. So this is something that can be deployed on any EVM chains at this moment, hence the difference. What was the other question, Carlos?
Carlos - 27:27
A follow-up from me, if you don't mind. Am I right to assume that a zkEVM does not necessarily imply privacy, just scalability?
Saif - 27:38
No, there is privacy there. It's not just scalability. I mean, when you're looking at scalability, those are more the roll-ups, the zk-rollups. Those are more specific to solutions to scale. But the zkEVM itself is more sort of a privacy solution at the EVM level.
Oliver - 28:07
I just want to say something on that. If you're building a zkEVM, you're competing in the L1 and L2 space. So your goal is to beat the other L1s and L2s with a superior proposition. They almost suffer from the same problem at the core, which is that they need developers, they need network effects. They need TVL and they need users. The competition for zkEVM is higher. So there are trade-offs between transaction latency, fees and security – the typical blockchain trilemma problem. That's the space that any smart contract protocol is operating within.
Panther is not operating within that space. We're operating within the dApplication space. Often every fund, every asset manager, every broker, every exchange, every user, and every computation may have some requirements for privacy at some point or the other. And if we deploy this protocol onto these virtual machines, we can enable the other ecosystem applications to function. If we were to bet on a zkEVM, that would be all of our eggs in one basket. By building Panther we've said we’re multi-asset. We're not interested in who wins 10 years from now. We're just interested in Panther being on that protocol. Higher expected outcome.
What is the go-to market strategy for the project? And how does it plan to gain traction and adoption in the DeFi ecosystem?
Oliver Gale - 29:52
For the community, members have been tracking the conversations happening in Telegram. As many in our community would know, we've been reevaluating the architecture in light of the Tornado Cash sanctions and the likely further restrictions of who've been facilitating things like laundering of North Korean funds, and stuff like that – criminal proceeds.
So we've taken all of that into account and extensively assessed what it looks like and the summary of Panther is: Panther is going to launch a zone that is currently codenamed T1000.
The first thing is, the Panther multi-asset shielded pool is being subdivided into zones, and each zone will be run by a guardian. The Guardian is your Creator of the zone, and they take responsibility for the actions and transactions that happen within their zone. It is a separate environment that shares the anonymity set of the entire multi-asset shielded pool.
And so, in that sense, new entrants don't have to start bootstrapping from zero, as far as privacy is concerned. At the same time, these actors can actually run the institutional dark pools, which is an example of how well-used things like dark pools are. Now, these are compliant, alternative trading systems in the TadFi world. So in the DeFi equivalent, Panther is enabling this type of deployment along with any permutation, for example, payment networks, brokerage services, etc.
So Panther is looking at enabling these bespoke zones to service different niches within multiple markets across multiple chains, and to bridge transactions between zones and between chains. That’s the end game. Stepping back from that, the goal of the market is to deploy a limited retail zone, if you will. This zone–we’re codenaming T1000, which is indicative of the fact that users will do basic sanction screening, identity checks, and so forth and will be able to transact within that zone, under $1,000 per day. They can do that as long as the zone is operating, which we expect will be in perpetuity.
In parallel to that, we're having discussions with some of these regulated FinTech broker crypto players, to get them to run their own zones and to begin offering private or confidential DeFi services to their user bases and their networks. We're seeing a lot of interest in that. So it is this approach where we're not – if the audience is familiar with Aztec, Aztec has implemented some sanction screening. We've taken a more thorough look at what this looks like in terms of data controller relationships, transaction amounts, due diligence, and so forth, and have come to a place where we can launch this zone, and have it be a permission zone, but with some checkpoints built around it. Essentially, it will be the DAO's responsibility to approve that proposal when it's made. So that's the go-to market and in parallel, we're also signing up zones.
Now, there is a day some time at the end of the roadmap when Panther is “sufficiently decentralized”. At that time, we will evaluate the essential handover of the entire protocol to the community and other parties. In that world, it is possible that zones of other designations – they may be DAO-driven zones, as opposed to regulated financial service provider-driven zones, or government-driven zones – those types of things become possible. That's sort of the progression from public beta, to the full main net to the end of the roadmap.
How will Panther make sure to stay compliant for retail users?
Oliver - 35:04
Panther does not need to be compliant. Panther is a protocol, and Panther Ventures is a development team. So the idea of the protocol being compliant is not the correct way to assess it. If we were building with the idea of the protocol being compliant, the likely outcome will be – and this is unfortunate for many DeFi protocols and many builders out there — is that they're going to find their projects come to a swift conclusion as they are attempting to do something and doing it ineffectively.
So if you are compliant, you're compliant, and if you're non-compliant your non-compliant. And then, if you're compliant in Country A, are you compliant in Country B through Z? And if you're not, then you're non-compliant somewhere. So there are a whole set of very difficult, if not impossible, challenges to solve when a protocol tries to take on the job of compliance itself, in any sort of long-term structure.
When Tornado Cash was sanctioned, that was what we expected in 2020. And that was why we built compliance into the vision; because we thought it was a short-term game plan to go for privacy with a dowel-type structure if you're not building your own L1. And extrapolating again from where we are with some more evidence, my expectation is many of the current DeFi privacy players are going to find themselves out of the market, or having to dramatically adjust their infrastructure to figure out how compliance works. The simple answer to it is: compliance is the responsibility of who uses the protocol – and the protocol design should facilitate operators to take that responsibility into their own hands. And at no time should the protocol custody the data, custody the keys, or control what is happening. At the same time, the protocol should enable those operators, if you will – “guardians” in our case – to respond to their own idiosyncratic legal-jurisdictional requirements. The protocol should be resistant to shutdown or blanket sanctioning, which is what happened with Tornado Cash as an early iteration of an on-chain privacy protocol for Ethereum – one that didn't contemplate the “what if?” questions from the perspective of compliance.
There's always this trade off. The question is: can you sufficiently decentralize?
“Sufficient” is not clear in the market. There is no lawyer on Earth who will tell you what “sufficient” actually means. They may tell you what they think it means, and what one thinks it means might not be what it actually means. That is going to be clarified over the coming months to years. Panther's position is that if you want to be the player that services both retail and enterprise – ultimately if you want to serve all vectors in the market – then you have to be around for that conversation.
So the retail MASP is sort of a risk-managed instance of a zone operating within the shielded pool. It can be thought of as a public eta. It's a step past the test-net because it's actually production privacy. But it's not fully untethered and available in “do-whatever-you-like” mode. That will be something that will be determined by, again, the guardians that utilize the protocol. They're free to do what they like with the protocol and deal with the repercussions of that, whatever those may or may not be.
What happened to the 100k $ZKP Zafari rewards?
Saif - 39:25
Yeah. So it's not about what happened. It's about when the rewards are going to be processed, and how. The fact that this whole Zafari and the testnet process is evolving. At least from my perspective, what we're trying to look at is: how can these rewards be issued in a decentralized fashion, and how can you actually create these external triggered PRPs on Mainnet?
So as you understand, the team itself does not custody the ZKP or the reward pool. If you have looked at the structure of how vesting happens and how rewards are logged in the pool, I did not want it to go forward and create a proposal to extract 1000k and do manual distribution and things of that nature. So, again, there is a bit of a novel mechanism where, when you perform or contribute to the testing in the test net, how can those contributions be validated and turned into a reward on the Mainnet that itself can happen?
So that one idea was created. There's work going on. The design changes have been done on the PRP creation on the Mainnet itself. I'm waiting for the protocol to be launched, and for all these external triggers be applied on v1. I understand that means there's a bit of waiting that has to be done. But again, these will be clubbed with the additional testing or basically the testing for v1 that is shortly coming. So there will be a lot of testing when the v1 code is deployed. And I think we can basically combine all of those efforts and contributions from the community and the rest of the team that test, and start this PRP generation on Mainnet when things launch.
I would love to hear feedback on that, and what the community thinks. But this is, I think, a novel and a good mechanism to reward users for their efforts and contribution on testing the product itself.
Will v1 rollout with all components at once, and which ones? Or will it be a gradual release?
Saif Akhtar
There is this updated, long pending roadmap that should be published this week. As far as “will it contain all of the features?”, I guess the question would be what are the features that you're talking about?
But, I will say high-level that v1 will contain the DeFi integrations, the ZSwap and basically interactions inside the MASP as its core feature. So those three are going to be included in the v1. I think eventually the rest of the features will be added as we move forward.
I think when we are in the test net, and when we all start to test the product, we would know exactly the maturity levels of different features, and this discussion of what feature to include will be more relevant then. But, from a planning perspective, what I said is in the plans.
My goal is to give more use-cases that all of us can use rather than just, you know, get-in and get-out. That's not the end game for the protocol itself. So more use-cases the user can interact with and deploy strategies from within the Panther is what would make Panther unique in terms of what you can do within that ecosystem.
How is the zSwap feature shaping up? Are there any new developments related to it?
Saif - 47:32
It's not what new development it is, it is the development for zSwap itself. So trades within the shielded pools are the features that are being worked on. Which kind of, in the background, is an atomic swap within the shielded pool.
It's like I said, this is supposed to be part of the v1 release. So there is development going on. The sub-team that is working on the DeFi integration, is at the final stages of the first prototype for the DeFi integration. Once they've done that then they will pick up working on the zSwap features. The same team basically will work on the zSwap as well.
About Panther
Panther is a decentralized protocol that enables interoperable privacy in DeFi using zero-knowledge proofs.
Users can mint fully-collateralized, composable tokens called zAssets, which can be used to execute private, trusted DeFi transactions across multiple blockchains.
Panther helps investors protect their personal financial data and trading strategies, and provides financial institutions with a clear path to compliantly participate in DeFi.
Website · One-pager · Lite Paper · Twitter · Telegram · Discord
