Merge pull request #6 from 0xPolygon/staging

Update libraries

.gitmodules

@@ -10,12 +10,12 @@
 [submodule "lib/solady"]
 	path = lib/solady
 	url = https://github.com/vectorized/solady
-[submodule "lib/deployment-log-generator"]
-	path = lib/deployment-log-generator
-	url = https://github.com/0xPolygon/deployment-log-generator
-[submodule "lib/contract-deployer-template"]
-	path = lib/contract-deployer-template
-	url = https://github.com/0xPolygon/contract-deployer-template
-[submodule "lib/storage-layout-checker"]
-	path = lib/storage-layout-checker
-	url = https://github.com/0xPolygon/storage-layout-checker
+[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

CONTRIBUTING.md

@@ -118,23 +118,23 @@ Interfaces should be the entrypoint for all contracts. When exploring the a cont
 
 ## Versioning
 
-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/deployment-log-generator#readme) to extract information about the version.
+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.
 
 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.
 
 ## Testing
 
 ### Deployer Template
 
-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/contract-deployer-template#readme).
+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).
 
 ## Deployment
 
 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.
 
 ### Deployer Template
 
-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/contract-deployer-template#readme).
+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).
 
 ### Deployment