The purpose of this post is to structure an AVS, focus on a specific use case, and discuss considerations around the architecture. Special thanks to the gigabrains that sanity-checked the idea: Vijay from Superfluid, Eskender from ENS, Katya from Wormhole, @cleandood, Austin from Arbitrum, and Tina & Nader from Eigenlayer.

If you’re new to what EigenLayer and AVSes are, you can start at “What is EigenLayer?”. If you already know what AVSes do and want to get into the good stuff, skip to the “Proof of Reserves” section.

What is EigenLayer?

EigenLayer is a protocol that enables programmable trust, using Ethereum. It accomplishes this by introducing the concept of restaking, which makes Ethereum stake available for other protocols and systems to use.

Making Ethereum stake available for use by other protocols is valuable for other protocols, because it lowers the cost of capital for stakers. Stakers who need to cover costs don’t have to sell as much of a native token, and because most native tokens that are currently used for staking have not existed as long as ETH, they’re more likely to be more volatile, and more likely to be sold.

This makes space for a marketplace where protocols that need staked assets to validate state updates can match with stakers from the most protocol with the largest value staked, Ethereum.

Making Ethereum stake available for use by other protocols is valuable, because it lowers the cost of capital. Additionally, through the use of Dual Staking, protocols can let stakers stake in said protocol’s native token, or restaked ETH. Protocols that secure themselves through staking a native token don’t have to distribute as much of their native token in rewards.

What’s an AVS?

Put simply, an Actively Validated Service (AVS) is a protocol, service, or system that:

1. needs stake to validate a “Task”,

2. swaps out or partially subs out the need for validators to stake their own token with restaked ETH, and

3. tracks reputation, in order to slash malicious actors.

EigenLayer’s flagship AVS is EigenDA, which is a Data Availability layer (like cacheing, or short term data routing) secured by Ethereum Trust. Other AVSes include Shutter Network, Lagrange, Mantle, Blockless, AltLayer, Espresso (decentralized sequencer), Brevis, and more.

Proof of Reserves

Rewind to 2020. The world was in a weird place. I was fortunate to start working at KPMG’s Blockchain Center of Excellence on the week that everyone was sent to WFH for “two weeks.” A year and a half later, we built out a robust client service model advising institutions, F100s, and crypto-facing businesses on how to do business with one another safely. We were also granted a patent!

The patent was for a product that processes offchain and onchain data, and provides institutions with a single pane of glass to start and scale crypto-facing business lines. One of the core features was a means to generate a Proof of Reserve in a manner that was friendly to attestations by auditing firms. While firms like Armanino have taken on the role of auditing crypto exchange Proof of Reserves, I think there’s an interesting alternative:

A consortium of entities making Proof of Reserves attestations!

I know what you’re thinking:

SWIFT?
Proof of Reserves?
Why do we need that when we have cross-chain zk proofs, ZK coprocessors, and ecrecover? You don’t trust the chain?

To that point, I say this:

As of writing, DEXs are about 7% of CEX spot trading volume. Until DAOs can get BitLicenses, we’re in an environment where a plurality of the trading volume happens offchain. That means another FTX can still happen.

Exchange thefts, hacks, and acts of fraud hurt victims the most, and hurt the industry almost as much. Because crypto as a space isn’t sufficiently ubiquitous, we haven’t escaped the maw of respectability politics. That means when something bad happens with crypto, we’re all held responsible, and expected to defend all of crypto.

The value of a consortium of entities performing ongoing Proof of Reserves is three fold:

• It shows retail customers that the venue they’re using is legit, and not two big withdrawals or a market liquidation cascade away from insolvency and a founder’s disappearance.

• It shows market makers that they don’t have to treat a longer-tail exchange like a bus stop, and can leave liquidity there after they’ve executed a trade.

• It shows regulators that we can come up with our own solutions to problems.

The consortium of exchanges and cryptoasset venues would perform the following tasks:

1. Conduct Proofs of Reserve, and have other consortium members co-sign those proofs.

2. Store other exchanges’ Proofs of Reserves long-term.

3. Post collateral, for slashing and redistribution to customers in case of fractional reserve detection events.

