By Michael de Hoog We launched the Base testnet in February to bring the next million developers and billion users onchain. Base is an Ethereum L2 powered by the OP Stack that offers a secure, low-cost, developer-friendly way for anyone, anywhere, to build decentralized apps onchain. We’re now working towards bringing Base to mainnet, with safety and security as top priorities. As we progress towards mainnet, we’ve gathered some valuable learnings on scalability and performance that position us for a stronger mainnet, as well as contributing to improving the OP Stack as a whole. Our overall goal is to identify challenges and proactively drive solutions that not only benefit Base, but strengthen the OP Stack as the underlying technology on which many projects will flourish. In this blog post, we explore the challenges faced after releasing the Base Builder Quests campaign, which resulted in a contract deployment surge on Base testnet. We’ll go through the steps we took to address these issues, illustrating the challenges L2s can face around unique data management and L1 synchronization. This type of  surge hadn’t been observed in a mainnet environment before, and gave us a unique opportunity to identify and implement a solution that helped scale the OP Stack. Challenges with L2 data management L2 networks inherit the security of L1 by publishing their data available on L1. This process involves taking the L2 blocks and writing them to L1 in batches. While this works well under normal circumstances, problems can arise when the L2 experiences a surge in data-heavy transactions, such as contract deployments. This is what we experienced during our Base Builder Quests campaign, when the number of new contract creations on L2 skyrocketed. Over 1M wallet addresses deployed a smart contract on Base testnet, causing the batcher to fall behind in processing the pending data. This led to the "safe head" (L2 blocks committed to L1) lagging behind the "unsafe head" (L2 blocks not yet committed to L1). Other OP Stack contributors, such as OP Labs, had previously identified this issue via prior synthetic load tests. The Base Builder Quest had quickly reproduced this bottleneck, and required our team to implement some short term fixes and find a longer term solution. Identifying and addressing the issue The first indication of an issue was a surge in gas fees on Base testnet, as the Base blocks were filling up causing the EIP-1559 mechanism to increase the L2 base fee. In response, we implemented an experimental gas limit increase on the testnet to better understand how our testnet would behave. This helped keep the base fee lower to keep up with the demand; however, this move had another effect: the increase in gas per block resulted in larger L2 blocks, which then caused some slowdown in writing those blocks back to the Goerli L1. To counteract this, we increased the expected compression ratio, decreased the gas limit back to its original size, and reduced the number of confirmations required for writing L2 batches to the L1. Despite these adjustments, the system struggled to reach equilibrium and write the unsafe blocks to the L1, at one point reaching over 4000 uncommitted blocks. It was only after the quests slowed down in the evening that we could close the gap. Implementing a long-term solution The Builder Quest gave us a better understanding of the block batch writing bottleneck. It was clear that we needed a longer-term solution. To solve for this for the long term, we implemented two changes to the batcher: An improved compression implementation that allows better utilization of L1 transaction calldata (PR) Submission of multiple batcher transactions per L1 block, instead of one at a time (1, 2) Load testing indicates that these changes increased the batcher throughput by up to 5x, essentially limited only by what we can fit into L1 blocks. Long-term impact to users The implemented changes helped improve scalability of Base and the OP Stack, and will also offer several benefits for users at mainnet. First, these changes pave the way for increasing block gas limits, which can enable us to ensure the base fee remains low and the platform remains accessible to users, even as the demand for blockspace increases. Second, these changes will help keep the safe tip in sync with unsafe block production, which is crucial for maintaining the speed of transactions and withdrawals on custodial exchanges that rely on an up-to-date safe block. Many of the folks now working on Base have spent the last decade scaling crypto at Coinbase. We’re excited to bring that expertise and focus to scaling Base and the OP Stack, which we see as the platform that will power the next generation of crypto, enabling us to bring millions of developers and billions of users onchain.

