smart-contract-best-practices VS solidity-template

Then i delved into best practises (https://consensys.github.io/smart-contract-best-practices/) and patterns (https://fravoll.github.io/solidity-patterns/) to improve.

Search for solidity exploits on Google, useful one: https://consensys.github.io/smart-contract-best-practices/ there are a lot of possible exploits so deploying one by yourself without audits is a no-go imo

Consensys' Smart Contract Best Practices is a good start for security related stuff (super important because you'll be dealing with people's money in smart contracts) https://consensys.github.io/smart-contract-best-practices/

The first question which any auditing interview concerns is mostly regarding what is your preferred audit process? Answers could be subjective, but I like to follow the industry standard as in this ‘Solcurity Standard’ article by Rari-Capital along with the Consensys’ best practices set of guidelines which pave a path for a thorough audit process.

Security should always be a major priority when developing smart contracts. Millions of dollars are lost to hackers on what seems like a regular basis. As a Web3 developer, you need to continuously stay up to date on the latest security best practices.

Solidity basics and best practices

Smart Contracts Best Practices

New updates to solidity-template are available! This template now supports more networks than ever. And for the first time, streamlined contract development to zk rollup L2s are possible!

Awesome to see a mention of solidity-template here! Check out the thread for more info.

This template includes an easy-to-follow example Counter.sol, with its interface ICounter.sol, Unit Test file Counter.t.sol, and Integration Test file counter.test.ts.

Reference for on-chain developers writing contracts that call these contracts in your Unit Test files to see the expected usage in Solidity.

solidity-template's sample contract, Counter.sol, is trivial, so the value add isn't observable here. Let me share a recent example where off-chain logic would never be able to be handled inside the Foundry unit tests: