0. Preface

The growth of the restaking ecosystem has resulted in myriad questions and conversations regarding the various actors of this nascent stack. Who is adding value in the restaking ecosystem, and what players might have the most upside over the coming years? In this piece, we will examine what we consider to be the current stack of layers for the restaking economy. We will then describe the situation of inevitable commoditization that multiple of these layers currently find or will soon find themselves in. Finally, we explore the emergence of verticalized restaking platforms. This new model for the organization of the current layers of the restaking ecosystem will hopefully provide clarity around where our team at Anthias Labs sees restaking developing over the next several years.

To begin, we present the current layers (and future layers) within the restaking economy. To be clear, some of these layers are currently non-existent or not as clearly defined in the restaking economy’s current form (e.g the intent layer and risk manager layer), but we think they will be significant layers in the iterations of restaking to come.

Liquidity Layer (e.g. Restakers)

The liquidity layer consists of whales, institutions, degens, and regular users who seek to earn yield on their capital. Liquidity is largely a commodity. However, product differentiation can be created via granular liquidity solutions, such as locking up liquidity for specific periods and providing larger amounts liquidity than competitors. An additional differentiator at the Liquidity Layer is quality of liquidity (e.g. price volatility of the liquidity). While projects like Lucidly and Royco are offering liquidity solutions for restaking projects, restaking platforms can also build in-house solutions to tackle these challenges.

Intent Layer (TBD)

The intent layer's value proposition lies in coordinating users' preferences, allowing them to whitelist trusted operators, set a yield target, and select a risk appetite, ranging from aggressive to more conservative AVSs. In general, a well-defined intent coordination layer has not yet emerged in DeFi. Similar to the liquidity layer, restaking platforms can build in-house intent layer solutions customized for restaking.

Risk Manager Layer (e.g. Gauntlet, Chaos Labs, and Block Analitica)

The risk manager layer is responsible for underwriting AVS risks, properly assessing the risk-return profile, and constructing portfolios for restakers to particpate in. The risk manager layer remains nascent due to the limited universe of AVSs and lack of real yield (until AVS payments are live).

Liquid Restaking Token (LRT) teams appear to be interested in handling the risk management layer, but most LRT teams seem to be set up as product engineering teams rather than risk management teams — will they bring in external risk partners or build in-house risk teams? The former seems be the primed direction currently, with Gauntlet’s partnership with Ether and Swell serving as a possible heuristic, but this layer is still significantly less defined.

Vault Infrastructure Layer (e.g. Etherfi, Renzo, Mellow, etc.)

The vault infrastructure layer consists of protocol-level smart contracts, which manage the functionality of managing liquidity from restakers, delegating to operators, opting into AVSs, and managing rewards. There is significant complexity in managing native restaking rewards (e.g resweeping), so this is non-trivial. However, this technology is commoditized since smart contracts are forkable. This layer is primarily developed by the LRTs as of today.

Operator Layer (e.g Chorus One, Figment, etc.)

The operator layer is a collection of entities (institutions and individuals) who run AVS software to execute tasks and ensure the operation of the AVS network. As of today, trust and branding have played a major role in the perceived quality of operators.

A significant question remains around how to ensure proper operator participation if an operator does not have its own capital at risk but rather solely delegated capital (principal-agent problem). Right now, operators seem to be abiding by Proof of Reputation, as in if they act maliciously or improperly, they will likely take a “reputational slashing” at the social layer. Questions remain about how this will play out in the restaking economy once it matures further.

Restaking Protocol Layer (e.g EigenLayer, Symbiotic, etc.)

This layer provides the necessary smart contracts required for AVSs to opt-in and liquidity to be provided. This layer also facilitates the required on-chain actions, thereby unifying all the actors in the ecosystem. While this layer is highly forkable and can be easily commoditized, this paper explores how many restaking protocol projects will accumulate power by becoming verticalized platforms.

While the graphic provided above reveals a very cleanly defined set of layers within the restaking economy, the reality will not play out in as picturesque a way. This is because every layer within the restaking market is incentivized to maximize its power and position of leverage. No layer wants to become a commodity.

This drive to avoid commoditization creates a hazier market structure as it will involve the following activities among other things:

• Verticalization: Players in the restaking market will attempt to expand their influence and control across multiple layers, leading to a more interconnected market structure.

