Mantle aims to be the connective tissue between ecosystem partners, projects and participants. It only stands to reason that we begin discussions on ecosystem building with Bybit, which has been heavily exploring next-level web3 initiatives in their development pipeline.

Also on the AMA were Mantle’s Head of Ecosystem Arjun Kalsy and Public Liaison Igneus Terrenus, who led this important conversation on how Mantle and its community can engage in new ways of shaping ecosystems, and be an integral part of the web3 future.

Prior to the AMA, we received more than a combined total of 1,500 questions, and saw the community responding at an unprecedented level. Thank you to all participants who attended the session and contributed questions!

Replay the AMA here on Twitter, or read our summary below.

• Some sentences have been edited for clarity and brevity.

1. What was the idea that motivated you to (put up the initial proposal on a new BitDAO infrastructure) and create Mantle?

B: As you all may already know, Bybit is the biggest contributor to BitDAO in terms of its treasury. BitDAO is actually a very independent team, and after some interactions and discussions, some of the team’s thinkers and I had an initial idea of working on this project. We really believe that the future of web3 is to be ushered in by decentralized autonomous organizations (DAOs) and a lot more infrastructure, and even sub-DAOs as compared to initiatives put forward by the bigger DAO. Over the last year, BitDAO has seen quite a bit of amazing achievements, including setting up the sub-DAO model, where we now have EduDAO, Game7 and zkDAO.

However, as time passed, we realized from the Bybit perspective, and considering that Bybit is also a big supporter of BitDAO’s $BIT token, there must be more that we can do to give $BIT token holders more benefits. And the answer is to provide more use cases.

The sub-DAO model helps us to look at long-term goals and initiatives, but for token holders, we are looking at creating more value for $BIT token and everyone who holds the $BIT token. To actually build more use cases, we decided via discussion that the fundamental thing was to have your very own public chain, either a layer 1 (L1) or layer 2 (L2), so that led me to bringing up this idea on the BitDAO forum. It was very well-received by the community, and now we have Mantle.

1. What is Mantle focusing on now?

A: Blockchains often go through this journey where they start out very centralized — and typically includes the creation of a token and building of an ecosystem — and eventually they become decentralized and morph into a DAO. With BitDAO, the end state has already been achieved, and we’re going from a DAO to a DAO-initiated infrastructure, and I think this is possibly the right way to go about building infrastructure.

On Mantle, and of course, on building the ecosystem itself: Mantle is built like a generalized smart contract layer — you can build anything on it. If I were to talk about how the community could participate and how this impacts the entire ecosystem — if you look at the data ecosystem right now, we’ve got BitDAO, the DAO; Mantle, the chain; Bybit, the exchange. We’ve got Mirana Ventures, the venture capital arm, and several other autonomous entities that BitDAO has invested into, that have large communities of their own. There’s already a huge amount of value in the big existing community.

This is different from other blockchain ecosystems. Mantle does not have to start from complete zero, as we already have a jumping off point. Now, the objective is to use Mantle to take this entire ecosystem in a single direction, and create incredible utility for $BIT token not just as a governance token, but one that will mobilize and focus resources of the DAO as an ecosystem token. It could be used across decentralized finance (DeFi), gaming and diverse projects being built on the same Mantle platform. It would also be used at the infrastructure layer via staking across different layers, for example data availability, the sequencers and more. By using Mantle, there’s incredible utility to be had for $BIT token; it strengthens its value for $BIT token holders in the community.

By building value accrual, we can possibly see one of the biggest communities within the ecosystem that is able to drive impact as well. With the ecosystem, we’ve got several things planned that we’ll be revealing in the weeks to come, but know that we have a massive calendar of builder programs to incentivize all sorts of creation. We’ve also got interesting incentives for users who test out the network and help us to find bugs, and so much more.

We’ve got this huge partner network to tap into, for example BitDAO and Bybit. So from the ecosystem building standpoint, we can look forward to interesting updates, concepts and projects coming.

1. What are the main goals that Bybit is trying to achieve by partnering with Mantle?

B: If you hold $BIT token on Bybit, you can actually upgrade your VIP levels on the platform. We are also implementing the token for use as trading fees, and releasing a Bybit Mastercard this quarter. If you use the card, you get some points that you can eventually swap for $BIT token or even merchandise.

We are fully supportive of BitDAO initiatives. We didn’t use $BIT to raise any funds, but instead actually contributed over $1 billion into the treasury. The initial plan was to bootstrap and really show our commitment to web3 development, which is why you see all these sub-DAO entities such as EduDAO, Game7 and zkDAO.

Mantle is now a network initiated by BitDAO, and it will, of course, see Bybit’s full support. We’ll be involved on either the (centralized) exchange level or the (decentralized) web3 level (or both). And we do have our web3 wallet now on Bybit, so we’ll introduce that to all of BitDAO’s users. Any project that will be deployed on Mantle or choose to support the Mantle network will be given priority in terms of support via token listings on the Bybit Launchpad and Launchpool, and much more. We have a whole package in terms of resources and ecosystem, and this will really bootstrap the development of projects as they continue to evolve into the web3 sphere.

Upon inception, Mantle also has a massive treasury, i.e. an ecosystem fund that will support projects. If you’re a project and choosing your tech or a network layer to launch on, Mantle could be extremely attractive because the support, grants and funds are there. You have a top-three exchange backing projects as a part of ecosystem support.

1. What areas are you shaping the growth of Mantle’s ecosystem in? Could you share some interesting dApp ideas as an example?

A: Ecosystem is a big focus for me. And as we try to grow Mantle, we are aiming to increase the size of the pie. Mantle will be looking at onboarding new developers and users. This is something that not only benefits Mantle and the $BIT community — it makes our community bigger, stronger and more powerful no doubt — but at the same time, it will also help to take the web3 space forward and facilitate continuous innovations within the space.

