The Staking Library is a first of its kind on-chain library that allows the creation of Staking Pool "instances", providing customizable functionality for all staking related needs on the Execution Layer.
The usage of library
should not be confused with the reserved solidity key library
. Instead, it refers to the library
defined within the scope of programming languages: A collection of prewritten code that can be used to optimize tasks. This collection of code is usually targeted for specific common problems. This is similar to the Portal's ability of providing multiple functionalities with customizability, and maintaining a set of smart contracts that can be deployed, upgraded and utilized by various types of users, permissionlessly.
In-depth understanding of EVM suggests that Ethereum is just a distributed computer. By that logic, smart contracts are no different than standard packages a python developer utilizes on their script. However, the approach to smart contract development focusing on protocols is so far user-centric. In past, developers discovered tools to distribute packages and maintain them, like git, making common functionalities easily accesible. Can we also distribute packages directly within Ethereum without disrupting the trustlessness, the novel idea of smart contracts?
To achieve this, Portal utilizes a version management pattern, LUP (Limited Upgradability Pattern), which is built on top of UUPS:
- User can deploy an UUPS proxy using a Remote Contract.
- Newly deployed contract delegates its functionality to the latest implementation contract.
- Newly deployed contract is used and controlled by the user.
- Remote Contract points to a referance of the latest version of the implementation contract.
- Parent can release a new version.
- Upgrading an instance is not mandatory.
- Owner can upgrade the code of the contract by pulling the address of the new implementation contract from the Remote Contract.
- However, Owner cannot change the code randomly.
In conclusion, Portal aims to make all functionality related to staking available on demand, easily accessible. Thus, Geode aims to remove the need for centralized or decentralized intermediaries that are surfaced as an undesired outcome of the lack of functionality on the Execution Layer.
For more information on the functionality of this repository please see our documentation.
A better, cleaner and safer development environment with Modular Architecture.
The Staking Library utilizes a Modular Architecture. Meaning all functionality is isolated within modules, to be used, inherited and combined by the packages. Modules also do not contain much functionality as they delegate to libraries. Making sure that shared logic among between package are compatible. Because, modules are abstract contracts that cannot be deployed and delegated, but libraries are.
There are currently only 3 packages: Portal, LiquidityPackage and WithdrawalPackage. However, there can be more modules and packages implemented later.
Additionally there are other contracts such as gETH, an ERC1155 contract, and its middlewares allowing every ID to have its own functionality.
For more information on the architecture of the smart contracts please see this document.
- Clone this repository:
git clone https://github.com/Geodefi/Portal-Eth
cd Portal-Eth
- Checkout to dev repository
git checkout dev
- Create
.env
file, similar to this
If mainnet is not forked, some tests related to ETH2 deposit contract may fail.
- Build the repository
npm install
- Compile the contracts
npx hardhat compile
For faster compilation use a local compiler:
- Right click on a smart contract
- Choose
Solidity: download compiler and set workspace local path
All unit tests are implemented within the test folder.
To run all tests:
npx hardhat test
To run just one test:
npx hardhat test path/to/test/file.test.js
To generate a coverage report:
npx hardhat compile --force
npx hardhat coverage
Deployments can be found here.
See our contributing guide.
See our ChangeLOG.
It is advised to audit these smart contracts with the order of:
- gETH
- Middlewares
- Modules
- DataStore Module
- Geode Module
- Stake Module
- Liquidity Module
- Packages
- Portal