release v 1.1

.github/workflows/slither.yml

@@ -0,0 +1,49 @@
+name: Slither Analysis
+
+on:
+  push:
+    branches:    
+      - '*' 
+  pull_request:
+    branches: [develop, master]
+
+jobs:
+  analyze:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      security-events: write
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v3
+
+      - uses: actions/setup-python@v4
+        with:
+          python-version: "3.10.6"
+
+      - name: Install Foundry
+        uses: foundry-rs/foundry-toolchain@v1
+
+      - name: Install poetry requirements
+        run: >
+          curl -sSL https://install.python-poetry.org | python - &&
+          poetry install
+
+      - name: Run slither
+        run: >
+          poetry run slither . --sarif results.sarif --fail-none --compile-force-framework foundry
+
+      - name: Check results.sarif presence
+        id: results
+        if: always()
+        shell: bash
+        run: >
+          test -f results.sarif &&
+          echo 'value=present' >> $GITHUB_OUTPUT ||
+          echo 'value=not' >> $GITHUB_OUTPUT
+
+      - name: Upload SARIF file
+        uses: github/codeql-action/upload-sarif@v2
+        if: ${{ always() && steps.results.outputs.value == 'present' }}
+        with:
+          sarif_file: results.sarif

.gitignore

@@ -9,4 +9,5 @@ reports/
 .vscode
 .pytest_cache
 node_modules
-/contracts_flattened
+/contracts_flattened
+logs

README.md

@@ -2,8 +2,8 @@
 
 ## Problem
 
-Lido DAO governance currently relies on Aragon voting model. This means DAO approves or rejects proposals via direct governance token voting. Though transparent and reliable, it is not a convenient way to make decisions only affecting small groups of Lido DAO members. Besides, direct token voting doesn't exactly reflect all the decision making processes within the Lido DAO and is often used only to rubberstamp an existing consensus.
-There are a few natural sub-governance groups within the DAO, e.g. validators commitee, financial operations team and LEGO commitee. Every day they need to take routine actions only related to their field of expertise. The decisions they make hardly ever spark any debate in the comunity, and votings on such decisions often struggle to attract wider DAO attention and thus, to pass.
+Lido DAO governance currently relies on Aragon voting model. This means DAO approves or rejects proposals via direct governance token voting. Though transparent and reliable, it is not a convenient way to make decisions only affecting small groups of Lido DAO members. Besides, direct token voting doesn't exactly reflect all the decision making processes within the Lido DAO and is often used only to rubber-stamp an existing consensus.
+There are a few natural sub-governance groups within the DAO, e.g. validators committee, financial operations team and LEGO committee. Every day they need to take routine actions only related to their field of expertise. The decisions they make hardly ever spark any debate in the community, and votings on such decisions often struggle to attract wider DAO attention and thus, to pass.
 
 ## Solution
 
@@ -23,7 +23,7 @@ See [specification.md](https://github.com/lidofinance/easy-track/blob/master/spe
 
 ## EVMScript Factory Requirements
 
-### Methods Compability
+### Methods Compatibility
 
 **Every EVMScript factory must implement [`IEVMScriptFactory`](https://github.com/lidofinance/easy-track/blob/master/contracts/interfaces/IEVMScriptFactory.sol) interface.**
 
@@ -33,7 +33,7 @@ Methods from this interface are used by EasyTrack at the motion lifecycle.
 
 **Every action done by EasyTrack must be allowed to do also by Aragon Voting.**
 
-This requirement fills automatically in cases when easy tracks do actions provided by the Aragon application. But for contracts outside the Aragon ecosystem access to Voting must be provided explicitly. To grant such access you can use role-based control access contracts from the OpenZeppelin package. To see an example of how this pattern was used in EVMScript factories see the `RewardPrgoramsRegistry.sol` contract.
+This requirement fills automatically in cases when easy tracks do actions provided by the Aragon application. But for contracts outside the Aragon ecosystem access to Voting must be provided explicitly. To grant such access you can use role-based control access contracts from the OpenZeppelin package. To see an example of how this pattern was used in EVMScript factories see the `RewardProgramsRegistry.sol` contract.
 
 ### Onchain EVMScript calldata decoding
 
@@ -55,18 +55,15 @@ Permissions for EVMScript factory must contain only methods used by generated EV
 
 ## Project Setup
 
-To use the tools that this project provides, please pull the repository from GitHub and install its dependencies as follows. It is recommended to use a Python virtual environment.
+To use the tools that this project provides, please pull the repository from GitHub and install its dependencies as follows.
 
 ```bash
 git clone https://github.com/lidofinance/easy-track
 cd easy-track
-npm install
-
-# in case of pyyaml installation issue, it should be installed manually
-# see issue for details https://github.com/yaml/pyyaml/issues/601
-poetry run pip install "cython<3.0" pyyaml==5.4.1 --no-build-isolation
+yarn install
 
 poetry install
+poetry run brownie networks import network-config.yaml True
 poetry shell
 ```
 
@@ -142,7 +139,9 @@ Run tests with coverage and gas profiling:
 brownie test --coverage --gas
 ```
 
-#### Coverage notes
+### Coverage notes
+
+#### Immutable issues
 
 Current brownie version has problems with coverage reports for some contracts. Contracts which use `immutable` variables don't get on the resulting report. Details can be found in this [issue](https://github.com/eth-brownie/brownie/issues/1087). Easy Track uses `immutable` modifier in next contracts:
 
@@ -153,5 +152,19 @@ Current brownie version has problems with coverage reports for some contracts. C
 - [RemoveRewardProgram.sol](https://github.com/lidofinance/easy-track/blob/a72858804481009f2e09508ffbf93d8a4aee6c84/contracts/EVMScriptFactories/RemoveRewardProgram.sol#L23)
 - [TopUpLegoProgram.sol](https://github.com/lidofinance/easy-track/blob/a72858804481009f2e09508ffbf93d8a4aee6c84/contracts/EVMScriptFactories/TopUpLegoProgram.sol#L26)
 - [TopUpRewardProgram.sol](https://github.com/lidofinance/easy-track/blob/a72858804481009f2e09508ffbf93d8a4aee6c84/contracts/EVMScriptFactories/TopUpRewardPrograms.sol#L27)
+- [TopUpAllowedRecipients.sol](https://github.com/lidofinance/easy-track/blob/522ae893f6c03516354a8d1950b29b3203adae52/contracts/EVMScriptFactories/TopUpAllowedRecipients.sol#L29)
+
+The workaround for the coverage problem is removing the `immutable` modifier from the above contracts. Without modifier above contracts will be listed in the coverage report.
+
+#### No-branching issue
+
+Another brownie issue is that some functions do not get into the coverage report. For example `decodeEVMScriptCallData` of `RemoveAllowedRecipient` contract:
+
+```
+  contract: RemoveAllowedRecipient - 100.0%
+    RemoveAllowedRecipient.createEVMScript - 100.0%
+```
+
+Although in brownie coverage report explorer (`brownie gui`) in statements section the function body is highlighted green, which means it is covered.
 
-The workaround for the coverage problem is removing the `immutable` modifier from the above contracts. Without modifier above contracts will be listed in the coverage report
+It seems such functions are not reflected in % coverage report, due to absence of branching in the function body. Adding dummy branching brings them to the report.