• Private Liquidity Deals: Large institutions and wealthy individuals with the right relationships will seek to secure exclusive liquidity deals, potentially leaving smaller participants (regular restakers) stonewalled and at a significant disadvantage. These private deals may create an uneven playing field and limit access to certain opportunities for the average user.

• Fight for Exclusivity: To increase their branding power (among other things), restaking platforms will compete for exclusive partnerships with key players such as AVSs, risk managers, and operators. Securing these exclusive deals will create stronger monopolistic and network effect dynamics.

How can the different actors within the restaking economy avoid a race to the bottom and achieve market dominance? This is what we will explore in the next section of this paper. Enter the verticalized restaking platform.

In a well-constructed marketplace, restaking platforms should facilitate a low-friction process that efficiently matches depositors to operators and operators to AVSs. Underwriting details will be determined by aligning capital and operators with AVSs that meet their risk and payment requirements. The primary purpose of the restaking platform is to coordinate all the layers effectively, and the platform that achieves this best will have the most product power.

To strengthen their market positioning, both LRT protocols (e.g. Etherfi, Renzo) and restaking protocols (e.g. EigenLayer, Symbiotic), in particular, are incentivized to become verticalized restaking platforms, where they offer well-coordinated, custom economic security systems, involving the coordination of liquidity, intents, and operators, combined with specialized knowledge around network design and risk management.

A restaking platform’s ability to sell a bundled offering creates an incredible position of leverage for the company, as the platform fulfills custom and specific needs. The key is to take all these commodities and properly coordinate them for a refined, granular, and specialized product offering for the AVS. In this world, it is the restaking platforms that can get away with price bargaining power.

This is analogous to the way by which dominant Web 2.0 business like Salesforce evolved: create stickiness by expanding the platform, offering a level of customizability, securing relationships, and acquiring or bringing in-house value-additive commodities. We see the restaking economy following a similar path.

The road to well-defined restaking platforms will involve increasing entropy before there is a fully organized structure. There are still many aspect of the restaking economy that must be fully fleshed out:

• Slashing Conditions

• Assessing Corruption Risk

• The Principal Agent Problem

• Dual Staking Mechanism Design and Implementation

• Sophistication / Granularization of Economic Security

• Light Node Operators — e.g. Can regular users create successful operators without requiring the infrastructure of major operator/validator entities like Chorus One or Figment?

In this paper, we explored the current and future layers of the restaking economy and what we see to be the future verticalization of these layers. There is significant work to be done around underwriting operator slashing risk, AVS payment rates, LRT payout rates to stakers, and LRT insurance funds, but we are advancing. Onward.

Anthias Labs, June 2024

Site

Twitter

About Argo

Argo is an initiative launched by Anthias Labs. Our goal is to help teams design and implement corruption-resistant crypto protocols. In particular, our research focus areas are the following: dual token Proof-of-stake models, ZK proving systems, and novel verification mechanisms (e.g proof of sampling by the Hyperbolic Labs team).

Infrastructure protocols and middleware protocols oftentimes require a network of operators (also known as nodes) to maintain healthy operation. To discourage malicious activities of the operators, which would undermine protocol integrity, there must be proper detection mechanisms and punishment mechanisms in place to dis-incentivize corruption.

Detection mechanisms:

1. Proof of sampling: Verifying that a subset of data or actions is representative of the whole, ensuring the integrity of the system.

2. ZK proving: Using zero-knowledge proofs to demonstrate the correctness of computations or actions without revealing sensitive information.

3. Optimistic proof / dispute: Assuming actions are valid unless challenged, with disputes resolved through a predefined process.

Punishment mechanisms:

1. Slashing staked collateral: Reducing or removing the staked assets of misbehaving actors as a penalty.

2. Slashing delegated staked collateral: Penalizing misbehaving actors by reducing or removing the staked assets delegated to them by others.

3. Permanent removal from the system: Banning malicious actors from participating in the protocol indefinitely.

4. Temporary bans from the system: Prohibiting misbehaving actors from participating in the protocol for a set period.

5. Slashing rewards: Withholding or reducing the rewards earned by misbehaving actors.

6. Damaging social reputation / capital: Publicly identifying and denouncing malicious actors, harming their standing within the community.

Designing a robust and corruption-resistant system requires a systematic approach that considers the roles and responsibilities of the operator network, the verification and detection mechanisms, and the penalty mechanisms.

Step 1: Defining Operator Network Scope and Requirements