When the market is down - it’s important to focus on artists making web3 a focus in their career. Welcome to the first ever weekly spotlight, where we cover five tracks we’re excited about. Here are our picks for this week. Bloody White - UNFAMILIAR BONES The second song off CURRENCY - a 4-song project entitling collectors of the primary sale a percentage of royalties in each of the tracks. Bloody is the definition of a crypto-native artist, fresh off 796 mints from all the songs off CURRENCY. Collect “UNFAMILIAR BONES” here. LNRZ x Sara Phillips - i don’t feel like dancing anymore The leading collective LNRZ teams up with Sara Phillips - one of the most consistent and active artists in the space. Anyone in LNRZ HQ knows Sara has constantly shown up for the LNRZ community - and they’re returning the favor by collecting the latest spotlight. Collect “i don’t feel like dancing anymore” here. Campfire - MIAMI FREESTYLE (ft. Aly, Tarot, Elle Symone, Early, & TK | prod. AbJo) The Campfire Genesis drop is out today. Recorded during Art Basel in 2022, the Campfire Miami sessions gathered more than 50 artists, producers, songwriters, and engineers at the House of Hits recording studio. “MIAMI FREESTYLE” is an excellent introduction to the Campfire collective. Collect “MIAMI FREESTYLE” by Campfire here. Black Dave - advice Sometimes it’s bigger than the music. Black Dave is a voice that has consistently shown up and offered valid insight into the trials and tribulations of a growing industry. Collecting from Dave is an endorsement to the future of independent artistry. Collect “advice” here. Thank you to our sponsor Sound. Harry was Here - stuck. One of the more lowkey artists on Sound, Harry has a consistent throline - quality music. The producer, singer and songwriter does it all, and he’s back with yet another single in a lane of its own. Collect “stuck.” here. Join The Community Invest in Music is free to subscribe and powered by NFT Now. Join the collector chat with the Invest in Music Pass. Follow Invest in Music on Twitter and collect on our website. Listen and Watch: Spinamp | YouTube Follow: Instagram | TikTok | Lens Disclaimer: The content of this announcement is published in the United States of America and persons who access it agree to do so in accordance with applicable US law. Coop Records Management LLC (“CRM”) is not a wallet provider, exchange, broker, financial institution, money services business, or creditor. The Invest in Music podcast, newsletter or other materials from CRM (collectively, “Content”) is for informational purposes only, and should not be construed as legal, tax, investment, financial or other advice. Nothing in this post or in any Content constitutes a solicitation, recommendation, endorsement, or offer by CRM or any third party service provider to buy or sell any securities or financial instruments or products. All Content is information of a general nature and does not address the circumstances of any particular individual or entity. CRM is not a fiduciary by virtue of any person’s use of or access to Content. You alone assume the sole responsibility of evaluating the merits and risks associated with the use of Content before making any decisions based on such Content. You should not treat any opinion expressed by Cooper Turley or others with respect to the Content as a specific inducement to make a particular NFT purchase or follow a particular strategy, but only as an expression of opinion. Before acting on information based on the Content, you should consider whether it is suitable for your particular circumstances and strongly consider seeking advice from your own legal, tax, investment, financial or other advisors. CRM or its affiliates or clients may, directly or indirectly, have a financial interest in Content discussed.

