DEV Community: Mahima Thacker

You Changed One Line and Called It a Migration. Opus 4.8 Has Other Plans.

Mahima Thacker — Fri, 29 May 2026 11:25:25 +0000

What actually changes in your backend when you move from Claude Opus 4.7 to 4.8, the 9 things the benchmark screenshots don't tell you.

Most of us ran the same play this week: open the config, swap claude-opus-4-7 for claude-opus-4-8, redeploy, see the request come back 200, move on.

The API contract didn't break, so it felt finished. It wasn't.

Anthropic's migration guide says code that ran on 4.7 keeps running on 4.8 with no changes, and that's true, but it's a statement about the request format, not about behavior.

Your output lengths, token bills, tool-call counts, retries, and where your agent decides to stop can all shift without a single error code.

So for anyone running Opus in production, 4.8 reads less like a "smarter model" headline and more like a list of changed defaults you should check before trusting it with real traffic.

Here's that list:

1. What "no breaking changes" actually covers

It covers the call succeeding. That's about it.
The same prompt can come back longer or shorter, spend more or fewer thinking tokens, call tools more or less often, and cost more or less per request, all while returning 200. If the only thing you checked after the swap is that the endpoint still responds, you haven't really tested the upgrade yet.

2. The effort default quietly dropped from xhigh to high

This is the one most likely to catch you, and almost nobody's mentioning it.

On Opus 4.7 the default effort was xhigh. On 4.8 it's high, on every surface, API and Claude Code included. If you upgrade and change nothing, your high-autonomy and coding agents may now reason less by default than they did the day before.

It's not a regression. high is Anthropic's chosen balance of quality and cost, and they recommend setting xhigh yourself for coding and agentic work. But it's still a behavior change riding along inside a "no breaking changes" release, and the only way you'll notice is by looking.

Two things worth knowing when you set it:

effort goes in output_config, not inside thinking. Put it in the wrong place and you get a validation error rather than a silent fallback.

xhigh isn't new in 4.8. It shipped with 4.7, where it was the default. The change in 4.8 is that you now have to ask for it.

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,                    # leave room to think + act
    output_config={"effort": "xhigh"},   # not inside `thinking`
    messages=[...],
)

The levels run low, medium, high (default), xhigh, max. Use xhigh for coding and long-running agents, step down to medium or low for cheap simple calls, and reach for max only when your own evals show it buys you something over xhigh, since it spends tokens with no ceiling.

3. Adaptive thinking is something you turn on

A common misread is that 4.8 "thinks adaptively now" out of the box. It doesn't. Adaptive thinking is a mode you enable with thinking: {type: "adaptive"}, and it's off until you set it. Once it's on, the model decides per turn whether a step needs real reasoning or a direct answer.

This matters because agent loops mix trivial steps and hard ones. "Read this file" and "refactor this module under these three constraints" don't deserve the same thinking budget, and without adaptive thinking you were often paying for deep reasoning on the trivial steps anyway. With it enabled, 4.8 wastes fewer thinking tokens than 4.7 did at the same effort level.

At high (the default) and max, the model will almost always think. At lower levels it may skip thinking on easy turns. Effort and adaptive thinking are separate knobs that interact, so it's worth setting both deliberately rather than leaving one on its default.

4. 1M context is the default.

That's not a reason to stop retrieving.
Opus 4.8 serves the full 1M-token window by default now, with no beta header and no long-context surcharge. If your client still sends an old context-window beta header for backward compatibility, you can drop it.

What the bigger window doesn't fix: noisy retrieval, duplicate files, stale context, sloppy chunking, missing citations, slow prompts, or a bill that quietly tripled because you started stuffing whole repos into every call.

5. The change you'll actually feel is tool behaviour

If there's one capability improvement to care about, it's this.

Anthropic calls out two things in 4.8: better tool triggering (the model is less likely to skip a tool call the task needed, which some 4.7 users ran into) and better compaction handling (long agentic runs stay on task with fewer derailments after the context gets compacted).

In practice, production agents don't usually fail because the model is dumb. They fail like this:

it should have read the file, but guessed
it should have run the tests, but skipped them
it should have called the API, but assumed the result
it had the constraint earlier in the session, then drifted off it

4.8 is aimed at that class of failure. For agent systems, raw intelligence was rarely the limiting factor. Picking the right tool, calling it at the right moment, using the result, and not losing the thread after compaction is most of what decides whether the thing works, and that's hard to read off a benchmark table but easy to feel in a long session.

6. System messages mid-conversation

Opus 4.8 accepts role: "system" messages placed immediately after a user turn in the messages array (there are placement rules). Earlier models, 4.7 included, rejected that with a 400.

It looks minor and it isn't, because it gives you a way to re-steer a running agent without rebuilding the whole prompt history. The agent is halfway through a refactor, tests start failing, your harness drops in a system entry like "fix the failing tests before continuing," and the agent adjusts.

Since you're not rewriting earlier turns, you keep your prompt-cache hits. Use the top-level system field for instructions that apply from the start, and in-array system messages for course corrections during the run.

7. Prompt caching now works for shorter prompts

The minimum cacheable prompt length on 4.8 dropped to 1,024 tokens, down from 4.7's higher threshold. Prompts that were too short to cache before will cache now, with no code change.

It's worth a few minutes to split the stable parts of your prompt from the dynamic ones so the cache actually earns its keep:

stable, cache it: system prompt, tool definitions, repo map, schemas, policy text
dynamic, don't: the user's question, retrieved chunks, latest tool output

Easy to skip in a demo, expensive to skip in production.

8. Same sticker price, different real cost

Standard pricing is unchanged from 4.7: $5 / $25 per million input/output tokens. But the sticker price isn't the bill. What you actually pay depends on effort level, context size, output length, tool calls, retries, cache hits, and batch usage.

There's also fast mode (research preview, Claude API, speed: "fast"): up to about 2.5x the output tokens per second from the same model, at $10 / $50 per million. Worth being precise here, because it's easy to misread: fast mode is a premium, roughly 2x the standard rate, not a discount. It's only cheaper compared to fast mode on the older 4.6/4.7 models, which ran $30 / $150.

The honest framing is that fast mode finally costs something reasonable for latency-critical paths, not that it got cheap.

The real cost decision is routing: which requests need 4.8, which can go to a smaller model, which run in batch, which justify fast mode.

9. Don't let "new model, must be better" replace your evals

This is the part I'd argue for hardest, and the rest of this post is why. Each change above is a thing to actually measure on your own workload before you trust 4.8 with production traffic:

The effort drop (§2): compare your hardest agent task at high vs xhigh. If you upgraded and left the default, did reasoning depth or token use quietly fall?

tool triggering (§5): count skipped-but-needed tool calls across your agent traces, 4.7 vs 4.8. This is the one most likely to have improved, so it's the one worth proving.

caching (§7): did your cache hit-rate change now that the floor is 1,024 tokens?

cost and latency (§8): track output tokens, tool-call counts, retries, and p95, and watch which direction each moved.

The question isn't whether 4.8 is better in the abstract. It's whether it's better for your workload under your cost and latency budget, and that's the one your evals can answer.

Bottom line

For casual chat, 4.8 just feels like a slightly better Claude. For anyone building agents, coding tools, RAG, or automation, the interesting changes aren't in the headline number.