• Functionality: Determine what critical functions your operator network will perform. Will they be verifying transactions, building blocks, attesting data, monitoring smart contracts, or performing other roles?

• Decentralization: Evaluate whether your operator network needs to be decentralized to prevent central points of failure and reduce corruption risks.

• Scale and Accessibility: Decide on the size of the operator network and whether it should be open to anyone or restricted (e.g., permissioned or whitelisted). Consider if there should be barriers to entry, such as financial commitments or hardware requirements, which can vary significantly between protocols like Solana and Ethereum.

Step 2: Designing Verification and Detection Mechanisms

• Accuracy of Performance: Establish criteria to determine if an operator has fulfilled their responsibilities correctly. This might include automated checks or community reviews.

• Corruption Scenarios: Identify potential corruption scenarios specific to the roles and functions of the operators. What forms of corruption could occur, and how could they impact the network?

• Dispute Frequency and Resolution: Estimate how often disputes might arise and outline a process for resolution. Consider using mechanisms like optimistic proof or dispute resolution systems where actions are presumed valid unless challenged.

• Finality of Verification: Define the desired level of finality for verifications—how conclusive and irreversible should the validation of actions be?

Step 3: Designing Penalty Mechanism

• Assessment of Corruption Risk: Continuously evaluate the corruption risk by analyzing the potential gains from corrupt activities versus the losses from penalties and lost opportunities. Implement a risk-reward framework to understand the attractiveness of corruption.

• Penalty Structures: Develop clear, stringent penalty mechanisms for deterrence, including slashing staked or delegated collateral, temporary or permanent exclusion from the network, and financial penalties. Consider also the impact of non-financial penalties like damage to social reputation.

Assessing corruption risk and implementing effective surveillance mechanisms are crucial for system security. This can be done by benchmarking potential earnings and costs for all possible corruption scenarios, and determining the relative cost-to-earnings ratio as a risk benchmark.

Benchmarking the Potential Earnings for All Possible Corruption Scenarios

Analyze the risk of corruption by comparing potential earnings from fraudulent activities against legitimate earnings. Direct gains may include profits from fraudulent transactions or system manipulation, while indirect gains, such as increased influence or control over the protocol, can lead to price dumping or market manipulation. Compare these corrupt gains against opportunity cost earnings, including block rewards, transaction fees, and other protocol incentives. Conduct a risk-reward analysis, weighing the severity and probability of punitive outcomes against the benefits of corrupt actions.

Benchmarking the Costs for All Possible Corruption Scenarios

Consider not only the financial costs of corruption but also operational and reputational damages. Financial penalties, such as slashing of stakes, serve as a direct economic disincentive. Loss of future earnings through exclusion from the system or reduction of delegated stakes adds long-term costs. Other costs include operational and hardware expenses related to corruption, reputational damage resulting in loss of business opportunities, and legal and compliance costs.

At Argo, we are looking to serve as an "activist" operator for a handful of AVS ecosystems. Our activist approach means that AVS teams can lean on us as research partners, as they design and stress-test their staking networks. Furthermore, to support our AVS partners, we are building monitoring tools, such as real-time surveillance to assess operator activities and detect deviations from expected behavior. If you are interested in working with us, please refer to the contact information below.

Contact: Aaron Xie, @arnx813 on Telegram

This research piece by Argo and Tokensight has been written to provide a high-level overview of EigenDA and its operator network. In this piece, we will explore potential corruption scenarios in which an operator disrupts the network. This research is meant to serve as our second joint piece to share our learnings and educate the community on AVS cryptoeconomic security as operator networks begin to launch in the next few months.

EigenDA is a data availability solution, designed to enable Ethereum rollups to store and scale transaction data in a secure manner, to achieve high-throughput, highly-scalable, and lower gas-costing transactions than current alternatives. EigenDA establishes a new precedent for secure data availability by deriving its cryptoeconomic security via restaked Ether from EigenLayer.

Data availability is a crucial concept in blockchain technology, particularly for Ethereum rollups, which are systems designed to handle transactions outside the Ethereum main chain to increase throughput and reduce costs. Essentially, data availability ensures that all transaction data is readily accessible and verifiable by all participants in the network, a vital requirement. 

The main service providers in the data availability space are Ethereum (post-blobs), Celestia, Avail, and the recently introduced EigenDA. We are also excited about Optimum, a new solution that was announced at Harvard Blockchain Conference on April 13th, which the team attended!