One interesting focus for us would be on the gaming side, because games have the ability to bring in a large proportion of non-blockchain users, and thereby giving them a first taste of web3 technology. We have the support of Game7, which helps to accelerate the development of blockchain gaming projects — and it has its very own grants program as well the involvement of industry experts. We’re building incredible tooling to help onboard gaming projects and users, all to expand the ecosystem on Mantle.

We’re well set to tackle the problem of getting new users and increasing the size of the web3 pie as a whole. On the DeFi side of things, we’ve seen some interesting innovations and witnessed a lot of development around liquid staking and derivatives — including options. And what I’m seeing in DeFi, most importantly, is the renewed focus on fee generation, which I think is very healthy for the entire ecosystem.

This means that business models will evolve towards actually sustainable DeFi projects. So, we’re looking to create some impact on the gaming side, and I’d encourage you to look into tooling or other kinds of middleware that will help drive users to interact with blockchains. There’s an extreme amount of innovation happening in spite of not-so-optimal market conditions. I’m very bullish on this, and we can bring the best of what’s out there to the community.

1. How will Mantle deliver instant on-chain transactions with faster finality for dApps such as gaming, in particular?

When you have a system where transaction processing finality and data availability are so tightly packed, there is a chance that things might break. This is an inherent problem with monolithic designs. While engineers and builders are building Mantle, internally within the teams — let's say we have to improve the data availability layer — it doesn't affect the rest of the chain if we have to swap out our current fraud proofs with some other new kind of fraud proofs. Essentially, a modular chain architecture creates a testbed that can be upgraded much more easily, and it becomes a lot easier to use, easier to maintain, and then we can continue to effectively push out upgrades iteratively, without having to keep forking the chain and making it difficult for builders.

Now, in terms of how this enables gaming, introducing rollups in general is great for high security. They also offer high performance, but we've seen other existing problems. For example, if you look at some of the ZK or optimistic rollup designs out there, the gas costs are still high. For gaming, where you need to be able to build a large number of interactions within the game so that the user stays engaged, that may not be ideal. Now, because of data availability and proofing systems that are baked into our design, not only is the chain delivering on high performance — we've seen very high TPS at upwards of 600,000 TPS and even beyond as we continue to upgrade the chain — but we are also able to keep costs low by offsetting some of these costs to data availability.

So gaming projects and big studios now have the confidence to build on a chain that delivers very high performance, and the team will continue to improve it. When improvements happen, it will neither affect the rest of the chain nor fork So that's why I feel that Mantle is a compelling tech stack for gamers to deploy games on.

1. How does Mantle compare to other L2s, and what will be its killer advantages?

On the technical side, I’d encourage our builders to look at the technical documentation. We’ve brought a number of innovations to market that other chains have shied away from. For example, we’re looking at an iterative optimistic rollup design that solves the challenge arising from a seven-day challenge period. We’ve also gone through this very innovative technique of Multi-Party Computation (MPC) / Threshold Signature Scheme (TSS) technology, and aim to create a pool of decentralized sequencers where there’s an independent body of nodes, called MPC nodes. Whatever proofs being submitted to the L1 will have been double checked, which helps us to reduce the challenge period from seven days to possibly three, or even one day.

We’ve also integrated data availability with EigenLayer, which is making waves in the Ethereum community. Data availability allows us to improve chain performance, while offsetting some of the costs associated with rollups data. The technology is still in its infancy and evolving, but our researchers and developers want to deliver the best on the market — the most cutting-edge technology to developers and users. Developers can then find new ways to leverage this technology and build interesting solutions.

On the fraud proof side, we’re working with Specular to create more innovative fraud proofs that are more efficient. And we’ve also seen how zero-knowledge (ZK) rollups are being integrated into different systems, and several testnets out there are utilizing ZK rollups and teasing their mainnets. We are looking at the space intently, because our mainnet is planned for either Q2 or Q3 this year.

On the ecosystem side, the ecosystem stack that we offer goes from hackathons to grants programs, to investment funds and listings. This is something on a level on which no other project in the market can operate. The $BIT community will see proposals on forums and have a part in some decision-making of course, but we’ll be able to further accelerate this ecosystem for builders. If you’re a builder and want to figure out a way to accelerate your project from product to marketing, to final distribution and listing, we can offer that. Builders will already have access to a huge community of users, and we want to create incentives for users to try out these protocols. If the builders succeed, Mantle succeeds. So we’re going to do all it takes to help projects and builders succeed.

1. How will the ecosystem facilitate interactions, and how does it differ from other networks?

A: All projects are trying to be multi-chain in some sense, and it’s only natural for projects to want to deploy on multiple chains. We do not expect the future to have only one monolithic or one type of chain — ecosystems will be built on more than one chain. And while there are a lot of blockchain ecosystems out there. Eventually they will coalesce into two or three bigger parties, so bridging is very important. We’ve seen plenty of risks being associated with bridging, so we’re being super careful about how we’re approaching bridging right now.

I’m bullish on ZK technology, which will allow us to create bridges that are more secure. But this is still pending research at the moment. We’ve got a lot of researchers and engineers looking at this, but I’m bullish on the fact that using a ZK approach will help us to solve bridging challenges, and that this will allow us to interact with essentially every other ecosystem. A user could be using an app that is actually working across two or three different chains, but they don’t even realize it because the bridging and user experience will be seamless. This is something we will see developed in 2023. It’s just a matter of patching together a solution, bringing the ecosystem together and further expanding the community.

1. How does Mantle expect to attract web2 users or users who are not familiar with crypto or web3?

B: If you look at the last bull run, only the very core crypto natives can take advantage of DeFi and the market, because it’s so complicated. It's our job to really kind of break the products down and explain it to them — so that all it takes for our users is one click to participate. That's our job at Bybit: to deliver that product for the masses. So we've launched the Bybit Web3 wallet. We anticipate that there's going to be a lot more cool features. We will utilize the Bybit Web3 wallet to help our clients bridge the gap. We’re really focusing on the user experience, and my expectation for Mantle and BitDAO is to create more innovations for which we can be the bridge to get people there. So that's our approach.