They're in the defaults and primitives: opt-in adaptive thinking, the effort default moving back to high,fewer skipped tool calls, calmer long-running agents, 1M context by default, mid-conversation system messages, a lower cache floor, and fast-mode pricing that makes more sense than it used to.

So treat the model swap as the first step, not the whole job. Re-set xhigh for your agents before you forget, re-baseline your prompt caching, and run your evals before you flip production over, not after the bill shows up.

If you've already done the 4.7 to 4.8 move and hit something I didn't list here, leave it in the comments. The silent-default stuff is usually what you only find out the hard way.

Sources: Anthropic's Opus 4.8 migration guide, the Effort and Adaptive Thinking API docs, and the Opus 4.8 announcement (May 28, 2026).

Decentralized Finance Part 4: Real World Assets Meet DeFi

Mahima Thacker — Fri, 29 May 2026 08:40:19 +0000

What if you could earn rent from a house you don’t own, in a country you’ve never been to, using an app on your phone?

That’s the power of real-world assets in DeFi.

What Are Real World Assets (RWA)?

Real World Assets are things that exist outside the blockchain.

Examples:

Houses
Company shares
Government bonds
Invoices
Art or collectibles

These things are now being linked to DeFi through tokenization.

This means creating a digital version of a real asset, which can then be traded or used inside smart contracts.

Why Should We Care?

Tokenized real world assets open up new investment opportunities, making high-value assets more accessible to everyone. They bring much-needed liquidity to traditionally hard-to-sell assets, allowing for quicker transactions. The transparency and security of blockchain technology reduce fraud and build trust. Plus, integrating RWAs with DeFi creates innovative financial products and services, building a more inclusive, efficient, and transparent financial system for all, and more...

RWA Needs an On-Chain Connection

Real world assets live outside the blockchain.

To use them inside DeFi, we need a way to connect them to smart contracts.

This means creating a bridge between the physical world and the digital one.

Someone needs to verify the asset, hold it safely, and create a digital version of it on-chain.

That digital token is what DeFi apps can then use for trading, lending, borrowing, or earning.

Without this connection, real-world assets cannot interact with DeFi tools. The token must reflect the real thing clearly and must be backed by trust.

You Can Make These TODAY!

The exciting part is that tokenizing real-world assets isn't just for big corporations or tech gurus. With the right platforms and knowledge, individuals and businesses can also participate in creating these digital representations of physical assets today. The process generally involves a few key steps.

First, the real-world asset needs to be legally verified and appraised to determine its value and ownership. This is a crucial step to ensure that the digital token accurately reflects the physical asset. Once verified, the asset is then 'tokenized' on a blockchain.

This means a smart contract is created that represents the asset, and digital tokens are issued. These tokens can then be bought, sold, or traded on various blockchain platforms. While it might sound complex, many platforms are emerging that simplify this process, making it more accessible for a wider audience. This means that the potential for bringing real-world value onto the blockchain is immense, and it's happening right now, opening up new avenues for investment and ownership.

Key Benefits of RWA + DeFi

1. New Investment Opportunities: Tokenized real-world assets make high-value assets (like real estate, art, etc.) more accessible to everyone, lowering the barrier to entry for investments.
Increased Liquidity: Traditionally illiquid assets can be bought and sold almost instantly on a global market, allowing for quicker transactions and easier access to asset value.
Enhanced Transparency and Security: Blockchain technology ensures that every transaction is recorded on an immutable ledger, reducing fraud and increasing trust in asset ownership and transfer.
Innovative Financial Products: The integration of RWAs with DeFi platforms enables new financial services, such as using tokenized real estate as collateral for loans or participating in decentralized exchanges with real-world backed assets.

Popular RWA Projects in DeFi

Centrifuge - Brings real-world loans (like invoices) to DeFi

Goldfinch - Offers loans to real businesses in emerging markets

Maple - Lets institutions borrow on-chain

Ondo - Tokenizes US Treasuries for yield

Challenges to Watch:

Legal rules are not clear yet
Need for trusted middlemen to hold the real asset
Hard to scale across countries
Price feeds and real-world data must be accurate
Final Thoughts

Real World Assets will bring real growth to DeFi.

They connect blockchain to the world we live in.

And they give DeFi a chance to solve real problems, not just trade tokens.

Decentralized Finance Part 3: The Complete Guide to Stablecoins

Mahima Thacker — Fri, 29 May 2026 07:19:31 +0000

The Problem That Started It All

Imagine you bought a cup of coffee with Bitcoin six months ago. Back then, it cost you 0.0001 BTC. Today, that same amount of Bitcoin could buy you either half a cup or three cups, depending on Bitcoin's wild price swings. But if you paid with dollars six months ago and pay with dollars today, you'd pay roughly the same amount. This is the fundamental problem that stablecoins solve.

What Are Stablecoins?

Most people think stablecoins are simply "non-volatile crypto assets." This definition is wrong.

The correct definition: A stablecoin is a crypto asset whose buying power fluctuates very little relative to the rest of the market.

The keyword here is "buying power." It's not about price stability, it's about purchasing power stability. A stablecoin should let you buy roughly the same amount of goods today as you could yesterday, next week, or next month.

Why Do We Care About Stablecoins?

Money serves three critical functions, and understanding these explains why stablecoins matter:

1. Store of Value

Money should preserve your wealth over time. When you save money in a bank or invest in stocks, you expect it to maintain its purchasing power. Volatile assets like Bitcoin fail at this because your wealth can disappear overnight.

2. Unit of Account

Money should help us measure how valuable something is. We price Bitcoin in dollars, not the other way around, because Bitcoin's constant price changes make it a poor measuring stick. Nobody wants to price their business in Bitcoin when it could be worth 50% less tomorrow.

3. Medium of Exchange

Money should facilitate transactions. While you can technically buy groceries with Bitcoin, most people won't because they don't want to spend an asset that might double in value next week.

The Web3 Money Problem: Ethereum works great as a store of value and medium of exchange, but fails as a unit of account due to its volatile nature. We need Web3 money that can do all three functions reliably

Categories and Properties of Stablecoins

1. Relative Stability: Pegged/Anchored or Floating

Pegged Stablecoins: These are tied to another asset's value. Most popular stablecoins fall into this category:

Tether (USDT): 1 USDT = 1 USD

USD Coin (USDC): 1 USDC = 1 USD

Floating Stablecoins: These maintain stable buying power without being tied to any specific asset. Think of it this way: if you could buy 10 apples with 10 dollars five years ago, but today you can only buy 5 apples with 10 dollars due to inflation, a floating stablecoin would adjust so you can still buy 10 apples with the same amount.

Anchored Stablecoins: These are pegged to a specific reference point that moves over time. Think of it like measuring ocean levels, where the anchor point itself changes but the relationship remains stable.

2. Stability Method: Governed vs Algorithmic

This refers to who or what controls the minting and burning of stablecoins to maintain their peg.

Governed Stablecoins: Humans or organizations decide when to create or destroy tokens. These are typically centralized:

A government entity

A company (like Circle for USDC)

A decentralized autonomous organization (DAO)

Algorithmic Stablecoins: Smart contracts automatically mint and burn tokens based on predetermined rules. No human intervention required:

DAI (partially algorithmic)

