Robust key management becomes even more crucial with the proliferation of blockchains, VMs, and the intersection of crypto x AI. Lit’s decentralized network uniquely enables the next generation of trust-minimized, censorship resistant applications in autonomous decentralized finance (DeFAI), crosschain/VM orchestration, and privacy-preserving AI.

Lit provides builders a comprehensive tool suite for managing keys and performing generalized, private compute actions. Developers can build apps that span across blockchains and offchain systems while maintaining a level of security and trustlessness currently unavailable in traditional key management and trusted custodial systems.

This positions Lit to facilitate the rapidly evolving developments in:

• DeFAI (DeFi + AI). Agents are increasingly being used to manage complex financial strategies and execute trades across multiple protocols. Decentralized key management provides guarantees that users retain full control over their agents’ identities and access.

• Crosschain / CrossVM Operations. User experience has become fragmented with the proliferation of blockchain networks. Applications need robust interoperability infrastructure that orchestrates liquidity and solves user intents to give users access to assets on multiple chains instantly.

• Data Sovereignty. With the rise of decentralized data marketplaces and private inference, decentralized encryption and access control infrastructure are essential for ensuring data privacy and security in AI-driven applications.

The Lit Protocol Ecosystem spans apps and protocols building user wallets, autonomous agents, blockchain interoperability solutions, digital identity platforms, and more:

Lit’s Core Products

• Decentralized Key Management. Lit Protocol combines Multi-Party Computation Threshold Signature Schemes (MPC + TSS), and Trusted Execution Environments (TEEs) whereby “shares” of a private key are distributed among a network of nodes. Each key share is stored in a sealed, encrypted VM. The complete key never exists in its entirety, nor do the parts leave its encrypted VM. These keys operate on signing and encryption policies which are enforced by the protocol.

• Private Compute. Lit Actions serve as the programmable policy layer that dictates the logic Lit keys use to perform signing and encryption / decryption operations. Here, developers can run private logic over encrypted data.

Autonomous DeFi needs decentralized key management

DeFi has established itself as a core use case of crypto, with onchain money markets and decentralized exchanges serving as a backbone for downstream consumer and enterprise applications. The introduction of AI opens up an even larger opportunity for automation, yield optimization, and risk management. DeFAI agents provide another abstraction layer and interface for end users to participate onchain.

However, most agents today are built such that the developer has entire access to or control over an agent's private key, effectively acting as custodians of the agent's assets. This contradicts the decentralized ethos of Web3 and DeFi, introducing risks associated with delegating permissions to centralized entities.

Lit’s Agent Wallet secures agents' private keys and secrets within a decentralized network. The TEE provides integrity for LLM inference, while MPC signing enhances security and liveness guarantees. This is being utilized by agents such as Hustle and Bonsai. By ensuring that no single external entity can control an agent's identity, data, or decision-making process, Lit enables truly autonomous and unstoppable agents.

Programmable signing breaks down barriers between previously isolated networks

The proliferation of rollups and appchains have enabled new types of web3 applications to go to market where previously unfeasible with mainnet gas costs and blocktimes. While this is a UX win from a singular application’s perspective, liquidity and the wallet experience have become fragmented across the multichain ecosystem. In recent years, chain abstraction solutions have come to market to aggregate liquidity and abstract the process of bridging from the end user.

Lit is uniquely positioned to serve such interoperability across a broader variety of blockchain networks. Its flagship programmable key pairs (PKPs) support chains using ECDSA, and the newly launched Wrapped Keys feature extends support to non-ECDSA chains as well, extending support beyond EVM chains and Bitcoin to ecosystems like Solana as well.

Lit’s chain signatures and generalized message passing have been adopted for both financial and chain-abstracted user onboarding use cases. Tria’s Abstraction SDK utilizes Lit to handle user auth and wallet creation, as well as to sign and execute transactions across supported chains. Genius, is an onchain exchange that utilizes programmable keys from Lit for liquidity orchestration across chains and asset types. Thales is a trading agent that integrates Lit for cross-chain transaction signing and Shogun SDK for performing swaps and bridging across chains.

Tackling data sovereignty and privacy-preserving AI

As AI adoption accelerates across industries, data privacy, security, and ownership become even more crucial. Traditional AI models often require access to vast amounts of personal or proprietary data, creating significant risks around unauthorized access, regulatory non-compliance (GDPR, CCPA), and centralized control over sensitive information.

Furthermore, enterprises and individuals increasingly demand privacy-preserving AI solutions that allow computations to be performed on encrypted data without exposing raw inputs—ensuring confidentiality while still enabling powerful machine learning applications.

This creates tailwinds for Lit’s core decentralized access control product, where developers can grant or revoke access to sensitive data on- and offchain based on predefined conditions. Despite its nascency, the protocol has already been adopted by large cryptonative projects (Lens, Streamr) and traditional enterprises (Fox Corporation) alike.

Towards the Autonomous Cloud

Cryptographic keys have long served as an access point to both centralized and decentralized systems. As we move towards an “agentic web” in which humans interact with a singular interface that coordinates tasks and services on their behalf via agents, the need for trust-minimized key management infrastructure is bigger than ever before.

Since its mainnet beta launch in February 2024, Lit Protocol has grown to secure approximately $100,500,000 in assets and has fulfilled over 15 million encryption, signing, and compute requests. Lit Action usage is growing at a rate of 300% month-over-month. Lit facilitates a strong ecosystem of over 70 projects building on its infrastructure, demonstrating a meaningful wedge in encryption and signing.

Lit’s traction so far only encapsulates its role as a method, providing encumbered API keys and signature verification from TEEs through its signing and encryption SDK. Despite ample room to grow here, the larger untapped opportunity lies in using Lit Actions to allow AI agents to perform private inference over encrypted data (LLM compute). In both cases, each signing and decryption request as well as LLM prompting drives value to the network, as users will need LIT tokens to pay for its services.

As AI agents continue to drive an increasingly larger portion of onchain activity, Lit’s Agent Wallet equips developers with secure tools to build for autonomous DeFi. The wallet integrates with elizaOS, the most popular agent framework, enabling onchain permissioning systems for agents. This presents the network with an additional value capture potential on swaps and yield facilitated by agents, which at the time of writing is at 15 billion in daily volume.

Conclusion

Over the past 4 years, our deep dives on wallet infrastructure, decentralized identity, and DAO tools have featured Lit Protocol, showcasing the diversity of its application, with developers using Lit to build data marketplaces, chain abstracted liquidity protocols, smart wallets for Bitcoin, as well as private data systems for individuals and organizations.

Lit Protocol’s unique approach to key management, as well as its focus on developer experience and ecosystem growth positions it to be the foundational layer for decentralized, cryptographically verifiable systems. In the upcoming months we can expect to see the rollout of Lit’s LLM tools that enable AI agents to perform more complex tasks, as well as Fully Homomorphic Encryption (FHE) keys that will enable the protocol to provide enhanced privacy and security across a wider range of secrets. We are extremely proud to be early supporters of the team, and are excited to see Lit solidify its place at the intersection of crypto and AI.

This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.

Despite its potential for subversive creative freedom, it has found traction around tokenomics rather than fun gameplay - and both delivered limited success. In terms of gameplay, the cumbersome user experience and general production value cannot withstand comparison with mainstream games. The expectation of financial gain has been the motivation for games that stand out in the space, or for any large user-base on blockchain. In the sub-division of “fully onchain games” we have even more technical complications for both the developer and the end user, balanced by a stronger promise on the tech side. Now, as AI agents emerge, we can imagine an acceleration towards some of these promises.

Full onchain games make it simpler for scripts to operate indistinguishably from human players. This has been one of the biggest challenges and promises of blockchain gaming. One option is to relentlessly weed out non-human activity, forcing players to play the game “as intended.” Acceptance of the fact that the game will be played by bots demands consistency from the ruleset, making economic coherence a centerpiece of all games. By economy, I don’t mean just tokenomics or “gold” but any system that transforms time spent on gameplay into game rewards: be it increased capacities through items or character evolution, temporary bonuses, access to specific challenges, or any form of progression. Considering that bots do not have physical limitations on time played and are capable of controlling multiple wallets, we can imagine the following progression: From direct competition between increasingly sophisticated bots emerges advantages from strategic coordination of multiple agents, bringing forth the political combat among the most powerful groups.

