Wormhole Governor - Flow-Canceling Design Proposal (Temp Check)

[claudijd]

Background / Motivation

The Wormhole Governor imposes a limit on total outflows from any given chain, and those limits (both dailyLimit and bigTransactionSize) are hardcoded in the governor config here. This is fixed to a notional USD amount for each chain and works inside a sliding 24h window. No VAA will ever be held longer than 24hrs unless it is deemed fraudulent and then manually held by a super minority of Guardians using the administrative override controls available to individual Guardians, defined here.

The current status quo is that several chains are often at nearly 100% utilization of the Governor limits for ~10 Wormhole chains. This causes problems for Wormhole UX and frustration as this impacts the flow of user transactions which are neither verifiably fraudulent nor a compromise of the bridge itself.

It is possible that this congestion is caused by users that are incentivized to transfer assets in a loop, whether back-and-forth between two chains or in a more complex flow that eventually has assets return to their origin chain before transiting Wormhole again. This loop by definition can oftentimes be explained as arbitrage opportunities.

These loops present a denial-of-service problem, which was well documented and accepted in the initial implementation of the Governor as an acceptable trade off. The harm of a denial-of-service is an acceptable trade off given the protection value offered by the Governor.

Any flow out of a chain adds to the sum of outflows that are currently tracked. When this sum exceeds the Governor limit, VAAs will be delayed until the transaction amount fits inside the headroom of the 24hr sliding window. Even in the case where a circular flow is occurring, and the net movement is zero, the limit is still reached regardless of how high the Wormhole Guardians set the limit. The existence of persistent incentives outside of Wormhole's control that result in circular traffic mean that any limit increase has potential to be either temporarily or persistently exhausted.

In the face of persistent incentives it could always result in trivial consumption of the Governor limits. Should this behavior continue it will result in UX issues with Wormhole, L1s seeking ever larger limits, and Wormhole Guardians feeling ongoing pressure to increase limits beyond risk tolerances of a super majority. Left unchecked, this most certainly results in a net effect of the Governor being less effective and the protocol being pushed to accept unbounded limits -OR- an unusable protocol, which necessitates a change in the algorithm for how Governor limits are computed by the protocol.

Flow-Canceling Design

If circular flows are occurring on Wormhole, a Governor mechanism could be designed that could handle these flows safely without encouraging Wormhole Guardians to continue to ever increase the Governor limits for chains where circular traffic is occurring. To achieve this, inflows and outflows could be considered to measure the limit consumption. When assets come in, the Governor could decrement the limit utilization and effectively cancel out these flows to zero and only constrain situations when the net flow exceeds a threshold set by the protocol.

This design would allow for more volume to flow through the bridge while leaving the notional Governor limits as is, or even lowering them, without usability impacts or the acceptance of existential risk by Wormhole Guardians.

This effectively removes the problem of “loops” exhausting the Governor limit and giving way to seemingly infinite demand of the limit usage. When a loop is completed, assuming users are just moving the same amount of notional assets around and around, the net flow will be effectively zero.

Benefits:

• Users can use the bridge without competing with circular flows
• Wormhole can support significantly more flow volume without increasing the Governor limits
• Wormhole Guardians would be able to lower the absolute Governor limit for many chains, with no obvious user impacts.
• Wormhole protocol as a whole will own much less black hat risk and bounty payout risk due to the lack of artificially inflated governor limits.
• Wormhole Guardians lower their opportunity cost of not spending as much time changing Governor limits in response to circular flows.

Backtesting Analysis

In order to model the Governor strategies, a mock implementation of the Governor behavior was created and run against historical VAA flows to reason about how the cancel flow strategy would affect the exhaustion of Governor limits. This backtesting analysis is aimed at better reasoning about what Governor limits could look like (assuming the flow demand remains constant and of the same basic composition of the backtest data set).

Sui was first to be looked at, which has some of the most obvious benefits from such a flow canceling strategy and determined that the netflow was significantly lower than the overall volume. The below diagram demonstrates this with the red line representing the Governor usage during the seven-day period vs what a cancel flow strategy would represent as the Governor usage during the same period using the same VAA data set.

The above graph clearly shows that the net flows in and out of Sui largely cancel themselves out nicely and help demonstrate that circular flows in and out of this chain are roughly neutralized. We then took a closer look at a much larger set of chains to reason about whether this strategy more aptly applies in those other cases.

When running the cancel flow strategy on the below mentioned chains, we can see that over a 7 day period, Wormhole never reached more than 35% of the limits as they are defined today. It stands to reason that a conservative Wormhole Guardian position could be to cut the limits in half if a cancel flow strategy was used. This would allow existing activity to continue within the Governor limits while also offering more existential protection to the bridge and increasing net flow overall.

If the same backtest is run, but without the cancel flow logic, we can see on the whole that these circular flow patterns quite quickly spike the limits across a number of chains up to 100%. When these limits are hit there is a very noticeable UX impact to users of Wormhole who may be wondering why their transactions are delayed. This information also demonstrates that there are certain chains that still even without the cancel flow strategy operate much lower than the actual limit, presenting a further opportunity for conservative Wormhole Guardians to advocate for even lower limits.

Stablecoins vs. L1 Coins

A similar analysis was done, but filtered by token type. Our motivation was to determine whether the majority of the traffic was being caused by a small set of tokens. If so, Wormhole Guardians might be able to only perform flow-canceling on an allow-list of tokens that represents the majority of Wormhole transfers. This would allow the benefits of Flow Canceling without exposing the protocol to additional volatility risks incurred by canceling the flow of more volatile tokens.

Based on these results, it appears clear that stablecoin transfers (USDC and USDT) represent a large share of the “budget” of Governor limit utilization for several chains. By implementing a flow cancel mechanism that decrements just for these tokens, Wormhole Guardians could experience a higher total volume of transfers while also lowering, rather than raising, Governor limits.

Summary Recommendation

It is our recommendation that Wormhole Guardians consider foregoing further Governor limit increases temporarily (3-4 weeks) to allow necessary time for Wormhole contributors to develop an example implementation of a flow canceling governor, which would have properties as defined above.

Such a strategy would not only make Wormhole safer, but additionally far more usable for users, Dapps, and infrastructure providers who rely on Wormhole every day. If Wormhole Guardians would like additional information to help reason about the trade offs of such a recommendation, they are invited to pose additional questions or risks that should be considered before an example implementation can be presented later this month for consideration.

[prototypo]

Good plan. I suggest that the stablecoin usage (probably for arbitrage) may change over time due to factors beyond Wormhole's observations. Therefore, some form of ongoing monitoring coupled with the ability to promulgate an updated list of coins to flow cancel through to the Governors would make sense.

[1xCL]

Thanks for the analysis and the proposal. I think the net flow approach makes sense.

Also, I think the hard limit is really bringing UX down. Implementing soft limits based on 30-day moving average of daily usage would be more suitable in my opinion.

[johnsaigle]

Please note that a draft pull request for Flow Canceling has been opened and that it contains an allow-list of tokens that can reduce a chain's Governor usage.