It has thirty-six courses spread over eight terms. It starts in Fall 2026 and ends with a senior project in the summer of 2030. Every lecture comes from a real university or a world-class teacher: Stanford, MIT, Yale, Harvard, Berkeley, Oxford, ETH Zurich, CMU, Princeton, Andrej Karpathy. Every course closes with an exam and something I build. And every hour of it happens in public, on this site.

This post explains why I did it, how the system works week to week, and how you can use it — whether you want to follow along, borrow the curriculum, or build your own.

Why a software engineer needs a bachelor he designs himself

I've spent my career building backend systems, infrastructure and the teams that run them. That work taught me a lot, but it taught me unevenly. Production work rewards depth in whatever is on fire this quarter. It rarely gives you a reason to learn how a CPU pipeline actually works, why a proof of an estimator is unbiased, or what Kant would say about the product decision you made last week.

Over time I noticed three gaps that kept costing me:

1. The foundations under the stack. I can ship a distributed service, but the layers below it — computer architecture, circuits, compilers, the maths inside machine learning — were things I knew about rather than things I knew.
2. The field that is rewriting everything. AI is no longer a side topic for engineers. Using models is easy; understanding them well enough to build, debug and lead teams around them is not.
3. The human side of leading. Managing engineers is a craft of judgment: psychology, ethics, economics, writing clearly. None of that is in the documentation.

A traditional degree would fix some of this, at the cost of years of fixed schedules and a syllabus designed for someone else. Random online courses fix nothing, because without structure they end the way most of us know: three lectures in, then nothing.

So I took the part of university that actually works — structure, breadth, deadlines and finished work — and dropped the parts that don't fit a working engineer.

The model: 36 courses, borrowed from Yale

A Yale bachelor's degree is built from thirty-six course credits. That number is a good constraint. It is large enough to force real breadth and small enough that each course has to earn its place.

I spread the thirty-six courses over four years and eight terms, just like a regular degree:

• Fall terms run from mid-September to the end of January.
• Spring terms run from February to the end of May.
• Summers are free, except the last one, which is reserved for the senior project (June to August 2030).

Each term holds four or five courses. That sounds like a lot next to a full-time job, and it is — which is why the load is balanced so a heavy technical course always sits next to a lighter reading-and-thinking one.

Ten areas, on purpose

The courses are spread across ten areas. The mix is the whole point:

• AI — from building neural networks from scratch with Andrej Karpathy, through Stanford's CS229, CS231n, CS224N and CS336, to deep reinforcement learning, ML systems, ML compilation and LLM agents.
• Software — MIT's performance engineering, algorithms, computer security and distributed systems.
• Hardware — digital design and computer architecture from ETH Zurich, FPGA and Verilog, circuits and electronics from MIT, and building a 6502 computer on a breadboard with Ben Eater.
• Crypto — cryptography, Bitcoin, blockchain and money, and zero-knowledge proofs.
• Math — probability with MIT's John Tsitsiklis and matrix methods with Gilbert Strang.
• Philosophy — Harvard's Justice, Oxford's General Philosophy, Yale's Death and Moral Foundations of Politics.
• Psychology — Paul Bloom's introduction to psychology, Robert Sapolsky's Human Behavioral Biology, and MIT's The Human Brain.
• Management — How to Start a Startup, MIT's New Enterprises.
• Economics — Yale's Game Theory and Robert Shiller's Financial Markets.
• Writing — Larry McEnerney's The Craft of Writing Effectively, paired with a weekly essay.

The technical areas deepen the engineering. The rest sharpen the judgment that leading engineers depends on. I don't think either half is enough on its own.

The goal isn't a certificate. It's to be the kind of engineer who understands the whole stack — from transistors to teams.

How a course actually works

Every course follows the same loop, so the system never depends on motivation.

1. Watch the lectures, in order

Each course is tied to its official lecture playlist on YouTube, from the university or teacher who made it. On the course page you get the full list of lectures, and each lecture has its own page with the video embedded, its chapters, and previous and next links. No hunting through search results, no reposted copies.

2. Read the study guide first

Every lecture page has a study guide: what the lecture covers, the key ideas, a walkthrough with timestamps that jump the player to the right moment, what to review before watching, and questions to check your understanding afterwards.

