#!/bin/bash

echo "

 ██████  ███████ ███    ██ ███████ ███████ ██ ███████

██       ██      ████   ██ ██      ██      ██ ██

██   ███ █████   ██ ██  ██ █████   ███████ ██ ███████

██    ██ ██      ██  ██ ██ ██           ██ ██      ██

 ██████  ███████ ██   ████ ███████ ███████ ██ ███████

Where building on Ethereum begins

https://github.com/stevedylandev/genesis

"

# Install Foundry

echo "❯ Do you want to install Foundry? (Y/n)"

read -n 1 install_foundry

echo

if [[ $install_foundry =~ ^[Nn]$ ]]; then

    echo "Skipping Foundry installation..."

else

    # Install foundryup

    printf "Installing Foundry..."

    curl -fsS https://foundry.paradigm.xyz | bash > /dev/null 2>&1

    # Install foundry

    foundryup > /dev/null 2>&1

    printf "\r✔️ Foundry installed    \n"

fi

# Install Helios

echo "❯ Do you want to install Helios? (Y/n)"

read -n 1 install_helios

echo

if [[ $install_helios =~ ^[Nn]$ ]]; then

    echo "Skipping Helios installation..."

else

    # Install heliosup

    printf "Installing Helios..."

    curl -fsS https://raw.githubusercontent.com/a16z/helios/master/heliosup/install | bash > /dev/null 2>&1

    # Install helios

    heliosup > /dev/null 2>&1

    printf "\r✔️ Helios installed    \n"

fi

# Install Hardhat

echo "❯ Do you want to install Hardhat? (Y/n)"

read -n 1 install_hardhat

echo

if [[ $install_hardhat =~ ^[Nn]$ ]]; then

    echo "Skipping Hardhat installation..."

else

    printf "Installing Hardhat..."

    if command -v pnpm >/dev/null 2>&1; then

        pnpm install -g hardhat > /dev/null 2>&1

    elif command -v npm >/dev/null 2>&1; then

        npm install -g hardhat > /dev/null 2>&1

    elif command -v bun >/dev/null 2>&1; then

        bun install -g hardhat > /dev/null 2>&1

    else

        printf "\rNo package manager found (pnpm, npm, or bun)\n"

        exit 1

    fi

    printf "\r✔️ HardHat installed    \n"

fi

# Install Solc

echo "❯ Do you want to install Solc? (Y/n)"

read -n 1 install_solc

echo

if [[ $install_solc =~ ^[Nn]$ ]]; then

    echo "Skipping Solc installation..."

else

    printf "Installing Solc..."

    if command -v npm >/dev/null 2>&1; then

        npm install --global solc > /dev/null 2>&1

    else

        printf "\rNpm not found\n"

        exit 1

    fi

    printf "\r✔️ Solc installed    \n"

fi

# Ask user if they want to create a wallet

echo "❯ Do you want to create a new wallet? (Y/n)"

read -n 1 create_wallet

echo

if [[ $create_wallet =~ ^[Nn]$ ]]; then

    echo "Skipping wallet creation..."

else

    echo "❯ What do you want to name your wallet?"

    read wallet_name

    cast wallet new --password ~/.foundry/keystores $wallet_name

fi

echo "

✔️ Installation complete!

Start a new project with 'forge init counter'

"

ogImage: "/blog-images/other/genesis.png"

![cover](/blog-images/other/genesis.png)

Many of us remember our first steps into Ethereum as we wrote some Solidity, compiled it, and deployed it to a long forgotten testnet. It's an exhilarating feeling, something we can't quite shake. Time goes on, you build some more, and soon you start to experience some of the pain points many devs experience daily when using Ethereum. This ranges from conflicting libraries, debugging web wallet interactions, scaffolding projects, interacting and testing contracts, the list goes on. After a few years you get comfortable with the bugs and mess, perhaps **too comfortable**. We become blinded to how new developers might experience Ethereum for the first time, as they have to navigate multiple different tools, old tutorials referencing frameworks that no longer exist, and beyond. Developers need a foundation, and in this post we will explore a possible solution: Genesis.

