Merge branch 'master' into non-standard-erc20-list

Author: montyly

.github/workflows/deploy.yml

@@ -19,7 +19,7 @@ jobs:
       CARGO_TERM_COLOR: always
 
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
         with:
           fetch-depth: 0
       - name: Install mdbook
@@ -28,7 +28,7 @@ jobs:
       - name: Build artifacts
         run: mdbook build
       - name: Upload artifact
-        uses: actions/upload-pages-artifact@v1
+        uses: actions/upload-pages-artifact@v3
         with:
           path: ./book
   deploy:
@@ -43,4 +43,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v1
+        uses: actions/deploy-pages@v4

.github/workflows/echidna.yml

@@ -126,19 +126,19 @@ jobs:
             expected: 'testERC20PermitDeposit(uint256):\s*passing'
           - name: MultiABI
             workdir: program-analysis/echidna/example/
-            files: multiabi.sol
+            files: allContracts.sol
             solc-version: 0.8.0
-            config: multiabi.yaml
+            config: allContracts.yaml
             contract: EchidnaTest
             outcome: failure
             expected: 'test_flag_is_false():\s*failed'
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
 
       - name: Checkout Damn Vulnerable DeFi solutions
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         if: startsWith(matrix.workdir, 'dvdefi')
         with:
           repository: crytic/damn-vulnerable-defi-echidna
@@ -167,7 +167,7 @@ jobs:
           contract: ${{ matrix.contract }}
           config: ${{ matrix.config }}
           output-file: ${{ matrix.files }}.out
-          solc-version: ${{ matrix.solc-version || '0.5.11' }}
+          solc-version: ${{ matrix.solc-version || '0.8.0' }}
           echidna-workdir: ${{ matrix.workdir }}
           echidna-version: edge
           crytic-args: ${{ matrix.crytic-args || '' }}

.github/workflows/lint_format.yml

@@ -12,7 +12,7 @@ jobs:
 
     steps:
       - name: Checkout repository
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
 
       - name: Set up Node.js
         uses: actions/setup-node@v3

.github/workflows/lint_links.yml

@@ -19,7 +19,7 @@ jobs:
   markdown-link-check:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - uses: gaurav-nelson/github-action-markdown-link-check@v1
         with:
           use-quiet-mode: "yes"

.github/workflows/manticore.yml

@@ -21,9 +21,9 @@ jobs:
     strategy:
       fail-fast: false
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Set up Python 3.8
-        uses: actions/setup-python@v4
+        uses: actions/setup-python@v5
         with:
           python-version: 3.8
       - name: Install dependencies

.github/workflows/slither.yml

@@ -21,9 +21,9 @@ jobs:
     strategy:
       fail-fast: false
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Set up Python 3.8
-        uses: actions/setup-python@v4
+        uses: actions/setup-python@v5
         with:
           python-version: 3.8
       - name: Install dependencies

CONTRIBUTING.md

@@ -1,70 +1,70 @@
-# Contributing to Building-secure-contracts
+# Contributing to Building-Secure-Contracts
 
-First, thanks for your interest in contributing to Building-secure-contracts! We welcome and appreciate all contributions, including bug reports, feature suggestions, tutorials/blog posts, and code improvements.
+First, thank you for your interest in contributing to Building-Secure-Contracts! We appreciate and warmly welcome all contributions, which include bug reports, feature suggestions, tutorials/blog posts, and code improvements.
 
-If you're unsure where to start, we recommend our [`good first issue`](https://github.com/crytic/building-secure-contracts/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) and [`help wanted`](https://github.com/crytic/building-secure-contracts/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) issue labels.
+If you're not sure where to begin, we recommend checking out our [`good first issue`](https://github.com/crytic/building-secure-contracts/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) and [`help wanted`](https://github.com/crytic/building-secure-contracts/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) issue labels.
 
-## Bug reports and feature suggestions
+## Bug Reports and Feature Suggestions
 
-Bug reports and feature suggestions can be submitted to our issue tracker. For bug reports, attaching the contract that caused the bug will help us in debugging and resolving the issue quickly. If you find a security vulnerability, do not open an issue; email [email protected] instead.
+Please submit bug reports and feature suggestions to our issue tracker. When reporting a bug, attaching the contract causing the issue is helpful for efficient debugging and resolution. If you discover a security vulnerability, do not open an issue; instead, email [email protected].
 
 ## Questions
 