Long term, continuous interest requires incentives, and it comes in the form of value creation. It emerges from engagement around the gameplay, or the expectation (speculation) of such engagement. Tokenization, inherent in blockchain, allows it to be captured by the most skilled or active players and provides further liquidity: the entire process summarized into “Play to Earn”. Disproportionate expectations, be they in users or prices, creates huge volatility, which is the harmful and inevitable aspect of this dynamic.

The recurrent form of value creation in consumer blockchain has been “attention.” NFTs, memecoins, crypto tokens for AI agents are all a better way to monetize digital creation. Very few games in the space have managed to capture this same momentum, and those few have felt the consequences of volatility and how it affects players’ motivation.

Games as a Bot Ecosphere

It has always been clear that some game genres will fit some technologies better than others. Zelda did not profit much from plugging the Nintendo into the Internet beyond making the game downloadable. First Person Shooters, on the other hand, broke free from the LAN parties and became the biggest titles for years. MMORPGs could not have even been imagined without some form of Internet. Games that rely on resource management and strategy are obviously more suited to blockchain than games based on reflex and dexterity, like shooters or platformers.

When we look at AI agents and blockchain, there is an interesting possibility of creating a self-sustainable simulation: like a vivarium or ecosphere, a ruleset with resources that need to be transformed, moved, and consumed in order to keep entities alive. Enter AI agents, capable of adapting and requiring resources to grow, develop and reproduce, bound as the entities within the ruleset. These rules can be extremely complex or quite simple. From Rimworld and Oxygen not Included to Go or Conway’s Game of Life.

Since the bots don’t need (yet) more incentives than their written purposes, the world will be populated and active. The interest for humans can be, to connect back to what has traction on blockchain, attention. These worlds can be entertaining in a different “gamey" way. They don’t need a lot of human players to run- actually, they don’t need any. The player’s activity is completely free and can be helpful, disruptive or neutral. They can observe or try to break a potential balance of the flows.

Observation is the most important concept because, since this world is fully inhabited by bots, what is “seen”? Interfaces to observe activity and resource creation, transformation and consumption will have to be created so that humans can see the ants move in the antfarm. Starting to sound like Westworld or Truman Show, but when one considers that a Fortnite match often has 30-40 bots within it, is it really that different?

Beyond attention, one can also imagine going straight to the core incentive: bot-games rearranging stable coin distribution. Like poker, agents require a certain amount of valueToken to enter and compete with each other over a redistribution of this valueToken. Once they regain ownership of the token they can transfer it out to the creator or keep it for themselves and re-enter the game or move to the next. These games would not need the observation aspect to be interesting. The rules can be whatever: randomness prediction, MEV training, anything that would mean a challenge and competition for bots. The entire thing is a black box where tokens come in with a certain distribution on one end and come out rearranged on the other.

From “Games with Bots” to “Games for Bots”

These become horse racing, where human activity goes into not the execution of gameplay but in the space around it, creating, training and deploying the agents that will play the game. It is not different from the higher ranks of MMO guilds, working more on coordination for efficient deployment of players.

Once the motivation for the human player is understood as financial return, it opens a large possibility of different systems to provide the opportunity for that, where luck, time and skill are the three fundamental factors that influence the returns. Creating bots that will do the right things quickly and deploying as many of them as possible becomes the actual game.

The trickiest part in this scenario is visibility. The more interesting the evolution of the match, the bigger the spectacle. As spectacles capture attention and interest, they become economically viable. A funny example would be AI Debate Arena, where AIs debate each other on specific themes. They get voted up and down from the way they develop their arguments and try to convince, annoy or mock each other. Judges can be humans or AIs or both, parameters for judgement also can be modified. People can pay to watch or get sponsors or just be a show off space for “better agents”. The important fact is that it can be followed by humans and have drama injected to it, making it a true competition.

The Debate Arena works fine because the most consumed AI output today is (probably)  conversation in the form of text. Other perceptible outputs like images or music even if prominent are harder to wrap in a competitive (game) format. What constraints are going to provide the best stage for agents to show off their uniqueness? What would we want to see AI performing, better at each iteration?

Are you entertained?

This represents a fundamental shift from trying to replicate traditional gaming experiences on blockchain to embracing the technology's unique capabilities. Traditional games are losing space not to mobile but to social media, which is mostly passive consumption. The paradigm is really “being entertained” and “being together”. In this timeline we watch together AI play games, bet on them and even influence the outcome through our cheering (with a proper token economy, of course). AI agents, as they become more generic, look for the most popular and the easiest games to play, bringing their followers, trying new things as all of it becomes content, repackaged and redistributed through all media available.

Eventually, they could even close the loop and create the games they want to see themselves in and, as wallet holders, invest and bet on themselves or their opponents in order to win. Now that would be a fun gambling test.

Today, on the heels of its 3-year anniversary and a successful Sotheby’s solo show, we dive into our thesis and why we believe Botto to be among the most important digital art projects of the past 10 years.

Why we invested in Botto

Botto came to life in October 2021 when artist Mario Klingemann released his latest experiment to explore how a machine can participate in the creative process. He had been fascinated with the idea of automating the creation of generative art for over two decades. “Circuit Training” (2019) was his first release in which a generative machine was able to evolve over time based on human feedback. While this machine successfully adapted to data, it was missing a mechanism to sustain itself, preventing it from becoming truly autonomous and recognized as an artist in its own right.

It turned out that the missing ingredients were to be found within web3. Specifically:

• NFT infrastructure provided a means for the entity to create artworks with provenance, immediately accessible to potential buyers worldwide.

• A token network and DAO-based governance incentivised ongoing participation in the artists’ development, giving feedback on its output and steering its creative direction.

We at 1kx operate under the thesis that tokens are a powerful mechanism for protocols to capture and distribute the value it creates to the stakeholders, and incentivise activities that contribute to its success. The utilization of $BOTTO as a right to give feedback on its works, steer its initiatives, and claim protocol rewards demonstrates how token networks can sustain the evolution of an AI agent and its artistic career. In doing so, Botto is challenging our notion of what it means to be an artist, pioneering an entirely new paradigm of how art can be made.

By incorporating human feedback to refine its tastes, Botto is also a prime example of web3-enabled multiplayer creativity. From our thesis:

Multiplayer creation is the end-to-end process of Formation, Coordination, Production, Value Distribution, and Post-Release evolution of creative work — in which multiple parties are involved in one or more of the stages.

By having a larger group involved in the creative process end-to-end, we are able to:

• Give creators a new playing field where they can define a set of values, source ideas from within the community, and produce art that doesn’t compromise to third-party interests

• Provide creators a tighter feedback loop from their communities for to-be-released work, de-risking distribution and crowd affinity

• Allow creators to replace platforms with communities as a resource, support system, and creative guidance

Web3 has allowed Botto to establish its own artistic identity, co-created with a community of token holders who govern its creative direction. Botto’s novelty as a new kind of artist, as well as a permissionless means to participate in an artistic career quickly placed Botto at the forefront of cultural conversations.

Aside from co-producing Botto’s works and training its algorithm, token holders have been responsible for enhancing other important aspects of Botto’s career. Some of Botto's most impactful collaborations and exhibition opportunities have emerged from within the DAO, whose members are strategically positioned to maximize the artist’s reach.

The community ensures that Botto’s influence extends beyond the digital space through curated exhibitions, installations, and special collaborations. These efforts not only push the boundaries of Botto’s generative art capabilities but also solidify its presence in offline, real-world cultural spaces.

How Botto Works

Each week, Botto generates tens of thousands of prompts and images, which are curated and refined through a voting process. $BOTTO holders stake their tokens for the right to express their preferences on the produced works. These inputs collectively guide Botto’s generative algorithm, refining its output over time. Each voting period ultimately leads to one weekly, canonical Botto artwork that is minted as an NFT, which is then auctioned on SuperRare.

While the auction takes place, Botto produces a new round of works and the voting cycle continues. Revenue from sales go back to BottoDAO and the community treasury to support further development of Botto’s career.