FRAX

RAI

UST (failed example)

3. Collateral Type: Endogenous vs Exogenous

This describes what backs the stablecoin's value.

Exogenous Collateral: Backed by assets outside the stablecoin's ecosystem:

USDC is backed by US dollars

DAI is backed by ETH, USDC, and other external assets

If these stablecoins fail, their underlying collateral (dollars, ETH) continues to exist and function.

Endogenous Collateral: Backed by assets within the same ecosystem:

UST was backed by LUNA tokens

If UST failed, LUNA would fail too (which actually happened)

The relationship creates a reflexive loop where the stablecoin and its collateral depend on each other for value.

The Endogenous Dilemma

Endogenous collateral sounds risky, so why use it at all?

The Answer: Capital Efficiency

With exogenous stablecoins like USDC, you need to over-collateralize. To mint $100 worth of DAI, you might need to deposit $150 worth of ETH. This ties up a lot of capital.

Endogenous stablecoins can theoretically operate with zero external collateral because they're backed by their own ecosystem. This makes them highly capital efficient but also highly risky.

Summary of Popular Stablecoins

Check out these visuals to understand how some of the most well-known stablecoins are built and how they work

(DAI StableCoin)

(USDC StableCoin)

(RAI StableCoin)

What Stablecoins Really Do

Beyond just maintaining stable value, stablecoins serve as:

Financial Infrastructure: They enable DeFi protocols to function with predictable unit pricing.

Bridge Between Traditional and Crypto: They allow seamless movement between fiat and crypto worlds.

Yield Generation: Many stablecoins can be staked or lent to earn interest.

Global Access: They provide dollar-equivalent access to people in countries with unstable currencies.

Which Stablecoins Are Good?

For Safety and Reliability:

USDC: Highly regulated, transparent reserves

DAI: Decentralized, over-collateralized, battle-tested

For Innovation:

RAI: Truly algorithmic, not pegged to fiat

FRAX: Hybrid model balancing efficiency and stability

Trade-offs to Consider:

Centralized stablecoins (USDC) offer stability but can be frozen or regulated

Decentralized stablecoins (DAI, RAI) offer censorship resistance but may have slight fees and complexity

Algorithmic stablecoins offer capital efficiency but carry higher risks

The Future of Stablecoins

The stablecoin landscape continues evolving as projects balance three competing priorities:

Stability - Maintaining purchasing power

Decentralization - Avoiding central points of failure

Capital Efficiency - Maximizing utility of locked assets

The most successful stablecoins will likely be those that find the optimal balance between these three factors while serving the core functions of money in the digital age.

Before you use or build with stablecoins, take the time to understand how they’re designed. The more you know, the better decisions you’ll make in the Web3 world.

Decentralized Finance Part 2: Money Markets

Mahima Thacker — Fri, 29 May 2026 07:10:24 +0000

Banks have controlled lending and borrowing for centuries. They decide who gets loans, set the interest rates, and hold all the power. If your credit score isn't perfect or you don't have the right paperwork, you're out of luck.

DeFi Money Markets flip this system completely upside down.

No credit checks. No paperwork. No waiting weeks for approval.

Just deposit your crypto as collateral, and borrow instantly. The smart contract handles everything else.

What Are DeFi Money Markets?

DeFi money markets are lending platforms built on smart contracts.

They allow users to:

Lend crypto and earn interest - Deposit your tokens and get paid for lending them out

Borrow crypto and pay interest - Put up collateral and borrow different tokens

The most popular platforms include Aave, Compound, and others.

But here’s the catch:

You can’t borrow unless you first deposit something valuable.

This is called collateral.

Traditional Borrowing vs DeFi

In traditional loans, you get money based on:

Your salary

Credit score

Personal background

In DeFi, none of that matters.

The only thing that matters is how much you deposit as collateral.

How Collateral-Based Borrowing Works

The Collateral System

In DeFi, collateral is your security deposit. It's like leaving your car keys with a friend when you borrow their bike. If you don't return the bike, they keep your keys.

Here's a simple example:

You deposit 1,000 USDC as collateral

You can then borrow 800 DAI (or ETH worth $800)

You can't borrow more than you deposited

Your collateral stays locked until you repay the loan

DeFi Money Markets Glossary

Collateral

The crypto you deposit as security to borrow other tokens. If you deposit 1 ETH to a protocol, your collateral is 1 ETH.

Loan-to-Value (LTV) Ratio

LTV determines how much you can borrow compared to your collateral value. It's expressed as a percentage.

Example with 75% LTV:

You deposit 1 ETH worth $1,000 as collateral

You can borrow up to 0.75 ETH worth of other tokens (or $750 worth)

The protocol keeps 25% as a safety buffer

Different tokens have different LTV ratios based on their stability and risk.

The Liquidation Threshold

Liquidation happens when your borrowed amount becomes too risky compared to your collateral. It's the protocol's way of protecting itself and other users.

Common triggers:

Your collateral drops in value (ETH price falls)

Your borrowed asset rises in value (borrowed token pumps)

You borrow too close to your limit

How Liquidation Works

When you cross the liquidation threshold:

Liquidators step in - These are users who "buy" your debt

You pay a penalty - Usually 5-10% of your collateral value

Your collateral gets sold - To cover the borrowed amount

You keep the rest - Any remaining collateral after paying debt and penalty

The warning system: Most protocols show you a "health factor" that warns you before liquidation happens.

Annual Percentage Yield (APY)

The yearly return on your investment, including compound interest. If you earn 10% APY, your money grows by 10% over one year with compounding.

Annual Percentage Rate (APR)

The yearly cost of borrowing without compound interest. If you pay 8% APR, you pay 8% interest over one year on the original loan amount.

Receipt Token

A special token you receive when depositing into a protocol. It's like a receipt that proves you deposited funds. These tokens are minted when you deposit and burned when you withdraw.

Reserve/Underlying Asset

The actual token you deposited into the protocol. For example, if you deposit ETH into AAVE, WETH is the underlying token, and you receive aWETH receipt tokens.

Key Benefits of DeFi Money Markets

For Lenders:

Earn passive income on idle crypto

No minimum deposit requirements

Withdraw anytime (subject to liquidity)

Transparent interest rates

For Borrowers:

No credit checks or paperwork

Instant loan approval

Keep your crypto exposure while borrowing

Access to leverage trading strategies

Popular DeFi Money Market Protocols

AAVE: The largest lending protocol with innovative features like flash loans and rate switching.

Compound: Pioneer in DeFi lending with simple, reliable mechanics.

MakerDAO: Focused on DAI stablecoin creation through collateralized debt positions.

Conclusion

DeFi money markets represent a fundamental shift in how we think about lending and borrowing. They remove gatekeepers, reduce costs, and provide global access to financial services.

The power is now in your hands. No banker can reject your loan application. No credit agency can block your access. Just you, your crypto, and the smart contract.

But with great power comes great responsibility. Understanding collateral, liquidation, and risk management is essential before diving in

Decentralized Finance Part 1: Understanding DEXs and AMMs

Mahima Thacker — Fri, 29 May 2026 07:05:57 +0000

A few years ago, if you wanted to buy or sell crypto, you had to go through a central exchange. You'd sign up, verify your identity, and trust the platform to keep your money safe.

