Giters

Cyfrin / evm-wallet-and-post-deployment-course

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Wallet & Post-Deployment Course

Welcome to the repository for the Wallet & Post-Deployment Security Course by Cyfrin Updraft!

This repository houses the written content of our courses, organized to facilitate easy access and contribution from our community. Please refer to this for an in-depth explanation of the content:

  • Website - Join Cyfrin Updraft and enjoy 50+ hours of smart contract development courses
  • Twitter - Stay updated with the latest course releases
  • LinkedIn - Add Updraft to your learning experiences
  • Discord - Join a community of 3000+ developers and auditors
  • Newsletter - Weekly security research tips and resources to level up your career
  • Codehawks - Smart contracts auditing competitions to help securing web3

This was considered part 2 of the security and auditing course, but now, it's it's own living breathing course!

Introduction, Resources, and Prerequisites

Link to video: Coming soon...

⚠️ All code associated with this course is for demo purposes only. They have been audited, but we do not recommend them for production use and should be used at your own risk.

Resources For This Course

Join Cyfrin Updraft for the best learning experience!

  • AI Frens
  • Github Discussions
    • Ask questions and chat about the course here!
  • Stack Exchange Ethereum
    • Great place for asking technical questions about Ethereum
  • Peeranha
    • Decentralized Stack Exchange!

Challenge Contracts Registry

  • TBD...

Potential Wallets

Note: We do not endorse any of the following wallets. All we have done is take a look to see if these wallets pass a small series of tests to make sure code that the developers release can be verified.

Browser

Hardware

Multi-Sig

Prerequisites

An intermediate understanding of solidity. You don't need to be a pro, but you should be familiar with:

  • Blockchain basics (transactions, blocks, decentralization, etc)
  • Running a smart contract test suite (hardhat, foundry, truffle, etc)
  • Solidity basics (variables, functions, structs, etc)

Nice to have

Outcome

  • Understand the potential dangers of different wallets
  • Understand how, as a protocol/developer, you should choose a wallet
  • Understand what you need in place after you deploy your contracts

Recommended Testnets

Section 1: Wallet & Key Management

Q: Why are we giving guidelines and not strict recommendations?

A: The wallet industry is constantly changing, and takes a LOT of work to assess how good different wallets are. Additionally, if you know what to look out for, that is more valuable than us giving you point-in-time recommendations.

Wallet types

What to look for

Tl;dr - the same things you'd look for in a protocol!

  • Open source
  • Active development
  • Audit history (Who did the review? What did they find? How good is the group?)
  • non-custodial
  • Do they have a security bounty program
  • If they ask you to wear your wallet around your neck, stay far away from them
  • Interview with Wallet Scrutiny

Wallet Safety

Cloud Wallet Infrastructure

Verify Metamask transactions

  • Foundry's cast
  • Joinfire
  • Metamask snaps

🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐

🔐 Exercises:

  1. Set up your Safe!
  2. Review classic key leeks
    1. .env leak with private keys
    2. Research one private key leak from rekt.news
  3. Check out keepmesafe

Section 1 NFT

  • Coming soon

🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐🔐

(back to top) ⬆️

Section 2: Post-deployment

Ideally, you'll want all of this setup before you go to production.

Summary of this whole section:

For protocols

  1. Have a security contact / bug bounty / safe harbor before you deploy
  2. Setup monitoring before you deploy
  3. Run a disaster recovery drill before you deploy

For security researchers

  1. Never exploit a smart contract without working with those responsible
    1. Even if you have good intentions
    2. The only caveat is maybe if the transaction is already in the mempool
  2. Get familiar with responsible disclosure
  3. Get familiar with toolings & platforms:
    1. Bug bounties
    2. Blockchain sleuthing

Watch this video from DeFi security summit

What to do, before you deploy

  1. Written & tested incident response plan
    1. Remember the rekt-test
    2. Have a "security contact" email in your code
      1. If you're a DAO, potentially elect a security officer
    3. Setup your monitoring system for invariants
    4. Setup your bug bounty/safe harbor program

Setup a security contact and policy

  • Example Openzeppelin
    • Contact information
    • Bug Bounty
    • Security Patches / Disclosures / Advisories
    • Safe Harbor
    • Additional Audits

Monitoring

Incident Response

Bug Bounties

  • Roll your own
  • Immunefi
  • HackerOne

Responsible Disclosure / Finding bugs in production code

What to do if you find a bug?

Do not exploit it

  1. Contact the team / those resonsible / bug bounty program
    1. Optionally, if they have a bug bounty/responsible disclosure procedure, use that
    2. SEAL 911 (or other 911 groups) is always a good option
  2. "Close the windows and blinds"
    1. Make sure you're on a secure chat channel, for example an E2E encrypted signal channel
  3. Verify the bug with the team / those responsible
  4. Come up with a game plan to fix
    1. This is where things get hard. Potentially pause the protocol, try to sneak it past governance, etc.
    2. Use a MEV-proof RPC
    3. Deploy and execute your fix in 1 single transaction, potentially with a whitehat kit to batch your transactions together.

What if?

  • They don't have a security contact or bug bounty
    • If there is really no one responsible for the code (this is web3 after all) you may have to announce and give people a long window of opportunity for them to leave the protocol, before announcing the issue.
  • They ignore the bug?
    • Give them a window to fix or acknowledge it, otherwise tell them you'll need to go public with the information. Give people the chance to leave the protocol before you publically disclose the issue. Use this as a last resort!
  • They don't pay you for your work?
    • Difficult one. You can always blast them on Twitter, but that can backfire. Ideally everyone works together.
    • If you start to negotiate a bounty, you are now a black hat.
  • The transaction is already in the mempool?
    • This is the only time it might be ok to exploit it, by front-running the attack. However, there still may be legal ramifications.

Whitehatting

🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠🌠

Section 2 NFT

  • Coming soon...

(back to top) ⬆️

Congratulations

🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊 Completed The Course! 🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊🎊

If you've made it this far... wow.

Where do I go now?

Coming soon: The EVM, Assembly, and Formal Verification Course!!

Learning More

Disclosures

The Cyfrin team runs CodeHawks, Cyfrin Updraft, and private security reviews. They are an advisor to the Peeranha project, and run various blockchain nodes like Chainlink & Ethereum. Additionally, the are responsible for the creation of the Aderyn and Solodit tools.

Thank you

Sponsors

Lead Lecturers / Code Builders

Guest Lecturers

  • XXXX

Special thanks

Huge Extra Thank YOU

Thanks to everyone who is taking, participating in, and working on this course. These courses are passion project data dumps for everyone in the web3 ecosystem.

Let's level up so we can keep web3 safer, and thank you again for taking this course!

Cyfrin Twitter Cyfrin YouTube

(back to top) ⬆️

About

License:GNU General Public License v3.0