Hardhat migration - Deployment scripts

.github/workflows/ci.yml

@@ -5,9 +5,9 @@ name: CI
 # Controls when the workflow will run
 on:
   push:
-    branches: [ master, Stable-Test, QA-Test ]
+    branches: [master, Stable-Test, QA-Test]
   pull_request:
-    branches: [ master, Stable-Test, QA-Test ]
+    branches: [master, Stable-Test, QA-Test]
 
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:
@@ -30,7 +30,7 @@ jobs:
       - name: Use Node.js 19.6.0
         uses: actions/setup-node@0a44ba7841725637a19e28fa30b79a866c81b0a6 # v4.0.4
         with:
-          node-version: '19.6.0'
+          node-version: "19.6.0"
 
       - name: Install truffle
         run: npm install -g truffle

.github/workflows/dependency-review.yml

@@ -6,17 +6,22 @@
 # PRs introducing known-vulnerable packages will be blocked from merging.
 #
 # Source repository: https://github.com/actions/dependency-review-action
-name: 'Dependency Review'
+name: "Dependency Review"
 on: [pull_request]
 
 permissions:
   contents: read
 
 jobs:
   dependency-review:
+    permissions:
+      contents: read
+      pull-requests: write
     runs-on: ubuntu-latest
     steps:
-      - name: 'Checkout Repository'
+      - name: "Checkout Repository"
         uses: actions/checkout@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871 # v4.2.1
-      - name: 'Dependency Review'
+      - name: "Dependency Review"
         uses: actions/dependency-review-action@5a2ce3f5b92ee19cbb1541a4984c76d921601d7c # v4.3.4
+        with:
+          comment-summary-in-pr: true

.github/workflows/scorecard.yml

@@ -2,9 +2,9 @@ name: Scorecard supply-chain security
 on:
   branch_protection_rule:
   schedule:
-    - cron: '0 0 * * 1'
+    - cron: "0 0 * * 1"
   push:
-    branches: [ "master" ]
+    branches: ["master"]
 
 permissions: read-all
 

.github/workflows/slither.yml

@@ -16,7 +16,7 @@ jobs:
       - name: Use Node.js 19.6.0
         uses: actions/setup-node@0a44ba7841725637a19e28fa30b79a866c81b0a6 # v4.0.4
         with:
-          node-version: '19.6.0'
+          node-version: "19.6.0"
 
       - name: NPM Login
         run: npm config set //npm.pkg.github.com/:_authToken ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -11,3 +11,21 @@ coverage.json
 .DS_Store
 integration-test/test.config.json
 .env
+
+node_modules
+.env
+
+# Hardhat files
+/cache
+/artifacts
+
+# TypeChain files
+/typechain
+/typechain-types
+
+# solidity-coverage files
+/coverage
+/coverage.json
+
+# Hardhat Ignition default folder for deployments against a local node
+ignition/deployments/chain-31337

.nvmrc

@@ -0,0 +1 @@
+v20.15.1

.pre-commit-config.yaml

@@ -1,35 +1,44 @@
 repos:
-- repo: https://github.com/gitleaks/gitleaks
-  rev: v8.16.3
-  hooks:
-  - id: gitleaks
-- repo: https://github.com/jumanjihouse/pre-commit-hooks
-  rev: 3.0.0
-  hooks:
-  - id: shellcheck
-- repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: v4.4.0
-  hooks:
-    - id: "trailing-whitespace"
-    - id: "end-of-file-fixer"
-      exclude: '\.tf\.json$'
-    - id: "check-yaml"
-      args:
-        - "--unsafe"
-    - id: "check-executables-have-shebangs"
-    - id: "check-case-conflict"
-# Project specific
-- repo: local
-  hooks:
-    - id: code-style
-      name: Project Style Check
-      entry: npm run lint
-      language: system
-      types: [solidity]
-- repo: local
-  hooks:
-    - id: unit-tests
-      name: Project Unit Tests
-      entry: npm run test
-      language: system
-      types: [solidity, javascript]
+  - repo: https://github.com/gitleaks/gitleaks
+    rev: v8.16.3
+    hooks:
+      - id: gitleaks
+  - repo: https://github.com/jumanjihouse/pre-commit-hooks
+    rev: 3.0.0
+    hooks:
+      - id: shellcheck
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.4.0
+    hooks:
+      - id: "trailing-whitespace"
+      - id: "end-of-file-fixer"
+        exclude: '\.tf\.json$'
+      - id: "check-yaml"
+        args:
+          - "--unsafe"
+      - id: "check-executables-have-shebangs"
+      - id: "check-case-conflict"
+  # Project specific
+  - repo: local
+    hooks:
+      - id: code-style
+        name: Check contact code style
+        entry: npm run lint:sol
+        language: system
+        types: [file]
+        files: ^.*\.sol$
+  - repo: local
+    hooks:
+      - id: code-style
+        name: Check typescript code style
+        entry: npm run lint:ts
+        language: system
+        types: [file]
+        files: ^.*\.ts$
+  - repo: local
+    hooks:
+      - id: unit-tests
+        name: Project Unit Tests
+        entry: npm run test
+        language: system
+        types: [solidity, ts]

