• EigenLayer introduced restaking to let new blockchain services/networks borrow Ethereum’s economic security (validator set + capital) instead of building their own - solving the “cold start” problem for crypto infrastructure.

• Since then, it has expanded to support staking with other assets, not just ETH, making it more flexible and accessible to more participants.

• But as more services launched, it became clear that developers were still rebuilding the same basic components again and again. EigenLayer solved a big part of the problem, but building still wasn’t as fast or smooth as cloud environments.

• EigenCloud is EigenLayer’s answer to that: a unified framework that helps developers build verifiable, slashable applications faster - with tools, building blocks, and shared infrastructure all in one stack.

As someone who’s been following EigenLayer since day one (not even joking - I was actually early on this one), the EigenCloud announcement feels like a major enhancement and one that deserves its own blog post.

The vision with EigenLayer started out simple: make it easier to create new blockchain services/networks. Today, there are over 30+ AVS’s live on mainnet, with more than 100 operators - ranging from home-stakers to larger organizations.

Safe to say, this new restaking primitive has gone a long way toward solving the “cold start” problem for blockchain infrastructure.

But this isn’t enough to get to cloud-level scalability. It’s still hard to build modern apps that take advantage of crypto’s built-in trust and verifiability. EigenCloud is an attempt to change this. At its core, EigenCloud is EigenLayer’s vision for building the “AWS of verifiable crypto apps.”

In this post, I want to break down:

• How we got here - the challenge with building new crypto infrastructure

• What EigenCloud actually is & what "verifiable apps" mean

• How all the pieces fit together

Let’s dive in.

The Infrastructure Innovation Problem

Let’s take a quick look back to see how the blockchain ecosystem evolved to where we are today.

In 2008, Bitcoin emerged as an application-specific blockchain with a limited scope, focusing only on peer-to-peer payments. It was specifically designed for a single purpose - to serve as a decentralized digital currency for the internet.

Then came Ethereum. Ethereum introduced a general-purpose smart contract platform, letting people to write code on the blockchain. This meant developers could build all kinds of applications, like games, financial tools, and digital collectibles - not just send money.

So while Bitcoin was built just for sending money, Ethereum made it possible to build all kinds of apps on the blockchain.

However, Ethereum has its limitations when it comes to innovating beyond the application layer. While it's great for building smart contracts, it doesn’t offer the same level of programmability for deeper infrastructure components such as consensus mechanisms, data availability, or oracle systems.

To build those kinds of services, developers often have two options: (1) launch their own blockchain or (2) go through Ethereum’s slow and complex protocol upgrade process. Both of thses take serious time, money, and effort: you need to attract validators, design a new token, secure enough capital to keep the network safe, and not the mention the legal/regulatory overhead.

Understanding Staking and Economic Security

Before we dive into solutions, let’s quickly cover a few key ideas to set the stage. If you’re already familiar with Ethereum’s staking model, feel free to skip ahead - if not, here’s what you need to know:

What is staking & why does matters

In Ethereum, Validators are the backbone of the network. They verify transactions, propose new blocks, and help keep the blockchain trustworthy and secure. To become a Validator, a user must lock up (or “stake”) 32 ETH as collateral - this process is called staking. The stake acts as a financial incentive: if a validator acts dishonestly (i.e.: by trying to confirm invalid transactions), they can be punished through a mechanism called slashing, which penalizes part (or all) of their staked ETH. On the other hand, honest validators are rewarded with ETH for the service they provide.

This entire system - where validators secure the network by staking tokens and face penalties for dishonest behavior - is what’s known as a proof-of-stake (PoS) blockchain.

What we mean by “economic security”

This system works because it aligns incentives: Validators are motivated to behave honestly to protect their stake, ensuring the overall integrity of the network. The more ETH that is staked, the more economically secure the network becomes. This is what we refer to as economic security.

Why bootstrapping infrastructure is still so hard

Now here’s the problem: building core blockchain services - like oracles, bridges, or data availability layers - often requires teams to launch their own networks from scratch. Because Ethereum doesn’t support these kinds of infrastructure-level features natively, developers have to take on everything themselves (such as launching a new token, attracting validators, and securing enough capital through staking). It’s the same infrastructure innovation problem we touched on earlier.

This is a lot of work, especially for early-stage projects. And without enough capital staked, the service may not be considered secure or trustworthy.

EigenLayer: Shared Security as a Solution

To address the infrastructure bottleneck, EigenLayer introduced a new approach: restaking.

Simply put, restaking allows validators to reuse their already-staked ETH to secure additional services beyond Ethereum itself. In other words, the same validators - which are running the service can run the additional protocols. And the same ETH securing Ethereum can now also secure new networks/services.

Here's how it works:

• EigenLayer enables Ethereum validators (called operators in the EigenLayer ecosystem) to opt-in and extend their responsibilities beyond Ethereum itself. (I’ll be calling these actors as operators as well.)

• These operators can choose to provide services to other networks, referred to as Autonomous Verifable Services (AVSs).

  • An AVS comprises a set of offchain container(s) + onchain smart contract(s). These are not necessarily consumer applications, but instead services that the consumer apps may require.

• If an operator misbehaves in any of these external services, their staked ETH on Ethereum can still be slashed.

This model fundamentally changes how new protocols are built: instead of building and bootstrapping a validator set from scratch, new services can plug into Ethereum’s existing economic security. EigenLayer turns Ethereum’s trust layer into a shared resource, creating a kind of marketplace for security that other protocols can use.

🌟 While EigenLayer started with ETH restaking, the model has since evolved to support staking other assets as well - meaning users can now stake a broader range of tokens (not just ETH) to help secure services.

New protocols like Symbiotic have emerged that are also exploring this space, using similar ideas but different technical approaches. But the core innovation remains the same: turning staked capital into reusable security for a broader ecosystem.

From Protocol to Platform: Enter EigenCloud

After introducing the core restaking protocol, EigenLayer built their own EigenDA to show how this works in practice. It proved that restaking (or the broader ‘staking‘ ) could secure real infrastructure with real throughput.

Since then, things have expanded rapidly. EigenLayer has been exploring everything from AI integrations to expanding the design space for decentralized infrastructure. (Crazy that I wrote this blog post with an overview of the AVSs less than a year ago and today there are at min x5 more AVSs.)

With all these different parts building on EigenLayer has become powerful, but also gotten pretty complex. Even as someone who follows the space closely, I found myself struggling to understand how all these different pieces fit together - the restaking/staking protocol, the data availability service, and various other projects they were building seemed disconnected.

This is where EigenCloud comes in.

Breaking down EigenCloud

EigenCloud is an attempt to unify all these different pieces into a single, developer-friendly framework. The goal is simple: make it easy to build verifiable, onchain applications by providing the infrastructure and tools in a single stack.

Think of it as an abstraction layer that makes building on EigenLayer feel like building in the cloud - with the added power of crypto-native verifiability.

So, what does that actually look like in practice? To make it more concrete, let’s cover the 4 core pillars that form the foundation of EigenCloud.

The 4 Pillars of EigenCloud

1. Developer Platform: The Tools You Actually Want

This directly tackles the "rebuilding everything from scratch" problem. Instead of every AVS needing to figure out operator management, slashing logic, and reward distribution, EigenCloud provides tool such as:

• DevKit CLI: Command-line tools for creating, testing, and deploying AVSs

• SDKs: Pre-built libraries

• Templates & Plugins: Starting points for common use cases

• Monitoring & Observability: Built-in logging and analytics

2. Trusted Primitives: The Building Blocks

These are ready-to-use services that any application can plug into:

• EigenDA: Data availability layer (already live, scaling to hundreds of mb/s)

• EigenCompute: Verifiable off-chain computation (coming soon)

• EigenVerify: Fraud proofs and dispute resolution (coming soon)

Think of these as the S3 or EC2 equivalent in AWS for crypto - core services that apps can use out of the box.

3. EIGEN Token: The Economic Security Engine

The EIGEN token powers the entire system, encouraging honest behavior from participants and providing a forking mechanism in case of disputes.

4. Commitment Infrastructure

This one feels more abstract from their description, but from my understanding, this refers to access to the operators and stakers, and so the EigenLayer protoocl. Instead of every AVS needing to find and setup their own validators, this layer lets you tap into EigenLayer's existing network of operators.

Ok, but what exactly is EigenCloud?

Simply put, EigenCloud is a unified framework that gives developers:

• The ability to create verifiable applications that use crypto incentives and slashing-based trust

• A network of AVSs to build on or integrate with

• Access to operators and developer friendly tools to run infrastructure

Cloud Programmability 🤝 Crypto Verifiability

So is this just AWS for crypto? Well, not quite.

The big innovation isn't just "cloud-level programmability" - it's cloud-level programmability with crypto-grade verifiability. In traditional cloud platforms, you trust the provider. In EigenCloud, you can prove outcomes cryptographically. No need to trust a centralized provider - actions are verifiable by design.

Why Verifiability Matters Now

You might be thinking: "Do we really need every app to be verifiable? Isn't this overkill?"

Here's why it matters: especially now that we're entering an era where AI agents will increasingly hold and move capital on our behalf. If you're giving money to any kind of agent or system, you want guarantees that it will do exactly what it was programmed to do.

Most failures in blockchain systems happen when you have to trust a person or a company. EigenCloud's main innovation is reducing the need for that kind of trust, bringing more control and reliability to how apps and infrastructure are built.

This unlocks an entirely new design space:

• AI agents with built-in slashing conditions

• Off-chain compute with on-chain trust guarantees

• Infrastructure that can prove its behavior cryptographically

Solving the Original Problem

EigenLayer introduced a way to let new services use Ethereum's security instead of building their own from scratch - that's the core innovation. But as more services got built on EigenLayer, things got complicated. You had the staking protocol, EigenDA, various other AVSs, and it wasn't clear how they all fit together.

EigenCloud seems to be their answer to this complexity - trying to package everything into a unified developer experience.

There's still a lot to figure out, but it's an interesting direction and the foundation is promising: cloud-like programmability with crypto-native guarantees.

If you have any questions or comments, feel free to reach out.

See you on the next one. 👋

We’ll cover:

• Why Ethereum needs intents – Scaling introduced fragmentation, making UX worse.

• How intents work – A way to simplify execution by focusing on what users want, not how it happens.

• How to build with intents – A look at the The Open Intents Framework and how it makes building intent-based applications much easier.

Trip down the memory lane: Scaling Ethereum

We scaled Ethereum with the rollup-centric roadmap—huge progress! But now we face a new challenge: Ethereum is fragmented.

Rollups, L2s, and alternative execution environments have created a siloed landscape where users and liquidity are spread across multiple chains. Moving assets between these ecosystems often means dealing with slow, manual, and complex processes.

We used to have one chain. Now, we have many. Switching between them, adding networks to your wallet, and managing assets across different chains is clunky and confusing, even for the most degens.

This fragmentation leads to inefficiencies—not just for users but also for developers building cross-chain applications. Gas costs, bridging delays, and liquidity fragmentation make interoperability difficult.

Ethereum should feel like a single network again, where actions happen smoothly without users worrying about chains, bridges, or approvals. For that, we need fast, cheap, and seamless interoperability—and intents offer a way to get there.

What are Intents?

At their core, intents change the way transactions work. Instead of users manually figuring out how to get from point A to point B, they simply declare what they want—and let specialized actors handle the rest.

For example:

• A user expresses an intent: Swap 100 USDC on Base for 100 USDC on Arbitrum.

• A solver (a specialized off-chain agent) finds the best way to execute this transaction.

• The solver handles everything: routing, settlement, and taking the finality risk.

This approach abstracts away complexity, letting users interact with Ethereum as if it were a single network, rather than multiple fragmented chains.

But really - What even are Intents?

Okay so I’ve read this same explanation way too many times now, and it didn’t really click to me at the start. So I’m going to dive a bit more.

• Simply put, to interact with Ethereum you need to send a transaction. A transaction is a structured message that tells the Ethereum Virtual Machine (EVM) exactly how to execute a state transition.

• You have to manually craft transactions, manage nonces, hold specific assets to pay gas fees, and understand how smart contracts interact. Crafting transactions is not a pleasant job—especially because execution decisions are often made without full information or sophisticated execution strategies. And the thing is users generally don’t think in terms of transactions—they think in outcomes. They don’t worry about approvals, bridging, or contract calls; they just know I have 100 USDC on Base and I want it on Arbitrum. This is the case in marketplaces, DAOs, public goods funding, and more.

• Enter intents. Instead of specifying every step of the execution, users simply sign a message that defines the outcome they want to achieve.

• Then, third-party solvers figure out the best execution path that meets those constraints.

This shift represents a move to a declarative model—where users specify what they want (the intent)—instead of the traditional imperative model, where they must manually define how to execute every step.

• Imperative: Defining how something should be done step by step.

• Declarative: Defining what you want, and the system figures out the best way to do it.

That’s the gist of intents as a concept, and basically the goal here is to make Ethereum feel more unified. Now, let’s talk about what it takes to build intent-based applications.

Building with Intents today: The Need for Better Infrastructure

While intents improve UX, integrating them as a new chain is not straightforward.

Generally there are two main options:

1. Partner with an existing intent protocol—This requires custom integrations, technical research & due diligence, and BD negotiations to get your chain supported.

2. Build your own solver infrastructure—which means handling liquidity, settlement, rebalancing, and execution costs.

Both of these are hard. While some intent-based infrastructure exists, adoption is slow due to these challenges.

If intents are going to scale, we need common standards & an open, modular framework. This is where the Open Intents Framework comes in.

The Open Intents Framework

The Open Intents Framework is an open-source, modular framework that makes building and deploying intent-based applications easier. Instead of every project needing to build its own intent infrastructure, developers can tap into pre-built tools like composable smart contracts, solvers, and UI templates.

It’s created as a public good, led by contributors from the Ethereum Foundation, Hyperlane, and Bootnode with support from the wider Ethereum ecosystem. The goal of the framework is to make intents open and permissionless for the entire Ethereum ecosystem. Hyperlane provided the initial funding, laying the groundwork for it to become a community-owned and community-funded project.

Now, teams that want to build with intents no longer have to start from zero.

How It Works: What’s in the Framework?

Let’s break it down.

1. Composable Smart Contracts

A set of pre-built smart contracts that define how intents are interpreted, executed, and settled—built on ERC-7683. Developers can integrate these contracts instead of building from scratch.

• ERC-7683: standard for cross-chain Intents on Ethereum.

• It standardizes how cross-chain interactions are expressed as intents. While ERC-7683 standardizes intent creation, it remains flexible in settlement.

• The Open Intents Framework comes with a default implementation for basic limit order swaps and Hyperlane ISM settlement. The core Base7683 contract is modular, meaning it can support different order types and settlement mechanisms (e.g., Arbitrum’s Broadcast Standard).

2. Open-Source Solver Implementation

A TypeScript-based solver that watches on-chain events and processes intents accordingly.

• While most solvers today rely on custom infra, this reference solver provides protocol-independent features.

• Includes indexing, transaction submission, and rebalancing.

• Complements Across Protocol’s reference relayer, making intent execution more robust.

By offering a reference solver, the framework lowers the barrier to entry for teams looking to run solvers without deep infrastructure expertise.

3. UI Template

A pre-built, customizable UI for projects integrating intents.

• Developers can use the template as-is or modify it for their specific use case.

• Reduces front-end development time by providing a functional user interface out of the box.

This makes it easier to launch new intent-based apps without spending weeks on UI development.

Beyond the Framework: Standardization, Settlement & Solver Evolution

The Open Intents Framework is just one piece of the work around intents. Across the Ethereum ecosystem, ongoing work on standards and infrastructure is helping make intents more practical, secure, & scalable.

1. Standards

• Standards like ERC-7683 and RRC-7755 ensure that intents can be executed in a consistent way across different chains and protocols.

• Cross-chain messaging standards like ERC-7786 (by OpenZeppelin/Axelar), ERC-7841 (by Espresso) or ERC-7854 (by Hyperlane) are also helping bring modular verification to intent execution.

2. Intent Settlement Diversity

• The Open Intents Framework includes a default Hyperlane-based settlement option, but it’s built to support alternative mechanisms as well. Hashi’s Oracle Aggregator, Espresso’s confirmation layer, Optimism’s Superchain native interoperability or Arbitrum’s Cross-chain Broadcaster Standard can be easily added to the Base7683 contract as settlement

3. Liquidity Management for Solvers

• For intents to work efficiently, solvers need liquidity. Projects like Everclear are working on automated rebalancing, so that solvers always have access to the capital they need.

• Additionally the Arbitrum Foundation will leverage Nomial for the Arbitrum Universal Intents Engine. Nomial is planning to add a reference solver.

4. Solver Intent Matching

• Right now, intents are submitted on the origin chain, and solvers fulfill them—but this system can be improved.

• Resource locks (where assets are temporarily held) are being explored as a way to improve execution efficiency.

• Uniswap’s The Compact is working on intent routing, ensuring that solvers can quote and fulfill intents efficiently.

• Collaboration between solvers (via platforms like Khalani) could expand solver coverage, making intents more widely available across all blockchains.

5. Better User Interfaces for Intents

• For intents to be widely used, they need to be easily accessible to users. Superbridge is experimenting with lowering the integration barrier, making it easier for wallets and applications to adopt intent-based execution.

6. Reference Solving

• The Eco team released Eco Routes, a framework for apps and chains to access permissionless cross-chain liquidity. They have been exploring how to adapt The Open Intents Framework reference solver to become a canonical solver for it.

End.

With open infrastructure and shared tooling, building intent-based applications is becoming a lot easier. Instead of every project reinventing the wheel, the Open Intents Framework makes integrating intents open and modular.

As intent-based execution becomes more widely adopted, we’ll move toward a unified Ethereum—where users don’t need to think about chains, bridges, or liquidity, and things just work.

Interested? You can head over to The Open Intents Framework to learn more & start building with intents!

If you have any questions, comments or ideas feel free to reach out to me, I’d love to hear from you!

