Here we would like to share with you some ideas on the update of Opium Protocol to Version 2. First version of the Opium Protocol was designed 3 years ago when there was neither such term as ”DeFi ‘’ nor there were the exciting innovations that we see today in space. Also, experiments with building on top of the Opium Protocol showed that there are some aspects that can be further improved or adjusted for both more efficient gas usage and a more future-proof development of the protocol. Moreover, some recent best practices can be introduced into the protocol to keep it up-to-date with the current ecosystem.
The main pain points and also possible solutions are described below. You can share your ideas on the topic to identify the best possible solutions for the sake of a more efficient community-driven development of the second version of the protocol.
Token standard
From a user perspective, the focus of the Opium protocol v2 is interoperability with the DeFi ecosystem at large.
The current version of the Opium protocol makes use of its own token standard - erc721o. At the time the first version of the Opium protocol was developed it made sense -it was DeFi before DeFi- to implement custom financial logic tailored for a specific protocol. Nowadays, however, the trend is ‘money legos’ - composability with other protocols- and maintaining a custom token standard has the downside of making a protocol insular in a sea of interoperability. For this specific reason, we have decided to replace ERC721o with ERC20.
ECR 721o is not widely adopted, but there is a very similar ERC1155 standard that became popular and got successfully adopted over the last years.
At the moment there is a connector used to bridge ERC721o into ERC20 and back when needed, but we would propose to use ERC20 positions directly by the protocol. ERC1155 would potentially save some gas, but on the other hand the wide support enjoyed by the ERC-20 standard gives more advantages in our opinion. As first pioneered by Uniswap, the usage of ERC-20 factories has become a common practice in the industry and, in the case of Opium 2.0, it will not affect neither the logic nor the user experience.
Practically speaking, this means that upon creation of a derivative on the Opium protocol v2 two ERC20 contracts will be deployed - representing a SHORT and a LONG position.
Their creation will be delegated to a Factory contract which will use the create2 opcode to deterministically create new position addresses and mint the requested amount of positions. If two ERC20 contracts have already been deployed on the respective addresses then the factory contract will only forward a call to mint the requested amount of positions.
Alongside the create2 opcode, the EIP 1167 (Minimal Proxy Contract) will also be implemented to optimize the gas consumption of the minting operations.
Users will also be able to acquire and execute a non-discrete amount of positions - i.e: 1.2 of a derivative, or 0.1 of a derivative etc…
Redemptions
Another user-facing feature that will be available is the exchange of market neutral positions for the originally deposited margin. This means that if a user will be holding an equal amount of ERC20 SHORT and ERC20 LONG, they will be able to swap it back for their original margin. Similarly, it will also be possible to burn multiple market neutral positions at once and receive all their respective collateral.
Solidity
From a more technical perspective, the protocol v2’s codebase will be using the latest solidity compiler version 0.8.x and we will switch from the truffle-web3 tech-stack to the more modern hardhat-ethers.js-typescript stack. There will be other optimizations in the Core contract that are meant to decrease the gas consumption - such as refactoring how the polymorphism is used for the create and execute function so that the creation and execution of single derivative positions won’t make use of expensive arrays, changing the visibility of some functions from public to external etc…
Upgradability
The upgradability pattern will also be implemented for the Core, Registry and TokenSpender contracts to ensure more flexibility in case additional changes will be required. The upgradability will be delegated to the governance so that no single entity will be able to apply changes to the protocol without the proper oversight of the community.
Overall, more parameters will be delegated to the governance logic of the protocol. Those parameters will include the fees for the execution of derivatives, the period during which a position can be cancelled, the synthetic authors’ fee, the proposal of new timelocks and token spenders. Furthermore, the governance contract will be refactored to implement the OpenZeppelin access control logic.
Segregation
Lastly, we propose to refactor the protocol following a pattern similar to Uniswap’s Core/Periphery contracts. The Core contracts will be responsible for executing the main business logic of the protocol and the periphery contracts might include desirable features that are proposed by the community - for instance integrations with other protocols such as AAVE and Compound for the usage of interest-bearing collateral.
Following the ethos of interoperability with which we started the post, a greater focus will be progressively placed on documentation, documentation, documentation. Sample repositories that will showcase how to develop derivative contracts on top of the Opium protocol will be made available and, overall, a greater emphasis will be placed on positioning Opium to be the protocol choice for builders and financial engineers.
Migration process
Opium Protocol was designed in a way that does not allow anyone to interfere into the derivative lifecycle, thus all positions created in v1 will remain functional till its expiration. New positions will be created via the new version. Similar to Uniswap version upgrades.