Then came Decentralized Exchanges (DEXs), a new way to trade crypto without giving up control.

No sign-ups. No middlemen. No waiting for someone on the other side.

Just you, a wallet, and a smart contract.

This is the revolutionary promise of Decentralized Finance (DeFi), where smart contracts handle everything automatically. Today, we'll explore the foundation of DeFi: Decentralized Exchanges (DEXs) and the magic behind them

What is a Decentralized Exchange (DEX)?

A Decentralized Exchange (DEX) lets you trade one token for another, directly from your wallet. There’s no company holding your money. Instead, smart contracts handle everything.

You connect your wallet. You choose what you want to swap. And the trade happens instantly.

How Does a DEX Actually Work?

Let's break down the key components that make DEXs possible:

1. Liquidity Pools

A liquidity pool is like a jar filled with two tokens. For example:

50 ETH and

10,000 DAI

People add their tokens to these pools. These people are called liquidity providers, and they earn small fees from every trade that happens.

2. Swapping

You want to swap your DAI for ETH?

The smart contract pulls ETH from the pool and adds your DAI to it.

The price changes based on how much you take and how much you give.

3. Automated Market Maker (AMM): The Price Calculator

Here's where it gets interesting. Instead of matching you with another trader (like in traditional markets), an AMM uses a mathematical formula to determine prices instantly. It's like having a calculator that always knows the fair price based on how much of each token is in the pool.

4. Small Fees, Big Rewards

Every trade pays a small fee (typically 0.3%). This fee gets distributed among all the people who provided liquidity to that pool. It's like getting a cut of every transaction just for helping keep the marketplace running.

Understanding Liquidity and Why It Matters

What is Liquidity? Liquidity is simply having enough tokens in a pool to make trading smooth and efficient. Think of it like having enough cash in your wallet to buy coffee without needing to break a $100 bill.

Why Do We Need It? Without enough liquidity, strange things happen:

Trades become slow and expensive

Prices swing wildly with small purchases

Large trades become nearly impossible

Who Benefits?

Traders get fast, reliable swaps

Liquidity providers earn passive income from fees

The entire ecosystem stays healthy and functional

Examples of Popular DEXs

PancakeSwap - Built on Binance Smart Chain. Fast and great for beginners.

SushiSwap - Available on many chains. It rewards people who add liquidity.

There are many more. Each one has its own pools, tokens, and features.

DEX vs CEX: Choose Your Adventure

Centralized Exchange (CEX):

Requires account creation and identity verification

Company holds your funds

Easy to use with familiar interfaces

Customer support available

Decentralized Exchange (DEX):

No signup required

You always control your funds

More privacy and anonymity

Full responsibility for your own security

The Bottom Line: Want complete control and privacy? Go with a DEX. Prefer simplicity and support? Choose a CEX.

How Automated Market Makers Work

An Automated Market Maker (AMM) is a smart contract that lets you swap tokens without needing someone else on the other side.

Let’s Break Down the Formula

X × Y = K
X = Amount of Token 1 in the pool
Y = Amount of Token 2 in the pool
K = A constant number that never changes

Think of K as the pool's "balance point." No matter how much trading happens, the formula ensures X × Y always equals K.

A Real-World Example

Let's say we have a pool with:

50 ETH (Token 1)
10,000 DAI (Token 2)
K = 50 × 10,000 = 500,000

Now imagine you want to buy 1 ETH using DAI.

After your trade:

ETH remaining = 49 (you took 1 ETH out)
To keep K = 500,000, we need: 49 × Y = 500,000
Y = 500,000 ÷ 49 = 10,204.08 DAI

Since the pool started with 10,000 DAI and needs 10,204.08 DAI after your trade, you must add 204.08 DAI to buy 1 ETH.

The price was calculated automatically by the formula, not by a person!

Why Prices Change as You Trade:

Here's where it gets interesting. The more ETH you try to buy, the more DAI you need to add to keep K constant. This makes each additional ETH more expensive.

Example:

Buying 1 ETH costs ~204 DAI

Buying 2 ETH would cost even more per ETH

Buying 10 ETH would be extremely expensive per ETH

This price increase is called "slippage," and it's completely normal in AMMs. It prevents any single person from draining the entire pool

This price jump is called slippage, the more you buy, the more you pay.

AMM vs Order Book

Order Book (used by CEX): Buyers and sellers agree on a price

AMM (used by DEX): The price is decided by a formula

In AMMs, you don’t wait for someone to match your trade.

The pool is always ready, the formula handles everything.

Key Takeaways

DEXs eliminate middlemen - You trade directly through smart contracts

Liquidity pools are the foundation - They provide the tokens needed for smooth trading

AMMs use simple math - The X × Y = K formula determines all prices

Everyone benefits - Traders get instant swaps, providers earn fees

You stay in control - Your funds never leave your wallet

In Part 2, we'll explore money markets

Gas Optimization Part 4: Solidity Tips for Cheaper Contracts

Mahima Thacker — Fri, 29 May 2026 06:55:31 +0000

Every line of your smart contract costs something.

Some lines cost more than others.

In this part of our gas saving series, we’ll explore how to write smarter Solidity code that keeps your contract lean and efficient.

Here are six simple and practical ways to reduce gas costs while writing Solidity smart contracts.

1. Use payable Only When Needed, But Know It Saves Gas

In Solidity, a function marked payable can actually use slightly less gas than a non-payable one.

Even if you're not sending ETH, the EVM skips some internal checks when the function is marked payable.

See this example:

function hello() external payable {}    // 21,137 gas

function hello2() external {}           // 21,161 gas

That tiny difference may not seem like much, but across thousands of calls, it adds up.

Only use payable when your function is actually meant to accept ETH

2. Use unchecked for Safe Arithmetic When You’re Sure

Since Solidity 0.8.0, all arithmetic operations automatically check for overflows and underflows. While this makes contracts safer, it also uses extra gas. When you're certain that overflow won't occur, you can use the unchecked keyword to skip these safety checks.

uint256 public myNumber = 0;

function increment() external {

unchecked {

myNumber++;

}

}

Gas used: 24,347 (much cheaper than using safe math)

Warning: Use unchecked carefully. Only when you're confident there's no risk of overflow.

3. Turn On the Solidity Optimizer

The Solidity Optimizer is like a smart helper that cleans up and tightens your compiled bytecode.

It does not change how your contract works, but it removes waste and makes it cheaper to run.

If you’re using tools like Hardhat or Remix, always enable the Optimizer before deploying to mainnet.

4. Use uint256 Instead of Smaller Integers (Most of the Time)

Smaller types like uint8 or uint16 might look more efficient, but they can cost more gas during execution.

That’s because the EVM automatically converts them to uint256 behind the scenes.

So, if you're not tightly packing them in a struct for storage savings, just use uint256.

Use smaller types only in structs when trying to save storage space.

5. Understand Storage Costs: Read + Write Costs Almost Same as Write

Storage operations are expensive. But here’s something surprising:

Reading a storage variable before writing to it doesn’t cost much more than writing directly.

Example:

Read + Write = 2,100 (read) + 20,100 (write) = 22,200 gas
Write only = 22,100 gas

That means if your code needs to read before writing, it’s okay, you are not losing much.

Plan your storage usage wisely. Reuse variables and avoid unnecessary writes.

