Day One — Starting from an Empty Folder

There's a specific kind of silence that happens when you open a terminal, create a new directory, and stare at it. No files. No structure. No README. Just an empty folder with a blinking cursor, waiting for you to type something.

I've been thinking about this project for weeks. I've studied how MEV works. I've read about arbitrage strategies, learned the Solana vocabulary, estimated the costs, and convinced myself that this is worth trying. I've done the research. I've made the decision. And now I'm here, sitting in front of the most intimidating thing in all of software development: the blank canvas.

It's like the first day at a new job. You've aced the interview. You've signed the offer letter. You've told everyone you know about this exciting new role. Then you show up on Monday morning, sit down at your desk, and realize that nobody is going to hand you a task list. Nobody is going to tell you where to start. The onboarding document is three years old and half the links are broken. You're just... here. Figuring it out.

mkdir solana-arb && cd solana-arb

There it is. My project exists. It's real. It has a name and a directory and absolutely nothing inside it.

Now what?

The Most Basic Question in the World

Here's something nobody tells you about building software: the hardest part isn't the complex algorithms or the clever optimizations or the elegant architecture. The hardest part is the first ten minutes. It's figuring out where to even begin when the problem space is enormous and your folder is empty.

I know what I want to build. I want a bot that monitors prices across Solana DEXs, detects arbitrage opportunities where the same token is priced differently on different exchanges, and executes trades to capture the difference. Simple concept. Three steps. Monitor. Detect. Execute.

But between "I know what I want to build" and "here is line one of the code," there's a canyon. And standing at the edge of that canyon, I'm realizing how many things I don't know.

How do you talk to a blockchain? Like, mechanically — what do you actually do? You connect to something called an RPC node, I know that much. But what library do you use? What format does the data come back in? How do you read the state of a liquidity pool? How do you construct a transaction? How do you sign it with your wallet? How do you send it?

These aren't rhetorical questions. I genuinely don't know the answers to any of them right now. I have the conceptual understanding — I've been studying for weeks — but the gap between "I understand how this works in theory" and "I can make this work in code" is approximately the same gap between "I understand how an internal combustion engine works" and "I can build a car."

It feels like showing up to assemble IKEA furniture, except instead of getting a box with all the parts and an instruction manual with confusing diagrams, you just get a picture of what the finished bookshelf should look like and a note that says "good luck, the hardware store is that way."

Choosing a Weapon

The first real decision I have to make is the programming language. And for this, I have two realistic options: Python or Rust.

Rust is what the serious MEV operators use. Solana itself is written in Rust. The on-chain programs (smart contracts) are written in Rust. The highest-performance bots, the ones that compete for sub-millisecond advantages, are written in Rust. If I want to build the fastest, most competitive bot possible, Rust is the answer.

But here's the thing about Rust: it's hard. Really hard. Rust has a famously steep learning curve, with a borrow checker that rejects your code for reasons that feel personally vindictive until you've spent months understanding memory ownership. Writing Rust when you're also trying to learn blockchain development, DEX protocols, and MEV strategy simultaneously is like trying to learn to drive a stick shift during your first time behind the wheel — on a freeway, in rush hour traffic. You'll learn eventually, but the probability of stalling out (literally and figuratively) is very high.

Python is the opposite trade-off. It's slower — significantly slower for the kind of hot-path computation MEV requires. But it's readable, forgiving, and fast to iterate with. Python lets you prototype an idea in an afternoon. It lets you make mistakes quickly and cheaply. It lets you focus on understanding the problem instead of fighting the language.

I choose Python. Not because it's the right long-term answer — I already suspect I'll need to rewrite everything in Rust eventually — but because right now, my bottleneck isn't execution speed. My bottleneck is understanding. I need to learn how all these pieces fit together, and I need to learn it by doing, not by reading. Python lets me do that.

It's the same logic behind why you learn to cook with a basic recipe before you try molecular gastronomy. Nobody starts with a sous vide machine and liquid nitrogen. You start with a pot, a stove, and some pasta. You learn what heat does to food. You learn how flavors combine. You build intuition. Then, once you understand the fundamentals, you graduate to fancier equipment.