A: Whether it's on your desktop website, tablet computer or your mobile phone, you're used to a certain kind of user experience and onboarding process now. Web3 has to be able to offer similar, if not better, UI and UX to see mass adoption and new users. At Mantle, we will be very committed to giving the user better experiences in terms of the product, and UI and UX.

1. How do you foresee the role that BitDAO will play in Mantle in the future?

B: On the Mantle network, $BIT is the native token. The more applications that're launched on Mantle, the more use cases we have for $BIT token. Previously, $BIT token only represented voting rights for BitDAO.

A: Not only will $BIT be the gas token on Mantle, it will also be the staking token on all those differentiated layers; for example decentralized sequencers for proof, data availability, and so on and so forth.

We can build phenomenal utility for the token and create an economy that is sustainable, that creates value for the token holder and become a driving force for one of the biggest DAO communities in the world. With the grant programs and some of the things we've planned, it’ll give us the opportunity to put these tokens in the hands of actual builders and users, which will add greater value to the ecosystem. So that's kind of the approach we want to take, and we’ll take it step by step to ensure that we do right by the community.

Join the Mantle community!

Website: https://mantle.xyz Twitter: https://twitter.com/0xMantle Telegram: https://t.me/mantlenetwork Discord: https://discord.com/invite/0xMantle Linktree: https://mantle.to/links

Find the answers in the replay of our highly-anticipated AMA, where EigenLayer’s Founder @SreeramKannan and Chief Strategy Officer @CJLIU49, as well as Mantle’s Product Lead @jacobc_eth and Product Manager @midroni dived deep into Mantle’s data availability layer, or catch the summarized bites below.

• Some sentences have been edited for clarity and brevity.

1. Tell us more about EigenLayer and what the team is working on.

C: EigenLayer is a restaking protocol. Ethereum, after the merge, works on a full proof-of-stake model, and there is a lot of ETH that is staked across a lot of validators that are securing the network — all the transactions and economic activity on top of it. The essential question is: Could you reuse or rent out the staked asset(s) or validator set to other networks, services, protocols and applications other than just Ethereum?

If you wanted to build certain types of blockchain-based software like oracles, bridges or data availability solutions, you might need high crypto-economic security to launch one of these systems. With EigenLayer, you can rent it from staked assets that are currently being used to secure Ethereum rather than try to bootstrap security from scratch yourself.

Many years of work went into Ethereum and getting people to trust the network. It's been around a long time, and it has accumulated a ton of trust and security.

Typically, a new network that needs a lot of security is likely to launch its own token and validator set to bootstrap that security base from the ground up. But with EigenLayer, you could let ETH stakers opt in to restake their staked ETH to not only secure the Ethereum network, but also secure whatever network, application or service that you are trying to build as well.

1. How are EigenLayer and Mantle going to work together?

J: EigenLayer has a product called EigenDA, which is a decentralized data availability layer that is secured by Ethereum. I was introduced to some of the talks that Sreeram was giving and was honestly deeply inspired. Sreeram and I talked about how EigenLayer could secure other features of Ethereum that were not built into the core protocol, but which could still have the same shared security and decentralization derived from Ethereum. One of the offerings that EigenLayer has been working on, EigenDA, helps us to dramatically reduce the gas fees of a Layer 2 (L2) beyond what an existing L2 is capable of.

Just to give some context into why this is the case, the vast majority of transaction fees incurred on a L2 goes towards paying for data on Layer 1 (L1). L1 was never meant to be used as a data protocol; it's good at a great many things, but data storage is not really what it was intended for. With EigenDA, we're able to break out the data portion of the transaction into a separate data availability protocol, and to allow those restaking incentives to ensure that the data protocol is still secured by Ethereum. Ultimately, our goal is to reduce the L2 transaction fees by about an additional 80% beyond what typical L2 transaction fees are.

1. What’s the relationship between EigenLayer and EigenDA?

S: EigenLayer is a general purpose platform that supplies the decentralized trust from Ethereum network stakers who opt in to any service that is built on top of it. This could be data availability services, MEV management, bridges, event-driven activation or even whole new chains. When we looked at what the most interesting service that can be built on Ethereum is and what is most needed today, we settled on data availability. What EigenDA does is it essentially takes the Ethereum validator set as a security source, and then creates a new kind of protocol, where whenever a user wants to commit data to Ethereum today, they write it into Ethereum. Rollups offload computation and just submit proofs. But for somebody else to verify that the proof was executed correctly, or to continue executing proofs afterwards, they need to have a snapshot of the inputs to that computation that was published to Ethereum. However, if he had a separate layer that is supported by Ethereum’s stakers, this proof of publication or data availability could happen at cheaper costs.

Ethereum itself has seen many breakthroughs that actually contribute to improving data availability. The most important one is called danksharding, which is still quite far down the road, and its intermediate version is called proto-danksharding. Both of these are built out of basic primitives like erasure codes and KZG polynomial commitments, which form the core foundations behind some ZK proofs.

EigenDA takes some of these cryptographic elements and builds a new module on top of EigenLayer for providing very cheap data availability. And when we talk about cheap data availability, instead of trying to evaluate the fees, at EigenLayer, we think that we should start evaluating the cost basis of providing data availability. The reason Ethereum’s data availability is expensive is because the total data bandwidth available on Ethereum is limited.

If we can expand the data bandwidth available on our data availability service, then we could significantly reduce the cost, especially if we could accomplish this without increasing the node requirements, and that's exactly what it does. Just to give a sense of orders of magnitude here, if you use the Ethereum blockchain purely as a data availability layer, you don't do any computation. You just write data to Ethereum, and Ethereum can support approximately 80 kilobytes per second a day. What we're shooting for in our first version is something around 10 megabytes per second. That’s a couple of orders of magnitudes worth of improvement over what Ethereum has today.

