Initial commit

.gitattributes

@@ -0,0 +1,2 @@
+* text=auto
+readme.md merge=union

code-of-conduct.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at bazzanigianfranco@gmail.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

contributing.md

@@ -0,0 +1,35 @@
+# Contribution Guidelines
+
+Please note that this project is released with a
+[Contributor Code of Conduct](code-of-conduct.md). By participating in this
+project you agree to abide by its terms.
+
+---
+
+- To add to the list: Submit a pull request
+- To remove from the list: Open an issue
+
+Ensure your pull request adheres to the following guidelines:
+
+- Search previous suggestions before making a new one, as yours may be a duplicate.
+- Make an individual pull request for each suggestion. This allows to better handle updates or comments on the proposed character.
+- New categories, or improvements to the existing categorization are welcome.
+- Keep descriptions short and simple, but descriptive.
+- End all descriptions with a full stop/period.
+- Check your spelling and grammar.
+- Make sure your text editor is set to remove trailing whitespace.
+
+Thank you for your suggestions!
+
+## Updating your PR
+
+A lot of times, making a PR adhere to the standards above can be difficult.
+If the maintainers notice anything that we'd like changed, we'll ask you to
+edit your PR before we merge it. There's no need to open a new PR, just edit
+the existing one. If you're not sure how to do that,
+[here is a guide](https://github.com/RichardLitt/knowledge/blob/master/github/amending-a-commit-guide.md)
+on the different ways you can update your PR so that we can merge it.
+
+## How to Create a Pull Request
+
+See [Sindre Sorhus’ guide](https://github.com/sindresorhus/awesome/blob/main/contributing.md#adding-something-to-an-awesome-list) on how to contribute with pull requests.

readme.md

@@ -0,0 +1,95 @@
+![](logo/logo.png)
+
+# Awesome Advanced Smart Contracts Testing and Verification [![Awesome](https://awesome.re/badge.svg)](https://awesome.re)
+
+> A curated collection of tools, frameworks, and methodologies for testing and verifying smart contracts. Designed for blockchain developers and security researchers.
+
+## Contents
+
+- [Tools](#tools)
+- [Fuzzing](#fuzzing)
+  - [Property-based Fuzz Testing](#invariants-fuzz-testing)
+  - [Differential Fuzz Testing](#differential-fuzz-testing)
+- [Formal Verification](#formal-verification)
+- [Mutation Testing](#mutation-testing)
+- [Branching Tree Technique](#branching-tree-technique)
+- [Contribute](#contribute)
+
+## Tools
+
+Arsenal of tools, tailor-made for probing and dissecting the inner workings of smart contracts, crème de la crème of fuzzing and verification tools.
+
+- [**Foundry | Ethereum development framework written in Rust**](https://github.com/foundry-rs)
+- [**Echinda | Ethereum smart contract Property-based fuzzer**](https://github.com/crytic/echidna/)
+- [**Medusa | Property-based fuzzer based on Echidna written in go**](https://github.com/crytic/medusa)
+- [**Maat | Dynamic Symbolic Execution and Binary Analysis framework**](https://github.com/trailofbits/maat)
+- [**Optik | Echidna + Maat coupling for coverage analysis driven Fuzzing**](https://github.com/crytic/optik/tree/master)
+- [**Etheno | JSON RPC multiplexer, analysis tool wrapper, test integration tool**](https://github.com/crytic/etheno)
+- [**Certora Prover | Formal verification Tool**](https://docs.certora.com/en/latest/docs/whitepaper/index.html#certora-tool-suite)
+- [**Halmos | Symbolic testing tool for EVM smart contracts**](https://github.com/a16z/halmos)
+- [**Pyrometer | symbolic execution, abstract interpretation, and static analysis**](https://github.com/nascentxyz/pyrometer/tree/master)
+- [**Gambit | Solidity mutation system**](https://github.com/Certora/gambit)
+- [**Vertigo-rs | Ethereum smart contract mutation testing framework**](https://github.com/JoranHonig/vertigo)
+- [**Bulloak | Solidity test generator based on the Branching Tree Technique**](https://github.com/alexfertel/bulloak)
+
+## Fuzzing
+
+**Fuzzing** or **fuzz** testing is an automated software testing technique that involves providing invalid, unexpected, or randomly generated data as inputs to a computer program.
+
+- [**Fuzzing Labs @Pat_Ventuzelo ETHCC5 Fuzzing talk**](https://docs.google.com/presentation/d/1uCgiclLuoFDtIlYSenf4CbTItAtqz6_QH6XoZi8xI7Q/edit#slide=id.g1107f83abee_0_65)
+- [**Trail of Bits Fuzzing Workshop**](https://www.youtube.com/playlist?list=PLciHOL_J7Iwqdja9UH4ZzE8dP1IxtsBXI) (10 hours Workshop)
+- [**@vn_martinez\_ Mastering Fuzzing**](https://www.youtube.com/watch?v=83q14K-WNKM) ([seminar materials](https://github.com/Elpacos/mastering-fuzzing))
+- [**Foundry Book Fuzz Testing**](https://book.getfoundry.sh/forge/fuzz-testing)
+- [**Frax finance frax-solidity Foundry tests**](https://github.com/FraxFinance/frax-solidity/blob/master/src/foundry/test/veFPISProxy.t.sol)
+
+### Property-based Fuzz Testing
+
+**Property-based** testing aims to identify and test **invariants**. Invariants are conditions expressions that should always hold true over the course of a fuzzing campaign. Invariants are about properties of the system as a whole, rather than specific reactions to specific inputs.
+
+- [**Trail of Bits pre-defined invariants**](https://github.com/crytic/properties)
+- [**Trail of Bits Echidna Tutorials**](https://secure-contracts.com/program-analysis/echidna/index.html)
+- [**Gustavo Grieco - Spearbit: Echidna Workshop**](https://www.youtube.com/watch?v=kAfknRlvAt0)
+- [**@agfviggiano Advanced Fuzzing Techniques: An eBTC Case Study**](https://youtu.be/ELY_zjIAKuE?feature=shared)
+- [**@agfviggiano OpenSense Invariant Testing Workshop**](https://www.youtube.com/watch?v=YAF79t_Sfiw)
+- [**RareSkills invariant testing in foundry**](https://www.rareskills.io/post/invariant-testing-solidity)
+- [**@horsefacts Invariant Testing WETH With Foundry**](https://mirror.xyz/horsefacts.eth/Jex2YVaO65dda6zEyfM_-DXlXhOWCAoSpOx5PLocYgwç)
+- [**Hybrid fuzzing: Sharpening the spikes of Echidna**](https://blog.trailofbits.com/2022/12/08/hybrid-echidna-fuzzing-optik-maat/)
+- [**Foundry Book Invariant Testing**](https://book.getfoundry.sh/forge/invariant-testing)
+- [**BadgerDAO eBTC invariant fuzzing setup**](https://github.com/code-423n4/2023-10-badger/tree/main/packages/contracts/foundry_test)
+- [**Maple core v2 tests**](https://github.com/maple-labs/maple-core-v2/tree/main/tests)
+- [**Uniswap permit 2 AllowanceTransferInvariants.t.sol**](https://github.com/Uniswap/permit2/blob/main/test/AllowanceTransferInvariants.t.sol)
+- [**Frax finance frax-solidity Echidna tests**](https://github.com/FraxFinance/frax-solidity/tree/master/src/echidna)
+- [**Sablier-labs v2-core foundry invariants**](https://github.com/sablier-labs/v2-core/tree/main/test/invariant)
+
+### Differential Fuzz Testing
+
+**Differential testing** is used to ensure identical behavior between two or more implementations of equivalent code. Useful if you are upgrading/updating code, or have written a more optimized version but you want to verify congruence among implementations.
+
+- [**@annascarrol Solidity Summit 2023 - Differential Testing with Foundry by Anna Carroll**](https://twitter.com/i/broadcasts/1BdGYrpOQVXJX) ([link 2](https://app.streameth.org/devconnect/solidity_summit/session/differential_testing_with_foundry))
+- [**Differential Test | Testing with Foundry**](https://www.youtube.com/watch?v=WhZQhxOG124)
+- [**Foundry Book differential testing**](https://book.getfoundry.sh/forge/differential-ffi-testing)
+- [**Seaport | Discussion #809 Understanding the "DifferentialTest" test contract**](https://github.com/ProjectOpenSea/seaport/discussions/809)
+- [**Murky Merkle Tree DifferentialTests.t.sol**](https://github.com/dmfxyz/murky/blob/main/differential_testing/test/DifferentialTests.t.sol)
+- [**EnbangWu Differential Fuzzing of solidity Fixed-point libraries**](https://github.com/EnbangWu/differential-fuzzing)
+
+## Formal Verification
+
+**Formal Verification** is an approach to assessing the correctness of software by checking whether a formal model of the program matches the formal specification. Unlike testing, formal verification can verify a smart contract's execution satisfies a formal specification for all executions without needing to execute it with sample data.
+
+WIP
+
+## Mutation Testing
+
+WIP
+
+## Branching Tree Technique
+
+Specification framework for writing structured Solidity tests.
+
+- [**@PaulRBerg Branching Tree Technique**](https://twitter.com/PaulRBerg/status/1682346315806539776)
+- [**@PaulRberg Solidity Summit 2023 Branching Tree Technique**](https://app.streameth.org/devconnect/solidity_summit/session/branching_tree_technique_writing_structured_solidity_tests)
+- [**PaulRBerg/btt-examples**](https://github.com/PaulRBerg/btt-examples)
+
+## Contribute
+
+Contributions welcome! Read the [contribution guidelines](contributing.md) first.