I’m still finding my feet in this field, and my notes are all over the place—so consider this my attempt to organize the chaos. If you’re new to Hyperlane and cross-chain apps, start with this post for the “why.” Here, I’ll dive into the “how.” I’ll keep it straightforward, and hopefully useful enough to recycle for future talks.

In this post I want to answer the following:

1. Why you should care about interoperability & Hyperlane?

2. What’s an interoperability protocol and how does it work?

3. Where to get started?

Quick Overview: Why Interoperability & Why Hyperlane?

Blockchains today are like islands—they don’t naturally communicate. This creates:

• Disconnected apps: Apps on one chain can’t interact with others.

• Fragmented assets: Tokens and liquidity are stuck on separate networks.

• User friction: Managing multiple wallets, bridges, and fees is confusing and frustrating.

Interoperability changes this by enabling seamless communication between chains. It allows developers to build apps that connect across networks, transfer assets and data easily, and unlock new opportunities for innovation and better user experiences.

This is where Hyperlane comes in.

Hyperlane offers permissionless, secure cross-chain messaging, meaning:

• Permissionless: Anyone can connect new chains or run their own infrastructure without needing approval from central entities.

• Secure: Messages between chains are verified with customizable security models.

• Simplified: Move assets and data between chains without needing to build or maintain complex, custom solutions.

Now, let’s dive into how it all works under the hood.

Hyperlane Core components

Hyperlane is a protocol for secure, permissionless communication between different blockchains. It works by combining a few key components that handle cross-chain messaging and security.

1. Mailbox Contracts

2. Agents: Relayers and Validators

3. Interchain Security Modules

Here’s a breakdown of how they fit together:

1. Mailbox Contracts

• Mailbox Contracts are the foundation of Hyperlane cross-chain communication. They are smart contracts deployed on each chain that handle sending, receiving, and processing cross-chain messages. Think of them as the entry and exit points for messages between chains. Each chain has its own Mailbox. The Mailbox contracts are permissionless to deploy.

2. Agents: Relayers & Validators

Relayers

• Relayers are off-chain actors that transport messages between chains. They monitor the Mailbox on the origin chain, detect when a new message is ready, and then deliver it to the Mailbox on the destination chain. Relayers work behind the scenes to keep things moving smoothly.

Validators

• Validators are responsible for ensuring the security of cross-chain messages. They sign checkpoints (Merkle roots) that summarize the state of messages dispatched from a Mailbox. These signatures are proof that the messages are legitimate and can be processed on the destination chain.

3. Interchain Security Module (ISM)

• Hyperlane takes a modular approach to security via customizable security models (e.g., multisig, cryptographic proofs), called Interchain Security Module’s (ISM). For example, a multisig ISM might require signatures from several validators before accepting a message, while a Merkle proof ISM checks that the message matches a valid state on the origin chain. This ensures that messages arriving on the destination chain haven’t been tampered with.

Step-by-step: How cross-chain messaging works

1. Send the message from the origin chain (message dispatching)

The process starts when the sender calls the dispatch() function on the origin chain’s Mailbox contract.

2. Message emitted from the origin mailbox

Once dispatch() is called, the Mailbox contract emits a Dispatch event. This signals that the message is ready for transport.  Validators observe the message and confirm it with a signature.

3. Relayer: collect, process, submit message

Relayers monitor the origin Mailbox for Dispatch events. When detected, the relayer collects the event data and initiates the next steps.

1. Message Collection: The relayer collects this message and verifies that the sender has paid the required gas for delivery. If additional security metadata is required, such as in the case of a multisig ISM, the relayer collects signatures from validators to ensure integrity.

2. Message Preparation & Simulation: Before sending the message, the relayer prepares the necessary ISM metadata to ensure the message is valid. It simulates the transaction to confirm success. If the simulation passes, the message is queued for submission.

3. Message Submission: Finally, the relayer submits the message, along with the necessary verification data, to the Mailbox contract on the destination chain. This function triggers the next step in the cross-chain messaging process, passing the message to the ISM for verification.

4. Mailbox retrieves the recipient’s ISM on the destination chain

On the destination chain, the Mailbox checks if the recipient contract specifies a custom ISM by implementing the ISpecifiesInterchainSecurityModule interface. If so, it retrieves the specified ISM; otherwise, it uses the default ISM.

5. ISM verifies the message

After retrieving the appropriate ISM, the Mailbox contract on the destination chain verifies the message using the selected ISM (e.g., Multisig signatures, Merkle proofs, ZK proofs, etc.).

If valid, the message is approved; if invalid, it is rejected.

6. Message processing and delivery

Once verified, the Mailbox calls the recipient contract’s handle() function. The recipient contract processes the message based on its logic, such as transferring assets or triggering specific actions in the application.

Can I add Hyperlane to my chain?

Yes, and it’s easier than you think! Hyperlane is designed to be permissionless, meaning you don’t need approval from anyone to connect a new chain. Here’s how it works:

1. Deploy Hyperlane core contracts:

   You’ll deploy core contracts to your chain, including: the Mailbox, which handles sending and receiving messages and supporting contracts like the Interchain Gas Paymaster (IGP) for handling gas payments, the Default ISM (if you’re not using a custom one).

   These contracts are the backbone of Hyperlane’s cross-chain messaging.

2. Set up the ISM

   The ISM is customizable depending on the security requirements of the application. You can use the default settings or customize according to your needs.

3. Configure Agents

   Set up the agents—relayers and validators—to monitor, verify, and transport cross-chain messages.

👉 And that’s it! Hyperlane ensures you can connect chains quickly and on your own terms. You can check out the docs for more info on the steps.

Warp Routes: A Hyperlane use case

Warp Routes build on Hyperlane’s infrastructure, letting you use cross-chain messaging in a straightforward way.

They allow any ERC20, ERC721, or native tokens to move effortlessly between chains. Warp Routes provide predefined paths for transferring assets and sending messages between blockchains, so you don’t have to set everything up from scratch.

• Abstract away the complexity: Warp Routes act as an abstraction layer over Hyperlane's core messaging and modular security. While Hyperlane handles the heavy lifting of cross-chain messaging—such as routing, message verification, and security—Warp Routes simplify this by pre-configuring the pathways for certain assets.

• Simplicity: Instead of setting up individual connections or configuring security modules for each chain, Warp Routes let you use these pre-established routes.

👉 Check out our docs for details on how to deploy and use Warp Routes.

Interoperability can feel overwhelming with all the buzzwords, but it doesn’t have to be. I hope this post gave you a clear, straightforward explainer and the tools (or at least some curiosity) to keep exploring.

• Check out the Hyperlane Bounties for some ideas & starting points

• Follow Hyperlane for the latest updates, research, and insights into cross-chain interoperability

See you on the next one!

In the novel, our main character, Ender, is trained to fight in a war using advanced simulations. These simulations don't just provide static tasks; they react in real time to the players' strategies and decisions, evolving based on predefined rules.

It's easy to think of these simulations as complex games, but there’s more at play here. It's a system that reacts and adapts independently of any direct human control—well, almost independently. In Ender's Game, the simulations are dynamic but ultimately controlled by external forces—teachers/commanders who tweak the parameters to push Ender further, preventing the system from being truly autonomous.

This raises an intriguing question: What if these worlds could evolve independently, without anyone behind the scenes pulling the strings?

As much as I find Matrix-like worlds highly entertaining, my goal with this post isn’t to write a sci-fi story. Instead, I want to break down why games are much more than “just games”, what exactly are autonomous worlds and how we're almost at the point of building digital worlds.

From Games to Autonomous Worlds

Games: The Gateway to Building [Autonomous] Worlds

Games have long been a way to explore complex systems and interactions. Yet, I dislike the word “game.” It’s often dismissed in my circles, and I find myself saying "it's not just a game" to convey the deeper impact games hold.

At their core, games are formalized play, meaning they take the creative essence of play and give it a framework with rules, objectives, and boundaries. Through play, we explore ideas, create meaning, and form bonds with others.

As Huizinga wrote:

“It is through this playing that society expresses its interpretation of life and the world. By this we do not mean that play turns into culture, rather that in its earliest phases culture has the play-character, that it proceeds in the shape and the mood of play.”

Huizinga argues that culture begins with play. Early societies expressed their beliefs, values, and understandings of life through playful rituals, games, myths, and storytelling. These activities were the building blocks of culture, not because they were serious or strictly functional, but because they allowed people to imagine, experiment, and give meaning to life in a shared, joyful way.

Simply put, games give structure to our natural impulse to explore, compete, and create meaning. The formalization happens through rules, and this is where things get interesting.

Rules as the Building Blocks of Digital Worlds

It might sound obvious—and that's a risk I’m willing to take—but rules are what define a game.

In a well-designed game, rules don’t just guide behavior; they create entire ecosystems. They establish boundaries, define roles, and introduce challenges, shaping the way players interact. In essence, rules turn games into mini-societies where complex dynamics—like economies, hierarchies, and competition—can be explored.

This brings us back to the question: What if games could evolve independently, driven purely by their rules?

Unlike traditional games, where rules are enforced by a central authority (e.g., developers or moderators), think about games that operate independently, evolving based on the interactions of their participants.

Now, take this idea a step further: What if these principles could be applied to entire digital spaces, creating self-sustaining systems beyond the boundries of traditional games?

This is where Autonomous Worlds come in.

What exactly are Autonomous Worlds?

Autonomous Worlds are digital spaces governed by immutable rules, often encoded as smart contracts. These worlds evolve through user interactions, free from centralized control. By building on principles from games—like structured rules and meaningful interaction—they represent a leap forward, creating systems that operate independently and transparently.

Ludens talks about this concept in Autonomous Worlds (Part 1), where he describes them as “containers for entities and a coherent set of rules.” Once the rules are established, the world functions autonomously, much like a self-sustaining system where participants shape its evolution. This introduces the concept of digital physics—a term often referenced in niche crypto and gaming circles. In the physical world, natural laws like gravity govern how everything behaves. Similarly, Autonomous Worlds are governed by digital physics: immutable, pre-defined rules that dictate the behavior of the digital space.

In Autonomous Worlds:

• Rules are encoded into the system (typically through smart contracts), and once those rules are in place, the world runs independently.

• Players interact within the system, driving its evolution, but no single entity controls the outcome.

In essence, Autonomous Worlds represent the next evolution of digital spaces. They are ecosystems where rules are transparent and immutable, fostering collaboration and innovation while serving the inhabitants rather than any central authority.

Building Autonomous Worlds

Enter Blockchain

To create spaces that evolve fairly and transparently, we need technology that enforces rules without centralized control. This is where blockchain comes in.

Blockchain’s transparency and immutability make it the ideal foundation for Autonomous Worlds. By locking rules into trustless, verifiable smart contracts, blockchain ensures these worlds remain fair and decentralized. Unlike traditional systems—where a central authority can override or manipulate the rules—blockchain guarantees that the system operates exactly as intended.

Elephant in the room: isn’t the blockchain only for finance? It’s easy to assume that blockchain’s role is only in finance.

Bitcoin and Ethereum initially popularized decentralized currency and finance, but its real power lies in creating enforceable rules for any system—games included. In other words blockchain is a tool for creating enforceable, transparent rules, which opens up applications far beyond transactions.

Blockchains do more than ensure transparency and security in Autonomous Worlds—it enables fully immersive, decentralized economies. Now, to be clear we're not turning games into economic systems; instead, we're creating environments where players' actions hold real value.

Beyond Censorship Resistance: Virtual Economies

In traditional games, assets like weapons, clothes, or virtual land are controlled by a central authority (usually the game developer), meaning players don’t actually own them. Developers can change, revoke, or manipulate these assets at any time. Blockchain gives us the tools to create worlds with independent rules and economies

As Chris Dixon explains in Read Write Own:

“Fungible tokens representing virtual currencies and NFTs representing virtual goods would flow freely through the network. Some NFTs would be “soulbound“ or nontransferable, representing a special achievement or an item forever tied to the person who attained it. Some NFTs would be transferable commodities like, virtual clothing, or “skins“ that can be bought and sold. And other NFTs would be a combination, with some features that are tradable and some that are not. An avatar might acquire experience points that reset on transfer, for instance.”

Unrealized Potential of Blockchain games

Games provide the perfect testing ground for exploring complex systems, serving as the foundation for fully realized Autonomous Worlds.

With 2.6 billion active players globally and a market set to hit $282 billion by 2025, gaming’s growth is undeniable. It’s clear there’s space for something new.

Though blockchain gaming hasn’t quiet taken off yet the potential is huge and we finally have the tools to create fun, immersive games that guarantee transparency and true ownership.

Tools to get you started

fucory guillotine summoner

@FUCORY

Why you should consider using @latticexyz MUD in one sentence:

I bet 1 month of dark forest dev work is 2 days of MUD today

22

1:32 PM • Sep 8, 2024

While this isn’t a step-by-step guide, I want to highlight two tools that are worth exploring: MUD and Redstone. These tools simplify the development process and help turn ideas into on-chain games with less sleepless nights.

• MUD: an open-source framework designed to make building on-chain games on Ethereum easier. It simplifies the process of interacting with on-chain data, offering features like automatic indexing and standardized data models.

• Redstone: Layer 2 blockchain optimized for games. It reduces costs using off-chain data availability while ensuring integrity, making it ideal for high-throughput gaming environments

With blockchains, we can build Autonomous Worlds—systems that react, evolve, and function independently, free from external manipulation.

To get there we start with games. It’s clear that gaming is no longer just about playing—it’s about creating, owning, and earning through virtual spaces. Games offer a glimpse into how autonomous systems can function in real life. They serve as a testing ground for the mechanics and interactions that Autonomous Worlds will one day fully realize. Players can experiment with rules and economies, build communities, and understand the power of collective ownership.

With gaming already a huge part of people’s lives, the chance to create Autonomous Worlds is even more exciting. And as these worlds grow and develop, they could redefine how we interact, create, and connect in the digital space. 🌎

Games are cool, but Autonomous Worlds are where things get really interesting.

TLDR:

• Fragmentation limits blockchain ecosystems – Chains operate in isolation, leading to disconnected user experiences, fragmented assets, and isolated innovation.

• Interoperability is key – Developers need seamless communication between chains to move assets, data, and smart contract logic across networks.

• Hyperlane simplifies cross-chain messaging – Hyperlane enables permissionless, secure messaging between chains, allowing developers to build cross-chain apps without the complexity of setting up custom infrastructure.

The blockchain ecosystem is rapidly expanding with over hundreds of networks like Bitcoin, Ethereum, Solana, and many Layer-2s. But there’s a catch, each chain operates in isolation. For developers, this creates significant hurdles. Building on one chain doesn’t give access to users, assets on others, limiting the potential reach and usability of decentralized apps (dApps). In this fragmented landscape, cross-chain connectivity is critical.

This is where Hyperlane comes in. Hyperlane enables permissionless and secure cross-chain messaging, allowing developers to build apps that communicate across multiple chains without the need to create complex, custom infrastructure.

In this post, we’ll cover:

• The current state of the multi-chain ecosystem

• The need for permissionless interoperability

• How Hyperlane enables permissionless, secure communication between chains

By the end of this post, you’ll have a clear understanding of why cross-chain functionality is a game changer for blockchains and how Hyperlane empowers you to build dApps that seamlessly operate across multiple ecosystems.

The multi-chain world 🌍

Today’s blockchain landscape is filled with well-known layer-1s like Bitcoin, Ethereum, and Solana, each with its own architecture and goals. But scalability challenges remain, which is why Layer-2 solutions such as Ethereum rollups (Optimism, Base, and Arbitrum) have emerged, providing additional layers to improve the base network.

In addition, Rollups as a Service (RaaS) platforms now let developers create customized rollups in just minutes. This ease of customization gives rise to app-specific rollups and appchains, tailored to the unique needs of different projects.

However this growing variety also leads to fragmentation. A dApp or rollup built on one blockchain doesn’t automatically connect with users, assets, or liquidity on another. This creates several challenges for developers:

• Cross-Chain Messaging: Managing state and operations across multiple chains is a significant technical challenge. Existing cross-chain solutions often require developers to build complex, custom-built messaging frameworks to coordinate operations across chains. Without an easy way to send data, trigger function calls, or synchronize state between blockchains, building multi-chain dApps becomes a huge challenge.

• Isolated innovation: Apps built on one chain remain siloed from others, restricting their reach and limiting the potential for innovation and collaboration across ecosystems.

• Complicated User Experience: Developers are forced to build apps that require users to manage multiple wallets, interact with various bridges, and pay different transaction fees across chains. This friction significantly impacts adoption and usability, which directly impacts the app's success.

The need for interoperability

In a world with many blockchains, interoperability—the ability for blockchains to easily communicate with one another—is key to solving the problems caused by fragmentation. Interoperability allows developers to build applications where assets, data, and smart contracts interactions can move across chains.

With cross-chain interoperability, you can:

• Directly transfer assets from one blockchain to another

• Use data from one blockchain in an application on another

• Execute smart contracts across different networks

Simply put, the ability to connect multiple chains removes barriers and unlocks new possibilities for dApps.

The Evolution of Cross-Chain Communication: From Bridges to More

The initial solution to cross-chain problems was bridges—mechanisms designed to transfer tokens from one blockchain to another. As per latest data on DeFi Lama, USD 1.779 billion worth of crypto assets were transferred on bridges in just the last week.

Bridges traditionally follow a lock-and-mint model: assets are locked on the origin chain and an equivalent synthetic token is minted on the destination chain.

While bridges are effective for basic token transfers, they introduced several limitations:

• Complexity for Developers: Each bridge typically requires its own infrastructure and custom messaging system. This leads to added operational overhead and complexity.

• Centralization and Trust Assumptions: Many bridges rely on centralized validators to operate. These validators approve the transfers and relay messages between chains. This centralization introduces trust dependencies, as users must rely on the validators to accurately and securely process transactions. Moreover, adding new chains often required approval or partnership with bridge operators, leading to bottlenecks.

• Limited Functionality: Bridges are primarily designed for token transfers and struggle with more advanced cross-chain use*cases, such as smart contract interactions or data sharing. This limits developers who need more than just token transfers to scale dApps across chains.