My pot and stove is Python. The molecular gastronomy kitchen is Rust. I'll get there. But not today.

python3 -m venv .venv && source .venv/bin/activate

A virtual environment. We're cooking now.

The Naive Architecture

I grab a notebook — an actual paper notebook, because sometimes thinking requires a pen — and sketch out the simplest possible architecture for an arbitrage bot.

Step one: Monitor. Connect to Solana, subscribe to price data from multiple DEXs. Watch for changes in real time.

Step two: Detect. When prices diverge between two pools for the same token pair, calculate whether the difference is large enough to cover transaction costs. If yes, that's an opportunity.

Step three: Execute. Build a transaction that buys the token where it's cheap and sells it where it's expensive. Sign it. Send it. Profit.

Three boxes, two arrows, one pipeline. Monitor flows into Detect flows into Execute. I draw it on paper and feel a small surge of satisfaction. It's clean. It's logical. It makes sense.

I think this design is solid.

Maybe someday I'll look back at this sketch and laugh at how simplistic it is. Maybe a real MEV architecture looks nothing like this. But right now, standing at the beginning with an empty folder and a paper napkin diagram, this is the best I've got. And you know what? It's enough. It's a starting point. It's a direction to walk in.

Every great system starts as a naive version one. Amazon started as a website that sold books. Google started as a research project that ranked web pages. The iPhone started as a phone that could play music and browse the internet. None of those first versions looked anything like what they eventually became, but they all started with someone drawing three boxes on a piece of paper and saying, "okay, this is the plan."

My three boxes are Monitor, Detect, Execute. Let's go.

What Do I Actually Need?

Before I write a single line of bot logic, I need to set up the basic infrastructure. And by "infrastructure," I mean the absolute minimum requirements to interact with Solana from Python.

An RPC connection. This is the gateway to the blockchain. An RPC (Remote Procedure Call) node is essentially a server that speaks Solana's language — you send it requests like "give me the current state of this account" or "submit this transaction," and it responds. Without an RPC connection, my bot is deaf and blind. I start with a public endpoint because it's free, even though I already know from my research that public endpoints are slow and rate-limited. For learning purposes, slow is fine. I just need something that responds.

A wallet. On Solana, every action requires a signature from a keypair. A wallet is just a keypair — a public key (your address) and a private key (your proof of identity). I need a wallet to sign transactions, and I need that wallet to hold some SOL to pay for transaction fees. I generate a new keypair, transfer a small amount of SOL to it, and immediately write down a rule for myself: this is a development wallet. Never put more money in it than you're willing to lose. I fund it with a trivial amount — enough for hundreds of transaction fees but not enough to ruin my week if something goes catastrophically wrong.

DEX data. I need to read the state of liquidity pools on at least two different DEXs. This means understanding how each DEX stores its data on-chain — what accounts to look up, what byte layout to parse, what fields represent the current reserves or prices. This is where it gets complicated, and I'll get to that. But for now, I just need to know which DEXs to target.

Transaction building. Once I detect an opportunity, I need to construct a swap transaction. This means interacting with the DEX's on-chain program, passing the right accounts in the right order, with the right data. Then I need to sign it and submit it.

Four things. RPC, wallet, DEX data, transaction building. That's the foundation. Everything else is built on top of these four pillars.

Discovering the Tools

I start searching for Python libraries that can help me interact with Solana. The ecosystem isn't as mature as Ethereum's — where you have battle-tested libraries like web3.py and ethers.js that have been around for years — but it's workable.

Two libraries stand out immediately:

solana-py. This is the main Python SDK for Solana. It handles RPC connections, transaction building, and basic blockchain interactions. It's the equivalent of having a phone that can make calls — the fundamental capability you need to do anything.

solders. This is the interesting one. Solders is a Rust-based library with Python bindings — meaning the core logic is written in high-performance Rust, but you call it from Python. It handles things like keypair management, transaction serialization, and cryptographic operations. The performance-critical stuff that would be painfully slow in pure Python runs at Rust speed under the hood.

