Add CODEOWNERS, update workflows

.env.example

@@ -1,5 +1,3 @@
 PRIVATE_KEY=
 INFURA_KEY=
-ETHERSCAN_API_KEY=
-POLYGONSCAN_API_KEY=
-POLYGONSCAN_ZKEVM_API_KEY=
+ETHERSCAN_API_KEY=

.forge-snapshots/Increment counter number.snap

@@ -0,0 +1 @@
+26304

.forge-snapshots/Set counter number.snap

@@ -0,0 +1 @@
+26394

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @uniswap/protocols

.github/ISSUE_TEMPLATE/BUG_REPORT.yaml

@@ -0,0 +1,31 @@
+name: Bug report
+description: File a bug report to help us improve the code
+title: "[Bug]: "
+labels: ["bug"]
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Please check that the bug is not already being tracked.
+  - type: textarea
+    attributes:
+      label: Describe the bug
+      description: Provide a clear and concise description of what the bug is and which contracts it affects.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Expected Behavior
+      description: Provide a clear and concise description of the desired fix.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: To Reproduce
+      description: If you have written tests to showcase the bug, what can we run to reproduce the issue?
+      placeholder: "git checkout <branchname> / forge test --isolate --mt <testName>"
+  - type: textarea
+    attributes:
+      label: Additional context
+      description: If there is any additional context needed like a dependency or integrating contract that is affected please describe it below.

.github/ISSUE_TEMPLATE/FEATURE_IMPROVEMENT.yaml

@@ -0,0 +1,37 @@
+name: Feature Improvement
+description: Suggest an improvement.
+labels: ["triage"]
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Please ensure that the feature has not already been requested.
+  - type: dropdown
+    attributes:
+      label: Component
+      description: Which area of code does your idea improve?
+      multiple: true
+      options:
+        - Gas Optimization
+        - General design optimization (improving efficiency, cleanliness, or developer experience)
+        - Testing
+        - Documentation
+  - type: textarea
+    attributes:
+      label: Describe the suggested feature and problem it solves.
+      description: Provide a clear and concise description of what feature you would like to see, and what problems it solves.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Describe the desired implementation.
+      description: If possible, provide a suggested architecture change or implementation.
+  - type: textarea
+    attributes:
+      label: Describe alternatives.
+      description: If possible, describe the alternatives you've considered, or describe the current functionality and how it may be sub-optimal.
+  - type: textarea
+    attributes:
+      label: Additional context.
+      description: Please list any additional dependencies or integrating contacts that are affected.

.github/PULL_REQUEST_TEMPLATE.md

@@ -19,7 +19,6 @@ Before deployment
 - [ ] fuzz and invariant tests (when applicable)
 - [ ] formal verification (when applicable)
 - [ ] deployment or upgrade scripts ready
-- [ ] version management agreed upon and implemented
 
 After deployment
 

.github/workflows/pre-commit.yaml

@@ -9,8 +9,10 @@ jobs:
   pre-commit:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
-      - uses: actions/setup-python@v2
+      - uses: actions/checkout@v4
+        with:
+          submodules: recursive
+      - uses: actions/setup-python@v5
         with:
           submodules: recursive
       - name: Install Foundry

.github/workflows/test.yaml