Reference: https://ethereum.github.io/yellowpaper/paper.pdf

6. Use < Instead of <= in Comparisons

When comparing numbers, use < instead of <=.

Why? Because:

< needs just one check

<= takes two checks (a comparison and an extra step to flip the result)

Fewer steps mean lower gas usage.

Example:

for (uint i = 0; i < limit; i++) {

...

}

This small change saves gas on every loop iteration and comparison operation.

Conclusion

Gas optimization is about understanding how the EVM works and making informed decisions about your code structure. Each of these techniques might seem to save small amounts of gas individually, but combined and applied across a large contract, they can result in significant cost savings.

Remember: Always test your optimizations thoroughly. Sometimes gas savings come at the cost of code readability or safety. Strike the right balance for your specific use case.

Key Takeaways:

Use payable functions when appropriate
Apply unchecked carefully for safe arithmetic
Enable the Solidity optimizer
Prefer uint256 for most variables
Understand storage access patterns
Choose efficient comparison operators

By implementing these strategies, you'll create contracts that not only work well but also cost less to deploy and interact with, making them more accessible to users and more profitable for developers.

Gas Optimization Part 3: The Foundation of Gas in Solidity and Smart Contract Efficiency

Mahima Thacker — Fri, 29 May 2026 06:51:43 +0000

You just deployed a smart contract, and it’s costing 98 gas to run a function that does nothing. Literally.

See for yourself, Why?

Because even doing “nothing” on Ethereum still means something to the Ethereum Virtual Machine (EVM).

Welcome to Part 3 of our gas optimization series, where we will look at how gas really works behind the scenes and how you can make your Solidity smart contracts use less gas by removing anything that’s not needed.

The Building Blocks: OPCODEs Are the DNA of Ethereum

In Solidity, saving on gas is like saving fuel in your car. To do that, you need to know about OPCODEs - the basic commands that tell Ethereum what to do. They're the ABCs of Ethereum's language.

When you write Solidity code, it doesn't run directly on the Ethereum network. Instead, it gets compiled into a set of OPCODEs that the Ethereum Virtual Machine (EVM) can understand and execute. Think of it like translating English into machine language that computers can process

What Are OPCODEs?

OPCODEs are low level instructions that perform specific operations:

Arithmetic Operations: ADD, SUB, MUL, DIV for mathematical calculations

Memory Operations: MLOAD, MSTORE for temporary data storage

Storage Operations: SLOAD, SSTORE for permanent blockchain storage

Program Flow: JUMP, JUMPI for conditional logic.

Cryptographic Functions: SHA3, ECRECOVER for security operations

Contract Interactions: CALL, DELEGATECALL for inter-contract communication

And here’s the catch:

Each OPCODE consumes gas, and some cost way more than others.

Pro Tip:

You can see the full list of OPCODE gas costs here: ethereum.org/en/developers/docs/evm/opcodes

The Secret Code: Function Selectors

Here's something that might surprise you: when you compile your Solidity code into bytecode, the names of your functions don't actually show up in the final assembly output. Instead, what ends up on the Ethereum network is something like a secret code called function selectors

How Function Selectors Work

Function selectors are created by taking the first four bytes of the hash of the function's signature. Let's look at a real example:

function doNothig() external pure {}

After compilation, this becomes:

46aad107

So when someone sends a transaction to your contract, they don’t send the name

doNothig()

,they send the selector 0x46aad107.

That’s how the EVM knows which function to run, without storing long names on-chain.

Gas Optimization Tips Every Developer Should Know

1. Keep It Light

The less code you deploy, the less gas you'll use during deployment. Think of it as packing light for a flight - every extra byte costs money.

Code size optimization strategies:

Remove unnecessary functions and variables

Use libraries for common operations instead of duplicating code

Implement proxy patterns for upgradeable contracts

Strip out debugging code and comments in production

Real impact: A 1KB reduction in contract size saves approximately 200,000 gas units during deployment

2. Choose Wisely: OPCODE Selection

Certain commands are cheaper than others. Picking the right ones is like choosing a budget airline over a luxury carrier.

Cost-effective choices:

Some instructions (like ADD) cost less than others (like SSTORE).

Store fewer variables

Avoid unnecessary require checks

Minimize state changes

3. Pack Data Tight: Transaction Data Optimization

The more data you send in a transaction, the more you spend. Keep your transaction data lean.

Data packing techniques:

Use struct packing to fit multiple variables in single storage slots

Compress arrays and use fixed-size arrays when possible

Batch multiple operations to reduce transaction overhead

Use events instead of storage for data that doesn't need to be queried on-chain

4. Minimize Memory Use

Memory is temporary, but still costs gas.

Avoid creating new memory variables when not required.

Use calldata instead of memory for function inputs when possible

5. Be Smart About Storage

Storage is the most expensive operation.

Only write to storage if you must

Use events to log non-critical data instead of storing it

Don’t overwrite storage values unless necessary

Every time you write to SSTORE, you’re paying a premium.

The Compound Effect

A little bit of gas saved on every transaction can add up to significant savings over time. If your contract processes 1,000 transactions per day and you save 500 gas per transaction, that's 500,000 gas units daily - potentially saving hundreds of dollars monthly at current gas prices.

Understanding OPCODEs and function selectors is just the beginning. In Part 4, we'll explore advanced Solidity techn

Gas Optimization Part 2: Timing Strategies and Batch Processing

Mahima Thacker — Fri, 29 May 2026 06:47:57 +0000

You've learned what gas fees are and how they're calculated. Now comes the practical part: how to actually save money on every transaction you make. The difference between a novice and an expert Ethereum user often comes down to understanding when and how to execute transactions efficiently.

Haven't read Part 1 yet? Check out my introduction to gas fees and how they work to understand the fundamentals before diving into these optimization strategies.

Let's explore the proven strategies that can cut your gas costs by 50-90% without compromising transaction security or speed

Strategy 1: Master the Art of Timing

Weekends: Saturday and Sunday typically see 20-30% lower gas fees as business activity decreases.

Off-peak hours: Between 2 AM and 6 AM UTC, when both American and European users are asleep, gas prices often drop significantly.

Avoid these high-traffic periods:

NFT mint launches

Major DeFi protocol updates

Market crash periods (panic selling drives up demand)

Weekday mornings (8-10 AM UTC)

You can use trackers like:

https://etherscan.io/gastracker

Pro tip: Set up gas price alerts on your phone. When prices drop below your target threshold, that's your window to execute pending transactions.

Strategy 2: Batch Processing

Why send 10 separate transactions…

When you can send one batch?

Batching reduces overhead, saves time, and lowers gas.

Let’s explore 3 Ethereum standards that enable powerful batching:

1) ERC-3005: Batched Meta Transactions - https://eips.ethereum.org/EIPS/eip-3005

This standard lets users combine multiple actions into one meta transaction.

Example:

Approve token

Swap on DEX

Send output to wallet

All in one call, reducing gas and relayer fees.

Great for:

Wallet apps

Gasless UX

Relayer-backed platforms

2) ERC-7821: Minimal Batch Executor - https://eips.ethereum.org/EIPS/eip-7821

This one’s about delegations and shared execution.

Think of it like batching multiple on-chain delegations, such as:

Voting
Staking
DAO participation