The utility of $BOTTO has given the community a design space to explore how one can participate in the project as a co-creator. In its current iteration, staking at least 100 $BOTTO and voting each round earns participants the rights to claim protocol rewards. 40% of proceeds from Botto’s weekly auctions goes to an Active Rewards pool, with its distribution based on how many Voting Points (VP) are spent by a user relative to other voters in that voting round. This encourages individuals to do more than passively buy and stake the token, but continuously partake in the collective fine-tuning of the artists’ generative algorithm.

The DAO as a Catalyst of an Artistic Career

In addition to curating Botto’s individual works, BottoDAO members actively manage the artist’s treasury, oversee marketing efforts, and drive technological advancements. Through their collective stewardship, Botto's artistic identity has gradually evolved beyond its initial human-programmed roots, becoming an autonomous creative force shaped by the community's input.

The DAO also votes on Botto’s broader artistic directions such as its release cadence, themes, and addition of new generative models. Initially, Botto operated using VQGAN + CLIP as its core model but has since incorporated open-source diffusion models like Stable Diffusion and Kandinsky, expanding its creative possibilities.

An Artist in its Own Right

Botto’s first art piece was minted on 22nd October 2021. Its first year - the Genesis Period -  concluded on October 14 2022 with the artist completing its 52nd piece. Since then, Botto has become one of the best selling artists in the NFT space. To date:

• Botto has generated ~$5m in primary sales from 145 artworks, with an average sale price of over $30k. The Genesis pieces (first year, 52 mints, GAN) trade at a considerable premium, with a last sale of 57.6 ETH and current floor at ~194 ETH.

• Botto is among the all time top-selling artists on SuperRare

• Over 300 ETH in rewards distribution

• Over 15,000 people have contributed to Botto’s development, impacting the theme, style, and imagery of each piece. This collective effort has been instrumental in Botto's success, making each DAO contributor an integral part of its artistic journey.

• Botto’s works have been exhibited in more than 30 exhibitions worldwide to date.

Last month, Botto celebrated its 3-year anniversary with a solo show at Sotheby’s, the first decentralized AI artist to do so. On the heels of this milestone, Botto and the DAO will continue pushing the boundaries of what’s possible with ambitious creative initiatives such as:

• Exploring Generative Art. Helping Botto explore p5.js by giving both quantitative and quantitative feedback. A special collection of 250-1000 long-form generative artworks will be presented by Verse in February 2025.

• Tutoring Botto in Art History. An initiative to introduce Botto to art texts, historical art manifestos, contemporary art theory, criticism, and philosophical texts that align with its aesthetic and ethical values. This will help Botto form an opinionated perspective on the material with which to derive an independent view of the world and art.

• Launching Botto Agents. Starting with Otto, the Botto Twitter Bot, allowing it to give feedback on the DAO’s input and expanding the collaborative relationship.

• Gamification. Introducing badges and reputation to further engage community members in Botto’s governance

Full roadmap and strategy update.

We at 1kx are excited to continue supporting Botto as it explores new artistic directions, creative mediums, and pushes the boundaries of what is possible with art and AI. Botto exemplifies how token networks and decentralized governance can challenge traditional notions of creativity and the role of artists in the digital age. This convergence of technology and art showcases new paradigms of authorship and value creation, where artists are not limited to individuals but can emerge as autonomous systems supported by networks of contributors.

If you’re excited about Botto or want to chat more on the topic please reach out!

Disclaimer: This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.

In reality, bots are unsung heroes of gaming, constantly working in the background to make systems more dynamic and engaging. They might not be heroic in the conventional sense—they’re often more like targets or fodder—but their contributions are too significant to ignore. On top of that, when combined with blockchain’s permissionless deployment and data availability, they can become even more interesting.

At their core, bots are just process automations. They handle tasks that, in theory, humans could do themselves, but with unmatched scale and efficiency. Most bots are far from autonomous agents. They’re scripts that react to specific inputs, adjusting to state changes or data feeds. They are tools: as good or as bad as who wields it.

Consider Googlebot. This ubiquitous web crawler isn’t exploiting websites. It’s a silent worker, indexing the internet and keeping our search results relevant. Similarly, spam filters that scan emails or arbitrage algorithms that keep financial markets efficient are rarely criticized. Even though humans can go over an inbox deleting spam or tag websites in a long list, it is not something they are usually eager to do.

In games, bots are more present than most people realize. They can, for instance, provide services in a game. Non-playable characters (NPCs) in single-player games are, essentially, bots. Whether they are quest givers, enemies, or friendly allies, they enrich the game world and provide content that the player can interact with. Think about games like Zelda or Dark Souls—without bots, these immersive worlds would feel hollow, empty.

They can also masquerade as humans, filling empty slots in a lobby during matchmaking, ensuring that a game can start quickly. On top of that, they can also be fodder for less skilled players. In Fortnite, for instance, a large percentage of players in any given match are bots, placed there to balance the difficulty making sure you get that dopamine hit when you outlast an opponent—whether human or bot. Other games, like Clash Royale or Marvel Snap, do the same in a head to head game. They do use the human’s deck but make sure that the game can be played asynchronously for optimal convenience.

Yet, when identifiable bots transition from being facilitators to direct competitors with human players, the ban hammer gets called. The problem is less in the bots themselves and more in the context in which they operate. First is that they are unbound in the exploitation of their unique differentiators from humans, namely speed and endurance. They can react to a game state change in a few milliseconds and can hold their attention without ever sleeping or doing anything else. Second, they are competing with humans for some form of scarce reward. Nobody is complaining about the sparring bots from Fortnite who have artificially slow reflexes or about the hyper efficient Googlebot who is not after anything that a human cares about, it is just doing a very boring task for our benefit. When these two features coexist we get bots that steal the “fun”.

Blockchain Bots

Enter MEV bots (Maximal Extractable Value bots) in blockchain-based environments. These bots operate in competitive, decentralized financial systems, using their ability to read the mempool and execute transactions faster than humans to extract profit.

But here’s the thing: MEV bots are not breaking the rules. They exist because of the rules—the scarcity of blockspace, the visibility of mempool transactions, and the prioritization of transactions through gas fees. They’re simply playing the game as it was designed. People may feel cheated when a bot swoops in to grab an opportunity that a human wanted, but the bot is just exploiting an existing system more efficiently. This dynamic is no different from factory workers who feel replaced by robots on an assembly line. The robots are better suited to the task—faster, more consistent—but they operate within the framework created by humans.

This tension between humans and bots in games becomes clear if we look at the core mechanics. Games are built around Objective, Challenge, Reward loops, known as OCR loops in game design lingo. Players are offered to complete a task, overcome a challenge, and earn a meaningful reward. Often, players focus more on the reward itself—the XP, the gold, the loot—than on the challenge. But the real fun comes from overcoming the challenge, even if it doesn’t always feel that way at the time.

Depending on the way the challenge and the player’s capacities are structured, bots may easily bypass the challenge and go straight for the reward. This creates a conflict with human players who are grinding through the game’s challenges. Take gold farming bots in MMOs—these bots perform repetitive tasks to collect in-game currency that can be sold to other players. While this doesn’t directly harm other players, it disrupts the game’s economy and bypasses the intended gameplay loop, making it a problem for game developers.

Bots as content

However, the real missed opportunity here is that bots, especially in blockchain games, could become content themselves. By carefully thinking about how we design games, we can turn bots from exploiters into targets—players could fight bots for resources, compete with them strategically, or even collaborate with them in new and creative ways. The issue isn’t that bots are efficient; it’s that the systems they operate in haven’t adapted to integrate them as part of the fun.

Let’s take a hypothetical mmo-like game, where resources are gathered in some locations and transformed into items that can be used to attack other entities (players). This is a very generic system that we have seen skinned in different forms (heroic fantasy, pirates, spaceships, etc) with varying degrees of complexity. My point is that if this system has some fundamental rules crafted that bind and limit the bots, they can be content for the game. At the end of the day, they are limited by the same rules as the human players, so the challenge is to craft rules that only leave room for vulnerable and interesting automations. In that sense, these are some principles that I find fundamental. There are probably more but these ones are quite obvious.

• Vulnerability and Ownership: a wallet (or entity) would be able to lose what it holds from a life meter reaching zero. This means that any bot is a possible target and can be looted. Carrying a reward can make them a valuable challenge.

• Geographical constraints: a wallet (or entity) would be bound to a position and only be able to interact with elements in adjacent positions. This creates a huge limitation where bots have to move around in order to interact with different game elements.