4. Build a SWIFT-like messaging layer for consortium members, allowing for faster transfers between exchanges. This can be accomplished in a number of ways: JIT (you post a blob indicating that you will be transferring X amount of tokens to an address that the receiving Consortium Member indicated belongs to them), or delayed settlement (within a specific SLA, with economic or reputational slashing, and eventual ejection from the consortium for missing SLAs).

If you create a consortium of exchanges and trading counterparties, and give them a reason to be in a consortium, there can be benefits to customers. For instance, there’s a strong power-law distribution when it comes to trading volume across CEXs. With a consortium model, one could create a scheme where depositing is a function of your average trading volume and your assets in reserve.

Periodically, the consortium would be required to post a PoR. They’d do so by submitting a blob that contains:

• Signatures from hot + cold wallets that they can access, and

• A ZK proof attesting to whether the sum of their customer balances is <= sum of balances on wallets whose signatures were submitted.

To make sure that exchanges aren’t chronically underreporting their balances, there would need to be a trusted setup (in other words, a tamper-resistant, secure, setup) for their PoRs. Initially, an audit and/or technical review by an infosec firm to confirm that the implementation of the AVS code is correctly ingesting customer balances would be done. That way, nodes in this PoR consortium can perform faster state updates. There would be two types of attestations:

1. Interim Attestation (IA): an interim proof that decrements the amount of tokens being sent outbound. This is sent so that other consortium members can keep track. Should there be a need to challenge an attestation, consortium members archiving these proofs will have enough information to do so.

2. Reserve Attestation (RA): An attestation from an auditor or neutral third party that funds are all accounted for, and that the systems in place to detect and ensure full reserves have not failed. Similar to a rollup, this would net settle all of the previous IAs since the last RA, and generate a proof indicating that the consortium member holds sufficient reserves for their business activities.

Proof of Reserves as an AVS

Using a DA layer like EigenDA, a node in the consortium could then disperse that blob to other nodes, who would then attest to the validity of that check, aggregate their signatures, and eventually post it onchain.

Once you’ve established this network of venues that are able to verify that one another’s balances are at least the amount of assets they attest to holding, you can use that same architecture to create cross-exchange messaging for balances. Since DA throughput is higher than most of the chains that CEXs support, you can append that DA blob with a hot wallet PoR and an unconfirmed transaction, and a recipient node within this consortium can choose to credit that before funds have settled onchain.

Coinbase and other exchanges have tokens in deep cold storage, with very complex key generation, storage, and access set-ups. To address the need to prove they have access to those funds without incurring outsized op-sec risk, one could structure different SLAs, and different collateral requirements to compensate for the difference in SLAs. To that end, this architecture finds a healthy balance between needing to constantly access cold storage, and saying “Funds are SAFU” when an exchange’s customers need assurances that their balance is backed by the tokens they sent.

In addition to exchanges, custodian settlement networks like BitGo and Fireblocks, and institutional margin accounts like what FalconX offers could be added into the consortium.

Proposed Architecture

In the above diagram, you can see four entities:

1. AVS Operator: The exchange or trading venue participating in attestations in order to meet regulatory requirements, provide customer trust, or participate in 0-confirmation transfers.

2. DA Layer: The Data Availability layer used to communicate IAs, RAs, and 0-confirmation transfers. This DA layer should also keep track of reputation, slashing conditions, forced removal of bad actors, and other parameters determined by the consortium.

3. AVS Nodes: The other nodes in the consortium. Nodes can be other venues, or parties incentivized to participate.

4. Base Chain: The chain on which IAs, RAs, and relevant DA and AVS information are settled.

Entry into Consortium

1. A venue, in collaboration with an auditor or other neutral third party, will undergo a trusted setup that ensures the following:

   • the party joining the consortium has the infrastructure necessary to post DA blobs and participate in signing blobs within agreed upon SLAs,

   • the party joining the consortium isn’t already running a fractional reserve,

   • the genesis state is valid,

   • there are systems and controls in place (software, operational, infosec, etc) to log and detect anything that could affect validity of attestations, and participation in the AVS.

2. Once the neutral third party has validated the joining party’s setup, the consortium may decide to permit the Operator to submit blobs immediately, or only act as a propagating node for a period of time. This allows for the consortium to gather live data on how well the new entry maintains participation in the network within SLAs.