As we start getting more and more interesting use cases on EigenLayer like Mantle, and as demand on these services start going up, we want to address the bandwidth issue by increasing it proportionally to increasing demand. We talk a lot about block space in the crypto community, which basically means how much data or computation bandwidth is available. The model that we are building for EigenDA is that the capacity of this data cloud storage expands as demand increases, and the underlying technology and distributed systems are already available. When you’re out of space and want to store more data, the cloud stretches to accommodate demand. We just need better engineering for this to be feasible.

That's the core underlying promise of EigenDA, and the way it accomplishes what I mentioned previously is by not requiring every node in the network to download all units of data. Every node in the network downloads only a very small portion of the data, but together, these nodes have a complete overview of all the data. So that even if a lot of nodes go offline, you can still reconstruct a complete dataset. That's the core principle of EigenDA, and that's why we can reduce the cost of data availability significantly in comparison to Ethereum.

1. How would you compare it to other blockchain data availability services that are out there?

S: What modularizing the blockchain means is that there are going to be separate layers: for example, one that just provides data availability and another layer that covers computation or other functions. Some of the members from the Ethereum community have gone on to build other blockchains, one of them being Celestia, which is a data availability blockchain. Polygon has also built its own version of a data availability blockchain called Polygon Avail. And of course, I also talked about danksharding and proto-danksharding, which pioneered several basic primitives that are needed to build a scalable data availability system. What is the fundamental difference between these systems and EigenDA?

Firstly, EigenDA is supported by EigenLayer, which is then supported by Ethereum’s network. Celestia and Polygon had to create new networks to actually support data availability and validation after, and the reason they have to create a new network is because prior to EigenLayer, whenever you have a new idea for a system that provides a certain service, the only way you can do it is to create a whole new blockchain network. This means that you have a new set of validators, a new token that facilitates and drives validator participation. You have to have some kind of a consensus protocol, which then maintains this new blockchain, and finally data availability, which is then built on top.

The luxury we have building on EigenLayer is that a lot of those things have already been taken care of:

The validator network is not a new network but a subset of the Ethereum network, and Ethereum stakers can just opt in anytime

We’re an Ethereum-centered project, we don’t have to build a new consensus protocol or a new layer

We don’t have a separate ledger, we just write data availability commitments in Ethereum, and Ethereum itself orders the data

All we're building is one particular unit of a layer that is responsible for just data availability. The separate data availability engine only does this one thing, which is to receive units of data that are then aggregated and ordered on top of Ethereum. You have many degrees of freedom in building the system, and you can optimize the system for latency and throughput in ways that you would not be able to when the system also has to do other things, such as ordering the ledger and more. By adopting the separation principle, we can actually get a series of performance benefits, which is difficult to achieve in these other systems.

Another dimension of EigenDA that we've thought about a lot is pricing. Existing blockchain systems are fundamentally pricing only for congestion, which means, on Ethereum for example, if there is not enough transaction demand to fill up the block space, the pricing protocol will start pushing prices down until there is some demand to fill the block space. This is what we call congestion pricing. But in the cloud, there is no congestion — the idea of EigenDA is to price things so that you can actually reserve a certain amount of data bandwidth.

The very premise of it is that data bandwidth should be abundant. But if data bandwidth is abundant, there is no congestion. If there is no congestion, there is no price. And of course, a system doesn't work without price because stakers and validators are putting their capital and operational expertise into it, so they need to get paid.

The way we do it is by having a completely different method of pricing: reservation pricing. So you can reserve on EigenDA a certain amount of bandwidth over a specific period of time, say six months or one year. And during that period, that bandwidth is completely reserved for that particular rollup. It provides price certainty that is simply not available anywhere else, and you can then design the economics around this quite efficiently. What reservation pricing does is that it enables or empowers rollups like Mantle to create more innovative economic systems that empower their users with certainty in the prices over a specific number of TPS.

Moreover, there’s dual staking, where someone has to secure something on EigenLayer, and each staker is basically underwriting validation. The only way we can hold them accountable is if there is a provable on-chain slashing event. If there is another token community that wants to stake and participate in the same type of validation, for example, on EigenDA for providing data availability, there is another dimension where the role of a token is now both a staking and validation token. We're also getting security from Ethereum, so together, you get dual security. One group of stakers certify that the data is available, while another group, i.e. stakers specific to Mantle, also certify that the data is available, and only then will the smart contracts confirm that there is sufficient data availability. This is the design that makes EigenDA customizable.

1. How does Mantle's use of EigenLayer change the security model of a rollup? What are some of the implications if there are any, for the security, of using EigenDA with Mantle?

S: Rollups are basically modular chains that are built on top of EigenDA. So, depending on how many Ethereum stakers opt in or are involved, there is a kind of transfer of security, which is different from Ethereum. I would say this is the most important difference in terms of the fundamental security model.

You can also write to just a special token committee that is only dedicated to the rollup. In typical cases, the rollup only writes data to the data availability committee that is maintained by big stakers. Relative to that, the EigenLayer model is uniformly better in providing security, because we are able to get a portion of Ethereum stakers and validators to opt in. This requires nuanced technical discussions, but in general, I think these are distinct dimensions on which one can think about security being transferred from Ethereum to EigenDA and therefore, for the rollup, how much is being staked and how decentralization is transferred — how many different node operators or stakers are participating in it.

1. Why would stakers want to restake their tokens with EigenLayer?

C: Fundamentally, the most evident one is that if you are an ETH staker and earn yield, you could expect to receive a portion of the fees. In the EigenDA example where rollups have to pay restakers in EigenLayer via EigenDA, stakers can increase their yield. And what's really interesting is that EigenDA is just one service on EigenLayer, but over time, let’s say we have 100 different networks on top of EigenLayer. You get access to these different networks, and can make a choice about what you want to do with your staked ETH; as opposed to existing staking models where one obtains yield in one single way, you'll be able to stack yield in many different ways. So it's really about capital efficiency.

1. Could you tell us a bit more about some of those efficiencies? What specifically do you think might arise?