Together, these two libraries give me the basic toolkit I need. solana-py talks to the blockchain. solders handles the cryptographic heavy lifting. It's not a complete solution — I'll need to write plenty of custom code for DEX-specific interactions — but it's a starting point.

pip install solana solders

Two packages. A few seconds of downloading. And just like that, I have the ability to talk to a blockchain from Python. It feels simultaneously momentous and anticlimactic, like getting the key to your first apartment and then standing in an empty room surrounded by boxes.

The First Line of Real Code

I open a new Python file. I stare at it for a moment. Then I type:

from solana.rpc.api import Client

client = Client("https://api.mainnet-beta.solana.com")
result = client.get_slot()
print(result)

Four lines. I run it.

A number comes back. A slot number. A big integer that represents the current position in Solana's blockchain. It's not useful by itself — it's just a number — but it means something extraordinary: my code just talked to a blockchain. My laptop, sitting on my desk, sent a request across the internet to a Solana RPC node, and that node responded with real-time data from a decentralized network processing thousands of transactions per second.

I feel like I just made a phone call for the first time. The conversation was boring — "what slot is it?" "it's slot 287,432,916" — but the fact that the call went through at all is thrilling.

I try a few more things. I query the balance of my wallet. I fetch information about a recent block. I look up the state of a token account. Each query teaches me something about how Solana organizes its data and how the RPC interface works. It's like exploring a new city — every corner reveals something I didn't expect, and every discovery leads to three more questions.

Then I try something more ambitious. I look up the account data for a Raydium liquidity pool — one of the major DEXs on Solana. I know the pool's public key from a block explorer. I fetch the account data.

What comes back is raw bytes. A wall of hexadecimal. No labels. No structure. Just data, packed according to a layout that I don't yet understand.

This is the moment I realize that reading on-chain data is nothing like reading a REST API. A normal web API gives you JSON with labeled fields: {"price": 1.05, "reserve_a": 1000000, "reserve_b": 950000}. A Solana account gives you something like 0x06000000000000000100000000000000... and expects you to know that bytes 8 through 40 are a public key, bytes 40 through 48 are a u64 representing the token A reserves, and so on. It's like the difference between reading a letter in English and reading one in Morse code. The information is the same, but the decoding effort is wildly different.

I stare at the hex dump for a while. I don't know how to parse it yet. But I know I will, because I have to. This is the data my bot needs, and learning to read it is not optional.

Realizing the Scale

As the day goes on and I keep poking at the blockchain, a picture starts to emerge of just how much I need to learn.

Reading pool state is hard, but it's just the beginning. Each DEX has its own data layout, its own account structure, its own quirks. Raydium stores data differently than Orca. Orca stores data differently than Meteora. If I want to arbitrage across multiple DEXs — and I have to, because that's where the opportunities are — I need to understand all of them.

Building transactions is harder than reading data. A swap transaction on Solana isn't just "buy this token." It's a carefully constructed instruction that references specific accounts in a specific order, passes serialized data in a specific format, and needs to be signed by the right authority. Get any of these wrong — wrong account, wrong order, wrong format — and the transaction fails. Or worse, it succeeds but does something you didn't intend.

And then there's the competitive reality that I've been reading about but haven't yet experienced firsthand. Even if I build a bot that can read data, detect opportunities, and build transactions, I'm competing against bots that do all of that in microseconds. My Python prototype, connecting to a public RPC endpoint with 200-plus milliseconds of latency, is showing up to a Formula 1 race on a bicycle. The opportunities I detect will have been captured by faster bots long before my transaction arrives.

I know this. I've read about it. But knowing it intellectually and feeling it viscerally are different things. Sitting here, watching my Python script take a full second to query a single account, I feel the gap between where I am and where I need to be.

It's enormous.

Why V1 Matters Anyway