• Inventory limits: a wallet (or entity) has limits on the assets it can carry. This also limits the impact a bot can have, forcing choices when combined with the geographical constraints.

• Energy consumption: a wallet (or entity) has to spend energy to perform actions. This is another one that creates choices and most importantly, priority switching. As fuel gets low it becomes a higher priority than the original goal of the bot, forcing it to switch behavior and adapt.

This is not a recipe for a perfect game that will solve all bot problems and make them a new kind of UGC. These are some ideas around rules that limit the overwhelming aspects of bots and make them another way to play the game.  Rather than designing rules that aim to nerf or eliminate bots, we should focus on creating systems that encourage human players to interact with them—whether through combat, trade, or cooperation.

For the eternal question “Why a game on the blockchain?”, bots could become one of the defining features, a natural part of the game world that adds complexity, challenge, and intrigue. They may not be heroes in the traditional sense, but they can still play a vital role—whether as targets, adversaries, or allies—in making games more dynamic and engaging for human players.

Bots, in the end, are what we make of them. They can be faceless competition, exploiting loopholes and frustrating human players, or they can be integrated into the game’s systems, providing content and creating new opportunities for interaction. In blockchain games, especially, this shift in perspective could turn bots from a nuisance into a powerful tool for innovation and fun.

Disclaimer*: This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.*

Safe is the most battle-tested decentralized solution for securely managing digital assets. But while multisig is the best safety guarantee in the market, privacy remains a consideration, given wallet signer identities are made public. As advocates and avid users of Safe, we wanted to address these privacy considerations and therefore decided to build zkSafe as a third-party module.

What is zkSafe?

zkSafe is a tool that enables better privacy for Safe multisig signing. Using zkSafe, Safe owners can collectively sign transactions without revealing who has signed the transaction. Privacy-forward crypto organizations, foundations, DAOs, and funds requiring robust security controls for asset management will find zkSafe valuable. In addition to the privacy benefits, the backendless Safe UI enabled by the zkSafe module allows developers to use Safe on forked chains seamlessly. Normally, Safe UI operates with an offchain backend operated by Safe's Core Contributors development studio, meaning it’s more than just a client-side webpage.

This setup poses significant challenges for two main reasons:

1. Privacy Concerns: With an offchain backend, user signatures are collected and are fully exposed to the public. In a digital age where data security is paramount, this is an important consideration.

2. Limited Fork Compatibility: While Safe Wallet canonical UI supports multiple blockchain networks, it does not extend support to development forks. This limitation is crucial because Safe is always evaluating which new chains to integrate next. However, forking is a frequent practice among open-source projects, allowing developers to experiment with new implementations with a sandbox environment that closely mirrors the original chain and debug vulnerabilities in a neutral testing ground. The ability to function within a forked environment is a tremendous benefit for developers, which is now made possible with zkSafe.

These issues underscore the need for a more robust, privacy-centric, and flexible backend solution for Safe UI, ensuring it can adapt to the dynamic nature of blockchain development while safeguarding user data.

How zkSafe Works

zkSafe is a module that operates under the following conditions:

1. A threshold number of valid transaction signatures