-Questions can be submitted to the issue tracker, but you may get a faster response if you ask in our [chat room](https://empireslacking.herokuapp.com/) (in the #ethereum channel).
+Questions can be submitted to the issue tracker, but you may get a faster response if you ask in our [chat room](https://slack.empirehacking.nyc/) (in the #ethereum channel).
 
-## Code
+## Code Contributions
 
-building-secure-contracts uses the pull request contribution model. Please make an account on Github, fork this repo, and submit code contributions via pull request. For more documentation, look [here](https://guides.github.com/activities/forking/).
+Building-Secure-Contracts follows the pull request contribution model. Create an account on Github, fork this repo, and submit code contributions through pull requests. For additional documentation, refer [here](https://guides.github.com/activities/forking/).
 
 Some pull request guidelines:
 
-- Minimize irrelevant changes (formatting, whitespace, etc) to code that would otherwise not be touched by this patch. Save formatting or style corrections for a separate pull request that does not make any semantic changes.
-- When possible, large changes should be split up into smaller focused pull requests.
-- Fill out the pull request description with a summary of what your patch does, key changes that have been made, and any further points of discussion, if applicable.
-- Title your pull request with a brief description of what it's changing. "Fixes #123" is a good comment to add to the description, but makes for an unclear title on its own.
+- Limit unnecessary changes (formatting, whitespace, etc.) to code unrelated to the patch. Save formatting or style corrections for a separate pull request, which doesn't include any semantic changes.
+- When possible, break down large changes into smaller, focused pull requests.
+- Complete the pull request description with an overview of your patch, including key modifications, and any further discussion points if relevant.
+- Use a concise title to describe your pull request's changes. "Fixes #123" is suitable for adding to the description, but not as a standalone title.
 
 ## Directory Structure
 
-Below is a rough outline of building-secure-contracts's structure:
+Here's a basic overview of Building-Secure-Contracts' structure:
 
 ```text
 .
-├── development-guidelnes # High-level best-practices for all smart contracts
+├── development-guidelines # High-level best practices for all smart contracts
 ├── learn_evm # EVM technical knowledge
-├── not-so-smart-contracts # Examples of smart contract common issues. Each issue contains a description, an example and recommendations
-├── program-analysis # How to use automated tools to secure contracts
-├── ressources # Various online resources
+├── not-so-smart-contracts # Examples of common smart contract issues, including descriptions, examples, and recommendations
+├── program-analysis # How to utilize automated tools to secure contracts
+├── resources # Various online resources
 └── ...
 ```
 
-## Linting and formatting
+## Linting and Formatting
 
 To install the formatters and linters, run:
 
 ```bash
 npm install
 ```
 
-To run the formatter, use:
+To use the formatter, run:
 
 ```bash
 npm run format
 ```
 
-To run the linters, use:
+To use the linters, run:
 
 ```bash
 npm run lint
 ```
 
-To run the individual linters, use:
+To use individual linters, run:
 
 - `npm run lint:format` to check the formatting
-- `npm run lint:links` to check for invalid links in markdown files
+- `npm run lint:links` to verify the validity of links in markdown files
 
-## Create the book
+## Creating the Book
 
-We use `mdbook` to generate [secure-contracts.com](https://secure-contracts.com/).
+We utilize `mdbook` to generate [secure-contracts.com](https://secure-contracts.com/).
 
 To run it locally:
 
@@ -73,4 +73,4 @@ cargo install --git https://github.com/montyly/mdBook.git mdbook
 mdbook build
 ```
 
-Note: we use https://github.com/montyly/mdBook.git, which contains https://github.com/rust-lang/mdBook/pull/1584.
+Note: We use https://github.com/montyly/mdBook.git, which contains https://github.com/rust-lang/mdBook/pull/1584.

README.md

@@ -2,41 +2,40 @@
 
 ![](https://github.com/crytic/building-secure-contracts/workflows/CI/badge.svg) ![](https://github.com/crytic/building-secure-contracts/workflows/Echidna/badge.svg)
 
-This repository, brought to you by [Trail of Bits](https://www.trailofbits.com/), outlines guidelines and best practices to write secure smart contracts.
+Brought to you by [Trail of Bits](https://www.trailofbits.com/), this repository offers guidelines and best practices for developing secure smart contracts. Contributions are welcome, you can contribute by following our [contributing guidelines](https://github.com/crytic/building-secure-contracts/blob/master/CONTRIBUTING.md).
 
-We welcome contributions, and you can contribute by following our [contributing guidelines](https://github.com/crytic/building-secure-contracts/blob/master/CONTRIBUTING.md).
+**Table of Contents:**
 
-**Table of contents:**
-
-- [Development guidelines](./development-guidelines)
-  - [High-level best practices](./development-guidelines/guidelines.md): High-level best-practices for all smart contracts
-  - [Incident Response Recommendations](./development-guidelines/incident_response.md): Guidelines on how to formulate an incident response plan
-  - [Secure development workflow](./development-guidelines/workflow.md): A rough, high-level process to follow while you write code
-  - [Token integration checklist](./development-guidelines/token_integration.md): What to check when interacting with arbitrary token
-- [Learn EVM](./learn_evm): EVM technical knowledge
-  - [EVM Opcodes](./learn_evm/evm_opcodes.md): Details on all EVM opcodes
+- [Development Guidelines](./development-guidelines)
+  - [Code Maturity](./development-guidelines/code_maturity.md): Criteria for developers and security engineers to use when evaluating a codebase’s maturity
+  - [High-Level Best Practices](./development-guidelines/guidelines.md): Best practices for all smart contracts
+  - [Incident Response Recommendations](./development-guidelines/incident_response.md): Guidelines for creating an incident response plan
+  - [Secure Development Workflow](./development-guidelines/workflow.md): A high-level process to follow during code development
+  - [Token Integration Checklist](./development-guidelines/token_integration.md): What to check when interacting with arbitrary tokens
+- [Learn EVM](./learn_evm): Technical knowledge about the EVM
+  - [EVM Opcodes](./learn_evm/evm_opcodes.md): Information on all EVM opcodes
   - [Transaction Tracing](./learn_evm/tracing.md): Helper scripts and guidance for generating and navigating transaction traces
   - [Arithmetic Checks](./learn_evm/arithmetic-checks.md): A guide to performing arithmetic checks in the EVM
-  - [Yellow Paper Guidance](./learn_evm/yellow-paper.md): Symbol reference for more easily reading the Ethereum yellow paper
-  - [Forks <> EIPs](./learn_evm/eips_forks.md): Summarize the EIPs included in each Ethereum fork
-    - [Forks <> CIPs](./learn_evm/cips_forks.md): Summarize the CIPs and EIPs included in each Celo fork _(EVM-compatible chain)_
-    - [Upgrades <> TIPs](./learn_evm/tips_upgrades.md): Summarize the TIPs included in each TRON upgrade _(EVM-compatible chain)_
-    - [Forks <> BEPs](./learn_evm/beps_forks.md): Summarize the BEPs included in each BSC fork _(EVM-compatible chain)_
-- [Not so smart contracts](./not-so-smart-contracts): Examples of smart contract common issues. Each issue contains a description, an example and recommendations
+  - [Yellow Paper Guidance](./learn_evm/yellow-paper.md): Symbol reference for easier reading of the Ethereum yellow paper
+  - [Forks <> EIPs](./learn_evm/eips_forks.md): Summaries of the EIPs included in each Ethereum fork
+    - [Forks <> CIPs](./learn_evm/cips_forks.md): Summaries of the CIPs and EIPs included in each Celo fork _(EVM-compatible chain)_
+    - [Upgrades <> TIPs](./learn_evm/tips_upgrades.md): Summaries of the TIPs included in each TRON upgrade _(EVM-compatible chain)_
+    - [Forks <> BEPs](./learn_evm/beps_forks.md): Summaries of the BEPs included in each BSC fork _(EVM-compatible chain)_
+- [Not So Smart Contracts](./not-so-smart-contracts): Examples of common smart contract issues, complete with descriptions, examples, and recommendations
   - [Algorand](./not-so-smart-contracts/algorand)
   - [Cairo](./not-so-smart-contracts/cairo)
   - [Cosmos](./not-so-smart-contracts/cosmos)
   - [Substrate](./not-so-smart-contracts/substrate)
   - [Solana](./not-so-smart-contracts/solana)
-- [Program analysis](./program-analysis): How to use automated tools to secure contracts
-  - [Echidna](./program-analysis/echidna): a fuzzer that will check your contract's properties.
-  - [Slither](./program-analysis/slither): a static analyzer available through a CLI and scriptable interface.
-  - [Manticore](./program-analysis/manticore): a symbolic execution engine that can prove the correctness properties.
-  - For each tool, this training material will provide:
-    - a theoretical introduction, a walkthrough of its API, and a set of exercises.
-    - exercises expected to require ~two hours to practically learn its operation.
-- [Resources](./resources): Various online resources
-  - [Trail of Bits blogposts](./resources/tob_blogposts.md): List of blockchain related blogposts made by Trail of Bits
+- [Program Analysis](./program-analysis): Using automated tools to secure contracts
+  - [Echidna](./program-analysis/echidna): A fuzzer that checks your contract's properties
+  - [Slither](./program-analysis/slither): A static analyzer with both CLI and scriptable interfaces
+  - [Manticore](./program-analysis/manticore): A symbolic execution engine that proves the correctness of properties
+  - For each tool, this training material provides:
+    - A theoretical introduction, an API walkthrough, and a set of exercises
+    - Exercises that take approximately two hours to gain practical understanding
+- [Resources](./resources): Assorted online resources
+  - [Trail of Bits Blog Posts](./resources/tob_blogposts.md): A list of blockchain-related blog posts created by Trail of Bits
 
 # License