Anzen X UMA: Increased Governance Efficiency and Lessons Learned on Cryptoeconomic Security
We’re thrilled to announce our partnership with UMA to streamline governance for Anzen Protocol with oSnap, and to share insights and lessons learned on cryptoeconomic security from some of the earliest pioneers of the concept.
Anzen: Economic security for AVSs, inspired by UMA
Earlier this year, we introduced Anzen Protocol and released our Whitepaper outlining an automated system for managing AVS payments to restakers based on proven models for economic security. One of the first citations in our Whitepaper was the paper: “UMA Data Verification Mechanism: Adding Economic Guarantees to Blockchain Oracles”. The UMA team pioneered the concept of economic security; the Optimistic Oracle was one of the first protocols in the space built on a foundation of cryptoeconomic security (in this case, secured by the UMA token). In this paper, the UMA team defined a framework for evaluating economic security objectively, based on profit from Corruption (“PfC”) and Cost of Corruption (“CoC”). Anzen uses the PfC and CoC framework to objectively measure economic security for AVSs and determine if more or less security is needed in order to facilitate an automated update to the rate of payment to restakers.
Each AVS integrated in Anzen has a unique formula for determining their PfC and CoC. We then use a governance process to onboard each AVS and conduct a unique risk analysis process. Before a new AVS is added, a governance proposal must be submitted. During the governance process, the risk management calculations are reviewed and audited by relevant organizations, individual third party experts (as part of a bug bounty program), and the community at large. If any critical mistakes are found, the module must be re-audited. This is not a smart contract audit, rather it is a risk management and economic analysis audit. Once the module passes this stage, the proposal goes to a vote.
Streamlining Anzen's governance with UMA's oSnap
Our governance process will be streamlined with the integration of UMA's oSnap. Anzen community members and stakeholders will be able to vote on governance proposals off-chain using Snapshot, and the results of their votes will be executed on-chain with validation from UMA. The benefits of this are significant. Snapshot is a very easy and low friction tool for governance, which will allow broader participation from the community. The off-chain voting allows for gas savings from users and smaller holders. Snapshot is widely proven throughout the ecosystem and is used for governance for many top protocols.
oSnap is secured by UMA’s Optimistic Oracle (“OO”). In the case of a dispute, no transaction is executed, and it will need to be re-submitted. In the meantime, UMA token holders will review who was correct in the dispute and reward that person from the other party’s bond. In practice, it’s not hard to detect if the proposal is wrong — we would expect to never see a dispute short of a mistake. The cross-chain bridge, Across Protocol, already uses UMA’s OO in a similar fashion, with tens of thousands of calls each day.
Learnings from early developments in Cryptoeconomic security
UMA’s design for the Optimistic Oracle hearkens back to a 2014 research proposal put together by Vitalik Buterin, called SchellingCoin. The idea is that if separate and isolated parties have to submit information, and they will be penalized if they submit conflicting information compared to the majority of participants, they will submit true information. So, UMA created one of the first implementations of Slashing.
UMA incorporated learnings into the DVM 2.0 upgrade that launched in Q1 2023 by having voters' staked balances that participate in the DVM be susceptible to slashing. The slashing mechanism incentivizes voter participation and redistributes tokens from inactive and wrong voters to the stakers who voted correctly. This hardens the schelling point by adding a more punitive cost function to being wrong.
Another update included in the DVM upgrade was requiring stakers to wait 7 days before they can execute a request to unstake from the UMA system. This provides economic security against a 51% attack as the malicious attacker would be forced to hold their $UMA while the token price drops due to the successful attack. Requests to the DVM should be below the economic security from a 51% attacker’s loss on $UMA.
In situations where integrations have higher value settled by the oracle, alternative resolution strategies can be used to limit the consequence of the DVM being corrupted. For example, in the case of an oSnap dispute, UMA voters resolve the 2 WETH bond between the proposer and disputer, but do not determine if transactions can be executed by the Safe or not. This means that a 51% attacker is only able to gain bonds from an honest disputer rather than forcing through a dishonest transaction that drains a DAO’s treasury.
AVSs on EigenLayer also need to ensure their PfC is higher than their CoC. However, both the CoC and PfC are constantly in flux, based on changes in TVL, restaked amount, and token prices, to name a few factors. In practice, we expect these fluctuations to be significant and sharp. And remember, as soon as the PfC lowers below the CoC, an AVS can be attacked. So if the PfC shoots up, or the CoC declines rapidly, and the AVS cannot automatically respond, there can be a potential exploit.
When TVL increases or decreases, for most AVSs, the PfC increases or decreases correspondingly. As you can see in the charts below, a quick look at DeFiLlama shows that a number of protocols in DeFi have historically had rapid TVL changes as part of their normal growth (or token outflows).
When token price increases or decreases, for AVSs that will incentivize restakers with native token payments, the resulting APY they offer to restakers will fluctuate accordingly, and indirectly this may change the CoC as restakers join or leave. For AVSs that make use of Dual Staking, where in addition to ETH collateral being staked there are native tokens used as stake for economic security, token price fluctuation directly changes the CoC. Token prices can be extremely volatile, including in the short term, as you can see in the chart below:
In practice, we suggest that all AVSs will need to have an efficient buffer, whereby the CoC is intentionally higher than the PfC by a certain threshold. That way, in case there is a rapid change in CoC or PfC, the PfC will likely remain above the CoC at all times. This is similar to how over-collateralization works in DeFi. Users in DeFi don’t keep their LTV just barely high enough to avoid liquidation, they usually establish an efficient buffer between their LTV and the liquidation point. This ensures that if token prices change before they have a chance to adjust their position, their LTV will hopefully remain above the liquidation point. The same is true for AVSs; smart AVSs will pay slightly more economic security than the bare minimum to prevent an attack, therefore creating an efficient buffer.
In order to clearly understand the safety of a DeFi position, most DeFi protocols offer a Health Factor, which is a ratio of the actual LTV to the minimum LTV. This provides DeFi users with a clear understanding of how over-collateralized they are based on a single metric. Anzen introduces a similar metric for measuring the safety of the economic security of a given protocol, the Safety Factor (“SF”). The SF measures the buffer between the PfC and CoC. It is used to determine how large of a buffer an AVS has, which in turn can be used to interpret if the buffer is efficient according to the standards of the AVS. On one hand, if the CoC is many times higher than the PfC, the buffer is likely too large and the AVS is overpaying. On the other hand, if the buffer is very small and only a few percentage points away from becoming vulnerable to an exploit, the buffer is likely too small.
With the SF, Anzen is bringing the PfC/CoC framework pioneered by early adopters like UMA Protocol to AVSs on EigenLayer to automatically manage their economic security and restaker payments.
Join the Community
Learn more about Anzen Protocol by joining the discord community or following on X (Twitter). Visit our landing page and read our full Whitepaper here.
Learn more about UMA by visiting their website, helping to secure the OO, or following them on https://twitter.com/UMAprotocol.