So why bother? If the Python prototype is too slow to compete, if the architecture is too naive to work in production, if the public RPC is too laggy to catch real opportunities — why am I spending time building something I know will be inadequate?

Because you can't build version two without building version one first.

I think about this a lot. There's a temptation in software engineering to skip straight to the "right" solution. To start with Rust, to start with a dedicated RPC node, to start with a sophisticated multi-threaded architecture. To build the production system from day one.

The problem with that approach is that you don't know enough yet. You don't know what the right architecture looks like because you haven't built the wrong one. You don't know where the bottlenecks are because you haven't hit them. You don't know which DEXs are worth targeting, which data structures matter, which error cases will bite you — because you haven't written the code that exposes all of those questions.

Version one is a learning machine. Its purpose isn't to make money. Its purpose is to generate knowledge. Every naive design decision I make today will teach me something when it fails tomorrow. Every performance bottleneck I hit will point me toward the right optimization. Every bug I encounter will deepen my understanding of how Solana actually works, as opposed to how the documentation says it works.

It's like those first few months at a new job. Nobody expects the new hire to revolutionize the company on day one. You're there to learn the codebase, understand the systems, build relationships, and figure out how things actually get done — which is always different from the org chart and the process documents. The value of those early months isn't measured in output. It's measured in understanding.

My Python prototype is my first day on the job. I'm learning the codebase. I'm learning the systems. I'm figuring out how things actually work.

What I Have at the End of Day One

By the time I lean back in my chair and look at what I've built, here's the inventory:

• A Python virtual environment with solana-py and solders installed
• A development wallet with a small amount of SOL
• A script that connects to a public RPC endpoint and reads blockchain state
• A function that fetches raw account data for a known pool address
• A notebook full of scribbles about data layouts I don't yet understand
• A three-box architecture diagram that I'm genuinely proud of and probably won't survive first contact with reality

It's not much. It's not a bot. It can't detect arbitrage. It can't execute trades. It can't do anything useful, really. It can connect to the blockchain and read some numbers. That's it.

But it's more than I had this morning, when I was staring at an empty folder.

I'm thinking about a concept I read somewhere: the distance between zero and one is infinitely greater than the distance between one and two. Going from nothing to something — from an empty directory to a script that runs and produces output — is the hardest transition in any project. Everything after this is iteration. Improvement. Refinement. But you can't iterate on nothing. You can't improve what doesn't exist. You can't refine a blank page.

I have something now. It's naive. It's slow. It doesn't understand half of what it needs to understand. But it runs. It connects. It reads data from a real blockchain. It exists.

The Gap Between Knowing and Doing

There's one more thing I keep coming back to as the day ends. All those weeks of research, all those articles and documentation pages and explanations of how MEV works — none of it prepared me for the specific, granular, unglamorous reality of actually writing code.

Nobody's blog post explained what it feels like to stare at a wall of hexadecimal bytes and know that somewhere in there is the token reserve data you need, but you can't find it because you don't know the byte offsets. Nobody's tutorial covered the specific error message you get when you pass the wrong account to an RPC call. Nobody's architecture diagram included the part where you spend thirty minutes debugging a dependency installation issue before you write a single line of business logic.

This is the gap between knowing and doing. Between reading the recipe and standing in the kitchen. Between watching someone ride a bicycle and actually pedaling one yourself. The knowledge is necessary — I wouldn't be here without it — but it's not sufficient. The doing is where the real learning happens.

I'm doing now. I'm typing. I'm making mistakes. I'm reading error messages. I'm querying the blockchain and getting back data I don't understand and slowly, painfully, starting to understand it.

Is this how every bot builder starts? Is this clumsy first-day fumbling the universal experience, or is everyone else more prepared than I am? I'm guessing it's universal. I'm guessing that every MEV operator who eventually built something far faster and more sophisticated than what I'm looking at started exactly where I am today — with an empty folder, a naive architecture, and the stubborn belief that figuring it out is just a matter of persistence.

I close my laptop. The folder isn't empty anymore. That's enough for today.

Tomorrow, I'll try to make it do something useful.