With atomic execution, if one part fails, nothing gets through so it keeps safe and predictable.

Perfect for:

DAO tools
Governance app
Delegation-heavy protocols

Example scenario: You want to withdraw from a liquidity pool, swap the tokens, and deposit them into a yield farming protocol. ERC-7821 ensures all these operations happen atomically, preventing scenarios where only part of your strategy executes

3) ERC-4393: Batch Micropayments - https://eips.ethereum.org/EIPS/eip-4393

When you need to make multiple small payments, ERC-4393 shines. This standard enables multiple tips or payments in a single transaction call.

Use case: Tipping multiple content creators or making several small purchases. Instead of paying gas fees for each micropayment, you pay once for the entire batch

Strategy 3: Wait for gas to go down

Gas prices go up and down every twelve seconds based on how congested Ethereum is. When gas prices are high, waiting just a few minutes before making a transaction could see a significant drop in what you pay.

Strategy 4: Use Layer 2 Solutions

Layer 2 solutions like zkSync, Arbitrum, and Optimism reduce gas fees by up to 95%. By bundling a large number of transactions together, these solutions reduce the number of on-chain transactions.

Popular options:

Arbitrum
Optimism
Base
Polygon (PoS)

Many dApps are now L2-ready. Just bridge your ETH once, and you’re good to go.

Wrap-up

Ethereum gas fees aren’t going away, but you can outsmart them with:

Good timing

Layer 2 networks

Batched transactions using ERC-3005, ERC-7821, and ERC-4393

Wait for the gas to go down

What’s next?

While timing and batching strategies can dramatically reduce your transaction costs, the next frontier in gas optimization lies in smart contract efficiency. In Part 3, we will explore advanced Solidity techniques that developers use to minimize gas consumption at the code level.

Gas Optimization Part 1: Understanding Ethereum Gas Fees

Mahima Thacker — Fri, 29 May 2026 06:42:08 +0000

“I paid $62 just to send $100. What?”

That’s the kind of reaction many new users have after making their first Ethereum transaction during peak congestion.

No NFTs. No DeFi. Just a simple ETH transfer.

Yet the gas fee was more than half the value of the transaction.

And they thought it was a bug.

But it wasn’t.

It was Ethereum being busy.

Welcome to the world of gas fees.

What Is Gas, Really?

If you’ve ever driven a car, you already understand gas.

Think of your Ethereum transaction as a car trip. To drive (process your transaction), you need fuel, and on Ethereum, that fuel is called Gas.

Just like fuel powers a car, gas powers your transaction on the Ethereum network.

But there’s a catch: The busier the road, the higher the fuel price.

So when the Ethereum network is crowded (say, during a hyped NFT mint), gas prices shoot up because everyone’s trying to get their transactions through.

Why Gas Prices Change

Back to our highway example:

If traffic is light, fuel is cheap, and if traffic is jammed, fuel costs more to cut through

Ethereum works similarly.

You can pay a higher gas price to get your transaction picked up faster by validators

Or you can set a lower price and wait.

Understanding the Components

Gas Limit

This is the maximum amount of gas you're willing to use.

For simple ETH transfers, it's usually 21,000.

Gas Price

This is how much you're willing to pay per unit of gas, measured in Gwei.

Gas Usage:

This is the actual amount of gas consumed by your transaction. It's often the same as your gas limit for simple transactions, but complex operations might use less than the limit you set.

Breaking Down Gas Fees: A Real Example:

Gas Limit = 21,000
Gas Price = 35.06 Gwei
ETH Price = $3,492.21

Step 1: Calculate Gas Fee in ETH

21,000 × 35.06 / 1,000,000,000 = 0.000736 ETH
Step 2: Convert to Dollars

0.000736 × 3,492.21 = $2.57

So, the fee for that simple transaction is about $2.57.

But when the network gets congested, gas prices might 10x, and that’s how people end up paying $50+ just to send ETH.

The Game-Changer: EIP-1559

In August 2021, Ethereum introduced EIP-1559, which revolutionized how gas fees work. Instead of the old auction-style system where users had to guess appropriate gas prices, EIP-1559 brought predictability and efficiency.

How EIP-1559 Works

The new system introduces several key components:

Base Fee: This is a fixed price per unit of gas that the network automatically adjusts based on demand. Here's the interesting part: this base fee gets burned (destroyed), permanently removing ETH from circulation.

Max Fee: The maximum amount you're willing to pay for the transaction. This acts as your safety net.

Max Priority Fee: The tip you're willing to give to miners to prioritize your transaction.

A Real EIP-1559 Example

Let's say you're making a transaction with these parameters:

Base Fee: 70 Gwei
Max Fee per Gas: 90 Gwei
Max Priority Fee per Gas: 15 Gwei

Here's what happens:

70 Gwei gets burned (the base fee is destroyed)

Miners receive 15 Gwei (your full priority fee since Max Fee - Base Fee = 20 Gwei, which is higher than your 15 Gwei priority fee)

You get 5 Gwei refunded (90 - 70 - 15 = 5 Gwei back to your wallet)

This system eliminates the guesswork. You know exactly what you'll pay upfront, and any excess gets refunded automatically.

Looking Ahead

Gas optimization isn't just about understanding current fees. It's about developing strategies to minimize costs while maintaining transaction reliability. In the next part of this series, we'll dive into practical techniques for optimizing your gas usage, including timing strategies, transaction batching, and smart contract optimization tips.

The key takeaway? Gas fees might seem complex, but they follow predictable patterns. Once you understand these patterns, you can navigate the Ethereum network like a pro, saving money and avoiding the frustration of failed transactions.

Remember: every Gwei saved is money back in your pocket. And in the world of DeFi and NFTs, where you might make dozens of transactions per month, those savings add up quickly.

They Lost Millions by Clicking ‘Sign’ - Here’s How to Never Make That Mistake

Mahima Thacker — Fri, 29 May 2026 06:35:53 +0000

Picture this: You're the treasurer of a major crypto exchange. Your phone buzzes with a notification - another routine transaction needs approval. You glance at your screen, see familiar addresses, and click "approve" without a second thought. Within minutes, millions of dollars vanish into thin air.

This isn't fiction. This exact scenario played out when Bybit, one of the world's largest cryptocurrency exchanges, fell victim to a sophisticated hack executed by North Korean cybercriminals. The culprit? A signer who didn't fully verify a transaction, leading to a critical Safe UI vulnerability that drained millions from their multi-signature wallet.

The harsh reality is that even the most secure wallet setups can crumble with one careless click. But here's the good news: these disasters are completely preventable when you know what to look for.

Don’t want to be the next victim?

Let’s walk through how to verify calldata, use multi-sig safely, and pick the right wallet for your level.

The Wallet Hierarchy: Choosing Your Guardian

Before diving into verification techniques, let's address the elephant in the room: which wallet should you even use?

Total Beginner with Small Amounts: Start with custodial wallets or keep funds on reputable exchanges. Yes, "not your keys, not your crypto" is true, but losing $100 to exchange risk beats losing $100 to your own mistakes.

Beginner with Small Money: Browser wallets like MetaMask or Phantom work well. They're user-friendly and perfect for learning the ropes with amounts you can afford to lose.

Intermediate Users with Medium Amounts: Hardware wallets like Ledger or Trezor become essential. They keep your private keys offline and away from internet threats.