Note: This is a high-level overview of bridges, and there are several variations of bridge designs, such as liquidity networks and atomic swaps, which aim to address some of these challenges. We're doing a short trip down the memory lane for this post, please bear that in mind.

Bridges to Interoperability Standards

After bridges, the industry moved toward interoperability protocols designed to overcome the limitations. These systems allowed for more flexible cross-chain messaging and smart contract interactions.

However these solutions often remained permissioned.

They rely on a set of trusted validators or operators to facilitate communication between blockchains. Developers who want to build cross-chain apps still have to work within the framework of these validators, introducing new trust dependencies and reliance on external parties. In many cases, adding a new chain to the system requires approval or even a formal partnership with the framework's operators. This approval process can create bottlenecks, as developers may need to negotiate terms or wait for the framework to support their desired chain.

While these traditional interoperability solutions represent significant improvements over bridges they remain centralized and permissioned, limiting the full potential of cross-chain scalability.

What we really need: Permissionless Cross-Chain Interoperability

What's truly needed is a way to connect chains without the bottlenecks created by centralized or permissioned systems. Permissionless interoperability allows any blockchain to communicate with another, without requiring approvals or relying on centralized intermediaries or validators.

Hyperlane is designed to provide exactly this type of permissionless interoperability. It enables developers to connect chains, run their own infrastructure, and build across ecosystems.

With Hyperlane’s permissionless interoperability, you get several benefits, including:

• No approval required: Developers don’t have to wait for central entities to add new chains or set up new connections. They can do it themselves.

• Run your own operators: Instead of relying on a fixed validator/agent set chosen by a third party, developers can operate their own validators, reducing reliance on centralized trust.

• More flexibility: Developers can build apps that connect seamlessly across multiple chains, with full control over how data and assets flow between them.

This decentralized approach mirrors how anyone can deploy a smart contract on Ethereum without needing permission. Hyperlane removes the complexity and restrictions, allowing developers to build cross-chain applications with less friction and more scalability.

Now, let's take a deeper look at Hyperlane, How it works under hood and what cross-chain communication with Hyperlane looks like.

Hyperlane: A Solution for Blockchain Interoperability

Hyperlane is a protocol for secure, permissionless communication between different blockchains, allowing developers to build apps that work seamlessly across multiple chains.

Why should you care?

Hyperlane simplifies cross-chain messaging by providing a streamlined, secure framework for transfering data and assets between chains. This eliminates the need for complex, custom solutions and accelerates the development of cross-chain apps.

With Hyperlane’s messaging capabilities, developers can:

• Transfer Assets: Move tokens across chains with ease.

• Share Data: Seamlessly use information from one chain in applications on another.

• Execute Smart Contracts: Enable contract interactions across multiple networks without added complexity.

What sets Hyperlane apart is that it’s fully permissionless, allowing anyone to add their own chain and operate the entire infrastructure themselves. This gives them full control over cross-chain communication, removing bottlenecks and ensures scalability.

Let’s take a closer look at how this works by exploring the key components of Hyperlane.

How Hyperlane Works: The Key Components

Let’s break down the 3 main components to understand how the protocol works:

Mailbox Contracts

Mailbox Contracts are smart contracts deployed on each blockchain that manage the sending, receiving, and processing of cross-chain messages. They serve as an entry and exit point for messages. A key feature is their permissionless nature - anyone can deploy a Mailbox. This enables developers to integrate cross-chain communication into their dApps without needing approval or access, ensuring a decentralized, open system for messaging between blockchains.

Agents: Validators & Relayers

• Validators: In Hyperlane, validators help secure cross-chain messaging by signing checkpoints (Merkle roots) when new messages are sent from the Mailbox. These signatures let Relayers deliver messages to other chains. Hyperlane’s validator set is open– anyone can become a validator if they are included in the Multisig ISM specified by the receiving chain's contract.

• Relayers: Relayers are off-chain actors responsible for transporting messages between chains. They pick up the message from one chain’s Mailbox contract and deliver it to another.

Interchain Security Module (ISM)

The Interchain Security Module (ISM) is a customizable security framework that verifies cross-chain messages. Think of ISMs as security Lego blocks—each one is a smart contract that can be mixed and matched based on your app’s security requirements.

For instance:

• Multisig ISM: Specifies which validators must agree to validate a message.

• Routing ISM: Adjusts security settings based on message type or content.

• Optimistic ISM: Adds a delay in message verification for more security.

With ISMs, you can configure and combine these blocks to create a tailored security framework.

Putting it all together

When a cross-chain message is sent using Hyperlane, it starts at the origin chain’s Mailbox Contract, which packages the message. Validators then sign off, verifying its legitimacy, and Relayers transport it to the destination chain’s Mailbox. Once the message arrives, the Interchain Security Module (ISM) ensures that the message is properly verified and processed.

Each of these components—Mailbox, Validators, Relayers, and ISM—work together to enable secure, permissionless communication between blockchains.

This process allows developers to send assets, share data, and interact with smart contracts across multiple networks, all while maintaining control over the infrastructure.

End.

As blockchains grow cross-chain applications will become essential for unlocking the full potential of decentralized technologies. Hyperlane makes it easy for developers to build cross-chain apps, without the complexities of custom infrastructure or needing permission.

On another post, we’ll dive deeper into the protocol’s inner workings and explain how messages and assets are transferred between chains. If you have any questions, feel free to reach out to me!

See you on the next one! 👋

(Fun fact: The banner features a photo of the Sombrero Galaxy, one of the cutest spiral galaxies, named for its resemblance to a Mexican hat. )

Two years ago, the concept of restaking was relatively unknown. At ETHCC this year, two separate restaking events were held on the same day. It's fair to say that its become one of the most popular areas in crypto right now. So, this is another blog post to clarify the new concept introduced by restaking: Actively Validated Services (AVSs).

This post will provide an overview of the EigenLayer Actively Validated Service (AVS) ecosystem, now the largest & most popular restaking ecosystem.

It's not a deep dive into a specific application but rather an introduction to what an AVS even is & what people are building.

Introduction

If this is your first post on EigenLayer, I recommend you hop onto this post first to learn about how it works.

In simple terms, EigenLayer builds on Ethereum by introducing a new way to use staked ETH for additional tasks.

Its core concept is to utilize Ethereum's established economic trust as a foundation for building infrastructure components called Actively Validated Services(AVS). In doing so, EigenLayer redefines bootstrapping for Proof of Stake (PoS) networks.

Let’s look at the key players & their roles before getting into the services that can be built on EigenLayer. Participants and Roles

• Stakers: Individuals who commit their ETH to support new networks and services. They can operate independently (Native Restaking) or delegate their ETH to operators (Liquid Restaking).

• Operators: Participants who manage technical and operational aspects of new networks/services. They are compensated through the rewards generated by their activities. To ensure trust and integrity, operators risk penalties (slashing) if they engage in misconduct.

• **Actively Validated Services (AVS): **The services and networks that require dedicated validation and operational efforts. They are not necessarily consumer applications, but instead services that the consumer apps may require.

I want to add another participant, which is the service consumer.

• Service Consumers: Applications and/or users that utilize the services provided by AVSs.

An AVS comprises a set of offchain container(s) + onchain smart contract(s).

To categorize AVSs, I've found this article from Coinbase very helpful. I'll follow a similar categorization with some tweaks.

Let's break down the main categories of services/networks being built on EigenLayer as the following:

• Rollup Services: Services that rollups (layer 2 scaling solutions) utilize.

  • E.g.: data availability layers, bridges, and shared sequencers.

• Decentralized Networks: Services that require a distributed set of validators.

  • E.g.: oracles and decentralized physical infrastructure networks (DePin).

• Privacy: Privacy-preserving tools/services.

  • E.g.: Zero-knowledge (ZK) coprocessors and Trusted Execution Environments (TEEs).

Before discussing these networks/services, it's important to once again clarify EigenLayer's role. With EigenLayer, a new service does not have to create a whole new network effect but instead can ask Ethereum stakers for capital and Ethereum validators to run the services.

Let’s add one more category where EigenLayer has a different role.

• Developer & Operator Tools: Developer tools are the tools that help build an AVS, and the operator services help run the operator software.

  • E.g.: developer tools and frameworks and operator services for managing node infrastructure and validator tasks.

Now let's get into each of these services/networks and talk about the projects that are currently building them.

RollUp Services

These are the services that the rollups (layer2 scaling solutions) can utilize.

Although we can add them to the decentralized networks category, having separate rollup services for the most common services can help us quickly identify rollup needs.

1. Data Availability

• What is it?

  • A Data Availability (DA) Layer ensures that all transaction data on a blockchain is stored, accessible, and can be independently verified.

• Why does it matter?

  • Blockchains have limitations in handling large volumes of data and transactions per second. Maintaining this data on-chain without compromising performance is challenging as the network grows. Along with the scalability challenges, storing all data on the blockchain is expensive. Each node in the network must store and process this data, leading to high operational costs and slower network performance. By offloading data storage to a separate DA layer, the Layer1 blockchain can focus on consensus and transaction processing, enabling higher transaction throughput and better scalability.

• Who is building DA layers on EigenLayer?

  • EigenDA: the first AVS (built by EigenLabs), they already have networks building on top of it, including MegaETH, Abstract Chain, Layer N, Movement Labs, Celo, Mantle , Versatus, Cyber & more.

2. Shared Sequencing (aka Decentralised Sequencing)

• What is it?

  • Shared Sequencing organizes transactions in a specific order across different layers or applications.

• Why does it matter?

  • Unlike traditional Sequencing, which is handled by each network individually, shared Sequencing coordinates transaction ordering across different layers and applications to maintain consistency and avoids having a central point that determines the ordering.

• Who is building Shared Sequencing?

  • Project(s): Espresso Systems, Radius, Zellular

3. Interoperability Layers

• What is it?

  • Interoperability layers enable different blockchains to communicate and work together. They facilitate data transfer and assets across various networks, ensuring that different systems can interact and share resources.

• Why does it matter?

  • These layers enable sharing resources, such as data and assets, across multiple blockchains. Interoperability layers open new possibilities for decentralized applications that can leverage multiple blockchain networks by allowing blockchains to interact.

• Who is building Interoperability Layers?

  • Project(s): Omni, Hyperlane, Polyhedra, Gasp

4. Roll-up-as-a-service (RaaS)

• What is it?

  • Rollup-as-a-Service (RaaS) enables developers to create and deploy rollups.

• Why does it matter?

  • Rollups significantly increase the transaction throughput of blockchain networks by processing multiple transactions off-chain and then batching them together. By reducing the amount of data processed on-chain, rollups also lower transaction costs for users and developers. A RaaS makes it very easy to create and deploy a rollup.

• Who is building RaaS?

  • Project(s): Altlayer, Conduit, Caldera

Let's make the RaaS offering more tangible by looking at Conduit's interface. As you can see from the screenshot below, I can build a stack (with an option to use EigenDA) and then deploy my rollup, which would take approximately 15 minutes!

At this point, it's important to mention Restaked rollups. These are rollups that depend on one or more AVSs built on EigenLayer.

Here’s a good post to read more about RaaS.

Decentralized Networks

These are services/networks that require a distributed set of validators. By having multiple validators, networks ensure that no single entity controls the entire system. This reduces the risk of malicious activities and ensures the network remains secure and neutral.

Let’s bring some clarity to what some of these services are.

1. Oracles

• What is it?

  • Oracles are services that bring external data into the blockchain for use in smart contracts. They bridge the blockchain and the outside world, providing information such as price feeds, weather data, and other real-world events.

• Why does it matter?

  • Accurate and timely data is essential for the correct execution of smart contracts. For example, when you make a swap, you want the correct exchange rate at the time of the swap.

• Who is building Oracles?

  • Project(s): Eoracle

    • Eoracle is already live on eigenlayer with over 100 operators.

2. DePin (Decentralized Physical Infrastructure Networks)

• What is it?

  • DePin connects physical devices to the blockchain for managing and operating  the devices. This includes Internet of Things (IoT) devices, sensors, and other physical infrastructure components that require autonomous operations, and in many cases uninterrupted connectivity.

• Why does it matter?

  • DePin enables new use cases and applications by integrating physical infrastructure with blockchain, such as smart cities and pet collars.

• Who is building DePin networks?

  • Project(s): OpenLayer, Witness Chain

Privacy

Privacy-preserving technologies need their own category. These are services that provide different privacy tools for blockchain networks.

Let's look at some of the examples.

1. ZK (Zero-Knowledge) coprocessors

• What is it?

  • Zero-Knowledge (ZK) proofs is a cryptographic method that allows data to be verified without revealing the data itself. In other words, they enable one party to prove to another that a statement is true without disclosing any underlying information.

• Why does it matter?

  • ZK proofs protect sensitive information by proving the validity of data without exposing it. They also minimize the amount of data shared, reducing potential attack vectors. Another important property is the scalability aspect; ZK proofs can improve efficiency by streamlining the verification process. (ZKP is a huge topic, and you should read my blog post over here to continue.)

• Who is building ZK coprocessors?

  • Project(s): Brevis, Lagrange

2. TEE (Trusted Execution Environments)

• What is it?

  • Trusted Execution Environments (TEEs) provide isolated environments within a device where sensitive data can be processed securely.

• Why does it matter?

  • TEEs and encryption protect sensitive information, ensuring that it remains secure and unaltered during processing and storage.

• Who is building TEE & Encryption services?

  • Project(s): Automata

3. FHE (Fully Homomorphic Encryption) coprocessors

• What is it?

  • FHE (Fully Homomorphic Encryption) coprocessors are specialized processors that handle confidential computations off-chain. They ensure that data remains encrypted and private during processing.

• Why does it matter?

  • They provide secure computation over encrypted data, ensuring that sensitive information remains private. Additionally, offloading computational tasks from the L1 blockchain to dedicated coprocessors improves transaction processing speed and overall network performance.

• Who is building FHE coprocessors?

  • Project(s): Fhenix

Services for AVS Builders: Developer & Operator Tools

This section is about the tools that are required for building AVSs.

1. Developer Tools and Frameworks

Building an AVS involves many steps, some of which are the same for many. Developer tools and frameworks are resources that simplify the process of building AVSs by creating components that can be used for building.

These tools simplify the development process by providing pre-built components and standardized workflows, making it easier and faster for developers to build complex applications.

Othentic is building a framework for developers to streamline the development of AVSs.

2. Operators & Operator Services

Operators in EigenLayer are responsible for the technical operations of AVSs.

Operating an AVS requires more specialized skills than running a standard Ethereum node. Unlike Ethereum validators, who validate transactions and blocks, operators manage specific tasks within AVS, including additional functionalities like data handling or cross-chain services.

Remember that operators potentially face higher rewards and risks due to the specialized nature of the services they manage, including potentially higher rewards, higher stakes, and more slashing conditions.

As the name indicates - operator services help operators manage their node infrastructure, validator tasks, and/or staking operations.

The operator landscape is one of its own; we will not be getting into it for this article. If you've made it this far - you're probably pretty curious, so I definitely want to leave you with some resources to learn more:

• Eigenlayer Operators

• Eth Restakers

Conclusion

By leveraging Ethereum's security, EigenLayer enables the launch and operation of Actively Validated Services (AVS) such as data availability layers, decentralized networks, and privacy tools. This simplifies development, accelerates innovation and reduces entry barriers for new projects, similar to how cloud services transformed app development. Just as the cloud became a fundamental layer for modern internet applications, EigenLayer aims to become a foundation for decentralized (aka web3) services.

EigenLayer is giving me a lot to write about. It’s been a few weeks since they released their token whitepaper, EIGEN The Universal Intersubjective Work Token, which introduces many new ideas.

Yes - I’ve read the 43 page whitepaper, hopefully it will make your life easier (and give me some interesting dinner conversation topics).

In this post, I aim to answer the following:

• Background info: What is EigenLayer & what innovations does it introduce?

• What’s the EIGEN token and its core features, what are intersubjectively attributable faults and how does the EIGEN token work?

• What are the potential risks & open questions for EigenLayer?

Before we get started, please note that this post builds on the concepts previously introduced in EigenLayer. If this is your first time exploring EigenLayer, I recommend starting here. You'll also find some terminology at the end of this post.

Background: Staking, Infrastructure level innovation & EigenLayer

Blockchains offer a new way to coordinate with distinct participants through an open and verifiable system, secured with cryptographic methods.

Understanding Staking in Ethereum

Let's take a look at Ethereum's staking mechanism to understand how blockchains work.

First – validators are key in maintaining the Ethereum network. They are responsible for verifying transactions, proposing new blocks, and ensuring the security and accuracy of the blockchain. To become a validator, users need to lock up their ETH, this process is called staking. If validators act dishonestly, they can lose their staked ETH through a penalty process called slashing.

The system of staking and slashing ensures that validators have financial reasons to act honestly. This encourages everyone to play fair and keeps the network secure for all users.

The Need for Enhanced Blockchain Services

Ethereum has its limitations when it comes to innovating beyond the application layer. Although Ethereum enables programmability at the application layer, it doesn't extend that flexibility to other underlying infrastructure components. There are still challenges when it comes to creating new blockchain services, such as oracles, bridges, and data availability layers.

These services require substantial resources and capital.

• Resource Issue: Building a new network from scratch requires attracting a sufficient number of validators/operators to ensure the network’s security and functionality. This can be slow and expensive.

• Capital Issue: New services often create their own tokens to bootstrap the network which requires significant investments, marketing, and time to establish value and utility. Additionally navigating the regulatory landscape for new tokens can be complex and costly.

High-level overview: Introducing EigenLayer

This is where EigenLayer comes in.

EigenLayer builds on Ethereum's model by introducing a new way to use staked ETH to run additional services. It does this through a mechanism called restaking. Restaking allows the same ETH that is staked for Ethereum to be used for other purposes.

With this mechanism, stakers can run new services that provide them with additional benefits, and developers can create innovative services without the need to bootstrap a separate network.

Let’s remember the different roles in the EigenLayer ecosystem: Stakers, Node Operators and AVS’s.

