VIP 13: Deprecate Arbitrum Support


Currently VOLT supports minting and redemption on both Ethereum mainnet and Arbitrum. The same VOLT rate is applied using the same contract code in separate mainnet and Arbitrum instances. Volt Protocol does not deploy PCV into yield venues on L2.

As we go deeper into the market governance design process, which will include a new PCV accounting and yield oracle system, it is becoming clear that maintaining a separate Arbitrum copy of the current placeholder system is too much overhead. Our priority is to first complete the VOLT system on mainnet and then extend its function. At the same time, we want to continue offering VOLT on L2 so that users can benefit from low fees when onboarding to the system.


Deprecate the VOLT Price Oracle and Peg Stability Modules on Arbitrum. Replace them with protocol owned liquidity (VOLT-DAI or VOLT-USDC) in the Uniswap 0.01% fee tier pool in a range covering the expected VOLT rate over the next 3-6 months. Occasionally rebalance as needed.

One advantage of this model is that it removes barriers to VOLT deployments on other L2 networks, as they will require only the deployment of the VOLT token and bridging some protocol owned liquidity, instead of the much larger overhead of our custom oracle and Peg Stability Modules on these chains.

There is currently ~40k VOLT circulating on Arbitrum. To ensure uninterrupted purchase and salability of VOLT on Arbitrum during the transition:

On Mainnet

  • use the PCV Guard to move 50k USDC from the Compound PCV Deposit to the Governor Multisig
  • use the PCV Guard to move 50k VOLT from the DAI PSM to the Governor Multisig
  • use the Governor Multisig to bridge 50k VOLT and 50k DAI to Arbitrum

On Arbitrum

  • provide liquidity in the VOLT-USDC pair on Uniswap v3 0.01% fee tier pool
  • use PCV Guard to withdraw liquidity from the VOLT PSM to the Arbitrum Governor Multisig
  • provide additional liquidity with the funds withdrawn in the same price range

The problem we’ve run up against in exploring a no-PSM model is the exposure the protocol would receive to toxic flow of arbitrage, or the need for manual rebalancing of the price.

An alternative model that retained L2 PSMs but eliminates the need for synchronous oracle updates across networks could look as follows:

  • add functionality for the L2 VOLT price to sync with L1 (does not require observation of L2 state from L1). Prevent mint or redeem if there has been more than 24 hours without an oracle sync.

  • use pessimistic accounting such that all VOLT available to mint on L2 is considered circulating in the yield oracle calculation. This way L1 does not have to check anything about L2 state.

  • add target and max buffer limits so that PCV Guards can rebalance liquidity between mainnet and Arbitrum safely

    • add a receiving contract so that yield can be sent from L2 to L1 and properly accounted for
  • add a 0.01% fee to VOLT mint and redemption on L2 such that even if the L2 and L1 VOLT prices deviate for a few hours, there will be no losses to arbitrage as the VOLT rate should never exceed 0.002% per hour.

A fancier version could also use a widening spread based on time since update, but the version described above seems adequate to accomplish our goals.

1 Like

The team has expanded our discussion to include the option of entirely deprecating VOLT L2 support. We believe this is the best course of action to ensure the protocol can meet its goals for best-in-class security while completing the MVP of market governance on a reasonable timeline.


The additional overhead and risk of maintaining a separate Arbitrum or other L2 oracle system for minting and redeeming VOLT, and infrastructure for cross layer PCV handling is substantial.

At the same time, demand on Arbitrum has not been large compared to mainnet, with 39,355 VOLT circulating on Arbitrum vs over 2m on L1. Total liquidity on L2 has grown substantially in the last year but is still a fraction of L1.

Our major development priorities are to:

  • onboard new venues
  • complete market governance
  • implement the veto module and effectively decentralize the protocol
  • add security measures such as Bad Debt Sentinel

In light of these considerations, Volt Protocol’s Arbitrum launch was premature. We know that L2 and low transaction fees are in Volt’s future, but this will require a comprehensive approach after the market governance system is complete, and include its own extensive design and audit process.

Deprecation Process

Deprecation will be formalized as part of a VIP and announced to the community. There are two major upgrades coming up that would require a change to the Arbitrum system. Deprecation should be included in whichever goes live to production first.

When the next venue onboarding occurs, the VOLT rate will be updated again to reflect the protocol’s average yield. At this time, further VOLT minting and redemption on Arbitrum can be disabled. All PCV remaining on Arbitrum will be sent back to the mainnet PSMs. This gives Arbitrum VOLT holders at least two weeks to redeem at their convenience, likely longer. Afterward, they will need to bridge back to mainnet to continue to benefit from zero fee, zero slippage PSM redemptions.

When the token migration to allow for the Veto Module is performed, we would also need to upgrade to a new VOLT token on L2. At this time, a PSM will be deployed on L1 allowing 1:1 conversion of old VOLT to new VOLT. If this migration should occur before the next venue onboarding (at soonest, it might occur in three weeks), it will likewise trigger an end to PSM availability on L2. oldVOLT holders on Arbitrum would need to bridge back to L1 to redeem if they do not do so prior to the upgrade.

1 Like

As a first step, further VOLT minting on Arbitrum can be disabled. Once this decision is confirmed, we’ll announce and continue to regularly remind and spread the word so that hopefully all genuine users (as opposed to airdrop farming bots that we can’t notify) will have ample time to redeem conveniently on L2.

The new deprecation timeline is as follows:

  • PSM redemptions on Arbitrum available as normal for 2+ weeks
  • when the next VIP batch is ready, switch to a fixed price PSM on Arbitrum (frozen at the VOLT price at that time)
  • leave enough PCV on Arbitrum for the circulating Arbitrum VOLT supply to redeem, withdraw excess PCV to mainnet

Arbitrum VOLT holders will therefore be free to redeem at their convenience on an ongoing basis, while there is no further overhead for maintaining an Arbitrum VOLT instance.

VIP-14-A will be created to decouple the Morpho, Maple and rate update on mainnet from the Arbitrum deprecation.

This VIP is the first step in Arbitrum deprecation. It pauses minting on the Arbitrum PSM and sets the oracle to a constant price oracle that does not accrue interest.

Deployment Steps

  1. deploy volt system oracle that has a fixed price

Governance Steps

  1. connect new oracle to oracle pass through with updated rate
  2. disable minting on USDC PSM
  3. disable minting on DAI PSM

Once these actions are complete, VIP-14 mainnet actions will be de-coupled from the Arbitrum actions.

PR Here: VIP-14-A Arbitrum Deprecation Proposal by ElliotFriedman · Pull Request #130 · volt-protocol/volt-protocol-core · GitHub

Once at least 3 external reviewers sign off, this VIP can go live.

1 Like

This proposal is being finalized as VIP 13, will be submitted to the timelock today and executed next Friday October 14.

Once executed, the VOLT price on Arbitrum will no longer increase, and will remain fixed at the price at time of update. VOLT will no longer be mintable on Arbitrum.

Holders of Arbitrum VOLT will be able to redeem with no fee at their convenience for an extended period, until governance decides to remove any unused redemption liquidity to L1 at a future date.

VIP 13 has been executed. Arbitrum VOLT is now redeemable at a fixed price of 1 VOLT = $1.056672 in DAI or USDC and will remain so for an extended period to allow users to redeem without needing to migrate back to L1.

Execution tx: Arbitrum Transaction Hash (Txhash) Details | Arbiscan