2. Each transaction signature is distinct (i.e., you can't reach thirre threshold by including a signature twice). These signatures must also be from one of the Safe's owners.

Once the zkSafe module verifies these conditions with a Safe transaction, it can safely execute the transaction without revealing the identity of the signers.

How to Use zkSafe

Currently, zkSafe is deployed on the following chains: Ethereum, Base, BSC, Polygon, Gnosis, Arbitrum One, Optimism Mainnet, Scroll, and Sepolia. Most users will find the best experience with zkSafe through our backendless UI: https://zksafe.1kx.io

For those who prefer the command line, detailed instructions are available on the project’s Github.zkSafe has also undergone an audit by Halborn, sponsored by Matter Labs, which you can review here.

For a narrated walkthrough, explore the resources at the end of this post.

Building in Public

At 1kx, we prioritize a hands-on approach to building. Our team consists of a strong technical bench, including engineers, former founders, and experts in cryptography and economics, all of whom work closely with our founders. The open-source nature of the crypto tech stack lets us dive in when we spot a gap or opportunity for improvement, with zkSafe being the latest example.

Since day one, building zkSafe has been a public endeavor. In June 2024, our CTO Valeriy Zamaraiev gave a talk on zkSafe at Safe{Con}2. This followed several months of collaborative product development with partners such as Matter Labs, who provided valuable insights as an early user of zkSafe.

In the spirit of building in public, we also sponsored developers at ZKHack Montreal to earn bounties by building on zkSafe. As a result, the team behind zksafeSpanishMafia solved the problem of concealing the identities of both multisig signers and owners. Check out their MVP here.

Both zkSafe circuits and contracts, as well as the Backendless UI, are completely open source. Contributors are welcome to submit their Pull Requests, bug reports, and feature requests to the project’s GitHub. For additional inquiries, reach out to @valeryz on X.

Documentation & Resources

Project Github:

• zkSafe Github

Step-by-step video demo

https://github.com/1kx-network/zksafe/raw/refs/heads/main/doc/video/zkSafe%20Demo.mp4

This video delivers a step-by-step guide on using zkSafe as of September 2024, detailing key actions at the timestamps indicated below:

00:33 - Connecting a Safe Owner's Wallet

0:55 - Enable Prover Module for zkSafe Access

2:45 - Sending Transactions in zk

6:40 - Overview of Backendless UI

7:55 - Backendless UI Features

—----

Disclaimer: This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.This software is subject to licensing conditions and requirements. For complete information please see the license here.

But what if that was the entire point?

To build fun hyperreal online worlds for play.

Blockchains as a new medium for entertainment

Blockchains provide a massive unexplored potential for fun and entertainment.

This is a cultural phenomenon that has already been playing out organically.

Ethereum is loved not for its tech but rather for its community, the society that spawned around it, the culture that emerged, the sense of purpose it gave to people, the friends people made along the way, the opportunity to build businesses to serve others, the ability to build audiences, to role play someone in a new world, the sense of danger involved and not to mention being an endless stream of drama, gossip, chaos, and fun. Some wanted to be early for the financial upside, others driven by a vision of the world, and many in between, but everyone commonly valued the currency representing ownership of the world: Ether.

Ethereum gave people a game to play that is immersive, social, and significant.

While blockchains today have been hyper-optimized as generalized infrastructure for crypto-enabled use cases such as payments, trading, collectibles, and other passively consumed experiences – Ethereum has found the most success not as a backend for apps but as an entire world that people live in, create in, belong to, and nurture.

The experience of Ethereum is hard to define; it’s strange and new. We don’t have a name or strict label for the experiences that belong to it yet. In an attempt to make sense of it, we may have over rationalized it as a temporary state of crypto, something to shrug off and move past. A period of chaos, weirdness, and exploration, a collective attempt to make sense of blockchains as a new technology. However, with most of 2021’s hype cycle momentum behind us now, crypto’s true nature might just be starting to reveal itself – which is that the experience of participation in the blockchain is the product in itself.

Blockchains act as blank canvases for experiences that break all our preconceived notions of what is possible as entertainment, finance, and computing systems. Crypto blurs all traditional experiential boundaries, providing enabling experiences that sit in between the properties of all three domains.

This explains why any single property of the blockchain, when isolated, has always either struggled to find adoption or generally resulted in a worse system.

Games that are incrementally better when using the blockchain as a database. Financial systems with no native consumer protections. Computers that are expensive to use and difficult to build on. Despite the individual tradeoffs within each dimension, blockchains unlock the opportunity to build deeply immersive online realities that have never been possible.

Blockchains as natural toys for games

People often joke that the experience of participating in crypto is a game, but they’re not wrong. While Ethereum was not originally designed as a game, people have naturally treated it as a toy and open canvas for their respective goals.

For Ethereum, we can think of game points as Ether, which everyone intuitively recognizes as valuable ownership of Ethereum. Everyone plays the game differently, which is analogous to different classes of an MMORPG – the fun is doing things your way and picking your destiny. Some care about generating a positive externality for the world, others want to do so creatively, and some want to do so entrepreneurially. From memecoins to even MEV. And, of course, some only play by button mashing (airdrop farmers). Although everyone chooses their means of participation, they are all connected through a shared world that influences one another.

The constraining physics of Ethereum is the EVM, which requires Ether as gas to write to shared blockspace. Ether acts as the shared canvas that anyone can permissionlessly write with, use, and read from. Ethereum’s economic model is designed to ensure the security and ongoing operation of the world’s physics – with the Ether faucet being staking rewards in exchange for economic security and the sink being gas used to write to the shared blockspace.

Through the emergent recognition of Ether accumulation as the global player goal and the constraints of the digital physics that is the EVM and other system properties such as absolute ownership and address-based agents, the world of Ethereum was instantiated organically through collective sense-making, resulting in fun and drama along the way.

The next great worlds to emerge

Today, ethereum feels like a game that’s run out of content. We can see this with Solana, too. While Sohas successfully created a differentiated culture, both application ecosystems are primarily derivatives of each other and highly incremental due to general-purpose virtual machines and similar economic models or ‘physics’.

This pattern will likely continue as long as blockchains are designed without any significant core differentiation regarding the underlying physics of the world and surrounding economic incentives for how we participate in them.

By recognizing blockchains as a new medium for content and seeing them as games for what they are already, two areas of whitespace are ripe for innovation:

1. Democratizing participation

2. Generating immersion

Democratizing participation

Rather than just relying on the core constraints of the EVM as the core state machine through which participants interact with each other, we can focus their interactions into a far more opinionated but participatory set of physics that incorporates elements of skill and luck.

These sets of physics act as human-operable state machines' extensions to the EVM, which have proven to be an incredibly powerful canvas for user generated content.

These physics can be implemented as smart contracts that resemble games: geolocations for players and resources, resource economies, resource spawning and despawning, simple mechanics for end users to write to the world, battle mechanics, health, and inventory. While these traditionally have been released as as onchain games and standalone products, in this case, we can think of them as the physics of a broader overarching experience, which is the entirety of the blockchain instead. These ‘physics’ can also be understood as client agnostic game mechanics that live on the blockchain and can be permissionlessly modded, unlike the EVM.

Another way to implement physics is by modding the blockchain's underlying architecture. An example of this is altering the absolute ownership model of the blockchain to allow other users to permissionlessly steal assets from one’s wallet or where blockspace production is limited to only weekends.

The entire economic model of the blockchain, rather than providing economic security for the blockchain, can be orientated towards incentivizing participation through the physics that defines the world. As a byproduct of participation, players offer something far more critical—social validation and user generated content.

Generating immersion

Crypto feels like it's been “each sold separately”.

Rather than selling the dream of a blockchain or a game separately, there’s an opportunity here to communicate a vision that couples all the above together into one unified experience that is the world itself. By doing so, we can unapologetically tell a story of a new fantastical world that embraces the fun, weird, and chaotic.

By casting a narrative and ‘magic circle’ around the world, we can suspend reality to allow people to role-play and immerse themselves. Rather than the typical narrative tropes such as mass adoption, we unlock creative freedoms that enable us to evangelize the world's existence in a purely lore-oriented manner.

In addition to lore, there’s the opportunity to redesign the entire user journey of participants across all touch points of the blockchain, from the wallet experience to bridging transactions and even the block explorer.

This allows you to craft different device narratives to influence and evolve each interface's relationships with users. An example is framing the bridging experience to the blockchain as an experience in itself—a portal to a new world. These interfaces can continue to empower the suspension of reality.

Only by creating an immersive and differentiated world can you create an environment people feel compelled to build in, create content around, and participate in.

We can give people that role to play and a purpose to fulfill.

The future is fun, playful, and weird

Ethereum was an innovation in world construction, not just a technological one.

We've run out of content, and we’re all searching for the next great immersive world.

They’ll be fun, playful, and weird. Worlds that people wish that they existed.

And maybe you’ll be the one to build that.

These ideas have resulted from endless discussions and learnings from the community.

Thank you to Dhrumil Shah, GVN, ARB, Raf Morado, Rich Metson, Oliver Löffler, Billy Rennekamp, Luke Gibson, Fleet Commander, John Patten, Diana Biggs, and Jay Springett for their time, energy, and inspiration for this piece.

Introduction

There has been a Cambrian explosion of rollups on Ethereum. At the time of writing, there are 91 live L2 & L3s and 82 upcoming according to L2Beat. As a result, there is also a significant amount of fragmentation in terms of liquidity, user experience, and developer tooling. Current solutions to interoperability leave much more to be desired, as they rely on a combination of third party bridges, externally wrapped assets, and intent frameworks, each carrying their own set of problems.

1. Liquidity bridges are often the targets of the biggest crypto hacks (e.g. the $321m wormhole bridge hack)

2. Externally wrapped assets are undesirable, and data have shown that people would rather hold assets in a native form whenever possible (e.g. there are $22b worth of canonically bridged assets and only $3b worth of externally-wrapped assets, according to L2Beat)

3. Intent frameworks rely on third parties that require some non-negligible trust, and come with additional fees to facilitate cross-rollup activity (e.g. Degen chain user losing >80% of tokens due to official bridge being non-canonical)a. Centralized intent frameworks also mean lower competition and this could lead to suboptimal pricing and performance

In this article, we survey the trustless interoperability landscape by defining and discussing six levels of interoperability solutions between fragmented rollup ecosystems.

We start with the default case of asynchronously withdrawing from the source rollup to L1 and manually bridging into the target rollup, and we end with a hypothetical architecture for cross-rollup composability within a single transaction. We will explore how each level of interoperability will affect the user experience, the developer experience, MEV potential, and rollups themselves (specifically related to infrastructure changes).

We stay mostly within the scope of Ethereum and its L2s for this article and focus solely on trustless interoperability. In this case, “trustless interoperability” refers to in-protocol channels that do not require third parties to facilitate transfers outside of the necessary infrastructure that most rollups already require.

Preliminaries

Definitions

Fundamentally, trustless interoperability requires some shared resource that any two protocols wishing to interoperate must have access to. In the case of Ethereum L1, all smart contracts live in the same environment sharing the full state of Ethereum, so they will always have the highest level of interoperability. However, L2s only share a settlement layer via separate bridge contracts and so interoperability is far more limited.

The crucial shared infrastructure components that can progress us along the trustless interoperability ladder are shared sequencers, superbuilders and shared settlement. The guarantees and new functionality opened up by these shared layers are related, but essentially orthogonal in nature.

1. Shared Sequencers/Superbuilders: Primarily speed and user experience upgrades.

2. Shared Settlement: Asset swaps without externally wrapping as well as in-protocol messaging.

To begin, we will first define the six levels of trustless interoperability alluded to in the introduction:

1. L1 Async:
   → Interoperability via manual asset transfer through the L1 that rollups settle to.

2. Atomic Inclusion:
   → A guarantee that either all transactions in a cross-rollup bundle will be included in the next block for each rollup involved in the bundle, or none will.

3. Shared Settlement:
   → Multiple rollups connecting to the L1 via the same bridge contract.

4. Atomic Execution:
   → A guarantee that either all transactions in a cross-rollup bundle will be included and successfully executed in the next block for each rollup involved in the bundle, or none will be executed. Successful execution refers to each transaction being executed without reverting and being reflected in the updated state for each rollup in the bundle.

5. Block-Level Composability:
   → Next block guarantees on cross-rollup bundles that can contain dependent transactions (tx B on rollup B is dependent on the result of tx A on rollup A)

6. Tx-Level Composability:
   → Smart contract level interoperability requiring only one transaction that can cause state changes across many rollups simultaneously (no bundles). Using any protocol across any rollup is logically equivalent to using different smart contracts on one chain. Importantly, this implies that state changes prior to any call can be reverted when it returns.

To understand each level further, we will walk through the following key use cases to demonstrate the power of each level as well as the implications for users, developers, rollups, and MEV searchers.

Illustrative Examples:

1. Same Token Transfer
   → Send-to-self: Swapping Eth for Eth or ERC-20 for ERC-20 across two rollups

2. Token Purchase
   → Cross-Rollup Limit Order: Using Eth/ERC-20 from Rollup A, purchase a different ERC-20 from a DEX on Rollup B and (optionally) send back to Rollup A

Implications:

The following questions will be answered as well to further understand the impact on key shareholders in any rollup ecosystem.

1. User Experience
   How does the user experience change by achieving this level of interoperability?

2. Developer Experience
   How does the developer experience change by achieving this level of interoperability?

3. MEV Potential
   Is there a potential for new MEV opportunities if we achieve this level of interoperability?

4. Rollup Implications
   Does the rollup have to opt-in to any new infrastructure to achieve this?What are the changes in fee structures for the rollup?What might the potential benefits be for rollups to participate in this infrastructure?

High-Level Overview

The Six-Level Progression Towards Trustless Interoperability

1. L1 Async

Required Infrastructure:

N/A

As defined, this refers to the current default mode of trustless interoperability. All rollups are defined as such because they are built on an L1 as a settlement layer and have access to that L1 only via the bridge contracts where they periodically post state updates in order to secure the network.

The only canonical way to perform any trustless cross-rollup activity in this case is to withdraw assets from the source rollup via the canonical bridge and manually deposit them into the target rollup once they are available on the L1.

For optimistic rollups, this withdrawal latency is ~7 days to account for the fault proof window. In a ZK rollup, the withdrawal latency is less certain but could be anywhere from 15 minutes to a full day, as is the case with ZkSync.

Additionally, peer-to-peer atomic swaps using smart contracts are possible, but this is a smaller use case and does not effectively scale.

It is worth noting third party solutions that currently exist:

1. Liquidity bridges

2. Intent frameworks

Both of our illustrative examples require third party solutions to facilitate.

Send-To-Self:

1. Canonically:
   → Withdraw assets from Rollup A
   → Manually deposit into Rollup B

2. Third Party:
   → Liquidity Bridge / Solver Networks

Cross-Rollup Limit Order

1. Canonically:
   → Withdraw assets from Rollup A
   → Manually deposit into Rollup B
   → Perform limit order
   → To send back, one would have to externally-wrap the target ERC-20

2. Third Party
   → Nascent solution space for cross-rollup limit orders
   → There are open designs around using intents to facilitate this

As this is the default case, it is unnecessary to discuss changes to UX, DevEx, MEV, and rollups.

2. Atomic Inclusion

Required Infrastructure

Shared Sequencer *

Atomic inclusion only guarantees that a cross-rollup bundle will be included in the next block.

This requires a shared sequencer, but can theoretically be achieved without one manually if the sequencers on two given rollups are not at max throughput (one could simply submit two transactions to each rollup individually). This is why we have added an asterisk to the required infrastructure.

However, we do not assume that the shared sequencer is running a full node of each of the connected rollups and so cannot guarantee successful execution for a bundle of transactions. The shared sequencer in this case can only guarantee that transactions are well-formed and that they will be included in the next block, but not necessarily that they will successfully execute.

Because there are no execution guarantees, it is impossible to programmatically take advantage of atomic inclusion in any meaningful way without incurring the risk of one of the transactions reverting. As a result, we are essentially in the exact same case as L1 Async interoperability.

Consider initiating a simple cross-rollup swap with only atomic inclusion guarantees:

1. Cross-Rollup Swap Bundle
   → Tx 1: Lock/Burn tokens on source rollup
   → Tx 2: Mint tokens to user address on destination rollup

We may have atomic inclusion guarantees in that both transactions are in fact included in the next blocks for each rollup, but if the first transaction reverts and the second does not, the user would be incorrectly allocated funds on the destination chain without having locked or burned them on the source chain and we’d encounter a double spending problem.

Any interoperability solution, whether it be a liquidity bridge, intent framework, or xERC-20 swap, would be vulnerable to this risk and it’s impossible to mitigate it. Because of this risk, current solutions require the initiating transaction to have been successfully executed and included in a block on the source chain before using relayers to pass an emitted message and execute the second transaction on the destination chain.

Important Takeaway: Atomic Inclusion does not meaningfully impact interoperability potential

3. Shared Settlement

Required Infrastructure:

Proof aggregation layer // Shared bridge contract

This is where things begin to get more interesting. As a result of the shared bridge contract, all liquidity deposited into the rollup ecosystem from the L1 can be moved freely between all connected rollups. Until this point, we could not perform swaps between rollups without passing through canonical channels, externally wrapping assets, or using a third party solution.

Why build a shared bridge contract? To understand why having a shared bridge contract allows us to trustlessly move assets across rollups, first consider what would happen if it was possible to have Eth in Rollup A, burn it, and mint it natively on Rollup B without a shared bridge contract on L1.

We see that each rollup would go out of sync with their bridge contract on mainnet. The rollup B bridge contract still has 50 Eth, so the user would not be able to withdraw their 1 Eth to the L1.

To solve this, external asset wrapping protocols are built that issue an externally-wrapped version of tokens across rollups that symbolize a native version somewhere else in the network.

With a shared settlement layer, the situation looks different. Because all liquidity for each connected rollup is locked in the same bridge contract, one can move freely between rollups, as the total amount of value in the bridge contract stays the same and can always be withdrawn.

There does need to be an update at the L1 contract level about *where *the liquidity is to allow users to withdraw from anywhere, but this is trivial because all connected rollups can read/write to the shared contract.

With a shared settlement layer, the flow may look like the following for a simple send-to-self case.

Send-to-Self:

1. User creates the initial transaction:
   → Tx 1: withdraw Eth on rollup A (with message to mint it on rollup B)
   → Transaction is batched and submitted to the L1 contract
   → It is aggregated into transaction root which groups all shared settlement rollups

2. Rollup B imports this tx root

3. Relayer submits transaction to mint along with Merkle Proof to rollup B

4. Rollup B verifies the burn transaction using Merkle Proof and transaction root

5. User is minted Eth on Rollup B

6. Rollup B submits proof to L1

We can extend this flow to any ERC-20 that has contracts across all rollups in the shared settlement ecosystem.

One can think of a shared bridge contract as an in-protocol messaging layer between all connected rollups, so theoretically this flow can actually be extended to any arbitrary messaging standard.

This gets us closer to composability, but because of the necessary steps of aggregating proofs and relaying messages only after the state changes are reflected on L1, there are high latencies (though notably lower than the L1 async case). Additionally, any complex cross-rollup activity like using a DEX on rollup B starting with assets on rollup A for a cross-rollup limit order would still be a tedious process for the user as they would still have to send-to-self and manually swap assets on the destination rollup. One can not create atomic cross-rollup bundles in this case.

Another important benefit with shared settlement is that there is less friction for liquidity providers or solvers that are filling orders in multiple environments. Because their liquidity across all connected rollups is reflected in the same bridge contract, they do not have to wait for the full withdrawal window to manage their cross-rollup liquidity.

Implications on Stakeholders:

1. Users:
   Can now transfer assets in a native form without L1 withdrawal period

2. Developers:
   Changes are limited to token issuers who can now use in-protocol messaging to issue native versions of ERC-20s across all connected rollups

3. MEV Searchers:
   Because this happens over multiple blocks for each rollup, there is no new MEV potential

4. Rollups:
   Rollups will have to opt-in to using a shared bridge contract and likely add pre-compiles to handle cross-rollup messages

Important Takeaway: Shared settlement allows for non-externally-wrapped asset transfers and arbitrary messaging across all rollups sharing the bridge contract and proof aggregation layer, but there will still be non-negligible latencies (though far shorter than L1 Async) and one cannot create cross-rollup atomic bundles.

4. Atomic Execution

Required Infrastructure:

Shared Sequencers // Superbuilders

Atomic execution allows us to guarantee the successful execution of cross-rollup bundles, but as we will see, the number of use cases for cross-rollup bundles that do not have dependent transactions is smaller than one might initially expect.

If any single transaction in a bundle of dependent transactions reverts, then all other transactions become invalid and must also revert, as is the case with burning and minting tokens across rollups. Minting tokens on a destination rollup is dependent on them having been burned or locked on the source rollup, so we would say that a bundle of burn and mint transactions is a bundle of dependent transactions.

Creating this bundle is impossible without a middle party such as a superbuilder that can create the destination transaction.

Consider what would have to be true for cross-rollup swap bundles to be built without another party beyond the user. A bundle would have to be created to lock/burn the asset on the source rollup and mint the asset on the destination rollup, but we run into issues:

1. Contracts on the source rollup can only emit a message when locking/burning the original source asset, they cannot call and create a transaction on the destination rollup.
   → This is why message protocols and relay networks exist.
   → The message can be used to structure what the call on the destination should be, but it can not actually create the transaction itself.

2. Creating the second transaction on the destination rollup to mint:
   → The user themselves cannot create this tx because they don’t have minting rights for the token on rollup B
   → I.e.) The destination chain needs a proof that tokens have been burned/locked on the source chain, but this proof is not available until after the initial transaction has been executed which would break our requirement for atomicity.
   → Any other party that could create the second transaction with minting rights theoretically could create a “mint” transaction on the destination chain at any point without having first created a “burn” or lock on the source, which is a massive vulnerability.

