Risk Factors

Use of the Increment Protocol, as with any decentralized finance application, entails certain risks. We have provided a list of some of the risks associated with the Protocol; however, the following discussion is not an exhaustive list of the risks associated with the Protocol and does not necessarily reflect the relative importance of the various risks. You should review the Documentation and the Terms of Service carefully and consult with your advisers before using the Protocol.

You should never trade or invest with funds that you can't afford to lose.

Risks Associated with Smart Contracts

All smart contracts are subject to risks. The Increment contracts have undergone testing, code reviews, internal audits and several external audits, but it is possible that they may still contain unknown bugs and produce economic errors that are inherently unforeseeable. In addition, the Increment contracts rely on certain third-party smart contracts. Although we believe these contracts to be reliable, they were not part of the audit and could contain errors.

Economic Risks

Liquidity

The protocol relies on liquidity providers to bring real collateral in order to mint virtual tokens to the Curve pool. Without enough liquidity remaining, traders may encounter issues when opening/closing positions, liquidations may become infeasible, and liquidity providers might be unable to close uneven positions.

Slippage

Unrealized PnL currently does not take slippage into account, so large positions can generate bad debt during liquidation. The Increment protocol limits the maximum position size that a single address can open, however, traders should be aware of this when taking positions with multiple addresses.

TWAP

The Increment protocol uses TWAP oracles for input validation of closing positions and liquidations. Manipulating TWAPs is more difficult than manipulating a spot price, but they can be tampered with if given sufficient financial resources. In addition, because TWAP is time-based, it could become out of sync with the markets during times of high volatility. Finally, because TWAP is generated from the protocol itself, it does not take into account prices on other exchanges and thus could become out of sync with the broader market.

Governance

Tokenholders will have the ability to vote on many aspects of the operation of the Increment protocol, from selecting the price oracle to allowing new trading pairs or tokens to the list of permitted collateral. There can be no assurance that that tokenholders will make decisions that provide the best outcome for traders.

In addition, there will be an “Emergency Admin” address controlled by a multisig made up of several core contributors and stakeholders of the Increment protocol. The Emergency Admin will be able to pause or unpause the entire Increment protocol. Implementation of the pausing function could be detrimental to user positions in case of price fluctuations. Pausing the protocol should only occur under extremely critical circumstances, such as if a hack were to occur.

More information on the types of operations that tokenholders can take part in can be found here.

Dependencies

Curve factory

As noted above, the Increment protocol relies on certain third-party smart contracts, which can be changed by the governance mechanisms of those contracts. In particular, Curve’s CryptoSwap powers our AMM. The admin (0x82561F43aEC744C076E2901d3fE23bfB8B03aD4d) of the curve factory (0x890b12affd59525e4f0273aF00Dcd9c4Ac7698C1) can change all parameters of the CryptoSwap contract. This changes the operation of the underlying trading engine impacting traders, liquidity providers and liquidators. Users of the Increment protocol may not have advance notice of changes in the CryptoSwap contract and this website may not be updated when such changes become effective.

Oracles

The Increment protocol currently uses Chainlink oracles to determine the funding rate of the protocol. When these oracles provide incorrect or delayed price information, the funding rates could be incorrectly estimated. In addition, liquidations may not be executed on time if oracle price updates too slowly or transactions are not processed. There can be no assurance that the current oracle or any oracle selected in the future will provide accurate information.

Reserve Assets

“UA” refers to “unit of account” by which transactions in the Increment protocol are denominated. Currently, one has to lock USDC to mint UA, in the same proportion. The protocol assumes a fixed price of 1 USD for each unit of UA. However, USDC is an upgradable contract where a native fee-on-transfer can be introduced. If such a mechanism is introduced, the Increment protocol would not longer be able to support USDC as the reserve asset due to accounting issues. For instance, if a 2 USDC fee is charged on every 10 USDC deposit onto Increment, the user should end up with 8 USDC but the protocol will see that as 10 USDC. In such a case the reserve asset will then need to be replaced with another asset.

The protocol might be changed through the governance process to allow other ERC20 tokens to be used as collaterals in the protocol – but while USDC’s value is almost completely static, the values of other tokens might change over time. To mitigate this risk, the Protocol includes a weight attached to collateral. The less stable the collateral, the lower its weight. This parameter may be changed by governance vote.

zkSync Era

The Increment protocol is built on zkSync Era, an Ethereum layer-2 protocol. A severe degradation in any part of this critical infrastructure will adversely affect the functionality of the Increment protocol.

For instance, if the sequencer on zkSync Era, which executes and batches L2 transactions, goes offline then Increment will become unusable and transactions will not go through. This can cause significant problems with oracle price updates and potential liquidations once the sequencer is back online. A sequencer oracle would detect potential sequencer downtimes and allow a grace period for users to react before updating oracle prices - however, so far there isn't a onchain sequencer oracle available for zkSync Era.

zkSync Era also offers a dedicated compiler responsible for transforming conventional Solidity and Vyper code into zkEVM bytecode. While there is extensive test coverage to ensure EVM compatibility, issues may still appear which may adversely affect the functionality of the Increment protocol.