IA Workflows

For outbound withdrawals:

1. AVS Operator has a customer or client that submits a withdrawal transaction on their platform.

2. AVS Operator logs that transaction, queues a withdrawal on-chain, and submits an IA in the form of a blob attesting to their customer balances being fully reserved.

3. The blob gets sequenced, finalized, and propogated between other DA nodes.

4. If the withdrawal fails, or does not get confirmed within an SLA that the consortium has agreed upon, the sending Operator may be slashed and/or have their reputation impacted.

For inbound deposits:

1. AVS Operator watches AVS for 0-confirmation deposits from other consortium members.

2. Once one has been observed (in a mempool, or as a blob), the recipient Operator can credit the deposit, based on Operator or consortium-specific risk management parameters.

3. If the withdrawal fails, or does not get confirmed within an SLA that the consortium has agreed upon, the sending Operator may be slashed and/or have their reputation impacted.

RA Workflow

Periodically, there will be a need for an external third party to perform ongoing assessments similar to the tests of effectiveness of controls, and soundness tests conducted when the operator was initially added to the consortium. The purpose is to make sure that the offchain business logic has not failed in a way that would evade detection via IAs. Once this assessment has been completed, the Operator should post a Reserve Attestation as a blob, signed by the external third party that conducted the RA. The third party should add a quantification of the findings, in order to inform a reputation score, and make it easier for other operators to programmatically adjust consortium benefits programmatically.

For instance, if a challenger exchange had a previous RA with 3 material defects, their reputation would suffer, and other operators may choose not to credit 0-confirmation deposits originating from said challenger. But if the challenger remediated those issues, and the subsequent IAs and RA revealed no material defects, then other consortium members may be inclined to programmatically resume 0-confirmation deposits originating from the challenger exchange.

Considerations

There are a lot of considerations at play, from an technical, risk management, and incentive alignment perspective. We’ll start with looking at the technical considerations.

Technically, this needs to be performant, and not extensively high-lift for consortium members to integrate. Without insider knowledge on how each consortium members’ stack works, I will assume that they have the technical ability to participate in this consortium. For the EigenLayer considerations, I will look at their docs:

1. What “Tasks” are being performed?

   For a consortium, there are a number of Tasks:

   1. Signing a message for a Proof of Reserve attestation

   2. Validating the PoR blob sent by another node

   3. Posting that PoR onchain

   4. Processing DA layer credited deposits while watching for onchain deposits to settle the credit

   5. Negatively impacting the reputation of nodes that do not settle DA layer credited deposits within agreed-upon SLAs

   6. Slashing actors that have not covered

   To start, these tasks would make up the tasks that the consortium AVS accomplishes, and could expand in complexity from there. One could imagine a governance layer where they agree upon supported chains, SLAs, buy-in and maintenance costs, trading revenue across exchanges going into an insurance fund, and other features.

2. What kind of Trust does your AVS want to inherit?

   There are three core ways to think about the trust that EigenLayer provides: Economic Trust (having a lot of capital staked), Decentralized (geo-distribution of stakers), and Ethereum Inclusion Trust (trusting that ETH will include your transaction in the next block).

   For the consortium, Economic state matters a lot, as there needs to be some recourse if a bad actor suffers a loss of reserves. Additionally, building this AVS with Ethereum Inclusion Trust in mind would make using and participating in the consortium attractive (basically guaranteed deposit/withdrawals).

3. Is the work to be done by the operator lightweight or heavyweight?

   Because this AVS would be effectively permissioned, this wouldn’t have the requirement to be lightweight. That said, since exchanges run a lot of complex tech to support their business lines, a low lift approach would likely increase buy-in.

