Due to necessity and after discussing with the UMA team, their perpetual contract system was modified to fit the needs of our protocol. The contracts that were modified:
PerpetualCreator.solwas modified to create
Perpetual.solwas modified to create
SynthereumDerivativeFactory.solis a new contract that is derived from
SynthereumPerpetualPoolPartyCreator.solto restrict deployment access.
Below is an overview of the modifications:
The deposit/withdraw and create/redeem functions in
SynthereumPerpetualPoolParty.sol can only be called by the Synthereum protocol.
All funding rate logic was removed from
SynthereumPerpetualPoolParty.sol . In Synthereum, the token sponsor is a contract and any synthetic asset bought/sold on the open market can be created/burned in exchange for its exact value in collateral based on a price feed, which guarantees a perfect arbitrage between Synthereum and DEXs, thus maintaining the peg.
Since our assets are perpetual, if we wanted to upgrade or change something in the derivative contract (change of collateral, for instance) it would require a new perpetual token to be deployed, which will create friction for end-users, liquidity providers, and protocols where our synthetic tokens are integrated. Thus, we wanted to be able to deploy a new derivative contract, but link it to the preexisting perpetual token. This upgradability was added in
SynthereumPerpetualPoolParty.sol was split into separate libraries in order to optimize the gas consumption. Note: this is detailed below in the Technical Specification section.
emergencyShutdown functionality in
SynthereumPerpetualPoolParty.sol has been modified to not only be callable by the UMA DVM, but also by the Jarvis DAO.
SynthereumDerivativeFactory.sol receives the
Creator role it will register every
SynthereumPerpetualPoolParty.sol that is deployed through it with
Registry.sol so they can request prices from the DVM.