The EigenDA system incorporates three primary roles critical to its operation: rollup, disperser, and operator. Each plays a unique part in enhancing data availability for Ethereum rollups.

Image from https://www.blog.eigenlayer.xyz/intro-to-eigenda-hyperscale-data-availability-for-rollups/

Rollup: This is the initiator in the EigenDA process. Rollups are Layer 2 solutions on Ethereum that bundle multiple transactions into a single transaction to reduce the load on the main Ethereum chain, thereby increasing transaction throughput and reducing costs. In the context of EigenDA, rollups post their transaction data to the system to take advantage of lower transaction costs and higher throughput, as an alternative to posting their data on Ethereum.

Disperser: The disperser’s role involves handling the data received from rollups. This entity takes the data blobs, breaks them into smaller chunks for the operators, and aggregates the chunks when needed. To get a better understanding of how dispersers work and the mechanisms and tech utilised (e.g erasure coding, KZG commitments, and multi-reveal proofs), please read this article. Rollups can operate their own disperser or utilize a third-party service provided by entities like EigenLabs.

Operator: Operators are node runners in the EigenDA network who receive the encoded chunks from the disperser. Their primary task is to verify the chunks, store the data, and maintain its availability. This verification and storage process is vital for ensuring the integrity and availability of the data within the network. The operators return a signature back to the disperser after storing the data, which is then aggregated to finalise the data’s entry into the system

EigenDA relies on EigenLayer primarily because it offers a robust and flexible infrastructure to implement Proof of Stake (PoS) mechanism, which EigenDA requires for the healthy operation of its operator network. Here's a detailed look at why this dependency is crucial:

• Ease of Development: Setting up a PoS system from scratch is complex and resource-intensive. EigenLayer simplifies the process of building a PoS system from scratch by providing a framework that projects can use and deploy. For example, one of the key challenges in any decentralised system is ensuring that all participants act in the best interests of the network. Misbehaviour, such as failing to store data properly or attempting to manipulate the system, needs to be detected and penalised. EigenLayer's PoS system provides the mechanisms for slashing (i.e., penalising) operators' stakes if they fail to meet their obligations, thereby aligning their incentives with the health and security of the network.

• Shared Security Model: EigenLayer's shared security model allows the same staked capital to be used across multiple applications, creating an economy of scale that reduces capital costs for individual projects like EigenDA. By leveraging restaked Ether (ETH) instead of requiring its own tokens for staking, EigenDA can tap into a larger pool of secured capital without needing to build and maintain its own staking and security infrastructure.

• Pre-existing Node Network: EigenLayer offers a marketplace coordination model where projects can readily access a network of nodes whose operators have already staked ETH. This means EigenDA can utilize a ready-made infrastructure of validators without the need to recruit and vet its own set of node operators.

As mentioned previously, Operators are node runners in the EigenDA network responsible for receiving encoded data chunks from the disperser, verifying their integrity using KZG commitments and proofs, and storing and maintaining the data's availability. They must stake collateral and follow slashing conditions, risking punishment if they misbehave, to ensure the network's security and the data's integrity.

Disruptions in the EigenDA service can occur through increased latency, limited access to data, or compromised data integrity, facilitated by a series of targeted attacks:

• Data Relaying Censorship: Attackers could manipulate the visibility and processing of data. By selectively blocking or ignoring specific transactions or their attestations, these attackers could distort the network's perception of data availability. This manipulation allows them to potentially benefit themselves or harm competitors by controlling which transactions are acknowledged and visible.

• Data Relaying Stalling: These same attackers could further undermine the network by slowing down the consensus process or opting out of it entirely. Such tactics introduce delays in data attestation and dissemination, increasing transaction confirmation times. This not only affects the network's speed and dependability but may also lead users to question its effectiveness and reliability.

• Data Attestation Corruption: In another form of attack, adversaries might manipulate the verification process to falsely certify incorrect or malicious data as accurate. This deceit leads the network to accept and rely on false information, enabling attackers to execute fraudulent transactions, manipulate market conditions, or even extract ransoms through threats to data integrity. The cascading effects of such corruption could severely compromise the associated rollups at multiple levels, particularly affecting their trustworthiness.

Determining whether it is economically feasible for an operator to corrupt the EigenDA network is uncertain, for now. This uncertainty primarily stems from the fact that EigenDA is a relatively new service. As such, it lacks a substantial amount of empirical data and has not undergone extensive real-world testing. Below, we identify some of the main variables that determine the economics, which should highlight the variability of the situation.