• Stakers: People who lock up their ETH to support new networks and services. They can participate in two ways: Native Restaking & Liquid Restaking.

• Node Operators (aka Native restakers): These individuals manage and run the software for services built on EigenLayer. Misconduct by operators can lead to a loss of staked ETH (aka slashing), keeping participants accountable.

• Actively Validated Services (AVS): The networks & services that are run by operators. E.g.: data availability layers, decentralized sequencers, oracles.

Simply put, EigenLayer expands Ethereum's existing security infrastructure (validator set + staked capital), allowing developers to deploy new services which can leverage this.

• By using staked ETH, EigenLayer provides new services with immediate economic security. This reduces the barrier to entry for new services.

• Stakers can earn more by restaking their assets in multiple services.

🌟 Checkout this cool dashboard for EigenLayer metrics.

Deep dive: Faults in Digital Services, Intersubjective EIGEN Token & Forking

Introduction

Okay so first off, I didn’t know what intersubjective meant before this.

The main question EigenLayer is trying to answer is can we have a system where we extend the cryptoeconomic security for digital tasks to intersubjective faults.

We’ll take it one step at a time. First - for this to make sense we first need to distinguish faults in digital services.

Faults in Digital Services

Let’s categorize faults in digital tasks based on how they are identified. The 3 main categories are:

1. Objectively Attributable Faults: These faults can be clearly identified using mathematical and cryptographic methods without the need for external opinions. E.g: double-signing a block can be proven on-chain using cryptographic evidence.

2. Intersubjectively Attributable Faults: These faults require wide agreement among observers outside the chain to determine correctness - they involve more complex scenarios where human judgment is necessary. E.g: oracle price discrepancies.

3. Non-Attributable Faults: These faults cannot be externally verified or attributed. E.g:, in a secret-sharing system, if nodes come together to reveal a secret, it is hard to distinguish between a malicious system and a malicious storer of the secret.

Key Points:

• Objectively Attributable Faults: Easy to prove and resolve on-chain.

• Intersubjectively Attributable Faults: Require broader agreement among observers.

• Non-Attributable Faults: Difficult to resolve due to the lack of external verifiability.

Focus on Intersubjective Faults in Digital Tasks

EigenLayer introduces the EIGEN token to address intersubjectively attributable faults.

Why intersubjectively attributable faults? Well because objectively attributable faults are limited to issues that can be proven with mathematical and cryptographic certainty. However, advanced blockchain applications often involve intersubjective assessments. For example, an oracle providing external data like market prices.

By addressing intersubjectively attributable faults, EigenLayer aims to expand the security and reliability of Ethereum to a wider range of services. This ultimately broadens the types of tasks and applications that can be managed on the blockchain.

Restaking ETH.  Any task with an objectively attributable fault can be resolved onchain by integrating its dispute resolution mechanism within Ethereum’s chain validity through smart contracts. EigenLayer employs this property to restake ETH and expand the scope of staked ETH to secure Actively Validated Services (AVSs) with objectively attributable faults.

Staking with EIGEN. The new EIGEN token introduces a complementary mechanism that is designed to specifically address “intersubjective” faults – faults that are not possible to address via ETH restaking alone. - EigenLayer Blog

This makes the EIGEN token universal—it can be used across various digital tasks, not limited to a single purpose.

👉 Bringing it together: In the context of the EIGEN token, intersubjective is used to describe faults (or verifications) that would have wide agreement among humans who are observing from outside the chain rather than being objectively verifiable through code.

Core Ideas & Features

There are 3 core ideas to to address intersubjective faults on EigenLayer:

• Setup and Execution Phase (aka Two phase of intersubjective agreement): Rules for coordination are agreed upon at an initial setup phase. (There are limitations on the rules so that the rules are self-verifiable, in other words there is no need for humans to come together and decide for each fault.)

• Slashing: If a participant doesn’t follow the rules they lose their stake.

• Token Forking: Mechanism to handle disputes in the system without altering the Ethereum blockchain. (Not self-explanatory - I’ll explain more on this below)

These design choices make it so that the EIGEN token can have the following 4 properties:

1. Universality: The token isn't limited to a single purpose but can support various services. It is designed in its Setup phase to fork-and-slash for intersubjective faults.

2. Isolation: The token maintains the ability to be used in apps that are not aware of the token's forking mechanism (more on this below).

3. Metering: Resolving faults have a cost. Metering in this context means keeping track of the costs involved in reaching agreements (Eg: rejecting a malicious fork, switching from one token to another). It ensures that resources (time + computational power) used to reach social consensus are properly accounted for.

4. Compensation: When faults occur that affect users, the system can slash and redistribute the stake back to the AVS users, ensuring fairness and accountability.

Overloading Ethereum Consensus & Token Forking

A very important risk of EigenLayer is the potential to overload Ethereum’s social consensus if not designed properly.

But what does it even mean to overload Ethereum social consensus?

Using the same capital to secure both Ethereum and a potentially malicious AVS can put all the funds at risk. If a large number of participants are affected, it could lead to substantial losses and may require intervention from Ethereum’s social consensus.

EigenLayer addresses this through a token forking mechanism, isolating the resolution of intersubjective faults from Ethereum’s core network. With this mechanism only staking activities and their associated disputes affect EigenLayer, while Ethereum remains focused on its core objective consensus tasks.

Applications using EIGEN for non-staking purposes are also isolated from the complexities of token forking because there is a separate token for such activities. These apps can be used without needing to be aware of any underlying forks.

Two-Token System: EIGEN & bEigen

In the EigenLayer network, tokens are utilized for various purposes: staking and non-staking use-cases like DeFi.

To clearly differentiate between the uses and manage dispute resolution EigenLayer has a two-token mechanism.

• bEIGEN (Backing EIGEN):

  • This is the primary staking token. Users lock up their ETH as bEIGEN, which is then used to secure various services within EigenLayer. The bEIGEN token is directly involved in staking and subject to slashing.

  • When a fault is detected, the bEIGEN token can be forked to create a new version (e.g., bEIGEN1 to bEIGEN2).

• EIGEN

  • This token is used for non-staking activities, e.g.: DeFi.

The main reason for having two token model is to isolate the impact of any forking in the bEIGEN token from non-staking applications - aka the Isolation feature.

The important follow-up question here is: Which bEIGEN will be backed? In determining which bEIGEN will be backed, there are 3 designs (v1, v2, v3) that focus on governance and upgradability, aiming to enhance security with each upgrade. In v1, governance decides which bEIGEN to back. In v2, the governance feature is removed, making the contract immutable. In v3, additional protections are added to prevent any potential corruption by the Security Council. (Read more on this: section 2.7.1.)

Risks & Open Questions

• Implementation Challenges: EigenLayer is still in its early stages, and much of the current work is experimental and theoretical. There’s a lot of work to be done to implement the system. Especially, managing the forking mechanism with numerous AVS could become increasingly complex.

• Impact on Home-Stakers: The introduction of AVS could influence the decision to become a home-staker.

  • With high off-chain requirements home stakers might not be able to run all the AVS’s and they could potentially get more advantages when they delegate instead, worth noting that there could also be additional benefits introduced for home-stakers.

• Increased Operator Workload: Operators will face a greater workload and have more decisions to make. Keeping Ethereum clients up to date becomes even more critical, adding to the operational burden.

• Operator Centralization: If there are high off-chain requirements for operators, this could lead to a concentration of resources and expertise among a limited group of operators.

• Fairness among Operators: operators can opt into various services, each offering different potential rewards. This setup could significantly alter the current "fair" reward system in Ethereum, where each node earns a similar annual percentage rate for staking ETH. The varied reward structures might incentivize operators to focus on maximizing returns, making it hard to maintain a balanced and fair environment for all network validators.

• Smart Contract Risk: Hacks or implementations design issues in the AVS’s.  Given these uncertainties and challenges, it’s important to monitor the development and follow up closely.

End.

EigenLayer is an important development for Ethereum, allowing staked ETH to be used for new services and applications. The two-token model separates staking activities from other uses like DeFi, enhancing robustness against malicious actions. This separation ensures that staking can continue while allowing EIGEN tokens to be used in various non-staking applications. By having an internal forking framework for handling complex disputes, EigenLayer helps keep the Ethereum network secure from issues that may rise within AVS ecosystems.

That’s all for today.

If you have any questions or comments please feel free to reach out to me, I’d love to hear! See you on the next one! 👋

Glossary

• Actively Validated Services (AVS): Services on EigenLayer that require active validation from participants via restaking.

• Crypto-economic Security: The combination of cryptographic techniques and economic incentives to secure digital tasks. This involves mechanisms like staking, slashing, and consensus to maintain system integrity and trustworthiness.

• Forking Token: A token that can split into multiple versions in response to disagreements or disputes. The forking process creates two versions of the token, each representing different interpretations or outcomes. Stakeholders choose which version to support.

• Intersubjective Faults: In blockchain networks, faults can be verified objectively (e.g., double-signing, invalid state transitions) or require human consensus to verify (intersubjective faults). Intersubjective faults cannot be objectively verified on-chain and need broad agreement from multiple parties to determine correctness.

• Liquid Restaking: Stakers delegate their ETH to operators. They provide only financial support  and leave it to the operators to handle technical requirements.

• Native Restaking: Stakers independently contribute tokens and operate a validator node.

• Operator: A participant in EigenLayer who runs validation services for AVSs

• Slashing: A mechanism where stakers lose their tokens if they fail to meet their commitments or act maliciously. Slashing ensures accountability and enhances security by penalizing non-compliant behavior.

• Staker: A participant who stakes their ETH, to support the network and earn rewards. They can choose to become solo-stakers or delegate to operators.

• Staking and Restaking: Traditional proof-of-stake systems, like Ethereum, require participants to stake tokens (ETH) to secure the network. EigenLayer builds on this by allowing ETH to be re-staked for additional tasks. This means that the same staked ETH can be used to secure various services beyond just the Ethereum network.

• Work Token: A type of token that needs to be staked (locked up) to perform certain tasks or work within a blockchain network. It serves as both a requirement for participation and a form of collateral that can be slashed if the work is not performed correctly. Here’s a great post that explains work tokens.

• The dominance of social media by a few large companies limits innovation and competition.

• Decentralized social media introduces a shift towards open protocols not owned by a single company. This enables users to directly connect with their audience. For developers, it simplifies creating new experiences by using shared data, eliminating the challenge of building a user base from scratch.

• Farcaster has taken the crypto world by storm with its new feature 'frames', allowing developers to create interactive experiences directly within posts.

An average internet user spends almost 2.5 hours daily on social media, a significant portion of their day dedicated to just a few platforms. 🤯 These platforms shape what we see, create the consumer apps we use, and influence how we interact.

The dominance of a few tech giants presents a significant challenge for new competitors. Whenever there's an app that's likely to succeed, they can replicate the features or acquire the app. This introduces a high barrier to entry for new social media apps. Innovation is limited. Users have just a handful of options.

This is where a new idea called decentralized social media, or web3/crypto social, comes in. It's a new type of social media that doesn't rely on one company to run everything. Instead, it lets users have a direct relationship with their connections — by keeping this data directly on the protocol layer. This means anyone can make new apps without having to build a whole new network from scratch. By lowering the barriers to entry for new social media applications, we could see a surge in innovative ideas and benefits for users.

In this post, I aim to answer the following:

• Why today's social media is failing us?

• What's the promise of web3 social?

• What's Farcaster, Warpcaster & Frames?

Social Media Today: its all just tech giants

The “typical” internet user spends almost 2½ hours each day using social media platforms, equating to more than one-third of our total online time. - DataReportal

Taking into account the time we spend on social media, you'd think there would be more options for users, more opportunities for developers, and more excitement about building new social experiences.

Yet, this is not the case. There is very limited competition and innovation in the social media space.

This is primarily due to the dominance of the top social media companies, which have reached such massive audiences that competing against them has become nearly impossible. A new app needs a lot of users to be successful, and before it can get there, giants like Facebook or TikTok can just copy its features.

For what it's worth, social media apps have served us pretty well in the last few years. The platforms are easy to use, creators can reach vast audiences, people can create online businesses and much more. I can easily connect with my family halfway across the world, order the yoga mat I see from my favourite influencer, slide into the DM's of founders, send newsletters to my internet friends, etc.

However, centralized social networks have significant control over how users engage with their audience. There are many restrictions on what users can do and what developers can build.

So, if you're not happy with the social media apps, can't you just build a new one? Well, it's not that simple.

Getting a social app to be successful requires bootstrapping a large user base — a daunting task. Suppose a new app comes out and has features that gets interest. In that case, tech giants can copy the features, and with their resources, they can probably do it even better. Some social media apps indeed let developers use their tools. However, these companies still hold all the control and can change the rules anytime.

Let’s talk about a few concrete examples on this topic.

A trip down the memory lane

There once was a world with Open Twitter APIs

In the early days of Twitter, the company provided open access to its APIs, allowing developers to build 3rd party apps that interacted with Twitter's platform. This openness led to many innovative tools.

But over time, Twitter changed its strategy. By 2018, it shut down several key APIs, including ones that were commonly used; the apps built on top of these APIs were now out of business.

Although there have been some limited APIs, access continues to change, with APIs being deprecated and changes being made.

One can imagine the challenges of building on top of a corporate network.

What happened to Clubhouse?

During the peak of covid lockdowns, I spent a lot of time on Clubhouse, the social media app where you can join live conversations.

Launched in March 2020, Clubhouse created a huge hype. As it became more popular, other big social media apps developed similar features. For example, Twitter came out with Twitter Spaces.

Clubhouse struggled to keep up. The growth slowed down as competitors introduced similar features (additionally, concerns regarding privacy and content moderation arose in Clubhouse).

Goodbye Clubhouse, Hello Twitter Spaces.

Clubhouse is one example of feature replication. Another notable one is Stories. Snapchat came out with stories, and then so did Instagram. Funnily, it has become the killer feature of Instagram.

As Kurt Wagner put it:

TwoTwo years ago, Instagram did something that felt a little desperate: It copied the best product from a direct competitor, and even gave it the same name. Snapchat Stories were suddenly Instagram Stories.

Remember Vine?

Vine was a short-form video app where users could share 6-second video clips — like TikTok does now.

Though it got a lot attention in the beginning, Vine was unable to keep its creators and struggled to keep up with its competitors.

Vine also faced opposition from other social media apps. For instance, Facebook banned certain Vine features from its platform. One example of a common pattern for large tech companies.

In October 2016, Twitter (which owned Vine) shut it down. This decision was made due to various factors, most notably increasing competition and monetization issues.

Many Vine creators had to transition to other platforms. Imagine the frustration of having to start over and rebuild your audience on a new platform.

Perhaps Elon will bring back Vine?

The problem with social media today.

In summary:

• Even with open APIs, corporate companies can change or remove access at any time.

• The dominance of a few major companies in the social media space limits competition and innovation. They can develop in-house solutions or acquire potential competitors.

• Users are bound to the platform they use and have only a few choices. If a platform changes or shuts down, they could lose everything they've built. This is particularly constraining for creators who rely on these platforms.

The common theme across these events shows the downsides of siloed and private social networks.

Now, the question arises: Can decentralized networks improve social media?

A new type of Social Media

Over the past year, decentralized social media has been one of the most exciting topics in crypto — also known as "web3/crypto social."

Decentralized social media operates on a foundation of open protocols. These protocols are the building blocks, allowing anyone to utilize the social data to create new applications. It's a move from a few big companies in charge to a system where users and developers have more power, leading to new online experiences and experimentation.

This approach to social media comes with 2 big promises:

1. For Developers: It's easier to create new social media platforms. They don't have to start from scratch to gather users.

2. For Users: They get a direct connection with their audience. They're not stuck to just one app and can pick an app that best meets their needs.

How Does It Work?

Unlike traditional social media, which keeps user and relationship data (also known as the social graph) in one central place, decentralized social media keeps this information on the protocol, accessible to everyone.

What does this mean as a user?

Well, users have more options.

• If you don't like how one app works, for example, shows your feed, you can switch to another. Regardless of the app you're using, you'll have the same account and connections.

• For content creators, there might be more ways to make money and connect with your audience — like micropayments, token rewards, and creating exclusive experiences. You may get new chances to earn from your content, even if you're not a big influencer.

• Since there's no single company in charge, it's less likely that posts or users will be unfairly removed or blocked. (While apps built on this platform can set rules, the underlying system remains open and fair.)

In general, one might do more with social media apps. New exciting and engaging experiences can emerge.

Developer Innovation: Devs do something

Developers can build new apps without having to bootstrap a network or depend on a single company's tools.

• For instance, imagine a developer creating an app for people interested in learning new languages, similar to Duolingo, but with your existing social connections. This app could help you find friends in other countries if you plan to travel and learn a new language.

• Or consider another developer who makes an app for pet lovers. This platform could let pet owners connect and plan meetups. The app can utilize existing connections to show which friends have pets and who can pet-sit while you're away.

Full disclosure: I certainly might not be the most creative person, but I hope the potential of these developer innovations shines through clearly.

There are some teams working on building this new foundation of social media. Most notable Lens Protocol and Farcaster. I've talked about both before; today, I want to once again focus on Farcaster as there have been many updates and new features.

Farcaster, Warpcaster & Frames

Farcaster: A New Take on Social Media

Farcaster is a decentralized social network built on Ethereum. It provides the foundation (a protocol) for building a social graph.

Anyone can make their own apps, called "clients," using shared information from Farcaster. Your personal info and connections become portable and can easily be moved with you from one app to another.

This approach removes the limitations of traditional social networks, giving developers the freedom to try out new ideas and features. For example, if you don't like how your feed looks on one app, you can make a new version.

Btw: I'm on Farcaster, quite enjoying it, posting my unhinged thoughts and food pictures.

How does it work?

Farcaster has a hybrid architecture with both on-chain and off-chain components.

The Farcaster contracts are deployed onto the OP Mainnet. These are used for account creation, keeping track of signing keys and paying for storage.

Most of what you do on Farcaster, like posting messages, following users, liking posts, or changing your profile picture, happens off-chain. Doing things off-chain makes Farcaster faster and cheaper to use.