These guides were drafted with AI from the lecture transcripts, and each one says so clearly until I have reviewed it. They are a map, not a replacement for the lecture. Reading the map first means I watch actively instead of passively.

3. Log every study session

After each session I write a short log entry: the date, the course, the hours, what I did, what I learned and the questions still open. It takes two minutes, and a small command scaffolds the file for me:

npm run bachelor:log -- c01 2.5 "Built micrograd"

Those entries are the heartbeat of the whole project. They feed the dashboard, the course pages, the full study log and an RSS feed.

4. Capture ideas as they appear

Studying across ten areas produces strange, useful collisions — a game-theory lecture that explains a team dynamic, a hardware course that suggests a tool. Those go into an ideas list, each linked to the courses it came from and tagged as a seed, something I'm exploring, building or have shipped.

5. Finish with an exam and an artifact

A course is not done when the last video ends. It's done when two things exist:

• An exam score. Most of these courses publish past exams or problem sets. I sit one under exam conditions and record the result.
• An artifact — something real built with what the course taught: code, a hardware build, a write-up, a small tool. Building it is where the ideas stop being familiar and start being usable. The artifact is linked from the course page.

Watching is easy to fake, especially to yourself. An exam and an artifact are not.

6. The transcript

Scores, grades and status for all thirty-six courses roll up into a transcript you can view on the site or download as a CSV. It's the same document a university would give you, except every line is backed by the log entries, notes and artifacts that produced it.

Why do it in public

I could keep all of this in a private notebook. I chose not to, for three reasons.

Commitment. A dashboard that shows the current term, the week, hours logged and courses completed turns a vague intention into a schedule I have to face every time I open it. Writing the plan down publicly is how I commit to it.

An honest record. Memory flatters. Months from now I will believe I understood a course better than I did. A dated log of the hours, the questions I got stuck on, the exam results and the things I built is the only reliable way to see what I actually learned — and where I need to go back.

Usefulness to others. The curriculum, the lecture pages and the study guides are free to everyone. If a single person uses them to start their own path, the project has already paid for itself.

How the system is built

The engineer in me couldn't resist building this properly, and the design choices are part of the method.

• Everything is a plain file. The program, the courses, every log entry, every idea and every study guide live as JSON and Markdown in the site's repository. Editing the degree means editing a file and pushing a commit. No database, no admin panel, nothing to break.
• Nothing is hardcoded. Progress, the current term, "now studying", hours and the transcript are all computed from those files and today's date. Mark a course completed and every page updates on the next deploy.
• Real pages for every lecture. The build generates a page for the program, each course, the log, ideas, transcript and all 858 lectures, each with its own title, description and structured data, so search engines can find them.
• Checked on every change. A validator rejects a course with a bad status or a log entry pointing at a course that doesn't exist, and tests guard the progress maths.

It's the same discipline I'd want in any production system: simple inputs, derived outputs, and checks that fail loudly.

How you can use it

You don't need to care about my progress to get value from this.

• Follow a single course. Open any course on the bachelor page, start at lecture one, and use the study guides as you go.
• Borrow the curriculum. The thirty-six-course plan is a reasonably balanced path for an engineer who wants AI, systems and hardware depth plus the humanities that make you better at work. Take it whole or swap courses for your own goals.
• Use the lecture pages as a study companion. Timestamped walkthroughs and self-check questions make long university lectures much easier to get through and to review later.
• Watch the experiment. The study log and RSS feed show what four years of structured, public learning looks like — including the weeks that go badly.
• Build your own. The approach is simple enough to copy: pick a credit model, choose courses across areas, require an exam and an artifact, log every session, and publish it.

What I expect to be hard

I'd rather write this down now than pretend later.

Consistency next to a demanding job will be the real test, not any single course. Some courses — computer architecture, deep reinforcement learning, distributed systems — will take far longer than their lecture hours suggest. Some lecture editions will age before I reach them, and I'll update them. And an exam without a professor is only as rigorous as the person sitting it — so I hold myself to the published conditions and time limits, and treat a low score as a reason to go back, not something to hide.

Day one

The first term starts today with neural networks from scratch, parallel computing with CUDA, Stanford's machine learning course, writing effectively, and Harvard's Justice. The first log entry is already up.

If you want to follow along, the whole degree lives at masoud.me/bachelor. If you start your own version, send me a note at me@masoud.me — I'd love to see what you put in your thirty-six.