@@ -3,19 +3,21 @@ name: test
 on:
   pull_request:
     branches: [main, master, staging, dev, feat/**, fix/**]
+  push:
+    branches: [main, master, staging, dev]
 
 env:
-  FOUNDRY_PROFILE: ci
+  FOUNDRY_PROFILE: ${{ github.event_name == 'push' && 'ci' || 'pr' }}
 
 jobs:
-  check:
+  forge-test:
     strategy:
       fail-fast: true
 
     name: Foundry project
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
         with:
           submodules: recursive
 
@@ -26,11 +28,13 @@ jobs:
 
       - name: Run Forge build
         run: |
+          echo Foundry profile: $FOUNDRY_PROFILE
           forge --version
           forge build --sizes
         id: build
 
       - name: Run Forge tests
-        run: |
-          forge test -vvv
+        run: forge test --isolate -vvv
         id: test
+        env:
+          FORGE_SNAPSHOT_CHECK: true

.github/workflows/trufflehog.yml

@@ -0,0 +1,40 @@
+name: Trufflehog
+
+on:
+  pull_request:
+    types:
+      - opened
+      - synchronize
+      - reopened
+
+permissions:
+  contents: read
+  id-token: write
+  issues: write
+  pull-requests: write
+
+jobs:
+  TruffleHog:
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        shell: bash
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1956744
+        with:
+          fetch-depth: 0
+
+      - name: TruffleHog OSS
+        id: trufflehog
+        uses: trufflesecurity/trufflehog@b0fd951652a50ffb1911073f0bfb6a8ade7afc37
+        continue-on-error: true
+        with:
+          path: ./
+          base: "${{ github.event.repository.default_branch }}"
+          head: HEAD
+          extra_args: --debug --only-verified 
+
+      - name: Scan Results Status
+        if: steps.trufflehog.outcome == 'failure'
+        run: exit 1

.gitignore

@@ -2,6 +2,7 @@
 /out
 /cache
 /coverage
+/report
 lcov.info
 .DS_Store
 .env
@@ -10,7 +11,3 @@ lcov.info
 
 broadcast/*/31337
 deployments/**/31337.*
-
-# storage layout checker library
-storage_check_cache
-storage_check_report

.gitmodules

@@ -1,21 +1,9 @@
 [submodule "lib/forge-std"]
 	path = lib/forge-std
 	url = https://github.com/foundry-rs/forge-std
-[submodule "lib/openzeppelin-contracts"]
-	path = lib/openzeppelin-contracts
-	url = https://github.com/openzeppelin/openzeppelin-contracts
-[submodule "lib/openzeppelin-contracts-upgradeable"]
-	path = lib/openzeppelin-contracts-upgradeable
-	url = https://github.com/openzeppelin/openzeppelin-contracts-upgradeable
-[submodule "lib/solady"]
-	path = lib/solady
-	url = https://github.com/vectorized/solady
-[submodule "lib/storage-delta"]
-	path = lib/storage-delta
-	url = https://github.com/0xPolygon/storage-delta
-[submodule "lib/deployer-kit"]
-	path = lib/deployer-kit
-	url = https://github.com/0xPolygon/deployer-kit
 [submodule "lib/forge-chronicles"]
 	path = lib/forge-chronicles
 	url = https://github.com/0xPolygon/forge-chronicles
+[submodule "lib/forge-gas-snapshot"]
+	path = lib/forge-gas-snapshot
+	url = https://github.com/marktoda/forge-gas-snapshot

CONTRIBUTING.md

@@ -2,6 +2,7 @@
 
 - [Install](#install)
 - [Pre-commit Hooks](#pre-commit-hooks)
+- [Requirements for merge](#requirements-for-merge)
 - [Branching](#branching)
   - [Main](#main)
   - [Staging](#staging)
@@ -12,14 +13,11 @@
   - [Code Style](#code-style)
   - [Interfaces](#interfaces)
   - [NatSpec \& Comments](#natspec--comments)
-- [Versioning](#versioning)
 - [Testing](#testing)
-  - [Deployer Template](#deployer-template)
+  - [Gas Metering](#gas-metering)
 - [Deployment](#deployment)
-  - [Deployer Template](#deployer-template-1)
   - [Deployment](#deployment-1)
   - [Deployment Info Generation](#deployment-info-generation)
-- [Deployer Template Script](#deployer-template-script)
 - [Releases](#releases)
 
 ## Install
@@ -41,21 +39,32 @@ This repo includes the following pre-commit hooks that are defined in the `.pre-
 - `doc`: This hook uses `forge doc` to automatically generate documentation for all Solidity files whenever the NatSpec documentation changes. The `script/util/doc_gen.sh` script is used to generate documentation. Forge updates the commit hash in the documentation automatically. To only generate new documentation when the documentation has actually changed, the script checks whether more than just the hash has changed in the documentation and discard all changes if only the hash has changed.
 - `prettier`: All remaining files are formatted using prettier.
 
+## Requirements for merge
+
+In order for a PR to be merged, it must pass the following requirements:
+
+- All commits within the PR must be signed
+- CI must pass (tests, linting, etc.)
+- New features must be merged with associated tests
+- Bug fixes must have a corresponding test that fails without the fix
+- The PR must be approved by at least one maintainer
+  - The PR must be approved by 2+ maintainers if the PR is a new feature or > 100 LOC changed
+
 ## Branching
 
 This section outlines the branching strategy of this repo.
 
 ### Main
 
-The main branch is supposed to reflect the deployed state on all networks. Any pull requests into this branch MUST come from the staging branch. The main branch is protected and requires a separate code review by the security team. Whenever the main branch is updated, a new release is created with the latest version. For more information on versioning, check [here](#versioning).
+The main branch is supposed to reflect the deployed state on all networks. Any pull requests into this branch MUST come from the staging branch.
 
 ### Staging
 
-The staging branch reflects new code complete deployments or upgrades containing fixes and/or features. Any pull requests into this branch MUST come from the dev branch. The staging branch is used for security audits and deployments. Once the deployment is complete and deployment log files are generated, the branch can be merged into main. For more information on the deployment and log file generation check [here](#deployment--versioning).
+The staging branch reflects new code complete deployments or upgrades containing fixes and/or features. Any pull requests into this branch MUST come from the dev branch. The staging branch is used for security audits and deployments. Once the deployment is complete and verified as well as deployment log files are generated, the branch can be merged into main. For more information on the deployment and log file generation check [here](#deployment).
 
 ### Dev
 
-This is the active development branch. All pull requests into this branch MUST come from fix or feature branches. Upon code completion this branch is merged into staging for auditing and deployment.
+This is the active development branch. All pull requests into this branch MUST come from fix or feature branches. Upon code completion this branch is merged into staging for auditing and deployment. PRs into this branch should squash all commits into a single commit.
 
 ### Feature
 
@@ -106,7 +115,7 @@ The repo follows the official [Solidity Style Guide](https://docs.soliditylang.o
   abstract contract AccessControl is ..., {
   ```
 
-- Unchecked arithmetic blocks should contain comments explaining why overflow is guaranteed not to happen. If the reason is immediately apparent from the line above the unchecked block, the comment may be omitted.
+- Unchecked arithmetic blocks should contain comments explaining why overflow is guaranteed not to happen or permissible. If the reason is immediately apparent from the line above the unchecked block, the comment may be omitted.
 
 ### Interfaces
 
@@ -116,62 +125,34 @@ Every contract MUST implement their corresponding interface that includes all ex
 
 Interfaces should be the entrypoint for all contracts. When exploring the a contract within the repository, the interface MUST contain all relevant information to understand the functionality of the contract in the form of NatSpec comments. This includes all externally callable functions, errors and events. The NatSpec documentation MUST be added to the functions, errors and events within the interface. This allows a reader to understand the functionality of a function before moving on to the implementation. The implementing functions MUST point to the NatSpec documentation in the interface using `@inheritdoc`. Internal and private functions shouldn't have NatSpec documentation except for `@dev` comments, whenever more context is needed. Additional comments within a function should only be used to give more context to more complex operations, otherwise the code should be kept readable and self-explanatory.
 
-## Versioning
+## Testing
 
-This repo utilizes [semantic versioning](https://semver.org/) for smart contracts. An `IVersioned` interface is included in the [interfaces directory](src/interface/IVersioned.sol) exposing a unified versioning interface for all contracts. This version MUST be included in all contracts, whether they are upgradeable or not, to be able to easily match deployed versions. For example, in the case of a non-upgradeable contract one version could be deployed to a network and later a new version might be deployed to another network. The exposed `version()` function is also used by the [Deployment Log Generator](https://github.com/0xPolygon/forge-chronicles#readme) to extract information about the version.
+The following testing practices should be followed when writing unit tests for new code. All functions, lines and branches should be tested to result in 100% testing coverage. Fuzz parameters and conditions whenever possible. Extremes should be tested in dedicated edge case and corner case tests. Invariants should be tested in dedicated invariant tests.
 
-Whenever contracts are modified, only the version of the changed contracts should be updated. Unmodified contracts should remain on the version of their last change.
+Differential testing should be used to compare assembly implementations with implementations in Solidity or testing alternative implementations against existing Solidity or non-Solidity code using ffi.
 
-## Testing
+New features must be merged with associated tests. Bug fixes should have a corresponding test that fails without the bug fix.
 
-### Deployer Template
+### Gas Metering
 
-This repo provides a deployer template library for consistency between scripts and unit tests. For more information on how to use the template, check [here](https://github.com/0xPolygon/deployer-kit#readme).
+The [Forge Gas Snapshot](https://github.com/marktoda/forge-gas-snapshot) library is used to measure the gas cost of individual actions. To ensure that the measured gas is accurate, tests have to be run using the isolate argument to generate the correct snapshot and ensure that CI passes:
 
-## Deployment
+```sh
+$ forge test --isolate
+```
 
-This repo utilizes versioned deployments. Any changes to a contract should update the version of this specific contract. A script is provided that extracts deployment information from the `run-latest.json` file within the `broadcast` directory generated while the forge script runs. From this information a JSON and markdown file is generated containing various information about the deployment itself as well as past deployments.
+When adding new functionality, a new gas snapshot should be added, preferably using `snapLastCall`.
 
-### Deployer Template
+## Deployment
 
-This repo provides a deployer template library for consistency between scripts and unit tests. For more information on how to use the template, check [here](https://github.com/0xPolygon/deployer-kit#readme).
+After deployments are executed a script is provided that extracts deployment information from the `run-latest.json` file within the `broadcast` directory generated while the forge script runs. From this information a JSON and markdown file is generated using the [Forge Chronicles](https://github.com/0xPolygon/forge-chronicles) library containing various information about the deployment itself as well as past deployments.
 
 ### Deployment
 
-This repo set up the following RPCs in the `foundry.toml` file:
-
-- mainnet: Ethereum Mainnet
-- goerli: Ethereum Goerli
-- sepolia: Ethereum Sepolia
-- polygon_pos: Polygon PoS
-- mumbai: Polygon Mumbai
-- polygon_zkevm: Polygon zkEVM
-- polygon_zkevm_testnet: Polygon zkEVM Testnet
-
 To deploy the contracts, provide the `--broadcast` flag to the forge script command. Should the etherscan verification time out, it can be picked up again by replacing the `--broadcast` flag with `--resume`.
 Deploy the contracts to one of the predefined networks by providing the according key with the `--rpc-url` flag. Most of the predefined networks require the `INFURA_KEY` environment variable to be set in the `.env` file.
 Including the `--verify` flag will verify deployed contracts on Etherscan. Define the appropriate environment variable for the Etherscan api key in the `.env` file.
 
 ```shell
 forge script script/Deploy.s.sol --broadcast --rpc-url <rpc_url> --verify
 ```
-
-## Releases
-
-Releases should be created whenever the code on the main branch is updated to reflect a deployment or an upgrade on a network. The release should be named after the version of the contracts deployed or upgraded.
-The release should include the following:
-
-- In case of a MAJOR version
-  - changelog
-  - summary of breaking changes
-  - summary of new features
-  - summary of fixes
-- In case of a MINOR version
-  - changelog
-  - summary of new features
-  - summary of fixes
-- In case of a PATCH version
-  - changelog
-  - summary of fixes
-- Deployment information (can be copied from the generated log files)
-  - Addresses of the deployed contracts

README.md

@@ -1,6 +1,5 @@
 ## Template Repo (Foundry)
 
-[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 [![CI Status](../../actions/workflows/test.yaml/badge.svg)](../../actions)
 
 This template repo is a quick and easy way to get started with a new Solidity project. It comes with a number of features that are useful for developing and deploying smart contracts. Such as:
@@ -14,7 +13,6 @@ This template repo is a quick and easy way to get started with a new Solidity pr
 - [Deployment](#deployment)
 - [Docs](#docs)
 - [Contributing](#contributing)
-- [License](#license)
 
 ## Setup