C: When I think about it from strictly a business angle, and just about the reason a lot of the most influential platforms in web2 on the internet have such big influence, it’s because they either control all of the supply or aggregate all supply and demand into a single platform. A lot of what's interesting about crypto is that you can build systems that perform, but are actually designed as public goods that are owned by many people instead of a single corporation. But there's still a lot of efficiency that you can derive as a platform from aggregating either all the supply or all the demand in the market. If one layer does a good job, it becomes the one place to get it. And if you’re a validator and you want to look for opportunities to stake and validate, you only need to go to one place to get it. This would make it more efficient for validators to discover opportunities or services, or to distribute tasks to validators.

1. You mentioned dual staking. What will happen on the $BIT side for Mantle to enable that to happen?

S: The core idea of dual staking is that there are two different token stakers — with Mantle, you’re looking at $BIT stakers. On EigenLayer, nodes restake ETH, and they're able to participate as a validator for the EigenDA process. In the same way, there'll be a special contract on which people can stake their $BIT, and when they do so, they are participating in the EigenDA protocol, and they communicate their interest to participate in the data availability for Mantle. Then they download and run the EigenDA software off-chain. Then, either the staker runs it or they ask a delegate or an operator to actually run it. What the operator does is they are basically downloading and running this version of EigenDA when they're downloading portions of data and submitting certificates. These certificates are then aggregated by the manual rollup sequencer, which will then aggregate all of these things and put a certificate onto Ethereum contracts. When EigenDA’s contracts verify that both the $BIT token nodes have received their portion of the data and the Ethereum stakers have received their portion of the data, we get an attestation on Ethereum that the activity happened. The rollup can then move ahead with this new state update.

1. Tell us a bit about some of the use cases that are going to be possible on Mantle with lower costs and this increased bandwidth for data availability?

J: We've been specifically trained to target use cases that weren't viable in traditional EVM networks. For example, with gaming, you can bring a lot more on-chain and have a lot lower transaction fees in the paradigm that we're working on together. It's also going to be true with social graphs and more. We have some specific features that leverage the Mantle chain that are going to do some pretty outstanding things with NFTs that are really different from what anybody has done historically, and probably would not be economically viable in the existing paradigm. The gaming and social graph stuff is really just the beginning though. There are all kinds of things that we want to enable and with Mantle; it's a pretty high priority to really look at some of the best EIPs that haven't been adopted yet at the L1 level, and to be able to adopt some of these EIPs earlier, so that we can enable better use cases. When we combine those with EigenDA or other forms of extensibility we want to be a bleeding-edge EVM chain and L2 for Ethereum. That really greatly improves the user experience and the capabilities of what blockchains are capable of doing.

1. Could you share a bit about some of the dApps that you're excited about, and what you think that'll do for builders or users working on Mantle?

J: We actually ported the EIP-3074 to an optimistic rollup framework for anybody that's not aware. EIP-3074 is an EIP that manages transaction and contract capabilities in general. This is even before account abstraction. Existing wallets can get access to meta transactions and have their gas paid without having to migrate to new accounts. There are multiple existing use cases that currently require contract accounts or people to migrate to account extraction. EIP-3074 can enable a lot of those capabilities right away, so we've been interested in implementing it on Mantle, and we've also been interested in adopting EIP-4337, which enables true long-term account abstraction, which is going to take a longer time to migrate existing users to, but it is insanely powerful and a massive user experience accomplishment. I think that we're positioned to really be on the bleeding edge of innovation.

Join the Mantle community!

Website: https://mantle.xyz Twitter: https://twitter.com/0xMantle Telegram: https://t.me/mantlenetwork Discord: https://discord.com/invite/0xMantle Linktree: https://mantle.to/links

Adding Mantle Testnet to MetaMask

Acquiring $BIT from the Testnet Faucet

Bridging your tokens to Mantle

Connecting directly to a Mantle RPC Endpoint

Using the Mantle SDK to fetch L1 gas price

Just remember, if you have any questions or need support at any point in your journey, send a message in the Mantle Developer Telegram or our Discord channel. We’ll be right there with you!

This tutorial assumes you are already familiar with wallets, Goerli ETH, and adding custom tokens and networks. If you are stuck on any step, or looking for a more in-depth guide, check our Complete Onboarding Guide here.

Add Mantle Testnet to MetaMask First, you will need to have MetaMask installed on your browser.

1. Once MetaMask is set up, click on your account icon in the top-right corner.

2. This will open a menu. Click “Settings” near the bottom.

3. From there, click on the "Networks" tab.

4. You will see a button labeled "Add a network".

5. Click on the button “Add a network manually”, which will allow you to enter the following information.

Network Name: Mantle Testnet New RPC URL: https://rpc.testnet.mantle.xyz Chain ID: 5001 Currency Symbol: BIT Block Explorer URL: https://explorer.testnet.mantle.xyz

You can now click "Save" and Mantle Network will now appear in your list of networks in MetaMask.

Now that we have our Mantle Testnet configured with MetaMask, we can move on to acquiring $BIT tokens and also gETH that will be needed for gas in various steps.

Acquiring Test $BIT The Mantle Testnet Faucet allows developers to receive testnet $BIT to experiment with the network and deploy their own dApps.

Using the faucet will require a small amount of Goerli ETH ($gETH) to cover the gas fee for minting $BIT. If you need Goerli ETH, you can use either the Paradigm or Alchemy faucets.

Visit https://faucet.testnet.mantle.xyz, verify your humanity, and enter your Ethereum address. You can mint up to 1,000 $BIT.

If you’re having trouble with the faucet, or need more $BIT, let us know in our developer Telegram group. We can also send $BIT directly into your Mantle testnet account.

You should see $BIT in your wallet shortly! If not, make sure you’ve imported the Goerli testnet $BIT token contract to MetaMask: 0x5a94dc6cc85fda49d8e9a8b85dde8629025c42be

Bridging to Mantle You are now ready to bridge your funds over to Mantle. In case you’re wondering, your very same wallet address is waiting for you on the other side.

Visit https://bridge.testnet.mantle.xyz and connect your wallet to Goerli.

$BIT is the native token on Mantle, so let’s start by bridging some $BIT. Input your desired amount and click deposit.

