“ Pearls don't lie on the seashore. If you want one, you must dive for it.”

Back in the PooCoin days, it seemed to me that a full understanding of what’s going on over there was very difficult to reach. I used smutty and low-efficiency bots found online to make the very first dollar. Alongside with @IvizzCut, we began to pave our stammering way into this gigantic ecosystem. Listing bots became buying bots, monitoring bots and others. We even built our own infrastructure and first dollars became, over the course of months, the first thousand dollars. We iterated every version of bots we had, changing strategies and discovering innovative tactics. This thriving ecosystem, especially on chain, evolves at an incredible pace, strategies had to be customised and developed very fast. Yet it was working.

Then, we saw the emergence of a lot of tools for degens. Dexscreener got out, listings bots were already all over the place and this year we finally saw the advent of chat bots that do most EVM interactions you need at this time. Suddenly it wasn’t worth it for new comers to take interest in building their own automatic strategies because a lot of these were already conducted by emerging tools. But will it suffice then? What concepts are you missing by using third-party software developed by other entities ?

Beginning with basics we will take a look at EVM interaction, explaining simple concepts along the way. I’ll guide you through the building of your own software to interact with EVM, the attached GitHub repository will help you follow every steps of this voyage. Reviewing local key management, contracts or events interactions, mempool monitoring and other advanced concepts. Soon enough you’ll have your own dexscreener, running on your own node with automatic token buying and selling.

This is not the story of how you are going to be rich from using self-made bots. This is the story of how I fell into the hole as a tech guy. Whatever the background you come from, allow me to be your white rabbit.

If you already know the full extent of the benefits of decentralization, we’ll catch up on the second episode of this series. For new comers and those eager for fresh basis, let’s explain why you should take a look at what’s going on.

Looking at a famous node providers blog on pros & cons of running your own ethereum node, you will notice 4 concepts. The first one is Privacy & Security, it doesn’t take a genius to understand the less you involve third-party or issue external communication the less you’ll have leaks and hacks. You reduce the exposed surface, so it is easier to secure. The second element is Censorship Resistance, nothing can stop you from broadcasting anything you want to the entire ethereum network. Losing this is not what we’ve joined this ecosystem for. Then they talk about, Infrastructure Decentralization. At the time of the writing, ethernodes.org shows that more than 45% of all ethereum nodes mainnet run at amazon‘s data centers, running a validator there during an outage could get your node disadvantage for inactivity. As unlikely as it seems, a similar risk is an exploit on Geth execution client which represents 85% of all ethereum execution clients. A lot of people understand this risk, Vitalik often communicate about minority clients and of this particular choke point. The last point is Sovereignty, you know how to run it yourself from anywhere in the world, relying on no one than yourself.

To be honest, these are marketing strategies for nodes providers. They’ve come to give you less and less freedom in how you can use the product you pay for. They wrapped the node API into a new API doing the multiple eth_calls and processing for you. To do a raw eth_call you could still buy a full node host by them that you’ll still pay by number of API calls. I see neither privacy nor censorship resistance nor sovereignty in this option.

You have to limit choke points, whether it is software or hardware related. By doing so you protect yourself against a lot of futures threats. For example, imagine if goodfellas develop a cryptocurrency wallet and a RPC provider and make those work together. What if they wrapped their RPC in order to log every single connection detail on wallet creation. That would deanonymize the wallet, at least to this imaginary entity.

You have even more reason to handle your EVM interaction on your own. Owning a node is just a step in the right direction.

Sometimes, centralized processing is worth the choke point. With wrapped node API, some companies have built security software that limit your on chain risks, group chat bots are way more efficient than what you can develop on your own (or are they?). After this article series, you won’t design your own super-efficient on chain bot or your own web3 security suite. However we will investigate the topic of wrapped API and other, make proofs of concept, understand them and maybe develop your own blacklist wrapper. Understand what’s happening behind the scene is key to evaluate your overall risk exposure. Episode after episode, we are going to take a deep dive into what vanilla EVM has to offer to every single user.

Sovereignty and independence come at the cost of acquiring competences. It is time consuming to technically rely only on yourself, I will try to make it as simple as possible so that you fast forward what I have experienced. Delegate EVM interaction is a smart choice for advanced services but you need to be fully aware of what is happening behind the services you use. A lot of people pay for low technical challenges in this space, let’s not be one of them.

In the next episode, I’ll get into the details of communication protocols I’ve briefly brought up, making sure everybody is up-to-date.