4. What are the slashing conditions?

   1. Slashing Conditions:

      1. If a Fractional Reserve is detected, or

      2. If an unpaid or unsettled deposit for another exchange has not been settled.

   2. Reputation:

      This is consortium-dependent, but I would imagine that reputation would a function of:

      1. product of time-weighted TVL and blob-signing percentage within SLAs,

      2. the quotient of 0-confirmation deposits/withdrawals to and from the exchange and total TVL, and

      3. sum of a quantified measure of each RA (ideally the auditor/neutral third party scores the Operator, or quantifies the findings in the RA).

      The consortium could add or remove other metrics, but the guiding principles were to incentivize keeping your node online, sending out withdrawals in a timely manner, making sure that there are little-to-no material findings in the RA to warrant demerits, and the amount of hot wallet turnover relative to TVL. The last metric is to reward challenger exchanges for ramping up and participating, as incumbent exchanges would have more capital to allocate towards consortium efforts, and more TVL.

Risks

What are the risks that each of the major counterparties would have?

1. Incumbent Exchanges

   The biggest risk for an incumbent exchange joining this consortium is the risk of contagion. In the aftermath of 3AC, Terra, and FTX, credit has dried considerably, and exchanges don’t want a demerit on their reputation if one of their partners falls down on a 9-figure trade. Additionally, because liquidity begets liquidity, an exchange with most of the trading volume doesn’t necessarily want to give up their lead, as it will be difficult to get that lead back.

   This risk can be mitigated by way of the consortium creating operator-specific SLAs on signing blobs, SLAs on time between RAs, velocity and sizing limits on unsettled deposits/withdrawals, and other metrics. If an exchange has some level of ongoing assurance that other participants in this consortium are not running a fractional reserve, they’re more likely to accept lower confirmation deposits from those exchanges, and can use that to attract new customers from other exchanges.

2. Challenger Exchanges

   The risks for smaller, challenger exchanges are that they will expend a lot of capital trying to retain volumes, but may lose customers to bigger exchanges the moment incentives dry up. Additionally, because smaller exchanges have less trading volume to rely on, they may be led to take riskier bets in order to make and earn market share. Moving fast and breaking things might increase attack vectors in cumulative ways.This risk is mitigated through the trusted setup and ongoing RAs. A challenger exchange participating in this consortium will signal to the market that they are reserved on an ongoing basis, and volume will migrate to exchanges that market participants can trust.

3. Market Makers

   Market Makers take on the risk of an exchange blowing up while custodying their capital. To mitigate that risk, market makers and customers either self-custody their capital, or keep capital on larger exchanges. The risk of an exchange being insolvent decreases if they’re participating in this consortium.

Incentives

How do you incentivize this group?

1. Big Exchanges

   There are desks that focus primarily on longer tail assets, and don’t go to the bigger venues because there’s no need. If barriers to transferring assets between exchanges were made lower, then desks market making on exotic desks could trade on the bigger exchanges without needing to wait as long. Additionally, bigger venues move slower than their longer tail counterparts. While that limits the downside of expending resources into tar pit narratives (features that aren’t scalable), it also limits upside, and runs the risk of losing early adopter trading volumes. By making it easier to bridge to these bigger exchanges, these venues may see more volumes from churned users without expensive re-engagement campaigns.

2. Smaller Exchanges

   Lower cost of capital for UA (user acquisition). Joining the consortium gives them access to more volume, and bigger MMers without paying as much for retention. It also acts as a marketing play, where retail and institutions can look at a smaller exchange taking part in PoRs that are validated by larger competitors, and trust that the exchange is here to stay, and committed to keeping customer cryptoassets safe.

3. Market Makers and Traders

   Market Makers and Traders benefit from the consortium because there’s easier bridging between exchanges lowers opportunity cost of capital. Lower opportunity cost of capital -> lower cost of execution. Proofs that the longer tail exchanges are fully reserved means that MMs don’t have to treat smaller consortium members like a transit stop (and if they do, they can quickly send their funds back out to another exchange).

Conclusion

In conclusion, EigenLayer has taken an idea that is, on its face, risky, and taken a lot of consideration into outlining and mitigating those risks.

1. With AVSes and Attributable Security, you can bootstrap a new service that requires stake, make operators provide additional stake on the side, create a reputational layer for slashing, and create incentives for all involved parties.

2. A network of exchanges providing Proof of Reserves attestations feels dull, but there’s an interesting design space that opens up once you have multiple exchanges that can send transactions quickly. Using a DA layer, and an incentivized service scheme like an EigenLayer AVS is one way to extend the design space in a way that makes room for new synergies.