.prettierignore

@@ -0,0 +1,16 @@
+build
+contracts
+typechain-types
+artifacts
+cache
+node_modules
+errorCodes.json
+
+
+truffle*
+migrations
+integration-test
+testHashQuote.js
+testRefundPegout.js
+testRegisterPegout.js
+testBridge.js

.prettierrc

@@ -0,0 +1 @@
+{}

.solhint.json

@@ -2,10 +2,7 @@
   "extends": "solhint:recommended",
   "rules": {
     "avoid-throw": "off",
-    "compiler-version": [
-      "error",
-      "^0.8.3"
-    ],
+    "compiler-version": ["error", "^0.8.3"],
     "max-line-length": ["error", 120],
     "max-states-count": ["error", 20],
     "avoid-tx-origin": "off",
@@ -23,4 +20,4 @@
     "no-unused-vars": "error",
     "no-empty-blocks": "off"
   }
-}
+}

CONTRIBUTING.md

@@ -1,4 +1,5 @@
 # Contributing
+
 ## How to contribute to RSK
 
 These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
@@ -7,15 +8,15 @@ These are mostly guidelines, not rules. Use your best judgment, and feel free to
 
 Continued code reviews and audits are required for security. As such, we encourage interested security researchers to:
 
-* Review our code, even if no contributions are planned.
-* Publish their findings whichever way they choose, even if no particular bug or vulnerability was found. We can all learn from new sets of eyes and benefit from increased scrutiny.
+- Review our code, even if no contributions are planned.
+- Publish their findings whichever way they choose, even if no particular bug or vulnerability was found. We can all learn from new sets of eyes and benefit from increased scrutiny.
 
 ### Code contributions
 
 A code contribution process starts with someone identifying a need for writing code. If you're thinking about making your first contribution, we suggest you take a moment to get in touch and see how your idea fits in the development plan:
 
-* Is it a bug in our [issue tracker](https://github.com/rsksmart/liquidity-bridge-contract/issues)?
-* Is it a novel idea that should be proposed and discussed first?
+- Is it a bug in our [issue tracker](https://github.com/rsksmart/liquidity-bridge-contract/issues)?
+- Is it a novel idea that should be proposed and discussed first?
 
 #### Review process
 
@@ -30,9 +31,9 @@ We make use of GitHub Checks to ensure all changes meet a certain criteria:
 
 Since this is a security-sensitive project, we encourage everyone to be proactive and participate in the review process. To help collaboration we propose adhering to these conventions:
 
-* **Request changes** only for correctness and security issues.
-* **Comment** when leaving feedback without explicit approval or rejection. This is useful for design and implementation discussions.
-* **Approve** when changes look good from a correctness, security, design and implementation standpoint.
+- **Request changes** only for correctness and security issues.
+- **Comment** when leaving feedback without explicit approval or rejection. This is useful for design and implementation discussions.
+- **Approve** when changes look good from a correctness, security, design and implementation standpoint.
 
 All unit and integration tests pass without loss of coverage (e.g can't remove tests without writing equivalent or better ones).
 
@@ -46,7 +47,7 @@ When automatic code quality and security checks are ready in the pipeline for ex
 
 ### Pull request etiquette
 
-* Separate your changes into multiple commits
-* If your pull request gets too big, try to split it
-* Each commit should at least compile, and ideally pass all unit tests
-* Avoid merge commits, and always rebase your changes on top of `master`
+- Separate your changes into multiple commits
+- If your pull request gets too big, try to split it
+- Each commit should at least compile, and ideally pass all unit tests
+- Avoid merge commits, and always rebase your changes on top of `master`