The profitability of corrupting the network can be calculated as follows:

Profit = Earnings from Corruption - Cost of Corruption

Factors to consider when measuring the profitability of a corruption scenario:

• Erasure Encoding Rate: Set between 10% and 50%, this rate affects data redundancy and the storage capacity required across the node network. A higher rate reduces the cost for an attacker, potentially increasing their incentive to corrupt.

• Monetary value of corrupting data attestations received and ability to successfully extract those funds

• Market value of the attacker's stake after the attack is discovered

Factors to consider when measuring cost of corruption:

• Cost of acquiring the necessary stake

• Principal-agent problem: Validators may act in their own self-interest rather than in the best interest of the restakers who delegate capital. In theory, if a validator is only staking delegated capital, their financial cost is $0.

• Social capital and legal consequences: Existing validators that are public entities must not only expend significant financial resources but also risk their social reputation and face potential legal consequences for engaging in malicious activities.

Over the next few months, we will be researching the following questions:

1. Will EigenDA initial operator set be whitelisted?

2. How centralized and entrenched on other AVSs will EigenDA’s operator set be? 

3. How many operators will there be and how concentrated will stake be among top operators? How reputable will they be?

4. How much TVL will the EigenDA network have and how does that attest to its security?

5. Are there more profitable attack approaches than attestation corruption for EigenDA?

6. How complex will their code be as an AVS? High code complexity may lead to an increased likelihood of bugs.

We will be conducting economic audits for more AVSs as they roll out. If you are interested in following along our research, please follow the Argo Twitter and TokenSights Twitter.

This economic security audit by Argo and Tokensight has been written to explain how the Omni operator network will work and to explore potential corruption scenarios in which an operator disrupts the network. This research is meant to serve as the first of many more audits to educate the community on AVS crypto-economic security as operator networks begin to launch in the next few months.

Omni is an interoperability chain, designed to enable Ethereum rollups to communicate in a secure, performant, and globally compatible manner. Omni establishes a new precedent for secure interoperability by deriving its crypto-economic security from a dual token model: restaked $ETH (via Eigenlayer) and $OMNI, its native token.

The job of Omni’s Operator Network is to participate within Omni’s CometBFT consensus mechanism as Validators. CometBFT is a Byzantine Fault Tolerant (BFT) consensus engine that powers Proof-of-Stake blockchains. It allows a set of nodes to securely come to consensus on the state of a blockchain, even if up to 1/3 of the nodes are malicious or fail in arbitrary ways. Projects like Osmosis, Juno, dYdX, Axelar, and more trust CometBFT for consensus.

To ensure that operators do not behave malicious, Omni employs a Proof-of-Stake (PoS) system such that operators participating as validators in CometBFT consensus must stake capital. If misbehavior is detected, an operator’s collateral will be slashed. Omni will employ a dual staking system, such that operators can utilize restaked Ether via Eigenlayer or $OMNI, the native network token.

CometBFT is a consensus mechanism that allows a set of non-trust validators to work together to constantly update the state of a blockchain. Each validator's voting power is proportional to their bonded stake, tying network security to honest validators' stake rather than just their count, incentivizing higher stakes.

Here's a high-level overview of how CometBFT works:

1. Proposer Selection: Each round, a proposer is chosen based on a deterministic round-robin algorithm considering each validator's voting power.

2. Proposal: The proposer broadcasts a block proposal containing a batch of transactions to all validators.

3. Prevote: Validators broadcast a prevote for the proposed block if valid, or nil if no valid proposal is received within a set time.

4. Precommit: If a validator receives >2/3 prevotes for the same block, it broadcasts a precommit for that block. If >2/3 prevotes are nil, it precommits nil.

5. Commit: If a validator receives >2/3 precommits for the same block, it commits the block to its local blockchain, finalizing the block. If >2/3 precommits are nil, it moves to the next round.

6. Round Progression: If a proposer fails to get sufficient prevotes or precommits, the protocol progresses to the next round with a new proposer until a block is committed.

We define cost of corruption as the amount of financial resources and social capital an attacker or group of colluding attackers would need to expend in order to successfully compromise the integrity and security of the Omni Network.

The two main corruption scenarios in the Omni Network are:

1. Greater than 1/3 Stake: A validator or set of colluding validators amass more than 1/3 stake of the Omni network and can engage in the following activities: transaction censorship or stalling.