Let's be honest the most fun thing to do in web3 right now is minting everything we do onchain. This is your sign to make more onchain memories! Your wallet is not just a wallet; it's a core part of your identity on the internet. And with Guild Pins, you can easily show other web3 citizens which community you belong to and support, an onchain memory of your experience. Guild Pins are non-transferable NFTs on Polygon, Arbitrum and Binance Smart Chain (later other chains as well). They are a “proof of join”, showing belonging right from member'’ wallets across applications. Imagine logging in to an app and seeing all the friends you could have based on the Guilds you have in common, kinda like Telegram's shared group or Twitter's shared following features. Your interests and history can greatly affect your potential new connections very wholesomely! WHY The purpose of a Guild Pin is to provide a claimable badge to transparently show your support and belonging to the communities you are in. Representing as an on-chain memory in time of your experience. Serving as a stable point onchain for further community efforts. As a community builder, you know how important it is to build a sense of belonging among your members. That's where Guild Pins come in! WHAT ARE PINS GOOD FOR Guild Pins aren't just a way to show off community spirit. They also serve as a building block for your community strategy. Use them as requirements for roles, or as keys to access your community in any other token-gated platform. And with every Pin being numbered or “ranked”, you can see who has supported you since day 1 and reward them with privileges accordingly. Pins also work as a constant source of onchain marketing and brand awareness since we bring our wallets and with them our Pins everywhere as part of our wallet-based identity, representing the community in other wallets, NFT applications, and marketplaces. Minting of the Pins costs 1 Matic to facilitate our operating costs. To get a Pin you need to join the community of your choice and you'll see the Pin among the rewards. Since pins are non-transferable, they are not a means for financial speculation, but for early support, pride and prestige!!! HOW TO USE PINS IN COMMUNITY STRATEGIES So how do Pins come into the Guild Model of requirements, roles and rewards? I’m glad you asked. Guild Pins that are minted after joining a community can be used as requirements in community strategies to set up conditions for further deepening the relationship between members. To segment the community based on time, involvement and interests. For example: Holding the Pin can grant members a “Pin Holder” role, which grants access to chatgroups and special events as a reward. And to make up a “verified member” role it could be used in combination with other requirements such as: following on socials, being regular at community events and having other roles in the community. There is one more twist: Pins are ranked in the order of members claiming them. Meaning, that every single token is numbered so it's an awesome tool to show a rough time of Joining, how long have holders been members of a community. To segment based on timeliness: You can also set up a range of ranks for Pins as requirements for roles: The holders of the first 500 Pins who were here and claimed the "joined Guild Pin” can have the early role, and enjoy special privileges The first 2000 Pin holders can have the semi-early role, etc etc We want members to be vouching for communities early, and having something to show for it. This was a short intro to Pins, here is a video about the feature: Guild.xyz is automated membership management for the platforms your community already uses. Create portable groups, social structures around on- & off-chain requirements and build unique user journeys across apps! There are more resources and guides here. Join Our Guild to know about new features before anyone else and get the best ideas on maximizing the possibilities in your community! Start building new connections and belonging today!