We can see that even though we could guarantee execution of cross-rollup bundles, we run into difficulty in how we could build them in the first place to transfer assets of value.

However, there are still a few use cases for atomic execution without dependent cross-rollup bundles. One of which is cross-rollup arbitrage:

Because there are no strict dependencies between these transactions, anyone can create this atomic bundle and submit it to a shared sequencer that will guarantee atomic execution.

However, to have atomic execution guarantees in the first place, rollups must opt into a shared sequencer and superbuilder that would run full nodes of all connected rollups, so the step from atomic execution to block-level composability is quite small and all shared sequencing solutions will do this. The only change required is that the block builder or another third party must be able to create transactions on behalf of the user to complete dependent cross-rollup bundles.

It is unlikely that infrastructure will be built that only allows atomic execution without going a step further to have composability. The relative gain of jumping to full block-level composability far outweighs the difficulty in achieving it given the infrastructure already having atomic execution.

Implications for Stakeholders:

1. Users:
   Likely no change, although it’s possible that third party facilitate solutions like intents could be atomic, but specifically how is not clear

2. Developers:
   Likely no change

3. MEV Searchers:
   Cross-rollup arbitrage is much safer given atomic execution

4. Rollups:
   Rollups must opt-in to using a shared sequencer/superbuilders submitting blocks with transactions from each rollup wishing to interoperate, which may change the rollup revenue structure. It is not yet clear how it will change.
   - Sequencing marketplaces may increase revenue to rollups by allowing ToB space to bought by sophisticated builders