Twelve days later, CoinDesk ran the headline that mattered: "Robinhood built a blockchain for tokenized stocks — memecoins took over."

The numbers are almost funny. Tokenized real-world assets — the entire reason the chain exists — sit at $12.8 million, about 4.1% of value locked. Meanwhile a cat-themed token called CASHCAT ripped 2,158% in a week to a $156M market cap. A launchpad called NOXA.fun and a trading bot called basedbot got their own analytics dashboards. The chain did $3.1B in weekly DEX volume and out-transacted Coinbase's Base.

None of this was an accident, and none of it was avoidable. It's what I've started calling the sniper effect: build a permissionless, low-latency, cheap-gas chain with a launchpad on it, and you will grow a sniping ecosystem — regardless of what you meant the chain to be for. Let me walk through why, technically.

What sniping actually is

A "sniper" is a bot that buys a token in the same block its liquidity becomes tradable, before any human can react.

The mechanics are simple and brutal. A token has no price until someone creates a market for it — pairs it with ETH or SOL in a DEX pool, or lets a bonding curve go live. That instant is the liquidity event. Before it, the token is worthless and untradeable. One block later, price discovery has already happened without you.

Snipers live in that gap. The classic pipeline on a public chain:

1. Watch the mempool. Every pending transaction is broadcast before it's mined. Bots — usually Rust or TypeScript, colocated near block producers — stream the mempool and pattern-match for a specific shape: a call to a DEX factory's addLiquidity, a bonding-curve completion, a presale claim window opening.
2. React in microseconds. The moment a liquidity-add is seen pending, the bot fires its own buy.
3. Win the ordering race. On Ethereum L1 this is a priority gas auction — outbid everyone else so your buy lands in the same block, ideally the very next transaction after the liquidity add.
4. Dump into the crowd. The bot now holds tokens at the lowest price that will ever exist, and sells into the retail buyers who show up seconds later.

On-chain data aggregated across Ethereum and Solana memecoin launches shows the top 10 sniper wallets routinely capture 30–60% of a token's opening liquidity. The "fair launch" you clicked buy on was, quantitatively, already over.

Why launchpads are sniper magnets

Launchpads didn't invent sniping, but they industrialized it. A launchpad like pump.fun — or NOXA.fun on Robinhood Chain — turns launching a token into a one-click bonding-curve deploy. That's great for founders and perfect for bots, because it makes launches:

• Frequent — hundreds a day, a constant stream of fresh liquidity events.
• Uniform — every launch has the same on-chain signature, so one bot template snipes all of them.
• Predictable — the bonding curve tells you exactly when the token graduates to a live pool. There's a countdown you can race.

On Solana, professional snipers subscribe to Yellowstone gRPC streams — validator feeds that expose transactions roughly 400ms before they confirm. The whole game is landing your buy in slot 0, the same 400ms slot in which the bonding curve completes and the pool is created. Slot 0 versus slot 2 is a 20–60% price difference on a launch that pumps.

And here's the part people miss: the only reliable defense the launchpad community has found is to out-snipe the snipers — bundle your token creation and your own multi-wallet buys into one atomic block-0 transaction (a Jito bundle), so there's literally no gap for an outsider to insert a buy into. The defense against manipulation is more manipulation. That's the culture a launchpad imports, wholesale, into whatever chain it lands on.

Now the interesting part: Robinhood Chain isn't Ethereum

Here's where it gets technically specific, because Robinhood Chain doesn't work the way L1 does — and that changes the shape of sniping without removing it.

Robinhood Chain is built on Arbitrum's Orbit stack. Full EVM compatibility, ETH as gas, 100-millisecond blocks, settlement to Ethereum L1, Chain ID 4663. Critically, like every Orbit chain in its early phase, it runs a single centralized sequencer — operated by Robinhood — with first-come, first-served ordering.

Sit with what that means for a sniper:

• There is no public mempool. You cannot watch pending transactions the way you watch Ethereum's. Transactions go straight to Robinhood's sequencer. The single richest signal snipers depend on on L1 — seeing the liquidity-add before it's ordered — is gone.
• There is no priority gas auction. FCFS means the sequencer orders by arrival time, not by who paid the most gas. You cannot bribe your way to the front of the block. Bumping your gas does nothing.