What about Warpcaster?

Warpcaster (formerly also called Farcaster) is an app (aka client) made by the Farcaster team. It's a Twitter-like app.

The Farcaster team controls Warpcaster; they decide what's allowed and how things work.

However, the big difference is if you're not happy with Warpcaster, you can simply go ahead and build your own app. A new app built on top of the protocol will not require sign-ups or ask users to connect with their friends again - this information is portable.

Ok finally - what are Frames?

Farcaster recently introduced something called Frames, and people are very excited about it. Frames are interactive apps inside your posts (called casts).

Frames extend the OpenGraph standard by turning casts into interactive experiences. Initially introduced by Facebook, OpenGraph is a standard for metadata used in web pages to ensure the content is accurately represented when shared or embedded on social platforms.

With Frames, developers can create new experiences for social media users. Users can do everything they want in one place instead of using many different apps, and they work in all Farcaster apps, not just Warpcaster.

For example, someone made a Frame to buy Girl Scout cookies - maybe the most successful Girl Scout ever?

Another developer made a Frame to play Doom.

Conclusion.

Decentralized social media aims to create open protocols for social networks rather than have corporate platforms. This way, users have a direct relationship with their audience. This allows developers to build new apps on top of the shared social data = which boosts innovation.

Also, for what it's worth, the fact that Twitter turned out to become a company rather than a protocol seems to be haunting Jack Dorsey.

I can go on, but this is a blog post, not a book. On my next post, I'll get more into Farcaster! If you have any questions or feedback, please feel free to reach out - I'd love to hear from you. 🙂

Last week, together with Carlos and Shiv, we participated in ETHGlobal’s LFGHO hackathon. As someone who still considers herself a newbie in DeFi, I've learned a ton. This post is a product of last week's efforts, containing all the information I learned about GHO and building with Aave – a developer's introduction to building in DeFi.

In this post, I aim to answer the following:

• What's Aave & GHO?

• How does GHO work? Why is it different from other stablecoins?

• How to get started building with GHO - hands on 🙂

Don’t worry if you don’t know anything about DeFi, Aave or GHO yet. I’ll be introducing all the concepts from ground 0.

Non-technical Intro to Defi, Aave & GHO

DeFi Primer

DeFi (Decentralized Finance), refers to a range of financial services available on public blockchains. It allows users to lend, borrow, trade, and earn interest on their assets without the need for traditional financial intermediaries like banks. DeFi relies on smart contracts that don't require intermediaries to execute. This makes financial transactions more direct and accessible to anyone with an internet connection.

I know many people who started trading crypto, or opted-in to receive crypto payments because of the issues they faced in their traditional banking systems. DeFi offers an alternative to traditional banking institutions by providing more accessible financial tools that are open to anyone with internet access. This openness can democratize access to financial services. However, it's also super important to recognize the regulatory challenges and risks associated with crypto and DeFi.

Aave, Uniswap, and Compound are popular DeFi platforms. They offer a variety of financial services:

• Aave is a lending and borrowing protocol. Imagine lending your cryptocurrency like you would in a savings account and earning interest. Or, borrowing against your crypto assets, much like taking out a mortgage against your house.

• Uniswap enables decentralized trading. You can swap different cryptocurrencies directly, without the need for a traditional exchange.

• Compound is similar to Aave, allowing users to earn interest on deposits. Rates fluctuate based on the supply and demand.

More about Aave

Aave is an Open Source Protocol that allows users to lend and borrow crypto.

There are 3 key players in Aave:

1. Depositor (aka supplier): These are users who add liquidity to Aave by depositing their cryptocurrency into a liquidity pool. In exchange, they receive interest on their deposits.

2. Borrowers: Users who draw liquidity from these pools by taking out loans. To do this, they must first provide collateral that is worth more than the loan amount — this is known as over-collateralization and helps keep the loan secure. An advantage for borrowers is the possibility of their collateral increasing in value, which can make repaying the loan more beneficial.

3. Liquidators: Their primary function is to monitor loans and ensure that they remain sufficiently collateralized (the value of the collateral>the value of the loan). If a borrower's collateral value falls below a certain threshold (due to price fluctuations in the cryptocurrency market), the position is considered undercollateralized and can be liquidated. They play a crucial role in maintaining the health and stability of the AAVE protocol.

GHO is a stablecoin native to the Aave protocol. Let’s first cover stablecoins.

Primer on Stablecoins

A stablecoin is a type of cryptocurrency designed to have a stable value. This is achieved by pegging the value to a stable asset like the US dollar, aiming to maintain a consistent value unlike other more volatile cryptocurrencies.

Stablecoins come in various forms, here are some of the most common categories:

• Centralized, One-to-One Backed Stablecoins: These are pegged to fiat currencies like the US Dollar on a one-to-one basis and are maintained by centralized entities.

  • Example: USDT (Tether) and USDC.

  • Benefits: Highly stable, widely accepted, and easy to convert to fiat currencies.

  • Risks: Reliant on the trustworthiness of the central issuer, potential for central points of failure.

• Decentralized, Crypto-Backed Stablecoins: These tokens are backed by other cryptocurrencies. For each stablecoin minted, there's a corresponding amount of crypto collateral.

  • Example: DAI - backed by Ethereum and other cryptocurrencies.

  • Benefits: More transparent than centralized stablecoins, with value backed by a diverse range of crypto assets.

  • Risks: Subject to market volatility of the backing cryptocurrencies

• Algorithmic Stablecoins: These use algorithms to maintain a stable value. Unlike traditional stablecoins. Algorithmic stablecoins rely on the protocol to manage supply and demand, for stabilizing their price.

  • Example: TerraUSD (UST) – Collapsed on May 2022

  • Benefits: Decentralized and not reliant on collateral; new approach to maintaining stability.

  • Risks: The mechanisms are complex and very experimental. Their value heavily depends on market confidence. A loss in confidence can lead to a death spiral, where the mechanism to stabilize the coin fails. We have seen several failures of algorithmic stablecoins like TerraUSD.

What about GHO?

GHO is an ERC20 token designed to maintain a stable value, pegged to the US Dollar. It falls in the decentralized and crypto-backed stablecoin bucket.

GHO Properties:

• Over-collateralized: Users must provide more collateral than the GHO they mint.

• GHO is minted not supplied: GHO, unlike other tokens, is minted rather than supplied. When you borrow on the protocol, you receive GHO, which is minted at that moment instead of being drawn from pre-existing supplies. The borrowing rate for GHO is not set by market dynamics but is determined by AAVE governance (=1 USD).

• GHO is natively integrated into the Aave market. This means that interacting with GHO on AAVE is very similar to interacting with any other asset of the protocol.

• It’s governed by the Aave DAO: GHO introduces a new concept called "facilitators." A Facilitator is a protocol or an entity who is authorized by the Aave DAO to mint GHO.

• Additionally, there's a discount mechanism in place for stkAAVE holders, allowing them to borrow at lower rates based on their staked assets.

📹 Great presentation by Steven Valeri on GHO & Stablecoins from Devcon.

But really - how does it work?

GHO is minted and burned by the smart contracts on demand.

Borrowing GHO

Here’s how the steps look like to Borrow GHO:

1. Provide Collateral: eg: User supplies 1 ETH as collateral to Aave

2. Receive aWETH: In return, the user receives 1aWETH.(aWETH is the token that represents the deposited Ethereum in Aave)

3. Borrow GHO: The user borrows 10 GHO, this process is minting the GHO

4. Acquire Debt Tokens: Upon borrowing, the user receives 10 debt tokens.

5. Interest Accrual: The debt accrues interest over time.

6. Repay GHO and Accrued Interest: Repaid interest goes to the treasury, instead of the asset supplier.

Supply of GHO

GHO is not supplied, it is minted by the facilitator on demand. When the user pays the GHO they have borrowed (aka their debt position) the GHO is burned by the facilitator and the interest is sent to the GHO treasury.

Important note here is that because there is no supply of GHO, the interest rates are not determined based on the utilization but instead by Aave governance.

🙌 To bring it all together - GHO is unique as it's minted on-demand and burned upon repayment. The interest rate is governed by Aave DAO, not market dynamics.

Building with GHO

Let's dive into the practical side of DeFi by getting into how to build with GHO.

We’ll write a basic smart contract to showcase some interactions with GHO within the Aave ecosystem. The contract will demonstrate how to interact with GHO, including depositing DAI and borrowing GHO from the Aave pool on behalf of a specified address.

You need to have Foundry installed for this workshop, you can follow the steps here.

Set-up

1. Create a project

   forge init gho-project 
   cd gho-project 
   

2. Install the dependencies

   forge install aave/aave-v3-core@a00f28e aave/gho-core@2abe8f7
   OpenZeppelin/openzeppelin-contracts@d00acef 
   

3. Create a 'remappings.txt and add the following onto it:

   aave-v3-core/=lib/aave-v3-core/ 
   aave-v3-periphery/=lib/aave-address-book/lib/aave-v3-periphery/
   ds-test/=lib/forge-std/lib/ds-test/src/ 
   forge-std/=lib/forge-std/src/ 
   gho-core/=lib/gho-core/ 
   @openzeppelin/=lib/openzeppelin-contracts/ 
   

4. Add the RPC Url to interact with GHO to foundry.toml

   [rpc_endpoints]
   goerli ="https://rpc.ankr.com/eth_goerli"
   

Interacting with GHO: Deposit DAI & Mint GHO

1.    Create a file in the src folder

touch ./src/GhoTest.sol

2. Here is the code for the smart contract, I have added the comments to explain what’s going on:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {IERC20} from "aave-v3-core/contracts/dependencies/openzeppelin/contracts/IERC20.sol";
import {IPool} from "aave-v3-core/contracts/interfaces/IPool.sol";
import {GhoToken} from "gho-core/src/contracts/gho/GhoToken.sol";
import {IGhoToken} from "gho-core/src/contracts/gho/interfaces/IGhoToken.sol";

contract GhoTest {
   IERC20 public dai;
   IPool public pool;
   GhoToken public gho;
   address public spender;


   constructor( address _daiAddress, address _poolAddress, address _ghoAddress, address _spenderAddress
   ) {
       dai = IERC20(_daiAddress);
       pool = IPool(_poolAddress);
       gho = GhoToken(_ghoAddress);
       spender = _spenderAddress;
   }

   function deposit(uint256 daiAmount) internal {
       // Approve the Aave Pool to pull the specified amount of DAI funds
       dai.approve(address(pool), daiAmount);
       // Supply the specified amount of DAI to Aave Pool
       pool.supply(address(dai), daiAmount, spender, 0);
   }

   function mintGho(uint256 ghoAmount) internal {
       // Borrow the specified amount of GHO
       // Note: This assumes that the necessary DAI has already been deposited
       pool.borrow(address(gho), ghoAmount, 2, 0, spender);

       // eg: you can also borrow the full amount in the contract for certain use-cases
       // but since GHO is overcollateralized you'll need to provide more DAI than the GHO to borrow
   }
}

Let's test this

1. Create a test file:

   touch ./test/GhoTest.t.sol
   

2. Add the following code to the file, I have added comments to explain what's going on. We’ll be testing on Goerli network, the network addresses are here.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import "../src/GhoTest.sol";
import "forge-std/Test.sol";
import "forge-std/StdCheats.sol";

contract GhoTestTests is GhoTest, StdCheats, Test {

   constructor() GhoTest(
       0xD77b79BE3e85351fF0cbe78f1B58cf8d1064047C, // DAI address
       0x617Cf26407193E32a771264fB5e9b8f09715CdfB, // Aave Pool address
       0xcbE9771eD31e761b744D3cB9eF78A1f32DD99211, // GHO Token address
       address(0x1) // spender address (or owner address)
   ) {}

   function setUp() public {
       vm.createSelectFork(vm.rpcUrl("goerli"), 9818553); // fork of the Goerli testnet
       deal(address(dai), spender, 100e18);  //  gives 100 DAI to the spender addr
  
       // Transfer the ownership of the GHO token to the owner address
       address owner = gho.owner();
       vm.prank(owner);
       gho.transferOwnership(spender);

       vm.startPrank(spender);
   }

   function testDeposit() public {
       uint256 depositAmount = 10e18; // 10 DAI

       uint256 initialDaiBalance = dai.balanceOf(spender);
       deposit(depositAmount);

       uint256 finalDaiBalance = dai.balanceOf(spender);
       // Check DAI balance before and after deposit
       assertEq(finalDaiBalance, initialDaiBalance - depositAmount, "DAI balance should decrease by the deposit amount");
   }

   function testMintGho() public {
       uint256 daiAmount = 100e18; // Amount of DAI to deposit for collateral
       uint256 ghoAmount = 10e18;  // Amount of GHO to borrow

       // Deposit DAI to provide collateral for borrowing GHO
       deposit(daiAmount);

       // Borrow GHO by miniting
       mintGho(ghoAmount);

       // Assertions to check the final state
       uint256 finalGhoBalance = gho.balanceOf(spender);
       assertEq(finalGhoBalance, ghoAmount, "GHO balance should be equal to the borrowed amount");
   }
}

3. Run the tests:

forge test

Conclusion

DeFi is not as daunting as it seems on the outside. By enabling direct, peer-to-peer financial transactions, it’s breaking down the barriers of traditional finance. Tools like Aave provide a user-friendly platform for experimentation and innovation. You can easily get started learning + building with Aave and GHO.

Last but not least, here’s our hackathon project!

See you on the next one. If you have any feedback or comments, please feel free to reach out, my dm’s are open!

Without a doubt, Restaking is a key narrative for Ethereum in 2024. This term was introduced by EigenLayer, a project that has quickly become a hot topic in the Ethereum world.

A few months ago, I wrote about EigenLayer. Since then, a lot has happened, and the interest has grown exponentially. So, I'm back with another post.

In this post, I aim to cover:

1. A Comprehensive Overview of EigenLayer: What it is & Why You Should Care

2. The Current State: What's new and happening now

3. Risks: What we should be careful about.

Part 1 - EigenLayer: A Comprehensive Overview

EigenLayer is a restaking protocol that has gained significant attention for its new and innovative approach in the Ethereum space.

Let's start by addressing the problem EigenLayer aims to tackle.

EigenLayer: Simplifying Network Bootstrapping

Proof of Stake (PoS) networks typically require operators to run nodes, supported by a token to incentivize their efforts. Launching such a network involves numerous complexities. Key among these are designing an effective token, ensuring its fair distribution, gaining market acceptance, and regulation to mention a few. These factors collectively limit innovation at the infrastructure level.

This is exactly where EigenLayer comes in - to address the challenges associated with infrastructure-level innovation.

Its core concept is to utilize the established economic trust of Ethereum as a foundation for building infrastructure components for advanced projects. In doing so, EigenLayer redefines the bootstrapping process for PoS networks.

How Does EigenLayer Work?

EigenLayer allows developers to utilize Ethereum's existing economic security infrastructure, which includes the validator set and capital. This process simplifies the creation of new networks and services by leveraging the already established security of Ethereum.

Central to this is the concept of 'restaking.' With restaking, EigenLayer enables the use of Ethereum's staked ETH and validator set for other services and networks.

Why does this matter?

• Streamlined Development of Network and Services: EigenLayer's approach of allowing ETH to be restaked streamlines the process of establishing new networks. It provides these networks with immediate economic security and operational support, removing the need for developers to bootstrap these elements from scratch. This not only accelerates network development but also lowers the entry barriers, paving the way for a wider range of networks and services. (Happy developers 🙂)

• New Staking Opportunities: This model offers new ways for ETH stakers to use their assets, potentially leading to additional rewards.

• Validator Utilization: This model offers validators new opportunities to leverage their existing resources. By participating in multiple networks, they can maximize their utility and broaden their earning potential.

A Detailed Overview: Roles, Mechanisms, and Impact

Here's a closer look of how the system works:

Ethereum Staking

Currently, the Ethereum network is secured by validators who stake their ETH as a capital-based commitment to follow to Ethereum's rules. The validators are responsible for storing data, processing transactions, and adding new blocks to the blockchain by running the validator software. If they don't follow the rules, then they risk losing this ETH. To become a validator, a minimum of 32 ETH is required. However, for those unable to meet this threshold, there is an option to contribute a smaller amount of ETH by participating in a staking pool which is like a group fund that’s managed by someone else.

EigenLayer (Re)Staking

EigenLayer takes this a step further. It expands their roles of validators, letting them participate in new networks and systems which require external operators. By doing so stakers can earn additional rewards which increases their involvement in the Ethereum ecosystem and gives them new avenues to earn rewards.

Before moving forward let's clarify the participants and their roles.

Participants and Roles

1. Stakers: They are the ones who commit their ETH to support new networks & services. They have two options:

   1. Native Restaking: Stakers can operate independently by taking on the responsibilities of both contributing tokens and operating an Ethereum Validator node.

   2. Delegating to Operators (aka Liquid Restaking): Stakers can delegate their ETH to Operators, focusing on the financial support while Operators handle the technical requirements.

2. Operators: These participants manage and run the software build on top of EigenLayer. They play a crucial role in maintaining the network's integrity and are subject to penalties for any misconduct.

3. Services: These are the networks and services that are run by Operators - they are called Actively Validated Services(AVS) - more on this in the next section.

4. Service Consumers: These are the end-users or applications that utilize the services provided by EigenLayer.

I mentioned “networks and services,” but what exactly falls under these categories in the context of EigenLayer?

Understanding Actively Validated Services (AVS)

Actively Validated Services are the services that require external operators to operate their networks. Examples of an AVS include data availability layers, decentralized sequencers, bridges, oracles, & more.

These services are not just passive entities; they have specific operational needs. This includes:

1. Certain node software requirements

2. Defining the conditions under which slashing (in other words penalties for malicious behavior) occurs.

Slashing: Ensuring honesty in EigenLayer

In EigenLayer the partnership between stakers and operators is crucial. When Stakers delegate their ETH, they are putting explicit trust that operators will act honestly.

To keep everyone honest, EigenLayer has a mechanism called “slashing.” If operators do something they shouldn't, they can get penalized. This means they might lose some of the ETH they put in.