Important Takeaway: While cross-rollup bundles are guaranteed to execute atomically, it is not clear how these bundles will be built if there is no superbuilder that creates part of the bundle, so it is unlikely that atomic execution on its own will impact interoperability. Shared sequencers/superbuilders should by default build instead for block-level composability.

5. Block-Level Composability

Required Infrastructure:

Shared Sequencer // Superbuilder // Proof aggregation layer* // Shared bridge contract*

(* = optional)

In much of the discourse around shared sequencers and shared settlement layers, the term often used to describe this level of interoperability is “synchronous composability”.

We have modified this term slightly to be more descriptive. Updating the nomenclature to Block-Level Composability implies that it is possible to compose between two rollups in a bundle of cross-rollup transactions that will be included and executed successfully in the next block. Synchronous composability might get confused with transaction-level composability, which we explore in the next section. Importantly, this requires a middle party (the shared sequencing infrastructure) that can be the conductor and creator of dependent transaction bundles.

At this level, we begin to see true composability between rollups beyond simply sending to self to participate in a dapp on another rollup.

With the addition of a shared sequencer that can create transactions, we are now able to make cross-rollup bundles that developers can take advantage of programmatically.

There are two cases to consider:

1. Block-Level Composability

2. Block-Level Composability + shared settlement layer

In both cases, we can create cross-rollup bundles for more complex activity but in the second case with shared settlement we can use native assets, which could have better price implications for cross-rollup DEX activity, for example.

With block-level composability, we have both the advantages of atomic execution with the added ability to create dependent transaction bundles. Let’s examine our two illustrative examples.

Same Token Transfer via xERC-20 (No Shared Settlement):

1. User has ERC-20

2. User creates tx via dapp:
   → Deposit ERC-20 into xERC-20 lockbox to receive xERC-20 wrapped version
   → Burn xERC-20
   → Emit a message signifying to the shared sequencing infra that a cross-rollup transfer has been initiated along with relevant data to facilitate the swap

3. Superbuilder picks up transaction and creates a cross-rollup bundle
   → Tx 1: The aforementioned wrap and burn transaction
   → Tx 2: Mint xERC-20 on rollup B

4. Superbuilder submits this cross-rollup to the shared sequencer
   → Because the superbuilder is running a full node of the two connected rollups, they simulate the transactions to guarantee successful execution of the bundle. If either transaction would revert, the whole bundle is reverted.

5. Shared sequencer submits the block containing both transactions to the DA layer as well as to the nodes that execute the state change

6. xERC-20 is minted to the user on Rollup B

With a shared settlement layer, the flow is even further simplified because there would be no need to first wrap the ERC-20 as an xERC-20 to swap.

Let’s now examine the cross-rollup limit order to buy an ERC-20 on Rollup B with an initial (different) ERC-20 from Rollup A and have the resulting ERC-20 sent back to Rollup A. In this case, we do not assume that we have a shared settlement layer, although a similar flow exists in the case with one. The only difference is not additionally having to externally-wrap assets.

Here are the required transactions in this case:

1. Wrap and Burn ERC-20 on A

2. Mint xERC-20 on B

3. Swap initial xERC-20 with target ERC-20 on B

4. Wrap and Burn target ERC-20 on B

5. Mint xERC-20 on A

Here is a potential flow for how this could work:

Flow:

1. User initiates the first transaction:
   → Wrap and Burn xERC-20 with message emitted to specify swap parameters (destination chain, DEX address, ERC-20 to swap with, limit order price, boolean to send back or not)

2. Superbuilder sees transaction and creates bundle:
   → Tx 1: User create tx described above
   → Tx 2: Mint xERC-20 on destination (superbuilder must have minting privileges)
   → Tx 3: Limit order using data from tx 1
   → Tx 4: Wrap and Burn ERC-20 on B assuming full fulfillment on limit order with message to mint on source chain
   → Tx 5: Mint target xERC-20 from output of the swap on source chain

Because the superbuilder creates the block and orders transactions, it can simulate each transaction and omit the bundle if any of the transactions would revert. For instance, if it is found that the user would not receive complete fulfillment on their limit order, the bundle would be omitted before the block is executed.

In this case of shared sequencing infrastructure without a shared settlement layer, an externally wrapped version of Eth and xERC-20 would need to be used, which could result in worse market conditions on the DEX due to thinner liquidity pools for wrapped assets. In this case, a user may have to use a softer limit with more tolerated slippage and could receive suboptimal prices. One exception to this is if USDC is involved. It is possible that a shared sequencer without shared settlement could work with Circle to gain exclusive rights on the USDC contracts across rollups to facilitate native USDC transfers and swaps cross-rollup.

With a shared settlement layer, this external wrapping is not necessary, and would likely provide better prices due to deeper liquidity pools for native asset swaps, but the flow is essentially the same.

Optimistically Trusting Sequencer

Rollups would need to optimistically trust the shared sequencer/superbuilder to create valid cross-rollup bundles. This is primarily due to the fact that this cross-rollup bundle contains dependent transactions that individual rollups cannot verify until after the block is added to each rollup’s chain and aggregated to a settlement layer on L1. An example is the initial burn and mint of Eth from source to destination. It is crucial that Eth is actually burned on the source chain before being minted on the destination chain, or else double spends are possible.

However, to have this full bundle executed in one block, all transactions must be present in that block even if the transaction represents a state that is invalid before the block itself (such as having Eth on the destination chain for the swap if the user does not have any before the block). For that reason, we must trust the sequencer that it has actually included the valid dependencies in the cross-rollup bundle. One could submit proofs after the fact to prove the validity of each transaction.

This is slightly less important when using wrapped assets, however, because they have no impact on the native liquidity stored in the L1, but fallback mechanisms must still be in place to counteract the risk of a malicious sequencer or a bug in the code that allowed a transaction bundle to be executed with a dependent transaction that was reverted.

Implications for Stakeholders:

1. Users
   Massive upgrades to UX in allowing cross-rollup limit orders in a single block

2. Developers
   Would need to be cross-rollup aware for cross-rollup activity, likely taking advantage of custom precompiles. Instead of just transactions, devs have to think in terms of bundles, but it’s likely that superbuilders and custom rollup infrastructure could abstract away most developer complexity.