Intermediate Users with Large Amounts: Combine multi-signature wallets with hardware wallets. This creates multiple checkpoints that hackers must breach simultaneously.

Advanced Users with Significant Holdings: Multi-signature wallets with social recovery, or custom solutions. At this level, you're building Fort Knox for your digital assets.

For wallet comparisons and security audits, check out walletscrutiny.com, it's like a Consumer Reports for crypto wallets.

Hot vs Cold Wallets

Hot wallets stay connected to the internet (MetaMask, Phantom, and mobile apps). They're convenient for daily transactions but vulnerable to online attacks.

Cold wallets remain offline (Ledger, Trezor hardware devices). They're like keeping cash in a physical safe, much harder to steal remotely.

Important:

Even a cold wallet becomes hot if you connect it to a Safe multi-sig UI!

Always be aware of when you’re online vs offline

Verifying Simple Transactions: Your First Line of Defense

When using MetaMask or similar wallets, you'll sometimes see transaction details that look like gibberish. Don't panic, here's how to decode them:

Check These Three Things:

Estimated changes - What's actually moving in and out of your wallet

The "to" address - Where your money is going

Hash data - The first 4 bytes reveal the function being called

For example, if you see "0xa9059cbb" in your transaction data, you can decode it using Cast (a developer tool):

cast sig "transfer(address,uint256)"

This returns the function selector you can compare against your transaction. If they match, you're calling a transfer function. If they don't match, stop immediately.

To verify the specific parameters of a transfer:

cast calldata-decode "transfer(address,uint256)"

This shows exactly where your tokens are going and how many.

Multi-Sig Transactions: Where Things Get Complicated

Multi-signature wallets require multiple people to approve transactions before they execute. Think of it like a shared bank account where both you and your spouse need to sign checks for large purchases

Critical Point: A signature request is NOT the same as a transaction request. You're not sending money yet, you're just adding your approval to a pending transaction.

How to Verify a Multi-Sig Transaction

Step 1: Install the Right Tools Get Cyfrin's Safe_hashes tool from GitHub

https://github.com/Cyfrin/safe-tx-hashes?tab=readme-ov-file#curl

This tool decodes Safe transactions into a human readable format.

Step 2: Run the Verification Command

safe_hashes --address --network --nonce

If no transaction appears, use --untrusted mode in above command

Step 3: Manual Verification (Advanced) For complete independence from APIs, use Cast:

cast calldata "approve(address,uint256)"

Then verify with Safe hashes:

safe_hashes --address --network --nonce 2 --data --offline --to

The Golden Rules That Could Save Millions

Never sign and execute simultaneously. Some wallets try to streamline this process, but convenience is the enemy of security.

Watch for operation codes. If you see "operation = 1" in your transaction, you're looking at a DELEGATECALL - essentially giving another contract permission to act with your wallet's full authority. This is extremely dangerous and should only be used in very specific circumstances.

Always verify these three elements before any signature:

The destination address (where is this going?)
The function selector (what action is being performed?)
The value or amount (how much is involved?)

Why This Matters More Than Ever:

The Bybit hack wasn't an isolated incident. Similar attacks happen regularly because people skip verification steps. The difference between a secure transaction and a devastating hack often comes down to spending 30 seconds to verify what you're actually signing.

Remember: in the world of cryptocurrency, there's no "undo" button. Once a transaction is confirmed on the blockchain, it's permanent. The few minutes you spend verifying could be the difference between protecting your assets and reading about your loss in tomorrow's crypto news.

The tools and techniques outlined here aren't just for crypto professional, they're for anyone who values their digital assets enough to protect them properly. Start with the basics, build good habits, and gradually level up your security practices as your holdings grow.

TL;DR

Pick the right wallet for your level

Always verify the transaction before signing, especially calldata

Never trust the UI blindly

Use Safe_hashes or Cast for decoding

Multi-sig ≠ automatic safety

One wrong click can empty your wallet. Take 30 seconds and verify, your future self will thank you.

RAG for Codebases Is Harder Than It Looks

Mahima Thacker — Wed, 27 May 2026 13:20:36 +0000

Building RepoChat, an AI tool that explains GitHub repos

I built a small AI tool called RepoChat.

The idea is simple:

Paste a GitHub repo. Ask questions. Get answers from the codebase.
Something like:

What does this project do?
How is the backend structured?
Where is authentication handled?
How do I run this locally?
Which files should I read first?

I did not want to build another chatbot. I wanted to build something useful for developers.

Because every developer has faced this problem:

You open a new repo.
There are 50 files.
The README is either missing, outdated, or too high-level.
You don’t know where to start.

So I wanted to see if RAG could help make codebase onboarding faster.

What RepoChat does

RepoChat takes a GitHub repository and turns it into something you can ask questions about.

The first version is intentionally small.

It has two main flows.

Indexing happens once for a repo:

GitHub repo
files
filtered files
chunks
OpenAI embeddings
Chroma vector DB

Querying happens every time someone asks a question:

question

embed question
search Chroma
top-K chunks
Claude
answer with sources

This split helped me think about the system more clearly.

The indexing pipeline prepares the repo.

The query pipeline uses that indexed repo to answer questions.

The basic architecture

The first version has a frontend and a backend.

The frontend is simple:

repo URL input
question input
answer section
sources section

The backend does the heavier work:

fetch repo files
filter useful files
chunk text/code
create embeddings
store chunks
retrieve relevant chunks
call the LLM

I used this kind of structure:

repochat-ai/
  apps/
    web/
    api/
  data/
    chroma/
  README.md

The stack:

Frontend: Next.js, React, Tailwind
Backend: FastAPI
Chunking: LangChain text splitters
Embeddings: OpenAI text-embedding-3-small
Vector DB: Chroma
LLM: Anthropic Claude Sonnet 4.6
Repo data: GitHub API

I used two providers for different jobs.

OpenAI handles embeddings because its embedding models are simple and reliable for this use case.

Claude handles generation because I wanted stronger reasoning and clearer explanations for codebase questions.

This felt better than forcing one provider to do everything.

Step 1: Fetching the repo

The first problem was getting the right files.

At first, I thought:

Just fetch the repo and send everything to the AI.

That sounds simple, but it breaks quickly.

Repos contain a lot of files that are not useful for understanding the project:

node_modules/
.git/
dist/
build/
lock files
generated files
images
large JSON files

So I had to filter files.

For the first version, I focused on files like:

README / readme files .md .py .ts .tsx .js .jsx .json

This already made the answers better.

One thing I learned here:

Good RAG starts before embeddings. It starts with choosing what data should enter the pipeline.

If you put garbage into the vector database, retrieval will return garbage too.

Step 2: Chunking code is not the same as chunking docs

This was the first part that felt harder than expected.

Most RAG tutorials use normal text:

paragraph
paragraph
paragraph

But code is different.

A code file has:

imports
functions
classes
comments
config
repeated names
small pieces that only make sense together

If chunks are too small, the model loses context.

If chunks are too large, retrieval becomes noisy.

Example:

function getUser() {
  ...
}

This function alone may not be enough.

The useful context may include:

import { db } from "./db"
import { users } from "./schema"

function getUser() {
  ...
}

So I had to think more carefully about chunk size and metadata.