Confirm the transactions (both on the bridge and in MetaMask).

Congratulations, your tokens are on their way to Mantle Testnet! You can confirm their arrival in two ways:

In MetaMask, add Mantle Testnet using ChainList. You should see your $BIT amount displayed as the native balance.

Click here to see a list of ERC20 tokens supported by the bridge.

If you’ve bridged $gETH you will need to import Mantle’s WETH contract to see it under your asset list: 0xdEAddEaDdeadDEadDEADDEAddEADDEAddead1111

Your tokens may still be on their way, in which case you can enter your address on the Mantle Block Explorer and click “Tokens” to view all tokens in your wallet.

Connecting to the RPC Node Connecting to a node allows dApps to read block data and send transactions to facilitate their business logic. This isn’t limited to initiating token transfers and checking their status, but also other operations where a public record is maintained on-chain for anyone to access and verify. This role is performed by Sequencers on Mantle.

Mantle’s node API supports the JSON-RPC implementation of Ethereum. All the endpoints can be accessed by sending HTTP requests, or establishing a WebSocket connection. More on that here.

For simplicity, let’s look at the rollup_gasPrices endpoint, which is one of the most commonly invoked since checking the current gas price is essential to sending valid transactions. The simplest way to use it would be to send HTTP requests to a node. Here’s a sample request that uses the command line tool Curl to fetch the current gas price on L1 and L2.

Request

Response

Notice how the gas price on L1 is orders of magnitude higher than that on L2! Head over to the tech docs to find more reference on other API endpoints. Our GitHub is also a good place to get started.

Using the SDK The Mantle SDK is an easy way to integrate the features of Mantle to your dApp. It is a TypeScript library of useful methods and tools that make block data handling and chain interactions more convenient. For instance, tasks such as generating Merkle proofs by passing state data, generating Merkle-Patricia trie proofs for wallet accounts or storage slots, etc.

Let’s look at the getL1GasPrice method that fetches the current L1 gas price from a node provider.

1. Once you’ve created and initialized a project directory, you can install the SDK package using the following command.

2. Next, create a test JS script and initialize an ethers and an SDK object. Then call the getL1GasPrice method with the SDK object passing an L2 node provider address as parameter. We’ll call the Mantle Testnet RPC, but the same works for a locally deployed node as well.

3. Finally, run the script using the node .js command to see the result. The gas price is in wei.

Feel free to explore the SDK docs that contain descriptions for all available SDK methods.

Looking for more examples? You can refer to this compilation of tutorials that use the SDK to demonstrate flows such as bridging assets between Ethereum and Mantle, and more.

What’s Next? You’re now one step closer to connecting your dApp to Mantle! If you’re building a dApp (or thinking about it!), fill out this form to let us know what you’re working on and how we can support you. It will also make sure you hear about our future grants and developer success programs. Once you’ve deployed on Mantle, let us know on our Developer Telegram so we can celebrate alongside you!

Until next time 👋

The End

Mantle is a modular layer-2 blockchain built on Ethereum. Our approach to L2 blockchain scaling ensures Ethereum-grade security at impressively low costs. Our testnet is live, allowing developers and users to experiment with an exciting, new tech stack.

This article is intended as a guide for exploring Mantle’s key innovations — to explain how our technology can improve the blockchain experience for users and decentralized applications (dApps). We do assume that the reader has a basic understanding of both Ethereum and optimistic rollups. If you’d like to brush up on core concepts, we recommend reading through our docs or visiting the following links:

• Learn About Ethereum

• An Incomplete Guide to Rollups

• (Almost) Everything You Need to Know About the Optimistic Rollup

Mantle’s technology stack brings unprecedented cost-saving, security, and performance to an Ethereum-based rollup. While we could choose a more traditional framing — such as the blockchain trilemma (scalability, decentralization, and security) — we frame our advancements through this lens because cost, security, and performance are fundamental drivers of blockchain adoption. These axes are essential to onboarding the next billion users and enabling next-generation dApps.

Mantle Technologies

First, we provide a quick overview of Mantle’s core technology improvements.

Modular Design

Though we experience blockchains as a single computing entity, blockchain nodes are actually performing three distinct tasks:

1. Nodes maintain a historical ledger of valid transactions

2. Nodes participate in consensus to agree on the contents of the ledger

3. Nodes update the state of the ledger in response to user or dApp submitted transactions

As each of these tasks grow in complexity, these three functions become entire disciplines in their own right. Today we conceptualize them as: (1) Settlement, (2) Consensus, and (3) Execution. Present-day blockchains, like Solana and Ethereum before The Merge, unify all three “layers” of operation within the same network. This means a node must divide its resources across all tasks at once. For this reason, we call such networks “monolithic blockchains”.

Mantle takes a fundamentally different approach. Rather than having nodes be responsible for several tasks at once, we create a system where every function is performed by an independent network of nodes. This way, each network can specialize in its task, leading to efficiency gains that pass on lower fees to users and better performance for dApps. This is the idea of “modular blockchains”, and can be done without compromising on security.

What is especially unique about Mantle is that it deploys rollup-based scaling with a modular design. This means that Mantle not only benefits from better operational economics through modularity, but also the increased throughput and scale inherent to an optimistic rollup.

Specialized Data Availability

A key challenge to operating an optimistic rollup is maintaining data availability. To uphold fundamental security assumptions, data from the rollup must remain available to give verifiers the opportunity to submit fraud proofs. Data availability is such an essential function that rollups today post their transaction data to Ethereum, incurring expensive gas fees and storage costs.

Here again, Mantle benefits from its modular approach. Rather than posting transaction data to Ethereum, Mantle uses EigenDA, a specialized data availability solution built on top of EigenLayer. EigenDA nodes are specialized to the data availability task and are independently upgradable, introducing lower costs and faster improvement cycles for our network as a whole.

Multi-Party Computation