If you're Robinhood's product team, you might read that and think you've designed sniping out. You haven't. You've changed its currency from money to milliseconds.

When ordering is first-come-first-served, the winner isn't whoever bids highest — it's whoever's packet physically arrives at the sequencer first. So the entire arms race migrates to latency:

• Colocating your bot as close to the sequencer's ingress as the network topology allows.
• Hammering the fastest RPC endpoints, hand-tuning TCP, pre-signing transactions.
• Spamming redundant transactions across multiple connections to win the race by brute force — which is exactly the kind of load that turned FCFS ordering on Arbitrum One into a spam problem in the first place.

This is latency MEV, and it's arguably worse for the little guy than a gas auction. A gas auction is at least legible — you can see the clearing price and decide not to play. A latency race is invisible and structural: the winner is simply whoever spent the most on infrastructure and sits closest to a sequencer only Robinhood controls. Retail was never in that race. 100ms blocks just slice the timeline finer, giving the fastest actor more distinct windows to win.

A centralized FCFS sequencer doesn't abolish MEV. It privatizes the mempool and hands a latency monopoly to whoever is closest to the machine.

Arbitrum's own acknowledgment of this is Timeboost — an express-lane auction that sells a latency advantage transparently, precisely because raw FCFS degenerates into a spam war. Robinhood Chain didn't ship with it. So at launch, the ordering policy on a chain built for regulated tokenized equities is the same naive FCFS that the memecoin snipers on NOXA.fun are, right now, optimizing their colocation against.

Why this was structurally guaranteed

Step back and the pattern is clean. Sniping doesn't need permission, insider access, or a broken chain. It needs exactly four properties, and every general-purpose chain that wants DeFi has all four on purpose:

• Permissionless deployment — anyone can launch a token without approval. Robinhood Chain has this explicitly; you don't need Robinhood's sign-off to deploy a contract.
• Low, flat fees — so a bot can fire thousands of attempts profitably.
• Low latency — the faster the chain, the more the edge accrues to whoever is fastest. 100ms blocks are a feature for snipers.
• A liquidity primitive with a known trigger — a DEX or a launchpad bonding curve, i.e. a predictable moment when a market goes live.

Robinhood built all four to make tokenized stocks trade smoothly. Those same four properties are the complete recipe for a sniping ecosystem. You cannot keep the first list and reject the second — they're the same list. The chain doesn't know a tokenized share of NVDA from CASHCAT; they're both ERC-20s hitting the same sequencer. Neutrality cuts both ways.

That's the sniper effect in one line: a chain's neutrality is the sniper's substrate. The moment you make something fair and open enough for tokenized equities, you've made it fair and open enough for the bots — and the bots are faster than your intended users by construction.

So what actually mitigates it?

Not much at the chain layer, and that's the uncomfortable takeaway. But there are real levers, roughly in order of how much they cost you in openness:

• Encrypted mempools / threshold ordering — hide transaction contents until ordering is fixed, so there's nothing to front-run. Powerful, but it fights the transparency that's half the point of being on-chain.
• Batch auctions — clear all trades in a window at one uniform price (the CoW Protocol idea). Kills the same-block advantage outright, at the cost of continuous trading.
• Sequencer-level fair ordering or Timeboost — either enforce fairness in the sequencer, or at least auction the latency edge transparently instead of letting it go to whoever colocates hardest. Robinhood, running its own sequencer, is uniquely positioned to do this and simply hasn't yet.
• Design the launch, not the chain — the honest one. Snipers exploit predictable liquidity events. Randomized launch timing, sealed-bid launch auctions, anti-bot allowlists, or atomic block-0 seeding remove the thing they race for. This is a product decision at the token layer, not something the chain can do for you.

If you're launching a token in this environment, assume the first block belongs to a bot and design so that doesn't matter — vesting, fair-price auctions, or simply not pretending your "fair launch" is fair. If you're building the chain, understand that "we run the sequencer" is a responsibility, not just a chokepoint: it's the one place you could actually enforce fair ordering, and declining to is a choice your users pay for.

Robinhood wanted to bring 28 million retail customers on-chain to trade tokenized stocks. What it actually shipped, in week one, is the fastest, cleanest sniping arena in crypto — and the bots noticed before the stocks did. That's not a bug in the execution. It's what happens when you build something genuinely neutral and forget that neutrality has customers you didn't invite.