The slashing conditions are defined in the AVS smart contracts, and impose penalties for rule violations. For example, operators are at risk of slashing penalties for actions such as double signing for sidechains or signing of non-existent messages for bridges.

This mechanism ensures the integrity and trustworthiness of the system.

Trust Bazaar: EigenLayer's Decentralized Marketplace

In a nutshell, EigenLayer creates a decentralized trust marketplace by taking Ethereum's trust (capital + validator set) and offering components of it to anyone interested. With this mechanism, stakers can opt-in to offer new services that provide them with additional benefits.

Part 2 - The Current State: EigenLayer

Today Mainnet Launch & Total Value Locked

• EigenLayer is launching its platform in multiple phases, starting with restaking on the mainnet, then introducing operators, and lastly, launching AVSs.

• They launched the restaking functionality on the Ethereum mainnet in June 2023. There is 648,964.0315 ETH staked (over a billion dollars!) as of writing this post and, and you can follow it on the dashboard, showing the breakdown of tokens.

• This phase started with a guarded approach to test the protocol at various stages. Right now, EigenLayer lets you do liquid staking with multiple LSTs and native restaking.

AVS World

• Various teams are actively developing AVSs, with EigenLayer's EigenDA being a notable example. As well as teams from Espresso, Witness Chain, Omni, and Lagrange, you can learn more over here.

• Note that AVSs are generally not consumer apps, instead they are services which are required by consumer facing apps. Such as oracles, shared sequences, bridges. - We’ll not be diving in for the sake of this post, something for the future.

EigenDA

• EigenDA is the Data Availability service which EigenLayer is building, it's the first AVS that has launched on the Goerli testnet.

• This is part of the second phase launch. It involves operators running validation services for EigenDA, demonstrating how services can run on EigenLayer.

• Currently the launch is on the testnet. EigenDA is especially important because it will be the first service on EigenLayer.

A Note on Restaking

• While the term 'restaking' is used to describe staking ETH denominated tokens on EigenLayer, it's a permissionless staking platform at its core. The initial focus has been on ETH-denominated tokens, but could extend to other forms of assets such as different tokens. This choice is driven to support the Ethereum ecosystem, as well as the relatively lower volatility of ETH. While the platform doesn't have to be tied to ETH and ETH-denominated tokens, the initial strategy has been to start with it.

Part 3 - Risks & Re-evaluating Incentives for Ethereum

Re-evaluating Incentives

A few months ago, Vitalik wrote a piece discussing the potential risks and implications of extending Ethereum's consensus mechanism beyond its original scope. The core message here is that while Ethereum's consensus mechanism is a powerful tool for maintaining a decentralized and secure blockchain, using it for decisions beyond its intended purpose can introduce risks and challenges that could undermine the system's stability and trust.

On similar lines, Justin Drake gave a presentation during Devconect, discussing related concerns and potential solutions. I highly recommend watching this, it's a very insightful overview of the potential risks and mitigations (especially if you have some background  on MEV).

🌟 The key question in restaking is how a staking protocol can change Ethereum validator incentives by enabling rewards beyond the core protocol's visibility, and if this could shift Ethereum's fundamental value proposition.

For example:

• The attractiveness of additional earning opportunities through restaking could drive up the demand for staked ETH, impacting the overall economics of the Ethereum network.

• The potential for higher yields through participating in EigenLayer’s staking could make the option for solo-staking less appealing, in the case where there are high node requirements for the networks and services - meaning that not every validator can opt-in for services that give better returns. On the other hand it could make solo-staking more competitive and capital efficient if different incentive mechanisms are provided.

Acknowledging that cutting-edge tech like this might have some initial challenges - and hence my reservations, it's still really exciting to see something so different. There's a buzz of new ideas and possibilities.

EigenLayer Risks

With that here are some notable risks with a bit more context:

1. Operator Centralization

2. Fairness and Reward Distribution among Operators

3. Risks of Operator Misconduct and System Security

4. Complexity and Trust Issues in Liquid Staking

5. Smart Contract Risks

Operator Centralization

• One of the main concerns with EigenLayer is the risk of operator centralization. This issue arises if there are high off-chain requirements for operators, potentially leading to a concentration of resources and expertise among a limited group of operators. Such a scenario could diminish the attractiveness and feasibility of solo-staking on Ethereum. In other words if the rewards of participating as a ‘delegated restaker’ are higher than becoming a solo-restaker, it might discourage solo-staking.

Fairness and Reward Distribution among Operators

• A critical aspect to consider is the fairness in reward distribution among operators. In EigenLayer, operators can opt into various services, each offering different potential rewards. This setup could significantly alter the current "fair" reward system in Ethereum, where each node earns a similar annual percentage rate for staking ETH. The varied reward structures might incentivize operators to focus on maximizing returns, making it hard to maintain a balanced and fair environment for all network validators. Now the validator has a lot more work to do to understand the projects and the reward structure - one month they can opt-into a certain AVS then another, constantly on the look for something better.

• (Adding to the centralization argument - due to the varied reward distribution it might make sense for a native restaker to choose to delegate to an operator instead of running the software themself, altering the validator distribution on the core protocol.)

Risks of Operator Misconduct and System Security

• The possibility of operator misconduct is a significant risk. Given that an Operator can participate in multiple AVSs, what happens if the rewards > penalties. Then the operator can choose to act dishonestly and willing to lose the stake. If there is a small number of operators participating it could make it possible to come together for an attack (attack > loss). (In certain cases you could imagine that the stake required to participate in an AVS, may be more than the 32 ETH to be an ETH Validator, which can limit the number of operators).