Another tradeoff for optimistic rollups is the necessity of long wait times for transaction finality. Funds move easily from Ethereum Mainnet to the rollup, but withdrawals require a long challenge period to satisfy trust assumptions. The current standard is a 7-day challenge period, in place on both Optimism and Arbitrum today.

Alternatives include using zero-knowledge proofs to implement a zkProver circuit. This can allow for near-instant finality, but requires complex technology that is still being developed and tested. A more feasible path is to implement architecture and incentive mechanisms that will allow a rollup to lower the challenge period now.

Mantle delivers on exactly this solution. Borrowing from the field of Multi-Party Computation (MPC), Mantle introduces a new node role (MPC node) that affirms the validity of blocks produced by the sequencer. MPC nodes will independently compute state roots from transaction data and provide a signature for valid state transitions. As more nodes sign the block, collective confidence in block validity increases. This creates a viable path for reducing the challenge period to as low as 1-2 days.

Improving the Blockchain Experience

Now with an understanding of Mantle’s design, we can better explain how Mantle users and developers stand to benefit on the axes of cost, security, and performance.

Cost

To explain how Mantle reduces costs for its users, first we must understand where costs originate on an L2.

There are two main sources of cost on a rollup.

1. L2 Gas Fees: Just like Ethereum, every operation on a rollup requires a certain amount of gas (see ETH opcodes). Users and dApps pay an execution fee, which is equivalent to the amount of gas used multiplied by the price of gas (determined by network demand).

2. L1 Data Publication Fee: All transactions on an optimistic rollup are inevitably published to a data availability layer. Most rollups today publish data to Ethereum, which means the L2 transaction fee must account for Ethereum gas costs.

How does Mantle compare? Being a rollup, Mantle’s gas prices are already incredibly low. This means that the primary cost passed on to users comes from data publication.

This is evident in the network activity of live optimistic rollups, as captured by Kofi’s Rollup Economics dashboard. For existing rollups, data publication costs account for, on average, 73-79% of the total transaction fee. When Ethereum experiences high network activity, this can inflate to more than 90% of total fees.

Data publication is the price a rollup must pay for both data availability and settlement on Ethereum. With Mantle’s modular design, we shift the data availability layer off Ethereum and onto EigenDA. Thereby directly addressing the primary source of cost passed on to users.

*Actual cost models that elaborate on the difference between EigenDA and Ethereum data availability will become available prior to Mantle Mainnet.*

Security

Security is the ability for a blockchain to maintain a valid ledger of transactions. This means individual nodes must discard fraudulent transactions and collectively prevent large-scale censorship from taking place on the network.

Rollups have favorable security properties compared to other scaling solutions, as they inherit security from their base chain. This means that once finality is confirmed, Mantle’s ledger of transactions is as secure as Ethereum.

As Mantle currently operates an optimistic rollup, you must also consider the length of the challenge period. This period of time creates friction for users (who must wait for finality prior to withdrawals) and liquidity providers (who must manage multiple days of liquidity to account for withdrawals).

Mantle MPC nodes offer a roadmap for progressively lowering the challenge period over time. Incentivized by their own staking mechanism, MPC nodes will independently assess and validate the sequencer’s state root. As more MPC signatures are added, confidence in the block’s validity increases.

This is a paradigm shift that takes optimistic rollups from being default optimistic, to verifiably optimistic. MPC signatures create cryptographic evidence to support network optimism. In the extreme, MPC nodes can certify validity under strong probabilistic parameters, removing the tension of proof by contradiction (the existing fraud proof model).

Important to our security model is that Mantle will still use verifiers and fraud proofs along with MPC nodes. We believe that these two mechanisms together — MPC validation and fraud verification — will create lower and upper bounds on Mantle’s challenge period.

*Mantle is currently operating MPC nodes on Mantle Testnet. Information about staking incentives and on how to join the permissionless set of MPC nodes will arrive closer to the mainnet launch.*

Performance

Though there are many ways to assess blockchain performance, nearly all definitions center around the measurement of a blockchain’s latency and throughput.

Latency is the time it takes for an individual transaction to be confirmed by the network. This metric is most important to users, who want to receive confirmation of their transaction in the smallest amount of time. Low latency will unlock use cases in social and gaming, where multi-user interactions are fundamental to the dApp experience.

Throughput is the network’s aggregate rate of processing transactions, often quantified by transactions per second (TPS). High TPS is important to developers, who need certain guarantees about the number of transactions a network can handle. This is especially important for DEXes and marketplace dApps, where multiple transactions can occur in the same block.

Mantle is committed to a throughput of 1,000 transactions per second, benchmarked by the transfer function. Latency for a transaction confirmation on L2 will be 3 seconds, whereas latency for L1 finality will be the length of the challenge period. These metrics apply to our aspirations for mainnet launch, and can be further improved as we continue to developer our network architecture.

Conclusion

These are just some of the many ways Mantle is committed to improving the rollup experience for users. If you’re interested in a deeper dive into any of our network architecture, please take a look at our docs. If you’re interested in building on Mantle, either as a developer or an existing team, you can get in touch by filling out our Interest Form. Our team would be more than happy to speak with you and answer questions on our Developer Telegram or Discord.

Sources:

• https://a16zcrypto.com/why-blockchain-performance-is-hard-to-measure

• https://www.paradigm.xyz/2022/07/consensus-throughput

• https://research.paradigm.xyz/rollups

• https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698

• https://dune.com/niftytable/rollup-economics

The End

Deploying a smart contract can seem intimidating, but with the right knowledge and tools you’ll see how easy it is to get started. In this guide, we will cover the basics of deploying contracts on Mantle. We’ll begin by explaining the necessary tools, how to compile and deploy your contracts, and finally how to interact with your deployed contract.

This tutorial will be using the Remix IDE. That means you can follow along from any browser that has MetaMask installed. If you haven’t installed MetaMask, acquired $BIT tokens from our faucet, or added Mantle as a recognized network, please first complete our Complete Onboarding Guide. If you’ve already bridged tokens to Mantle, you’re ready for the tutorial!

Introduction to Remix