In short, Genesis would be an all-in-one CLI tool for building on Ethereum. While this concept is nothing new, it's surprisingly lacking in the Ethereum ecosystem. Alternative L1 blockchains usually have something like this where it can manage all aspects of the developer workflow for that given chain; Stellar is a great example of this. Even while the chain is new, the CLI is impressive and gives developers everything they need to go from zero to deployed dApp. They have the advantage of using techniques and fundamentals created by diverse tools in the EVM ecosystem. The key is a central binary that helps aggregate different aspects of the developer workflow, so a new dev (or even an experienced one) doesn't need to reach for five different tools to accomplish one task. It helps improve the flow of tutorials and provides a high bar of standards set for EVM development.

How far this goes is pretty flexible; even if Genesis was just a startup script that installs some of the fundamental tools developers need it would be a step in the right direction. If it makes sense there could be multiple layers of interfacing and abstraction on top of those tools. Because of this Genesis would likely be written in Typescript, Go, or Rust depending on the tooling interface that would take place. While Rust is one of the more intimidating languages to choose from, it is ideal for CLIs and system programs. Many of the new and best tools are being written in Rust as well, so depending on the interfacing needs it might make more sense to take that path. With that said there will still probably be parts of the tool written in Typescript as there are necessary web UIs that will just be simpler to work with in those environments.

Genesis would have the goal of being anything from a simple getting started tool to an all-in-one tool for developing on Ethereum, and it could include the following features.

# Private key only accessed at runtime

PRIVATE_KEY=$(genesis wallet private-key --account testnet)

Many of the foundational tools for building on Solidity would be bundled into Genesis, such as a compiler, security scanners / fuzzers, and LSP integrations. These are all crucial pieces to a good developer experience and can often help save smart contracts from vulnerabilities or prevent malicious code editor extensions.

This one might be harder to attain, but it would be nice to have an easy way to get testnet eth to a developer's wallet. Many of the options out there require a mainnet balance or some other kind of hoop that can limit privacy. One option might be a POW faucet similar to [this one](https://sepolia-faucet.pk910.de), and while it's not ideal, I think it's better than the other existing options. There are many alt L1's that have easy to access faucets, and while Ethereum faces many more challenges comparatively, we should strive for a better DX.

Tools like Foundry make contract deployments and interactions pretty decent, however there is still some room for UX improvements. For example we could pull the ABI for a given contract and provide autocompletions for the shell, making it much easier to interact and test functions. Turning it into a TUI and providing an experience like Etherscan would also be great to see. Currently there's a lot you have to type out in the terminal to interact with a contract, and some people may not want to write a full Solidity script just to try something.

We've discussed _a lot_ of features, and it's hard to imagine where we would even start. Yet like any project, the key is to start small and simple. Genesis would begin and start as a tool installer; a simple CLI that helps developers acquire the fundamental tools they need to start building. Perhaps a next step would be initial setups, like prompting to create a keystore wallet, showing how to access it, how to start a new project, etc. From there we could start looking into what it might look like to expand. There would need to be some decisions around whether it makes sense to wrap other tools or write our own native packages, and it would be a case by case basis. For example, writing a simple dev focused web wallet that links to keystores might make more sense than writing light abstraction over foundry tools. Those decisions would be crucial as it both dictates the developer experience of Ethereum and has the potential to drown out other tools and providers (which we obviously don't want to do).

A key factor in making those financial decisions would be the success metrics in its early development. Measuring the success would rely on a few key factors including:

## Wrapping Up

While there is a delicate balance between building native tooling and supporting existing tooling, there should be a collective effort to improve the developer experience of Ethereum. We want a world where new and old builders alike can enjoy building EVM based applications and improve our ecosystem further, and it starts with us. Try out the MVP of Genesis by copying and pasting the script below into your terminal, or view the source script [here](https://stevedylan.dev/genesis)!

```bash

curl -fsS https://stevedylan.dev/genesis | bash

```