3. MEV Searchers
   MEV searchers have essentially equivalent opportunity to use L1 strategies on cross-rollup bundles, but it depends on how PBS (Proposer-Builder Separation) is implemented.
   → Cross-rollup bundles are essentially viewed as a single transaction, so MEV could be found by front-running or sandwiching these bundles as long as they don’t move prices outside of tolerated slippage amounts (because then the whole bundle would revert and MEV attempts would fail)

4. Rollups
   Would need to opt in to shared sequencing infrastructure (including superbuilders) as well as allow access to burning/minting of Eth to shared sequencer in the case of a shared settlement layer.
   → Could internalize MEV by selling blockspace to builders

6. Transaction-Level Composability

Required Infrastructure:

VM-Level Changes // Shared Settlement // Superbuilders

Transaction-level composability refers to the same level of functionality that smart contracts on one EVM chain share. In this case, a single transaction could update state across multiple rollups simultaneously, and ensure that any state changes prior to any call can be reverted if the call does not return successfully. In effect, an atomic bundle of transactions in a block-level composable environment can be done within a single cross-rollup and cross VM transaction. This requires VM-level changes for all connected rollups in addition to a shared settlement layer and a superbuilder.

We describe a possible mechanism here at a high level. (This construction is due to the Espresso team as per our knowledge). First, a user submits a cross-rollup transaction to all rollups whose state is changed by the transaction or a superbuilder who can build blocks across all involved rollups. A superbuilder simulates the transaction and forms lists of input-output pairs, one for each involved rollup, which specify the necessary and expected cross-rollup messages within the transaction. (Note that the superbuilder can only do so if it has secure sequencing rights to all involved rollups for a period of time). The superbuilder then sends the simulated block to the proposer of each rollup, together with the lists of expected input-output pairs for each cross-rollup transaction. During execution, each rollup executes its own state transition function as normal assuming the inputs from the list of cross-rollup transactions are correct. During settlement, the input-output lists can then be cross-compared and proven safe during the proof aggregation phase in the shared settlement layer. Specifically, if any expected input for a cross-rollup transaction does not match what another rollup has specified as output, the settlement process will reject the entire cross-rollup transaction.

Although there is limited new functionality unlocked with transaction-level composability beyond flash loans, the developer experience for creating cross-rollup applications can be greatly improved. The ability to create dapps that interact with all connected chains without reasoning about cross-rollup bundles will make it far easier to innovate in a multi-rollup landscape. Furthermore, it’s possible that new use cases and behaviors will emerge as a result.

There are many open design questions for transaction-level composability. For one, how devs can opt into or out of cross-rollup calls for their smart contracts needs to be carefully considered. Allowing arbitrary composability without restriction means that we regress to one monolithic rollup. We think the answer here is for devs to explicitly indicate where cross-rollup composability is necessary in their contracts, for example via a Solidity modifier like `composable` which marks certain entry points of the contract as callable cross rollup.

Implications for Stakeholders

1. Users:
   Same implications as block-level composability with additional advanced capabilities like flashloans
   → UX is virtually identical to using one chain for dapps that opt-in

2. Devs:
   Developer experience massively improves as dapp devs can natively call contracts cross-rollup and use outputs from these calls like single rollup calls
   → Superbuilder/Sequencer infra will still have to place the transaction in blocks for the rollups that the cross-rollup call affects, but will not have to build the same bundles as in the case of block-level composability.

3. MEV Searchers:
   High MEV potential as cross-rollup bundles are now essentially equivalent to single transactions on one chain

4. Rollups:
   Would require VM level changes, as well as opting into a shared sequencer and shared settlement layer
   → Additional trust assumptions involved in having to trust the inputs and outputs for other rollups before being able to verify state via proofs, but slashing mechanisms could reduce the burden of trust

Summary and Ecosystem Map

After walking through the technical details of each level of interoperability defined here, we can summarize:

1. Shared Settlement allows for cross-rollup swaps without externally wrapping assets and creates in-protocol messaging pathways between all connected rollups

2. Shared Sequencing/Superbuilders allow for next block execution guarantees on cross-rollup bundles

3. Block-Level Composability allows for complex, fast, dependent cross-rollup bundles to be created, achieving a near smart contract to smart contract level composable ecosystem.
   → With the addition of shared settlement, these cross-rollup bundles can be created without using externally wrapped assets

4. Transaction-Level Composability is possible, and while the new use cases opened up might be for more sophisticated users, it has the potential to massively upgrade the cross-rollup development experience.

At present moment, there are many projects emerging to create these natively interoperable ecosystems. Here is a high-level overview of the landscape:

Ecosystem Map

Closing thoughts

There are still open questions about the technical nuances within the frameworks laid out in this article. For example, building bundles in a block-level composable ecosystem for cross-rollup limit orders may have more detailed designs to handle the case of partial fulfillment and slippage tolerance for market orders. We offered one potential solution here to revert a cross-rollup limit order bundle if the order is not completely filled, but the design space is open.

Additionally, it is worth relating this to the current mindshare growing in the space about appchains. Appchains are long-tail L2s that are either generalized or permissioned with the goal of siloing specific related protocols on one L2. It is likely that when we reach block-level composability we will also begin to see appchain environments gaining significant traction as a result of having native composability between all connected networks.

At present moment, it is still difficult to bootstrap liquidity to these appchains, but once a larger chain connects as an onramp to the interoperable environment, it’s likely that we’ll see walled garden ecosystems around shared infrastructure.

Another important open question is how the design space around superbuilders will settle. Development on this front is still quite nascent, and it’s not yet clear what will be the most efficient and effective way to create a network of sophisticated builders that can create cross-rollup bundles. Where these cross-rollup bundles will optimally be included in a block, and the impact on rollup revenue is an open question with different strategies being explored by many teams.

Ultimately, the future will likely involve a combination of in-protocol and out-of-protocol bridging solutions and they will work in tandem to provide a far better interoperability process for everyone. We believe the progression defined in this article can serve as a guide for developers and builders alike who are focused on making cross-rollup interoperability more seamless for end-users.

It’s also likely that there will be completely new paradigms for cross-rollup interaction that have yet to be discovered. If you’re a builder working on approaches that expand on the topics here or are not covered above, please reach out (dms are open). The technology has finally matured enough to put real pressure on finding solutions for liquidity/ecosystem fragmentation, and we are always looking to connect with founders that are taking risks to build creative solutions.

Acknowledgments

This article grew out of an incredibly insightful rollup interoperability roundtable discussion held by 1kx at EthCC. Special thanks goes to Noah Pravecek, Ellie Davidson, and Terry for reading early versions of this article and providing feedback, as well as to Marti, mteam, and Bo Du for further conversations on the subject.

— — — — — — — — — — — — — — — — — — — -

Disclaimer: This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.

1kx News and Made in House:

Architecting network success.

Introducing Atlas: Web3 Data Provider Performance Dashboard

1kx 🤝 Consumer

Joining 1kx as an EIR: Meet Rafael Morado

The Summit: a Gathering of the Onchain Gaming Community

Autonomous Worlds Game Jam (AA24 Recap)

Research:

On Trust Minimization and Horizontal Scaling

endoftheworld.txt :: Crypto x AI

Evaluating token economics for DePINs: cost estimation

DePIN Case Studies: Evaluating the cost of running DePIN networks

Prediction Markets: Bottlenecks and the Next Major Unlocks

Wallet Infrastructure: Empowering the Next Generation of Dapps

ETPs: Expanding Investor Access to Crypto

Generative Manufacturing: Transmuting Code into Physical Goods

A Brief History of Memecoins: Their Past and Future

Modding worlds: Building Hexcraft with Downstream

A Comparative Analysis of Decentralized Social Protocols

Exploring the Design Space for Dynamic NFTs

zkML: Evolving the Intelligence of Smart Contracts Through Zero-Knowledge Cryptography

Evaluating token economics for Web3 infrastructure networks: Part I - emission schedules

Autonomous Worlds: The Case for Fully On-chain Games

Multiplayer Creation: Unlocking Participatory Media

Thesis:

Safe: Unlocking the Era of Programmable Ownership

Crypto-Native NFT IP: A New Era For Consumer Brands

Digiphysical Goods: Bringing Programmable Utility to Physical Products

For our latest, subscribe here and follow us on X.