When we first enter into Remix, it can seem like there is an overwhelming amount of information on the page. That’s why before we begin, let’s take some time to better understand Remix’s interface.

There are four components to Remix’s layout:

1. Side Panel: An interface that can switch between a file explorer, contract compiler, deployment interface, and a debugger.

2. Icon Panel: Acts as a menu to change the contents of the side panel.

3. Main Panel: Contains the primary view for editing our contracts and debugging.

4. Terminal: An interface to read the results of execution and traces.

Deploying a Contract

Now that we understand the layout, let’s click back into the main file explorer. You’ll see that in our default workspace, Remix will have supplied us with 3 contracts: Storage, Owner, and Ballot.

Let’s start off by clicking on Storage.sol.

Storage.sol is a very simple contract that only has two available actions:

1. Stores a number on-chain via function “store”

2. Reads said stored number via function “retrieve”

As this tutorial is about deployment (and not Solidity), we’ll use this default contract in our workflow. To compile the contract click on the Solidity icon on the left navigation bar, and hit compile.

If there are any errors, they will appear at the bottom. For example:

Now that we’ve compiled our contracts, we can deploy them on Mantle Testnet. Select the deploy icon on the left, choose your environment to be “Injected Provider — MetaMask”, and click “Deploy”. (Important: Make sure you’ve chosen your network on MetaMask to be “Mantle Testnet”.)

You should be greeted with a popup like so:

Click “Confirm” to deploy your contract. And congratulations! You’ve deployed a contract onto Mantle Testnet! 🎉🎉

The “deployed contracts” section should be populated with more information. If you expand the contract, you can interact with the contract directly on Remix.

Interacting with the Smart Contract

Let’s interact with the contract via Remix. Enter a number into the textbox beside “store”, and click on the “store” button. Since this is a state mutating function, we will need to pay some $BIT to perform the transaction.

Once the transaction has gone through, clicking on “retrieve” should return on the number we inserted into the textbox above.

Using the Mantle Block Explorer

We can use the Mantle block explorer to understand more information about our contract and its deployment. Going back to the deployment interface, you copy the address as shown below.

Then, go to Mantle explorer, paste the address in the search bar and click on search.

It may take a few seconds for information to update after contract deployment. You should see here the details of your deployment transaction, as well as any transactions you submitted when interfacing with the contract through Remix.

Inspecting the contract address on the explorer also shows us that we have performed two transactions:

1. To create the contract

2. To change the stored value

If you feel like playing around with the explorer a little more, then you can also try copying your MetaMask wallet address to check the various transactions, deposits, withdrawals and more!

Conclusion

Congrats on deploying your very first contract on Mantle Testnet!

We’ve covered the basic onboarding by setting up the MetaMask and adding Mantle Testnet to it, followed by getting gETH and $BIT token for smart contract deployment. After deploying, we interacted with the contract with mutation function (storing a value).

We even covered explorer basics by confirming that the smart contract was actually deployed on testnet, and inspecting the various transaction calls that we made.

Hoping this walkthrough was a good start to getting onboarded to the Mantle’s current testnet. We encourage everyone to start building cool dApps on Mantle Testnet and reach out to our team with demos and questions!

Soon we will be covering more advanced ways to build, test, deploy, and interact your contracts with such tools as Forge and ethers.js, so stay tuned!

We are excited to share that Caldera has officially opened two public testnets!

Caldera is already live, running multiple production rollups on mainnet for select projects. But we wanted to open up public Caldera chains for the broader Ethereum developer community to test with.

Since we support multiple settlement layers, we’ve deployed one testnet on Goerli Ethereum, and the other on Polygon Mainnet. These testnets have been launched to showcase the power of Caldera chains and provide developers a first-hand experience of building on Caldera. The two testnets are:

1. Testnet #1: Deployed on Goerli

2. Testnet #2: Deployed on Polygon Mainnet, utilizing USDC as the chain’s native gas token

Check them out at https://testnet.caldera.dev.

Discover the Power of Caldera

These public testnets have been designed to be open for all developers and users to explore and interact with. Developers can now deploy smart contracts and connect to them via common tools like Ethers.js and Thirdweb, and users can add the testnets to their wallets, interact with the deployed contracts, and experience what it’s like to use a Caldera chain.

Caldera chains are EVM-compatible, and work with all of the tools that developers and users are familiar with: from wallets like Metamask, to front-end SDKs like Ethers.js and Web3.js, to development environments like Foundry and Hardhat.

Along with the testnets, we have deployed a few applications to enhance the user and developer experience:

1. Faucet: Request funds for use on the network

2. Bridging Interface: Seamlessly bridge assets between networks

3. Block Explorer: Monitor and analyze transactions, blocks, and addresses

4. Calderamon: A demo app enabling you to mint an AI-generated monster NFT.

What’re the testnets for?

These public testnets exist to demonstrate the capabilities of Caldera chains and provide developers a way to quickly and permissionlessly test out their development workflows.

The testnets are meant to exist for demonstration purposes only. Do not move large amounts of funds to the testnets. The testnets may be reset at any time.

This is not an incentivised testnet and participation does not confer a right to any tokens or renumeration of any kind.

Caldera's public testnets are a significant milestone in our journey to make blockspace inexpensive and highly available. We look forward to your valuable feedback as we continue to develop the Caldera ecosystem. Happy building!

Get Involved

We invite you to join our growing community!

• Twitter: https://twitter.com/calderaxyz

• Discord: https://discord.gg/9KDXrWE48t

• Mirror: https://mirror.xyz/calderachains.eth

• Linkedin: https://www.linkedin.com/company/calderaxyz/

Join Us

Caldera is always on the lookout for talented builders who share our passion for enabling blockchain developers. Check out our job postings to explore opportunities to work with us.

Deploy your own chain

If you're interested in deploying your own blockchain using Caldera, we'd love to hear from you. We’re already running multiple rollups in production, live on Ethereum and Polygon mainnet.

Get in touch with our team to discuss how we can help bring your vision to life.