Today we’re excited to share that the Taiko alpha-3 testnet, Grímsvötn, is live! This is the next step on the road to a decentralized, Ethereum-equivalent ZK-EVM, and this testnet will be critical in testing much of the network design and components. Relative to alpha-2, the most prominent changes are: New protocol economics design and implementation Proposers AND provers are permissionless (alpha-1 had permissionless proposers, alpha-2 had permissionless provers) L3 implementation: inception layers Let’s cut right to it: this testnet focuses on the decentralized part of our decentralized, Ethereum-equivalent ZK-EVM. Or to be more specific, permissionlessness that can tend towards decentralization. The big thing to test here is how proposers and provers interact with each other and with the protocol, driven only by protocol economic incentives. The other big thing to test is deploying Taiko on top of Taiko as an L3, something we submit is maximally simple owing to the reusability of the type-1 design. We refer to this as “inception layers”. To jump right in and get to testing, transacting, deploying, or proposing and proving, see the guide: To learn more about this testnet, please read on. https://taiko.xyz/docs/guides Primary objectives of this testnet: Test the new protocol economics design and implementation, including the new fee/reward model. Test the Bridge using partial Merkle proofs to verify signals/messages (a1 and a2 both used full Merkle proofs). Test the new oracle prover. Now regular proofs can come before oracle proofs. Test proof cooldown (30 minutes suggested). Test new ETH deposit using withdrawalsRoot on L2. Test inception layers. We will deploy a Taiko L3 in a few weeks. Some things stay the same: Open to all developers to deploy smart contracts. As Taiko aims to be a type-1 ZK-EVM (Ethereum-equivalent), you can use all the Ethereum/Solidity tooling you are familiar with, and deploy your Ethereum smart contracts exactly as is. Open to all users who want to use it and play around with some transactions. Open to all interested parties to run an L2 node (requisite for being a proposer or prover) The L1 environment is the Ethereum testnet Sepolia Faucets for requesting sample ERC20 tokens to the Taiko testnet L2. For ETH on L1, you can use existing Sepolia ETH faucets. Bridge to move assets between testnet L2 and L1. Block explorers to view assets and activity on testnet L2 and Sepolia L1. Status page to monitor the network. Rewards for proposers and provers To accomplish the goal of testing the new protocol economics design, alpha-3 will be an incentivized testnet towards proposers and provers. We need to test how permissionless proposers and provers act in a mainnet-simulated environment, where they act rationally according to the fees and rewards of the protocol. (Alpha-2 was incentivized only on the prover side). Simulating a mainnet environment with permissionless economic activity is not so simple on a testnet due to the lack of real value assets. We do our best as follows: Initial TTKO distribution When proposing a block, proposers need to pay the protocol in a protocol token. (They also need to pay Ethereum L1 gas fees: SepoliaETH in our testnet’s case). We call this protocol token TTKO (test TKO) in alpha-3. To seed an initial group of potential proposers with this token, we look back to those who performed useful work for the network on alpha-1 and alpha-2 testnets: The top \~2,000 proposers by number of blocks proposed in alpha-1 will each be given some TTKO. Those addresses can be found here. The 195 provers that proved at least one block in alpha-2 will each be given some TTKO. Those addresses can be found here. We will share on our Discord, Community Forum, or Twitter when the TTKO has been distributed to their respective recipients, along with the calculations that determined the amounts. Please stay tuned. At that point, TTKO holders will be able to become proposers on alpha-3! Note: if you earn TTKO by proving alpha-3 blocks (right now, as the chain progresses), you can use it to propose at any time. Simulating rational network participation In order to incentivize potential proposers to propose blocks in a mainnet-like manner, we stipulate two things: To avoid spam proposing blocks (which would hurt provers who must expend real computing resources to prove the queue of blocks), we openly signal that TTKO balance will be among the inputs rewarding network participants come mainnet time. We do not provide more info as to how, because we have not conceived of it. To avoid hoarding of TTKO and bypassing the point of the simulation, we further signal that rational and useful block building and proposing will be among the inputs rewarding network participants come mainnet time. We do not provide a specific formula, because doing so would render any formula a gameable goal (in a testnet environment without natural value spam protection). These countervailing forces hopefully have the outcome of treating TTKO as something you do not want to expend in spam proposing blocks, and treating proposing as something you want to do rationally—basically, what you believe is optimal. Imagining you are a rollup proposer trying to maximize the real L2 fees you earn is the idea. This is our humble attempt to simulate the testing mechanics the network needs. In order to incentivize potential provers to prove blocks in a mainnet-like manner, we stipulate: The already mentioned condition of TTKO balance being among the inputs rewarding network participants come mainnet time. Recall that provers earn TTKO from the protocol when submitting valid proofs. So the “job to be done” from a prover (i.e., generating proofs) maps to earning TTKO. (As opposed to for proposers, where the “job to be done” means proposing blocks and paying TTKO, and earning SepETH.) But please do not mistake the above for meaning a rational or optimal strategy means indiscriminately proving blocks to earn TTKO. Provers expend real computing resources when generating the ZKPs. It is thus not riskless that they would recover their real costs (especially if they are not efficient). It is also unknown when they would possibly be able to recover those costs. It is a decision a prover should consider carefully. Note in a mainnet environment with a known protocol token value, the decision becomes apparent, taking into consideration their efficiency and the competition’s. Note the difference from alpha-2, where provers were rewarded in USDC, corresponding to the number of blocks proven. Hardware requirements for proving As of now, you can use the same hardware to prove blocks that was used in alpha-2. That was a minimum hardware requirement of: 8 or 16 core CPU; 32 GB memory. If using this hardware, rough benchmarks were: proof generation takes approximately 10 minutes, and if renting a machine with the above specs, would cost approx $0.15 per proof. Note: this is not representative of what a full ZK-EVM proof will eventually cost as not all circuits are included yet. More circuits are being integrated as we go. Adding more circuit coverage may happen on a rolling basis, or represent an upgrade to an ‘alpha-4’ testnet. Either way, when heavier-duty hardware are required, we’ll make sure to communicate it as much in advance as possible. Please note, reward or profit considerations (if any) will heavily depend on a variety of factors, and is in no way guaranteed. This holds for proposers, provers, and all network participants. Certain assumptions used may not reflect reality for the duration of the testnet period, protocol flaws can be found, and mainnet timing is uncertain. We reserve the right to adjust the program, with the ultimate goal of testing unprecedented permissionless proposing and proving in a ZK-Rollup. You should only participate if you are keen to help the network test a technical design. Basically, for science. L3 scaling: inception layers Inception layers refer to using Taiko as an L2 and deploying the exact codebase as an L3 on top. Given Taiko's Ethereum-equivalence, the L3:L2 relationship maps closely to the L2:L1 relationship, offering maximum reusability and simplicity. This is needed because a single rollup can only scale Ethereum so far before state bloat becomes a problem. Multiple rollups (L2/L3/L-) are required for Ethereum at great scale. Inception layers (reusing same type-1 codebase) unlock extremely extensible scalability for Ethereum. Further, Ethereum-equivalence across L2s, L3s, and beyond means inheriting some powerful properties, like built-in arbitrary message passing. This follows from the ability for one type-1 to read Merkle proofs from another. This combats a downside of having multiple chains: fears of fragmentation degrading the UX/DevX. With the different layers (adjacent and atop) easily able to speak to each other using Merkle proofs, a fragmented outcome can be avoided. Please note, we will only deploy an L3 in a few weeks, but anyone is technically able to do so at any time. You can check the docs to learn how. For more information on cross-layer message passing and bridging, please read this section of our docs. For even more information on how we are thinking about making cross-layer communication efficient and robust, please see this research idea. Timelines and expectations We loved learning from our past two testnets, and have wasted no time in getting to the next iteration to learn more. We’ve also loved seeing the community participate as users, node/proposer/prover runners, builders, and more. For alpha-3, if all goes well, we expect it to be a longer lived testnet. Future large upgrades (a4+) may indeed be smart contract upgrades vs deprecation and regenesis. This way, we think community builders, Ethereum ecosystem projects, and other partners can deploy and integrate in a steadier state. However, please be aware that in some cases a regenesis may still be required. Get involved Once more, here is the testnet hub where you can find documentation, guides, and links to all relevant apps and tools for testnet usage: Just like the first two times around, besides deploying, using, proposing, and proving, there are plenty of other ways you can get involved and help Taiko improve. Some of these include: Providing feedback or share any bugs you come across on this form. Create tutorials or other content that can help developers, proposers/provers, and users get started. In fact, it is now easier than ever to contribute, because we put everything about this testnet (and much beyond) out in the open! Follow along on our team project board: and build right alongside us. We are one team! We will have Community Call #3 on Friday, June 9th at 14:00 UTC on our Discord server, in the stage channel. We will provide some general updates, but hope to spend much more time answering questions and talking testnet. Please ask any questions you would like in this Discord channel in advance, or you can also ask them live. The questions can be testnet-related or general. Thank you Thank you to our devoted crew of community contributors from all domains, spanning engineering to education and much more. As you may see from the details in this post, aiming to be permissionless from the beginning means we rely on community participants to a great degree. We could not do this without you. We know the Ethereum ecosystem is full of exciting projects and ideas that you can spend your time and energy on, and we so appreciate you choosing to be part of our effort. We are more motivated than ever to deliver a type-1 ZK-EVM to - and with - the community. Join us 💗 Explore open positions on our job board. Follow us 🥁 To stay updated on the latest from Taiko: Website: https://taiko.xyz Discord: GitHub: Twitter: Contribute Contribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing guide.