Messari hosted a public AMA with Metronome's ($MET) Principal Engineer, Manoj Patidar in the Messari community group. This is a transcript of the conversation.
Messari: Patidar, thanks so much for joining us this afternoon to field some questions about Metronome. We have a lot of great questions in the queue, and I’m excited to chat. Thanks for being here.
Manoj Patidar: Thanks. Super excited for the discussion.
Messari: Before we jump into specific questions, can you give us a bit of background on yourself, Metronome, and a quick “ELI5” explanation of Metronome?
Patidar: I am lead blockchain engineer. I have vast experience in blockchain technology including chains like Eth, qtum, EOS, bitcoin etc. I have been working on Metornome from phase1 and doing design on phase2 and 3 too. Metronome is based on the core principles of self-governance, reliability, and portability. It needs all of these things to be Metronome.
Self-governance: Contracts that are immutable once deployed, where users elect to stay on chains.
Reliable: with a highly predictable supply without mining, allowing owners to plan ahead when considering supply.
Portable: Allow users to move their MET from chain to chain based on their needs.
Messari: Awesome, thanks! I also want to briefly mention there's an in-depth profile on Metronome here. I want to jump into a few initial high-level questions, starting with initial deployment and audits.
First: “Why did you choose Ethereum as the first chain to deploy Metronome on? Why Ethereum Classic the second?
And secondly: “How many times were Metronome’s smart contracts audited and who conducted the audits?”
Patidar: We choose EVM based chain to start with so that metronome's unique portability can be tested quickly. Because we have some good number chains which support smart contract and evm. Smart contract devleoped for one evm based chain can be resued in other too. The cross chain functionality has been tested with ETH-ETC. Qtum is coming soon. We have plan to launch on non-evm chain too.
Metornome's contract were audited multiple times internally and externally by three auditors . Details about who audited are available here also.
Messari: We have a bunch of validator questions, but first a quick question about chain re-orgs: “What happens to MET on a chain that is a reorg victim?”
Patidar: During chain-reorg , MET work exactly same as any underlying chain's native currency or ERC20 . Transaction which happen during chain reorg and fall in shorter chain may become invalid. These kind transactions may or may not exist any more in the newly accepted version of truth i.e longest chain.
Also regarding chain-reorg in context with chain hop - validator network takes reorgs seriously and that's why the port time can be so long to mitigate against this. Also, important to note that this could be a reason someone chooses to move their MET away from a chain, if they feel it's insecure
Messari: ...now to validator questions. First: “How do I become a validator?” And pretty much the same question again: “What are the requirements for an average people to be a validator? Is there a timeline for average people to be a validator?”
Patidar: Team is currently considering the best process for potential Validator to submit their interest and include community feedback. Once this process and timeline are in place we will inform the community.
Messari: “From a technical standpoint, how difficult was it to build and audit the validator code?”
Also we have two questions about the size and phases of the validator network.
First: “If you expand the validator network, how big will you let it get?”
And second: “How does Phase 2 and Phase 3 of validators work?”
Patidar: It is difficult to rate the difficulty on scale because this can be subjective for technical and non technical person. Technically it is was difficult but we have made it. We have got very experienced people working under guidance of chief design Jeff Garzik. Validator code is working seamless since launch . We are proud of quality of work delivered.
While the validator network may grow initially, our focus is on phase 2 and 3. In Phase3, we have vision to completely phase out the off chain validators network and metronome portability feature work like blockchain on blockchain. Each set of metronome contract will be considered as one metronome lilypad on a chain which may have additional responsibility of validating burn hash of other chains once it is submitted by user doing chain hop. Each chain hop transaction will carry additional information with it to help validating metronome constant global supply, previous burn hash and chain of burn hashes at given point of time.
Messari: We have a couple questions about dapps and DeFi tools on Metronome, starting with this one: “What DeFi tools are we going to be able to use with Metronome?” And the second one: “Are you planning to partner with dApps to integrate Metronome? Are you currently working on that?”
Patidar: As Jeff teased in a recent AMA, DeFi is one of best use cases of Metronome. Just as hint, more exciting things to come in MET is a financial layer on top of metronome. We will update the community as there are developments with this. But Metronome’s structure is particularly well suited for De-Fi, Jeff has even gone as far to say it was De-Fi before “De-Fi” was a thing.
We are exploring these possibilities. As Jeff has mentioned before, the team can't disclose any of the conversations until they have closed.
Messari: We have a whole bunch of chainhop questions I want to get through.
First: “What is the difference between a chainhop and an atomic swap?”
Patidar: The team has written very good article about chain hop and atomic swap. TLDR; - from the article : Atomic swaps are necessary when both parties wish to exchange one cryptocurrency for another at a given price, peer-to-peer. These parties may be concerned about their counterpart holding up their end of a deal. A chainhop is the movement of one asset/coin across two or more blockchains. More details are here. More details here.
Messari: Next: “Why is the confirmation time for chainhops so long, and will there ever be lower confirmation times?”
Patidar: As of now we have chosen long confirmation time because of low network hash rate of ETC and to avoid effect of chain reorg and 51% attack issue. We may choose to lower it for other pair of chain for example ETH-qtum.
Messari: Two more chainhop questions: “What upcoming chainhop that the team has already identified excites you the most?” ...and... “In an interview with Pomp, Matthew Roszak mentioned a potential hop to Binance chain? How is this possible without EVM support there?”
Patidar: We currently working on Qtum and RSK. Also doing active research about other chains like EOS. We do consider all opportunity and do technical feasibility about new chains when community is more interested about. We are looking into since this is a popular chain and want to find ways of allowing users to choose potentially non-evm chain in future.
Messari: We have a couple questions about future chain integrations and interoperability, which I’ll loosely summarize by asking: can you share any plans for near-term future integrations? And one privacy-related question about MimbleWimble: “What about Mimble Wimble? Can metronome use that at all to help provide privacy to its users?”
Patidar: Currently, we are working on Qtum and RSK chains. Appreciate any feedback from the community on which chains they would like to see MET on. Re MW - if an underlying chain that MET is riding on uses it in some capacity, then the MET on the chain would likely share some of those characteristics.
Messari: Thanks so much for your time, Manoj. I really appreciate your answers, and I know we’re running up on our one-hour time limit. Anything else before we conclude?
Patidar: Thanks for inviting for AMA. Very happy answering questions from the community.