• Additionally, if the mechanism for re-balancing collateral in EigenLayer fails due to slow adjustment, latency, or incorrect parameters, it can expose the system to various security risks. To counteract this risk, EigenLayer proposes an "unbonding period" solution. This approach introduces a mandatory delay between the time a staker requests to withdraw their stake and when they can actually access it. (Here's a post by EigenLayer which explains their approach) The proposed solution seems effective in addressing the loophole of premature withdrawal by malicious operators. It's a complex mechanism that EigenLayer is actively refining to enhance security and effectiveness in addressing this potential risk.

Complexity and Trust Issues in Liquid Restaking

• Complexities emerge when stakers use external operators and need to select AVSs- which AVS does the restaker want to support? EigenLayer's solution involves operators using different addresses for each AVS combination they support (For example, an operator working with 2 AVSs can have 3 addresses: AVS 1, AVS 2, and both - explained here). While this allows stakers to retain control over their stake, it introduces a layer of complexity in understanding which address represents which service(s). Additionally, the problem of 'can I trust the operator' continues to exist, as with any permissionless blockchain.

Smart Contract Risks

• Bugs and issues in the smart contracts of EigenLayer or the AVSs pose a potential risk of getting slashed unintentionally. To mitigate the smart contract risks EigenLayer relies on a governance committee to address issues due to unintended slashing. The committee can reverse the slashing that resulted from bugs or malicious code.

End.

There's a lot of research yet to be done. This includes the work on the AVS, bringing these systems to life, and designing the protocol in a way that strengthens Ethereum's core values. While EigenLayer's solutions are promising, they must balance effectiveness with manageable complexity to ensure the system remains reliable.

I tried very hard not to use “ethereum alignment” which has become a meme at this point, nonetheless I hope that my message comes through. Trying to avoid new-hype-unclear terminology at all costs 😀

It's really exciting to see all the new things happening in the Ethereum world thanks to EigenLayer. Restaking is one of the main narratives for Ethereum going into 2024, and kudos to the EigenLayer team for keeping me excited.

If you have any questions or comments, feel free to reach out to me. See you on the next one. 👋

Key Terms

• Restaking: Using staked ETH to support other services.

• AVS (Actively Validated Services): Services that need external operators to function.

• Liquid Staking Tokens (LST): Tokens representing staked cryptocurrencies.

• Operator: A participant in EigenLayer who runs validation services for AVSs.

• Staker: A participant who stakes their ETH, to support the network and earn rewards. They can choose to become solo-stakers or delegate to operators.

• EigenDA: Data Availability service by the EigenLayer team.

• Slashing Conditions: Rules set by EigenLayer's smart contracts that impose penalties (slashing) on operators for dishonest or faulty behavior.

As I was heading back from Devconnect, scrolling through my notes, full of ideas on what to work on next, I realised that I've been in the crypto/web3 industry for 2 years! Like full-time, day-night kind of 2 years, not your typical 9 to 5. It definitely feels so much longer, and I still feel like I’m pretty new.

So, as I mark my 2nd anniversary working in crypto, I decided to put some of my ramblings on paper. My notes turned out to be not just about working in crypto but generally working in a initiative-driven, dynamic and disruptive industry, especially as someone coming from the corporate world.

This blog post is basically some of the things I learned and don't want to forget.

1. How you communicate is the sheer determinant of your success. First, how you speak, then how you write. Listen to good communicators & read, a lot. Even if you don't learn from the context, you'll learn how to write/speak well and, more importantly, structure your thoughts. In the end, it doesn’t matter if you have the greatest tech, if you can’t convince people to use it becomes irrelevant.

2. Most people are in it for the money. There's a lot of money, so of course, many people come for it; hence, you'll hear a lot of speculation and price talks. A lot of easy money = drama. Similarly, being rich doesn't equate to being successful. On the bright side, it's quite easy to identify and filter people and projects.

3. A lot of the tech doesn't work (yet) - shocker? I've seen companies that appear extremely polished from the outside but lack a solid technical foundation or even any sort of plan. I'm not saying these efforts won't eventually work out; rather, I'm pointing out that they may not be as refined as they seem. Initially, this frustrated me (especially trying to build something with many parts not working). However, now I understand this is what people mean when they say, 'We're still early,' because, well we’re really building the tools together. Also please note that this doesn't mean you should believe everyone and everything. Best is to be an optimistic realist. 🙂

4. Be VERY interested! In my daily life, I spend a lot of time explaining to people that blockchain/crypto is not bad. If I weren't personally interested, I wouldn't be able to do. Also, it's so fun and easy to work with people who are actually interested and enjoy what they're doing; the opposite is true as well.

5. Put stuff on the internet 🛳️. Anything - writings, talks, presentations, code. Saying I built cool projects without having your cool projects on the internet means nothing. Leetcode doesn't get you a job here (or anywhere in the startup world); it's the open-source contributions you've ALREADY made. If you want a job you MUST do the work prior.

6. The talent in the crypto space amazes me. The energy of interesting and motivated people is contagious. After meeting so many people in Devconnect, I have a long list of ideas. This also means that: Team >> Ideas. Surrounding yourself with inspiring people is a life hack.

7. Many people make it seem more complicated than it is. People used to complain in the corporate world about the number of acronyms. It's the same here - there are way too many buzzwords and abbreviations. The concepts are probably not that complicated, however, people generally use big and new words. So don't get intimated by this. In fact, I see it as an opportunity to make things simpler.

8. There are lots of scams & security vulnerabilities. There are hacks and scams every day. Even the most "degen" names are vulnerable. Don't connect your wallet to everything; don't send your tokens if someone tells you they'll send you something in return, etc. Be EXTRA cautious.

9. There's a cult-like nature, which is a huge minus. People get stuck in their opinions, especially when money's involved and they're winning together. It turns into a kind of group thing that's more about getting along than adding value. This is a huge drawback. I hope that with more high-value projects and tech-savvy and ambitious folks this can change.

10. Show up PREPARED. There are a lot of irl and virtual events. Being present and engaged puts you 3-0 ahead. But NEVER go unprepared - do your research and have a clear message of what you bring to the table.

11. The default is "no". If you don't take your shot, it's the same as asking and getting a no (which, trust me, is rarely the case). A general life hack.

12. Tips for giving presentations. Don't say "Ummmm." Here's a great video on tips and tricks for giving presentations. Regarding slides, if you think that you have too many slides or too many words on them, you probably do. Also talk slow. Especially in spontaneous situations; there’s no right or wrong answer, so relax.

Some of these may seem intuitive, but it's amazing how easy they are to overlook.

Two wild years have taught me more than just writing smart contracts and the intricacies of crypto twitter. It's been less about the code and more about the bigger picture stuff - like working on things you are personally interested in with people you care about and just showing up to do your own thing.

Final words - It was a 10/10 decision, and I’m excited for what’s coming.

Now, this post is on the blockchain forever. 🤝

• Zero-knowledge proofs (ZKPs) can cryptographically prove a statement is true without revealing the statement itself. They offer a new level of privacy in digital transactions, allowing for verification without compromising sensitive data.

• Zk-SNARKs, which stand for Succinct Non-interactive Arguments of Knowledge, are a type of ZKPs. ‘ Succinct’ and ‘Non-interactive’ highlight their efficient performance, while ‘Zero-knowledge’ refers to their privacy-enhancing feature. They are becoming increasingly important in the blockchain world, significantly improving both scalability & privacy.

Zero-knowledge proofs (ZKPs) have become a buzzword in the web3/crypto space, often surrounded by a buzz of excitement and sometimes confusion. As blockchain technology evolves and the applications built on it grow more complex, ZKPs are increasingly crucial for two primary reasons: privacy and scalability.

Despite the growing importance of ZKPs, much of the existing information about them tends to be quite technical. This is my stab to change that. My goal is to give you a clear and straightforward guide to ZKPs for the blockchain world.

In this post, I’ll cover:

• What are ZKPs & zkSNARKs?

• How do they work?

• Why you should pay attention?

What is Privacy if Not an Illusion in Public Blockchains?

Blockchains like Bitcoin and Ethereum are public ledgers. Every transaction is recorded and visible to anyone who accesses the blockchain. This transparency is great for ensuring honesty and security but not so much for privacy. Think about this: your bank account was available for everyone to see…

It’s important to note that the information shared on these blockchains is linked to public keys, not your actual government-issued identity. This means all actions are pseudonymous rather than anonymous.

While using public keys or wallet addresses does provide a degree of anonymity, this does NOT equate to privacy. Your transactions, although not directly linked to your real-world identity, are still fully visible on the public ledger. This transparency has led to numerous instances where digital identities were traced back to real individuals.

Therefore, there’s surely a need for a more robust privacy solution in such an open network, and there have been various approaches Zero-knowledge proofs (ZKPs) are one of these. In a world where every transaction is a matter of public record, ZKPs offer a way to maintain privacy while still verifying the authenticity of transactions.

What is a Zero-Knowledge Proof (ZKP)?

In cryptography, zero-knowledge protocol or zero-knowledge proof (ZKP) is a method that enables someone (the ‘Prover’) to convince another party (the ‘Verifier’) that they know a secret or a fact without revealing what that secret is. Simply put, the Prover demonstrates they have certain knowledge, and the Verifier checks this claim without disclosing the actual information.

You can create zero-knowledge proofs for facts such as:

• Knowledge of a private key belonging to a wallet without disclosing the private key

• Proof that you made a donation without sharing how much it is

• Knowing where Waldo is without sharing the exact location

In these examples, the Prover can maintain privacy while still sharing proof of a specific knowledge. This concept might sound abstract, so we’ll break it down as we go along.

But first — why should you care?

Privacy

• ZKPs are crucial because they offer a new level of privacy in digital transactions. They let you share just enough information to get the job done without revealing anything extra. This is particularly important in the context of public blockchains, where traditionally, every transaction detail is visible. With ZKPs, you can prove the validity of a transaction, like a fund transfer, while keeping the amounts and involved parties private.

Scalability

• Secondly, ZKPs contribute to scalability in many applications. By using a ZKP, one party can confirm that a complex computation or transaction was carried out correctly without requiring others to repeat the same work. This approach reduces the computational load on the network. In other words, there is no need for re-execution — only the proof needs to be verified. (Ideally, verifying a ZKP requires significantly fewer resources than re-executing the computation.)

Zero-Knowledge Proofs: Breaking it Down

Let’s talk about the key concepts of ZKPs through an example scenario.

Say that Alice needs to prove ownership of a digital wallet to Bob without revealing her private key. (PS: never give your private key; it has full control over your account. This means whoever has the private key will also have complete control over your account.)

• The Prover (Alice): Alice wants to demonstrate that she owns the digital wallet without sharing her private key.

• The Verifier (Bob): Bob wants proof of Alice’s claim.

• The Witness (Statement Being Proven): The ‘witness’ refers to the specific statement or fact being proven. Here, it is the claim that Alice is the owner of the wallet.

• The Proof: Alice provides a proof that validates her wallet ownership without sharing her private key. This proof is a result of cryptographic computations demonstrating that Alice possesses the key without actually showing it.

In this example, Alice effectively uses cryptographic methods to generate a zero-knowledge proof. Bob, on the receiving end, can verify this proof without ever needing to see or know the private key itself.

What makes a “Zero-Knowledge Proof”?

Now that we know Alice can prove her ownership of a wallet to Bob without revealing her private key, let’s look at the fundamental properties that define a ZKP.

A ZKP must satisfy 3 properties:

1. Completeness — if the statement is true then a prover can convince a verifier. If Alice truly owns the wallet, she can produce a proof that convinces Bob of her ownership. Completeness ensures that if the claim is true (Alice does own the wallet), and both Alice and Bob follow the protocol correctly, then Bob will be convinced by the end of the process.

2. Soundness — a cheating prover can not convince a verifier of a false statement. This assures that if Alice does not actually own the wallet, she cannot trick Bob into believing she does. Soundness means that a dishonest prover (Alice) can’t falsely convince an honest verifier (Bob) into believing a false claim.

3. Zero-knowledge — no additional information beyond the truth of the statement is revealed. While Alice proves her ownership of the wallet, she shows nothing else to Bob — particularly, her private key remains secret. Zero-knowledge means that Bob learns only that Alice owns the wallet and nothing more.

Zero-knowledge proofs in the Blockchain Space

Zero-knowledge proofs have a variety of use cases in blockchains today. Here are some some examples:

• L2 Rollups for scaling blockchains: These are used to offload some of the computational work from the main blockchain layer (L1). By handling state transitions off-chain, they reduce the processing burden on L1, which functions more as a verifier with limited computational capacity. — Eg: Starknet, Matter Labs, Scroll, Polygon

• Bridges: These facilitate transactions between different blockchains. By using zero-knowledge proofs, a bridge can, for example, verify that funds have been locked on one blockchain before allowing corresponding actions on another. — Eg: Succint.

• Privacy-focused cryptocurrencies: Enables transactions on the blockchain while keeping certain transaction details private. — Eg: Zcash, TornadoCash, Worldcoin,

• Gaming: Blockchain strategy game — ‘Dark Forest’ (more on this below)

• Lightweight Blockchains: Mina Protocol, is a blockchain that uses zero-knowledge proofs to maintain a small blockchain size.

📍 If you’ve made it this far, you probably think that ZKPs are among the most fascinating parts of cryptography, and I’m with you on that. Now we’re getting to specifics: zk-SNARKs.

What about these zk-SNARKs?

One particular type of Zero-Knowledge Proof that has significantly impacted the crypto world since its introduction in 2011 is zk-SNARKs

Zk-SNARKs let someone prove they know a secret without disclosing what that secret is. They’re important in the context of blockchains because zk-SNARKs make transactions faster to verify and keep them private without revealing sensitive transaction details.

But what exactly are zk-SNARKs? The term ‘SNARK’ stands for ‘Succinct Non-interactive ARguments of Knowledge.’ Let’s break it down:

• S — Succinct: This means the proofs are short and can be checked quickly. (A word I have googled many many times)

• N — Non-interactive: There’s no need for back-and-forth communication between the prover and verifier, streamlining the verification process. Unlike some proof systems where the verifier might need to interact with the prover, non-interactive proofs eliminate this need. If proofs were interactive, it would mean that clients would have to engage in a lot of communication with the verifier to confirm that a statement or transaction is true.

• AR — Argument of Knowledge: ‘Argument’ is a technical term implying a slightly weaker form of ‘proof’. It means the proof holds as long as the prover doesn’t have unlimited computing power.

• K — Knowledge: The prover can demonstrate they know a secret or information through a cryptographic process.

A SNARK by itself doesn’t have to be zero-knowledge. The ZK part adds the extra feature that the proof can keep some information hidden.

It’s interesting to note that zk-SNARKs weren’t initially developed for blockchains or speeding up transactions. The original idea was about doing calculations on big data sets without downloading them. However, in recent years, we’ve seen significant experimentation and adoption of zk-SNARKs within the blockchain space.

🫡 Highly recommended presentation on ZK by Justin Thaler, covering these topics and diving into more technical aspects.

zkSNARKs in Action: Dark Forest 🌳

Let’s make things more concrete with an actual example.

Dark Forest, an innovative strategy game built on Ethereum that uses zkSNARKs. It’s an ‘incomplete information game,’ similar to poker, where players strategize without full knowledge of their opponent’s positions.

In the game, players are in a universe where they can’t directly see where everyone and everything is. This is known as the “fog of war.” Players don’t show where they are. Instead, they use a secret code to represent their location. This code says, “I’m at a secret place”, without telling exactly where.

This is where zkSNARKs come into play:

• zkSNARKs are used to verify players’ movements and locations in the game. They allow players to prove they are in a certain location without revealing their exact coordinates.

• Every time a player moves, they must use zkSNARKs to prove their move is valid.

The use of zkSNARKs in ‘Dark Forest’ is crucial. Without them, players could cheat by pretending to be somewhere they’re not. But since the players are required to submit zkSNARKs, they are kept from lying. You can see that by incorporating zkSNARKs, Dark Forest guarantees fair play.

The end

The potential of Zero-Knowledge Proofs is what makes them super exciting. In the future, we might see ZKPs becoming as common and essential as today’s encryption methods. Think about how encryption is key to online shopping — it started as something complex, but now, we use it all the time without even thinking about it. Similarly, ZKPs are currently complex pieces of cryptography, but they’re likely to become simpler and part of our daily lives.

Hope that this introduction triggers your interest and gives you some basics. This post is just the beginning & I’ll be writing more on ZK, specifically focusing on how developers can leverage this tech.

If you have any questions or comments reach out to me on Twitter! See you on the next one! 👋

First and foremost, let me introduce myself as someone who deeply loves Istanbul. Rest assured, you'll find great views & places, amazing food, culture and cats! Having spent most of my life in this city, I must confess that I might be a bit biased. Just a tiny bit. 🙂

So let’s get into it. Whether you're a first-time visitor or returning, here are some notes that can help you get around.

Food

Istanbul is a foodie's dream, and you won't go hungry! It's got a bit of everything, thanks to it’s unique spot between Europe and Asia. The food here reflects centuries of history, influenced by the Byzantine & Ottoman Empires.

🌟 For a very comprehensive guide to the best restaurants in Istanbul, be sure to check out Kaan's Foodie Guide.

My personal favourite food picks:

• Lahmacun: aka Turkish Pizza. Thin, crispy dough topped with meat, veggies, and herbs.

  • Where to get it? Tatbak, Çiya, most kebab places

• Döner: Meat slowly cooked on a vertical rotisserie. Often served in a wrap or on a plate with rice on the side. Iskender is a variation that combines döner meat with yogurt and tomato sauce.

  • Where to get it? Karadeniz Döner Asım Usta, Bayramoğlu, Garaj

• Mantı: aka Turkish Dumplings. These are dumplings filled with minced meat (usually lamb or beef, in most places there are also veggie options generally filled with spinach or mushrooms) and served with yogurt, garlic and oil with chilli.

  • Where to get it? Sinop Mantı, Casita, Emek Mantı, Bodrum Mantı

• Turkish Breakfast (Kahvaltı): This is a whole event. You'll get a little of everything - cheeses, olives, fresh veggies, honey (bal & kaymak), and all sorts of bread. There's also "simit," a popular Turkish pastry covered in sesame seeds.

  • Where to get it? Van Kahvaltı Sofrası, Divan Bebek, Yer Moda, Beyaz Fırın, Journey

• Desserts: Baklava is layers of pastry filled with nuts topped with syrup - the pistachio one is my favorite. Künefe is made from layers of shredded pastry, and is filled with cheese, soaked into syrup, and served hot. It has a crunchy outer layer and a soft, sweet interior!

  • Where to get it? Güllüoğlu, Köşkeroğlu, most kebab places

* To be fair - I can add lots more food options here, but leaving it a 5 top picks for the sake of this post.

Some more tips:

• Tipping is customary in Turkey. It's typical to leave a 10-15% tip in restaurants and cafes and for services. However, you should check the bill, as some places include a service charge.

• Unique beverages to try: Turkish Coffee, Ayran (a cold savory yogurt-based beverage), Rakı (an alcoholic drink of Turkey)

• Anthony Bourdain visited Istanbul twice where he filmed season 6 of his show and has some cool rec’s.

Cowork

🌟 Highly recommend checking out Dogan's Guide, where he shares the best cafes and places where you can take your laptop with you.

Transportation

Metro 🚉

Use the metro when you can. Traffic is real, and it can get even crazier than you can imagine.

In most metro stations, there are machines where you can buy an "Istanbulcard," which you can use for public transportation. Don’t forget to add some money into it to pay for the rides.

Taksi 🚕

You have several options for getting around using taxis or ride-sharing services:

• Uber: Uber is available in Istanbul, and it's a convenient option for getting around the city. Uber in Turkey only uses licensed taxi drivers. Be sure to have the Uber app set up and link your credit cards.

• BiTaksi: BiTaksi is a local app that allows you to request a taxi. With the BiTaksi app, you can pay for your ride using either your credit card or cash.

During peak times, it can be challenging to get a cab through these apps. I cannot explain the times I couldn’t find a taxi… It gets super frustrating.

In such cases, you try getting a taxi on the street.

Here are some tips so that you don't fall into any tourist traps:

1. Get a Licensed Taxis: Look for officially licensed yellow taxis or the turquoise taxis.

2. Always Use the Meter: Ensure the taxi driver activates the meter at the beginning of the trip.

3. Use the Local Currency: Have Turkish Lira (TL) in cash for taxi rides. While some taxis may accept credit cards, it's best to have cash on hand, especially for short trips.

4. Clearly specify the Destination: Clearly communicate your destination to the driver. Show the driver the address or location on a map or GPS app to avoid misunderstandings. I also recommend looking at the route and specifying the road to take. Note that most drivers may not know English.

   I remember one of my friends got on the cab on the Asian side and was going somewhere near, like a 20 min ride. It turned out to be a +1 hour ride because the road they took was crossing the bridge to go to the European side and then back to the Asian side, almost where they started (?!)

5. Verify the Fare: At the end of your trip, verify that the fare displayed on the meter matches the rate on the official taxi fare card.

Turkish Bath - Hammam 🛁

Funny header if you've never heard that there's such a thing as a Turkish bath. But it's a huge thing!

A Turkish bath, also known as a "hammam," is more than just a place to wash; it's a whole experience with cleansing, relaxation, and culture. The process typically involves several steps, starting with a session in a hot, steam-filled room to help you relax and sweat. Next comes a scrub to remove dead skin cells, followed by a massage scented with aromatic oils.

Here’s historical hammam’s that you can visit:

• Galatasaray Hamam

• Cagaloglu Hamamı

Shopping

People often ask, "Can you take me to places where I can buy gifts?". You can check out shops in Beyoğlu and the Grand Bazaar to find cute gift options.

Now, when you get to the Grand Bazaar, be ready to do some bargaining. The shopkeepers often expect some negotiation. And here's a tip: don't rush into buying the first thing you see. Chances are, you'll find something similar just around the corner.

You can also checkout the Egyptian Bazaar for dried nuts and fruits & Turkish Delight! It’s just next to the Grand Bazaar.

What to do, Where to go - More Notes

• Be sure to go to Moda for a day & evening! It’s on the Asian side and a popular destination for locals and visitors offering a wide variety of food and drinks! 🍻

• Highly suggest that you take a Bosphorus Ferry Tours on a sunny day 🌞

• This isn’t a tourist guide but be sure to find a tour and head to the Historical Peninsula. It is one of the most historically and culturally significant parts of the city where you can find some of the most iconic landmarks and historical sites in Istanbul. It’s a place where ancient history and modern life coexist, and Byzantine, Roman, and Ottoman heritage live.

• If you have a day to spare, you can go to the Prince Islands.

• You should definitely go to this area (Bebek) and grab a coffee at this hotel or the cafes nearby; the view is very lovely. You can walk around the area, get some ice-cream and enjoy the Bosporus.

• Two Turkish movie recommendations that are fun and take place in Istanbul:

  • Eyvah Eyvah: A comedy film portrays the clash of cultures as a man from a remote Turkish village navigates life in Istanbul.

  • Organize İşler: A Turkish comedy-drama film that tells the story of a small-time con artist who gets involved in more significant schemes.

Last but not least, make sure to take a walk by the Bosphorus!

See you soon, t-8! 👋

• EigenLayer is a restaking protocol that enables ETH stakers to validate different networks/services built on Ethereum through a set of smart contracts.

• EigenLayer aims to create a decentralized trust marketplace by taking Ethereum’s trust (capital + validator set) and offering components of it to anyone interested. This allows developers to focus on infrastructure-level innovation without the burden of bootstrapping a new network.

• Stakers can earn rewards by helping operate and secure various networks and services built on Ethereum, such as data availability layers, decentralized sequencers, and bridges.

• EigenLayer faces risks like operator collusion, over-commitment, and bootstrapping challenges, which require careful service/network design and monitoring.

EigenLayer is without a doubt one of the projects that has gained the most attention in recent months. There are almost weekly podcasts, presentations, and updates. Before diving into the details, I knew only a few buzzwords and didn't understand how it actually worked. This post is essentially my study notes and me brainstorming out loud.

Simply put, EigenLayer is a new solution to address the challenges associated with innovation at the infrastructure level in the blockchain ecosystem. It's a restaking protocol that enables ETH stakers to validate different networks and services built on Ethereum through a set of smart contracts on Ethereum. By restaking ETH on EigenLayer, stakers can support new Ethereum projects by providing services to operate them and gain access to additional staking opportunities.

In this blog post, I want to talk about EigenLayer in more detail - including: what it is, how it works, why you should pay attention, the use cases, and the risks involved.

Let's get to it.

But first - Why should I care?

1. Developers don't need to bootstrap a new ecosystem: Developers get access Ethereum's staked capital and validator set, so they can now spend less time on security bootstrapping. This means faster development cycles and new use cases.

2. More opportunities for ETH stakers: If you are an ETH staker seeking additional options, then EigenLayer might be an appealing choice. This protocol works alongside your existing Ethereum validation, allowing you to utilize your staked capital more efficiently and obtain extra advantages without much-added cost.

3. Increased security: By extending the crypto-economic security of Ethereum to additional applications EigenLayer contributes to an overall more secure and robust decentralized ecosystem.

What is EigenLayer?

As the whitepaper reads:

EigenLayer is a set of smart contracts on Ethereum that allows consensus layer Ether (ETH) stakers to opt in to validating new software modules built on top of the Ethereum ecosystem.

It’s a “restaking” protocol that allows ETH stakers to secure different networks and services, such as data availability layers, sequencers, bridges or other services built on top of Ethereum.

A Trip Down Memory Lane: Understanding the Blockchain Landscape

First, let's go back a bit; Bitcoin emerged as an application-specific blockchain with a limited scope, focusing only on peer-to-peer payments. It was specifically designed for a single purpose. Every innovation during that time in 2011-2012 required the creation of a new network.

Ethereum then introduced a general-purpose smart contract platform, allowing developers to build various applications, and making the blockchain ecosystem more programmable.x

However, Ethereum has its limitations when it comes to innovating beyond the application layer. Although Ethereum enables programmability at the application layer, it doesn't extend that flexibility to other underlying infrastructure components (e.g., consensus layer, data availability layers, new virtual machines, oracle networks); in other words, for services that cannot be proved on top of the EVM. Such infrastructure-level components require actively validated services (AVS) with their own validation.

This means that any innovation going beyond the application layer must either build its own service/network (e.g., Chainlink, Solana, etc.) or undergo a lengthy protocol development process (if accepted by the Ethereum community and will be implemented in the protocol).

Addressing Infrastructure Challenges with EigenLayer

EigenLayer is a new approach to tackling the challenges associated with infrastructure-level innovation. The idea behind EigenLayer involves leveraging a decentralized trust network to build the infrastructure components necessary for advanced projects.

Very briefly - here's how it works? EigenLayer introduces a method called restaking, which enables networks and services to be protected by staked ETH rather than their own tokens. Ethereum validators can opt in to offer new services that provide them with additional benefits. To do this, they must download and operate any necessary software. These services may impose conditions that lead to the loss of a validator's staked ETH if they behave dishonestly. This ensures that the validators act honestly, as their stake is on the line.

The core question EigenLayer tries to answer is: can we borrow trust from these decentralized networks & supply it to anyone who wants to consume it.

What’s this “decentralized trust“?

Decentralized trust gets lost in translation, so I want to focus on it for a second. (Tbh, I'm not in love with naming, but that's how I feel for most terms in the blockchain space.)

Decentralized trust is a fundamental concept for blockchains. It refers to the ability of a system to establish trust among participants without relying on a central authority or third-party intermediary.

There are different trust models, each with its own trade-offs. Let's look at what decentralized trust means for Ethereum.

Ethereum is a decentralized blockchain network that uses a consensus algorithm called Proof of Stake (PoS) to achieve trust and security without relying on a central authority. Multiple independent nodes validate and verify transactions, making manipulating or controlling the network challenging for any single participant, thus providing censorship resistance.

In Ethereum's PoS, validators lock up a portion of their cryptocurrency (ETH) as collateral to propose and validate new blocks in the blockchain. A validator must deposit 32 ETH to run a dedicated staking node. They risk losing some of their staked ETH if they don't follow the rules. This mechanism encourages participants to act responsibly.

Today, Ethereum has over 550k validators, as the data from hildobby’s Dune Dashboard.

App developers can build secure and reliable applications by leveraging Ethereum's decentralized trust network. They can ensure that their smart contracts function as intended without needing a central authority or third-party intermediary to establish trust.

Decentralized Trust Marketplace

Putting things together:

• In decentralized networks, participants can trust the system to operate securely, accurately, and reliably, without a central governing entity.

• EigenLayer aims to create a decentralized trust marketplace: by taking Ethereum’s trust (capital + validator set) and offering components of it to anyone interested.

How does it work?

EigenLayer creates a marketplace connecting ETH stakers, who pledge their services for additional offerings, and services/networks that need operators on the other end. It's a set of smart contracts on Ethereum that facilitate this.

The two primary actors involved in EigenLayer are:

1. Actively Validated Services (AVS): service/network requiring external operators to operate their networks - these are the services requiring decentralized trust. (Also referred to as Services/Middleware). An AVS can be a Data Availability layer, Decentralized Sequencer, Bridge, Oracle etc.

2. Stakers: actors who choose to provide specific services and, in return, can earn additional revenue. Stakers can run the software built on top of EigenLayer or delegate their stake to an operator.

Actively Validated Services

First, to create an AVS on EigenLayer, you need:

1. Off-chain container that operators must download and run (e.g., a service may require a validator to run a particular software)

2. On-chain contract that specifies the terms for payments and penalties (slashing)

Restaking in EigenLayer

A staker can opt in to new modules built on EigenLayer to provide security and validation services. This is called restaking.

To participate in restaking, stakers must do one of the following:

• download and execute the node software required for these modules

• delegate their stake to an operator that does this

Upon opting in, these modules enforce penalty conditions on the ETH that has been staked to encourage honest behaviour.

Restaking: Different (Re)Staking Options

Now you may ask: Is this the same ETH that one needs to stake to become a validator? What if I don't have the 32 ETH required to become a validator?

EigenLayer offers different restaking options. Each has its own risks and rewards.

• Native Restaking: This option is suitable for solo-stakers/home-stakers who want to restake their same staked ETH natively. When they stake within the Ethereum protocol, they need to specify a withdrawal credential, which is the account with the power to withdraw the staking collateral. To participate in EigenLayer, you need to assign this credential to the EigenLayer smart contracts. (L1 → EigenLayer)

• Liquid Restaking: Liquid staking is a service that allows users to deposit their ETH into a staking pool and receive a liquid staking token in return (such as those offered by Lido and RocketPool). Stakers can deposit liquid staking tokens into EigenLayer. Different options exist here, such as ETH LP restaking.

Service developers have the flexibility to set specific conditions for their stakers. For example, they can decide which tokens to accept as stakes and establish rules for distributing rewards. A module that prioritizes decentralization may only accept natively restaked ETH.

Now, a critical question: How does EigenLayer ensure stakers remain honest?

Dishonest Actors: Slashing

To ensure the honesty of stakers, service creators implement slashing mechanisms, which are penalty conditions for those who violate the rules. Stakers agree to the terms & conditions when they choose to provide a specific service, and they risk losing a portion of their staked ETH if they act dishonestly.

If you are delegating to the operator, you are also trusting the operator to act honestly and could face similar penalties.

Honest nodes getting slashed: Unintended Slashing

First - audit, audit, audit. Services must undergo security audits to avoid bugs and attacks.

It happened - there's a bug or malicious code 😳. Let's say a bug or malicious code resulted in an unintended slashing penalty. EigenLayer relies on a governance committee to address such issues. The committee can reverse the slashing that resulted from bugs or malicious code.

While some argue against human involvement, it is important to emphasize that the committee's role is solely to veto unintended slashing decisions. They do not make subjective judgments but rather act as a safety net for stakers.

Also, the committee operates transparently, with their actions and member identities openly accessible to ensure trust. Both services and stakers can opt in, fully informed of the committee's role and structure.

Risks & Challenges

Some questions that come to mind:

• What happens if only a small group of restakers participate in multiple AVS and come together for an attack? Could restaking lead to overleverage?

• How and when do the slashing and pay-outs happen? What if the slashing is too late?

• Who can run the off-chain software specs? Can everyone participate and become an operator, or will there be high requirements?

• Will people use EigenLayer?

Operator collusion: Small set of restakers

If only a small group of stakers are participating in restaking for many services, then the system can become cryptoeconomically insecure.

Here’s the example from whitepaper:

Consider an AVS which is secured by $8M of restaked ETH and which contains a total locked value of $2M. With a quorum of 50% required to capture the $2M of locked value, the application appears to be secure, since a successful attack would result in least $4M of the attacker’s stake being slashed. However, this may not be the case if the same set of stakers are also restaking in other AVSs. In the simplest case, exactly the same set of restakers participates in 10 other AVSs, each of which have $2M locked. Thus the total profit from corrupting this group of restakers is 20M$ but the total value at stake is only 8M$ thus making the system cryptoeconomically insecure.

It's saying that the system is at risk if the same stakers are involved in multiple services, making it possible to gain more from an attack than losing all the capital stake. (attack > stake)

Most of the risk mitigation is up to the AVS design. Applications can set some rules for the types of stakers they want; for example, you can only have natively staked ETH. Additionally, apps can limit the amount of funds that can be stolen during an attack (e.g., a bridge can restrict the value flow within the period of slashing).

Staker can’t pay the slashing fee

If the mechanism for re-balancing collateral in EigenLayer fails due to slow adjustment, latency, or incorrect parameters, it can expose the system to various security risks. Therefore, services on EigenLayer must maintain proper ETH balance to ensure the safety and stability of the network.

Consider the case where a staker who is restaking in multiple services acts dishonestly in various services (before the slashing is imposed), and then they don't have enough ETH to pay the slashing fees. What about when the gas fees are high, and the tx doesn't go through? The contracts are on Ethereum L1, so when the gas fees are high, this can create a problem for new AVS to be deployed, but more importantly for the stakers slashing to take place and pay-outs.

It's crucial that stakers can actually pay the slashing fee on time if they act dishonestly.

This is again up to the AVS design. For example, you can design the system so that if a slashing tx hasn't occurred, the staker might be unable to run the service for a certain time. However, this introduces a new risk that no stakers are running the services needed for the AVS at a specific time.

Operator Centralization: Off-chain Software Requirements

The off-chain software specs depend on the AVS design.

If services impose high off-chain software requirements, they create barriers to entry for potential stakers and operators. These complex specifications can lead to a situation where only those with advanced infrastructure can participate, resulting in centralization.

It’s suggested that services have simple off-chain software requirements to encourage more people to participate. Easy-to-meet requirements allow many operators to join without needing to upgrade their current systems. This way, more individuals can become operators, and the network avoids becoming centralized due to heavy or complex requirements.

Bootstrapping the services

Big Q: will ETH stakers (re)stake?

It’s one of the most attractive projects and gained a lot of traction in a very short time. However, as with any new ecosystem, there’s a significant need for education among stakers, service developers, and users. I generally view this as an opportunity for those looking to get involved 🙂

EigenLayer Use-Cases: What can I really do?

EigenLayer enables many use cases, including MEV Management, Data Availability Layer (DA), Decentralized Sequencers, Light-Node Bridges, and Fast-Mode Bridges.

EigenCloud

@eigenlayer

Huge alpha there. Event driven state updates (like collateral refilling, liquidation, atomic arbs with value flow to arb-ed protocols) can be built on @eigenlayer.

androolloyd.hl

@androolloyd

very excited to see more of this being talked about and even more so to learn about eignlayer, protocol owned validators is a powerful thing, it opens up a world of opportunities in the bribe market as well as how protocols can start to drive guarentees about state updates/mgmt

41

2:10 PM • Oct 20, 2022

These are a few possibilities, and there can be many more. For more information and potential use cases, you can visit the EigenLayer forum. Like any new and evolving technology, some may work out while others may not.

Although most of these use cases don't have their docs available, I want to provide an overview of a proposal around MEV Management, which has some resources for me to go with. I'm also grateful to the Discord moderators who directed me to these resources. (I wish it were docs>discord, but I've come to accept that docs are the last place updated in the crypto world.)

Essentially, EigenLayer enables programmable staking and slashing, which is a powerful tool for a decentralized network. Let's get into some technical details to make this a bit tangible.

MEV Management w/EigenLayer - Brief Overview

*This is a whole new topic. I’m going to assume you have some knowledge on MEV-boost and proposer-builder separation (PBS) for this section. Here a comprehensive list of resources to get started if you’re new to these. *

Sreeram Kannan

@sreeramkannan

Title: "MEV and restaking: Mycelial networks at the root of the dark forest!"

Talk, on applications of @eigenlayer for MEV management, with the right starting time here:
youtube.com/live/t3sL0sCJF…

156

9:32 PM • Mar 24, 2023

First, some background - MEV-boost is a middleware software run by validators that implements proposer-builder separation (PBS). PBS is currently not implemented in the Ethereum protocol itself, mev-boost is a way to test and experiment while the research continues.

PBS introduces a new role, the block builder, responsible for building the optimal block and offering it to the block proposer. Block proposers auction off the right to make the entire block. The block proposer cannot see the contents of the block; they simply choose the most profitable one.

The current implementation of MEV-boost only allows for full-block building, limiting the freedom of block proposers, who are a highly decentralized set.

Let’s look at this proposal: Preserving Block Proposer Agency with MEV-Boost using EigenLayer

The proposal aims to improve MEV management by upgrading MEV-Boost with partial-block building, giving block proposers more control and increasing censorship resistance using EigenLayer.

Under this proposal, block proposers must opt-in to EigenLayer and follow additional conditions or risk losing part of their stake. They can now fill part of the block with their transactions, enabling greater control in block composition. If the proposer proposes a block other than the alternative block they assembled, they must include the Builder_part in that block, or they will be slashed by EigenLayer. You can find more details and potential risks of the proposed approach in the proposal itself.

The main idea is that when you think about the applications, consider adding new customizable slashing conditions, which can give you a much more programmable and flexible network.

🌟 For a deeper dive into this topic, I highly recommend checking out Jon's in-depth post and Alex’s presentation on mev-boost

Projects interested in EigenLayer

• EigenLayer is building the EigenDA which is a hyper scaled data availability layer, which is the first use-case that being built by the team themselves.

• Espresso Systems is developing Espresso Sequencer in they plan to use EigenLayer for restaking

• Mantle is planning to use EigenLayer’s data availability(DA) layer

Current State of EigenLayer

EigenLayer testnet launched on Apr 6, 2023 on Ethereum Goerli network. This is an early, non-incentivized, and experimental testnet.

The protocol will launch in three stages: Stakers, Operators, and Services. Currently the Stage 1 is for stakers. Stakers can participate in liquid re-staking and native re-staking, you can follow the stats here.

Conclusion

In conclusion, EigenLayer is an innovative solution that addresses the challenges associated with infrastructure-level innovation. By leveraging a decentralized trust network and introducing restaking, EigenLayer enables ETH stakers to support new Ethereum projects while gaining access to additional staking opportunities. However, it's important to play devil's advocate and acknowledge the potential risks involved, such as operator collusion, restaker centralization, and bootstrapping the ecosystem.

After all the research, I can say that EigenLayer is one of the most innovative ideas I've seen in the Ethereum ecosystem in a while. As with any new technology, it's important to remain critical and mindful of the risks involved. By doing so, we can ensure the development of a robust and trustworthy ecosystem.

I usually do code-deep and this was different from what I typically do, so please be honest with the feedback and let me know if you have any questions, my DM's are open!

In this post, I want to talk about today's social media applications, what decentralized social protocols can unlock & dive into Farcaster. So let's get into it.

Intro to Decentralized Social Networks

Web3 social (aka decentralized social) has been one of the most exciting areas in crypto for the last year. I've already written about in a past post, but want to give a refresher here for simplicity.

You can check out my previous post: Web3 Social & building with Lens Protocol 🌿

Web2 Social Media Applications

Social media apps impact our lives in many ways. It’s safe to say that they bring many benefits; the apps are user-friendly, allow creators to communicate with their audiences, enable individuals to establish online businesses, and even allow grandparents to post cat pictures, among other things. From the rise of Tiktok stars, viral memes, and "a day in my life" videos (or do I need to say vlogs?), these platforms have made it easy to connect with anyone and reach a large audience. However, now we are seeing a decline in both user satisfaction and innovation.

New tech like web3 can bring some fresh ideas to the table. Let's first talk a bit about the slowdown & limitations of the current platforms.

Web2 Social Media: Limitations & Challenges

It’s true that centralized social media platforms provide a top-notch user experience, but this comes with a trade-off. The companies running the platforms have a lot of power, from control over users and content, how the algorithm works, app features, how the API/tools are controlled etc.

As a content creator, the most important thing to point out is that user’s don’t have a direct relationship with their audiences. The social media platform can ban the user or content. A few months ago, YouTube banned Bankless and Stani's Twitter was suspended after he made a joke. I don’t even want to imagine what I’d do if Twitter banned my account.

Wu Blockchain

@WuBlockchain

Aave founder Stani Kulechov has been banned from Twitter after joking about being Twitter's interim CEO.

719

9:08 PM • Apr 27, 2022

The power extends beyond user and content control, the platforms may offer developer tools which they are also in control of. For example, there used to be a time when developers could use Twitter's public API to create new tools and services. However, after 2012, Twitter limited data access, which obsoletes most of these tools and damaged developers' trust. Or for example just this week, Twitter announced that they'll no longer support free access to the API. Now the developers building tools and companies who use API for their business need to pivot.

Developers

@XDevelopers

Starting February 9, we will no longer support free access to the Twitter API, both v2 and v1.1. A paid basic tier will be available instead

19.7K

12:05 AM • Feb 2, 2023

Feature set is another point worth pointing out. Before Instagram had a tab where you could see every person's activity (a stalker's dream)? For better or worse, Instagram decided to change this; they also changed how posts are displayed on the feed.

The top-notch user experience is becoming to feel not so top-notch anymore.

Alongside the power which the centralized social media companies have, innovation in the social media space is very limited. There's a high barrier to entry for any new app because a social media app is only as powerful as its active users. So for a new social media app to be successful, it must build a huge network effect; otherwise, platforms like TikTok or Instagram can incorporate the same features.

Remember Clubhouse? A couple of months after Clubhouse's, Twitter created Twitter Spaces. Unfortunately, Twitter, which already had a much larger user base, was able to mimic the features, and Clubhouse fell into decline.

Decentralized Social Media

Over the past year, decentralized social media has been one of the most exciting topics in crypto, also known as "web3 social media." Before, most crypto apps were about DeFi (Decentralized Finance) or NFTs. However, given social media's role in our lives and the limitations that social media services present, there has been a large focus on building decentralized social networks.

Decentralized social is a new type of social media that operates on a decentralized network and isn't controlled by a single person or company. The common objective of decentralized social media is to offer more control to its users. Users do not need to trust and rely on a single entity. Developers can create new experiences using the open social graph; this way, users can communicate with each other irrespective of the app they use.

Different teams are building the infrastructure for web3 social media, each with unique advantages. While some objectives overlap, it's better to evaluate each protocol individually. In the next section of this post, we'll look closely at Farcaster.

Farcaster

Farcaster is a sufficiently decentralized social network. It is an open protocol that can support many clients, just like email.

The Farcaster Protocol is a decentralized social network built on Ethereum. Being an open-protocol is enables users to have a direct relationship with their audience and provides developers access to the underlying data & API's.

Btw, you can find me on Farcaster as edatweets.

To clarify, Farcaster is the protocol, and the team is also building a client on top of it. The Farcaster app is a Twitter-like app with some extra features. For example, there's an NFT tab where you can see the NFTs the people you follow buy; another fun feature is when you write "gm", the like button turns into a "GM" reaction button.

Why should I care?

• User & Developer Experience: The identity and relationship data is portable, so users can take it from app to app. This allows developers to build new apps with the same users without starting from scratch. For example, if you don't like the algorithmic feed displayed on Farcaster, you create a new one. Basically, the open social network allows you to create tailored experiences. To be honest, I have no intention of leaving Twitter today, but there are days when Twitter is not as fun, and I see lots of content that makes me angry or doesn't add any value. If I could carry my followings/followers to another app that only shows me content that makes me happy or inspired. In that case, I'd reconsider.

• Built-in Monetization: Crypto introduces financial incentives and opens the door for experimenting with monetization for a decentralized social media. Today, the predominated model for monetization on social media is advertising. With a decentralized social network and built-in token structure, you can leverage the existing social graph to create new tools with a financial layer. For example, I mainly go to Amazon today for online shopping; I don't even check other websites simply because I don’t want to signup and enter all my information again. However, suppose I could just carry my personal information anywhere. In that case, I could easily use other e-commerce websites and even see the reviews from people I know.

• New Use-Cases: An open social graph allows anyone to build apps allowing for permissionless innovation. This opens up opportunities for developing innovative and previously impractical or inefficient applications.

But really, how does it work?

Let's get technical (not too deep, but let's cover some basics). 🛠

