@gammaswap/v1-core
v1.2.2
Published
Core smart contracts for the GammaSwap V1 protocol
Downloads
17
Readme
Description
This is the repository for the core smart contracts of the GammaSwap V1 protocol.
This repository does not contain implementations of GammaPools but rather abstract contracts that can be used to implement GammaPools for different types of CFMMs
The only implemented contract in this repository is the GammaPoolFactory which instantiates new GammaPools to enable the borrowing of liquidity from CFMMs, the PoolViewer which views storage data from GammaPools, and storage contracts to track loans and store price information.
The storage contracts to track loans and store price information are not necessary if a subgraph exists to do the same.
Steps to Run GammaSwap Tests Locally
- Run
yarn
to install GammaSwap dependencies - Run
yarn test
to run hardhat tests - Run
yarn fuzz
to run foundry tests (Need foundry binaries installed locally)
To deploy contracts to local live network use v1-deployment repository
Note
To install foundry locally go to getfoundry.sh
Solidity Versions
Code is built with solidity version 0.8.21. But the evm in hardhat is set to Paris for Arbitrum deployment.
Concrete contracts support only solidity version 0.8.21.
Abstract contracts support solidity version 0.8.4 and up.
Interfaces support solidity version 0.8.0 and up.
GammaPool.sol, GammaPoolERC4626, and GammaSwapLibrary.sol support solidity version 0.8.13 and up due to abi.encodecall bug.
We used solidity version 0.8.21 so that the code is ready to deploy to ethereum mainnet but set the evm in hardhat to Paris because at the time arbitrum does not support push0 opcode (shanghai evm).
Publishing NPM Packages
To publish an npm package follow the following steps
- Bump the package.json version to the next level (either major, minor, or patch version)
- commit to the main branch adding 'publish package' in the comment section of the commit (e.g. when merging a pull request)
Rules for updating package.json version
- If change does not break interface, then it's a patch version update
- If change breaks interface, then it's a minor version update
- If change is for a new product release to public, it's a major version update
How to Generate Minimal Beacon Proxy Bytecode
The source code for the Minimal Beacon Proxy is in /contracts/utils/MinimalBeaconProxy.sol
- Disable bytecode metadata hash in hardhat config file solidity: { settings: { metadata: { bytecodeHash: "none" } } }
- Run 'npx hardhat compile'
- Retrieve bytecode from MinimalBeaconProxy.json file in artifacts
*The reason for the changes in the bytecode depending on protocolId > 256 is because if protocolId > 256 then it takes 2 bytes in the bytecode instead of 1 byte, which means the bytecode must allocate this space.