2. Greater than or equal to 2/3 Stake: A validator or set of colluding validators amass more than 2/3 stake of the Omni network and can engage in the following activities: double spend.

Only Restaked TVL Scenario (No $OMNI Staking): Assuming a total value locked (TVL) of $1.5B in the Omni AVS contract on Eigenlayer, a validator or set of validators would need to acquire $500M worth of restake TVL to control 1/3 of the network stake.

Dual Staking Scenario (Restaking and $OMNI Staking): With $1.5B of restaked Ether in the Omni AVS contract on Eigenlayer and an additional $1.5B of $OMNI staked, an attacker or group of attackers would need to acquire $500M worth of restaked Ether and $500M of staked $OMNI, totaling $1B in required capital. The dual staking mechanism effectively doubles the cost of corruption compared to the solo restaked TVL scenario.

Solo Restaked TVL Scenario: With an assumed $1.5B of TVL in the Eigenlayer, a validator or set of colluding validators would need to acquire $1B worth of restake TVL to control 2/3 of the network stake.

Dual Staking Scenario: With $1.5B of restaked Ether in the Eigenlayer and an additional $1.5B of $OMNI staked, an attacker or group of attackers would need to acquire $1B worth of restaked Ether and an additional $1B of staked $OMNI, totaling $2B in required capital.

• Principal-agent problem: Validators may act in their own self-interest rather than in the best interest of the restakers who delegate capital. In theory, if a validator is only staking delegated capital, their financial cost is $0.

• Social capital and legal consequences: Existing validators that are public entities must not only expend significant financial resources but also risk their social reputation and face potential legal consequences for engaging in malicious activities.

An attacker controlling more than 1/3 of the stake in the Omni Network could potentially disrupt the network by censoring transactions or stalling the network.

• Transaction Censorship: One potential attack scenario is transaction censorship, where the attacker refuses to include certain transactions in the blocks they propose. They could potentially profit by accepting bribes to include or exclude specific transactions. However, the profit from such attacks is highly unclear given the nascency of Omni.

• Stalling: Another scenario is a "stalling" attack, where the attacker deliberately delays block confirmation by withholding their votes or voting for invalid blocks. This could be used as a form of extortion, where the attacker demands a ransom to resume normal operation.

Attackers controlling a supermajority (>66%) of stake in the Omni Network could potentially execute profitable attacks, most probably a double-spend. In a double-spend attack, the attacker sends a transaction, waits for it to be accepted, and then creates a conflicting transaction sending the same funds back to themselves, effectively spending the same funds twice.

The potential profit from a double-spend attack can be calculated as: Profit = Value of double-spent transactions - Cost of acquiring the necessary stake - Cost of executing the attack

For example, if an attacker double-spends $500 million and the cost of acquiring a 2/3 stake is $2 billion, the profit would be approximately -$1.5 billion. Furthermore, these examples assume the attacker can successfully cash out the double-spent funds and maintain their stake's value.

The profitability of a 2/3 stake attack depends on several factors:

• Cost of acquiring the necessary stake

• Value of double-spent transactions or bribes received for censorship

• Ability to successfully cash out double-spent funds

• Market value of the attacker's stake after the attack is discovered

• Legal and reputational consequences

To illustrate a simple example, let’s assume the total stake in Omni equals $300 million and the Gross Value Extracted is estimated to be the same in both attack types ($150 million). 

As presented in the calculated scenarios above and as recommendation for auditing purposes, Omni as an AVS would benefit from placing greater weight in its slashing conditions toward transaction censorship and stalling attacks (>1/3 Stake Attack) than double spend attacks (≥2/3 Stake Attack), since an adversary would profit from attacking the former and incur a loss from the latter.

Over the next few months, as several AVSs go live, the team will closely monitor the rollout of the operator networks. When Omni goes live, we aim to answer the following questions:

1. Will Omni’s initial operator set be whitelisted?

2. How centralized and entrenched on other AVSs will Omni’s operator set be? 

3. How many operators will there be and how concentrated will stake be among top operators? How reputable will they be?

4. How much TVL will the Omni network have?

5. Are there more profitable attack approaches than double spend for Omni?

6. How complex will their code be as an AVS? High code complexity may lead to an increased likelihood of bugs.

We will be conducting economic audits for more AVSs as they roll out. If you are interested in following along our research, please follow the Argo Twitter and Tokensights Twitter.