We can break the Farcaster network into 3 layers:

1. Identity Layer: built on Ethereum and defines who’s on the network.

2. Data Layer:  stores messages by the people on the network. A Delta Graph on Farcaster is used to represent and synchronizes the state of the network; here delta refers to an action the user takes such as posting a message. There are Hub’s, which are nodes that have a full copy of the network and is used to synchronize the delta graph.

3. Application Layer: consumes the messages from the data layer to create different applications.

Here are some of the main challenges with a decentralized social network & how Farcaster approaches them:

• Identity: a decentralized social network must issue decentralized social identities and map them to users. Farcaster has two identity systems working together to provide a system that's decentralized & trustworthy. First, users must claim a unique numeric identifier called the Farcaster ID(fid) to get started. The fid is issued in a smart contract(Farcaster ID Registry) on Ethereum, once a user gets it, it's theirs forever. The fid is not a human-friendly identifier, and that's where a secondary name system comes into play. Users can claim a Farcaster name (fname), like "edatweets" which is unique and connected to the fid. This secondary name system is governed by a namespace to make sure that people can't impersonate one another (for example, I can't get the username: beyoncé). there’ll also be a price associated with the name (just like buying a webdomain) which will generate revenue for the protocol.

• Account Recovery: This has been a hot topic not just in decentralized social media but for the general user experience with Ethereum. Account abstraction, can solve account recovery for Ethereum accounts, but since its not implemented at the moment, Farcaster created its own recovery mechanism. Farcaster approaches recovery by allowing users to set a recovery address. The recovery address can request a transfer to a new address, for example when you loose access to your account. There's a wait period before the transfer is executed to ensure that the recovery address doesn't have total control and is only used when the primary address is absent.

• Applications: Users can interact with the network from different apps. An app needs some kind of power to create messages on behalf of users. You don’t want to give each app your private key, as that would give the app full control of your account. That's where signers come in to give the app access without giving away full control of the account. A signer is a key-pair that can sign messages on behalf of an fid. Users have the flexibility to choose the app they prefer, instead of having a single option.

This is a basic overview, if you’re interested I’d highly suggest took into the documentation and the video series.

Challenges w/Farcaster

• When building an internet-scale protocol, scalability is a huge challenge.

• Adoption. As with any new technology, getting people interested and actively using it is crucial. Developers will only want to come and build if there's a large set of active users. The good thing is that users only need to try out one app using the Farcaster protocol, and then they are on the network.

Farcaster Ecosystem

If a large number of developers are interested in the protocol and creating helpful tools, in that case, Farcaster can provide the building blocks for next-gen social media. The ecosystem is growing, and here's some apps and tools being built.

• Purple and Searchcaster are clients to search on Farcaster. If you don't like how your feed is displayed, you can choose a new client with a different algorithm or use these clients to search for specific topics.

• Phrasetown, Yup's Farcaster Feed, Omilos are different clients built on Farcaster. As a user, you can choose whichever UI they like the most.

• Eventcaster: a user-friendly events platform built on Farcaster, you can directly create, discover and join events from the app.

This is my second post on decentralized social media, the first one featuring Lens Protocol and now a dive into Farcaster. As you can tell, I'm pretty interested to see how crypto/web3 can offer a new approach to social media.

If you have any questions or comments, please feel free to reach out to me. Catch you on the next one!