For every chunk, I kept metadata like:

The file path is very important.

A chunk from:

apps/api/auth.py

means something different from:

apps/web/components/Login.tsx

Even if both mention “user” or “auth”.

The file extension is not stored separately, but it is still available through the path.

Step 3: Embeddings and retrieval

Once the files were chunked, I created embeddings using OpenAI’s text-embedding-3-small model and stored them in Chroma.

When a user asks a question, I embed the question too.

Then the system searches Chroma for chunks that are close to that question.

So if someone asks:

Where is authentication handled?

the system may find related chunks even if the exact word “authentication” is not used everywhere.

It can still find related words like:

auth
login
session
token
middleware
jwt
user

This is where RAG becomes useful.

But retrieval is not magic.

Sometimes it retrieves:

the README instead of the actual code
a frontend file when the backend file is more useful
a config file because it has matching words
a chunk that mentions the right term but does not answer the question

That was a good reminder:

RAG is not just “put data in vector DB and ask questions.” Retrieval quality matters a lot.

Step 4: Asking questions

The Q&A flow looks like this:

User asks a question:

embed the question
retrieve top relevant chunks
send chunks + question to Claude
generate answer
show answer with source files

I wanted answers to include sources because without sources, it is hard to trust the output.

For developer tools, source references are not optional.

If the AI says:

Auth is handled in middleware.

I want to know:

Which file?
Which function?
Where should I look?

So the answer should include something like:

Sources:

- apps/api/middleware/auth.ts
- apps/api/routes/users.ts
This makes the tool much more useful.

What broke or felt messy

This was the most useful part of the build.

A few things were harder than expected.

1. Large repos are noisy

Small repos are easy.

Large repos need better filtering.

A real repo may contain:

docs
examples
tests
scripts
generated files
frontend
backend
infra

If everything is indexed equally, answers become messy.

A better version should rank files based on importance.

For example:

README.md
package.json
main entry files
routes
config files
src/
docs/

should probably matter more than random test snapshots.

2. README is useful but not enough

README files are helpful for high-level questions.

But if you ask:

How does auth work?

the README is usually not enough.

You need code.

This is where code-aware retrieval becomes important.

3. File paths matter a lot

At first, I treated chunks mostly as text.

But for codebases, metadata is part of the answer.

A chunk from:

backend/routes/payment.ts
It is not just text.

It tells you:

This is backend code
This is route-level logic
This likely handles payment APIs

So the file path helps both retrieval and explanation.

4. The model needs strict instructions

If the model does not know something, it should say so.

For example:

I could not find authentication logic in the indexed files.

is much better than:

The app probably uses JWT authentication.

For a developer tool, guessing is dangerous.

So the prompt rule was intentionally strict:

Answer using only the provided repo context.
If the answer is not present in the context, say that clearly.
Always mention the source files used.
Do not guess implementation details.

What I learned about RAG

Building RepoChat made RAG feel much more real to me.

Before building it, RAG sounded simple:

embed docs
retrieve docs
ask LLM

After building it, I see it more like this:

choose the right data
clean the data
chunk it properly
store useful metadata
retrieve the right chunks
control the prompt
show sources
test bad answers

The retrieval part is only one piece.

The developer experience around it matters just as much.

A developer should not care about embeddings or vector DBs.

They should only feel:

“I understand this repo faster now.”

What I would improve next:

The first version is useful, but there are many things I would improve.

1.Better code parsing

Instead of splitting files only by text size, I want to split code by structure:

functions
classes
exports
API routes
components

Tools like Tree-sitter could help with this.

2.Repo map

Before answering questions, the app could build a repo map:

frontend
backend
API routes
database
auth
config
tests

This would help the model understand the project layout better.

Better source citations

Right now, file-level sources are useful.

But line-level sources would be better.

Example:

apps/api/auth.ts:45-72

That would make answers easier to verify.

3.Evaluation questions

Every repo could have test questions like:

How do I run this project?
Where is auth handled?
Where are API routes defined?
What database does it use?

Then I can test whether RepoChat answers correctly.

This is where evals become useful.

4.MCP integration

Later, RepoChat could expose repo search as an MCP tool.

Then an agent could ask:

search_codebase("where is auth handled?")

and use RepoChat as a codebase understanding tool.

Final thoughts

RepoChat started as a small demo, but it taught me a lot.

The biggest lesson:

RAG is only useful when the developer can trust the answer.

For codebases, trust comes from:

good retrieval
useful chunks
file metadata
clear sources
honest “I don’t know” answers

I still want to improve RepoChat, but even this first version made one thing clear:

AI tools for developers should not try to replace understanding.

They should help developers reach understanding faster.

That is the part I find exciting.

Code

GitHub: https://github.com/mahimathacker/repochat-ai
Live demo: https://youtu.be/kSgZSqH6iXk

I’m still improving it, especially around better code parsing, line-level citations, repo maps, evals, and MCP support.

Are u still confused about how swapping works on Uniswap or other DEXs?

Mahima Thacker — Sat, 29 Mar 2025 05:13:50 +0000

Not anymore 💁‍♀️
This might seem long, but trust me it’s worth every scroll 😉
Let’s break it down in simple terms — no advanced math, no technical fluff.

1/ What is AMM?

An AMM (Automated Market Maker) is like a robot that lets you swap tokens without needing a buyer or seller.
Instead of matching orders like an order book used in a centralised exchange. it uses a liquidity pool (a jar of tokens) and a formula to decide the price. So,
No order books
No middlemen
Just a smart contract doing the job
The formula calculated the price ->X * Y = K

2/ What’s in the Liquidity Pool?

Each pool holds two tokens, say: Token 1 = ETH (e.g., 50 ETH) Token 2 = DAI (e.g., 10,000 DAI)
This pool is created by users (called liquidity providers) who deposit equal value of both tokens.

3/ The Magic Formula: X * Y = K

This is the core logic of how prices are determined.
X = Amount of Token 1 (ETH)
Y = Amount of Token 2 (DAI)
K = Constant value that should never change
As you trade, the values of X and Y shift, but K always remains the same. That’s what keeps everything balanced!

4/ Let’s Understand With an Example:

Before Trade: ETH in pool = 50 DAI in pool = 10,000 Constant K = 50 * 10,000 = 500,000

Now let's say you want to buy 1 ETH using DAI.

After the Trade: ETH left = 49 (because you took out 1 ETH)
To maintain K = 500,000, the pool must now hold more DAI. 49 * Y = 500,000 Y = 500,000 / 49 ≈ 10,204.08 DAI

So the pool needs 10,204.08 DAI after your trade. That means you have to add ~204.08 DAI to buy 1 ETH

That’s how price is automatically calculated — by using the formula, not a person 🫣

5/ Why Price Increases as You Trade?

The more ETH you try to buy, the more DAI you must add to keep K constant.
This makes ETH more expensive with each purchase. That’s slippage — and it’s normal in AMMs

6/ Order Book vs AMM

In an order book, trades are matched between buyers and sellers at the same price.
In an AMM, the price is calculated automatically based on how much is in the pool

7/ Final Takeaway

You’re trading with math, not a person.
The pool keeps everything balanced using X * Y = K.
More buying = price goes up (and vice versa).
No need for someone on the other side — you just interact with the pool!