Forem: Saurav Kumar

Beyond Function Calling: Introducing Advanced Tool Orchestration on the Claude Developer Platform

Saurav Kumar — Wed, 26 Nov 2025 05:09:17 +0000

The future of AI agents relies on their ability to seamlessly and efficiently integrate with vast libraries of tools—from internal databases and company-specific APIs to public services like GitHub and Slack. As professional developers, we know that scaling an agent from five tools to fifty or five hundred introduces critical bottlenecks: context bloat, slow execution, and unpredictable tool invocation.

To solve these challenges, we are excited to introduce three advanced features on the Claude Developer Platform that fundamentally change how agents discover, orchestrate, and utilize external capabilities. These features move Claude from simple sequential function calling to intelligent, programmatic orchestration.

1. Tool Search Tool: Dynamic Discovery for Infinite Scale

When building agents that connect to many services (e.g., a five-server MCP setup with dozens of tools), token overhead quickly becomes a critical limitation.

The Challenge: Context Bloat and Accuracy

Traditional tool use requires loading all tool definitions into Claude's context window upfront. For a large multi-server environment (e.g., GitHub, Slack, Jira, Sentry, Splunk), tool schemas can easily consume 50,000+ tokens before the agent even begins its work. This limits space for conversation history and reasoning, increasing cost and reducing performance. Furthermore, overwhelming Claude with dozens of similar-sounding tool names leads to frequent selection errors.

The Solution: On-Demand Tool Discovery

The Tool Search Tool solves this by letting Claude discover and load tools only when they are needed for the current task.

Developers mark less-critical tools with defer_loading: true in the API call. Claude initially only sees the lightweight Tool Search Tool itself and any frequently-used tools. When Claude determines it needs a specific capability (e.g., "create a pull request"), it searches the tool definitions, and only the relevant tools (e.g., github.createPullRequest) are loaded into the context.

Real-Life Use Case and Benefits

Massive Token Savings: In internal testing, this feature resulted in an 85% reduction in token usage on average compared to the traditional approach, preserving hundreds of thousands of tokens for reasoning and history.
Improved Accuracy at Scale: By only presenting Claude with the most relevant tools, selection accuracy significantly improves, especially when dealing with large tool libraries. Internal benchmarks showed accuracy improvements from 79.5% to 88.1% on complex, multi-server evaluations.
Scale Without Cost: You can now connect your agent to hundreds of tools across dozens of microservices (e.g., a vast internal API ecosystem) without incurring a massive token penalty on every request.

2. Programmatic Tool Calling (PTC): Efficient Code Orchestration

For complex, multi-step workflows involving data processing, the traditional method of making sequential tool calls—with each result returning to Claude's context—is slow and inefficient.

The Challenge: Context Pollution and Inference Overhead

Context Pollution: When processing large data (e.g., 10MB log file analysis or retrieving 2,000+ expense line items), the raw, intermediate results flood Claude’s context window. This pushes out critical information and forces Claude to use precious context space for raw data processing, rather than high-level reasoning.
Inference Overhead: Each tool call requires a full API round-trip and a new model inference pass to process the result and decide the next step. A 5-tool workflow involves 5 inference passes, leading to high latency.

The Solution: Code-Driven Execution

Programmatic Tool Calling enables Claude to orchestrate complex operations by writing a Python script that runs in a sandboxed execution environment. Instead of the model seeing all intermediate results, the script handles the logic: loops, conditionals, data transformations, and parallel execution.

The script calls your tools (get_team_members, get_expenses, etc.), and the results are routed directly to the running code environment, bypassing Claude's context window. Only the final, processed output from the script is returned to Claude for the final response generation.

Real-Life Use Case and Benefits

The Budget Compliance Check: Imagine determining which team members exceeded their Q3 travel budget. PTC allows Claude to write a script that:
1. Fetches team members and budgets in parallel.
2. Fetches all expense line items (e.g., 2,000 records).
3. Sums the expenses, compares them to the budget limit, and filters the results—all within the code sandbox.
4. Claude only sees the final list of the 2-3 members who exceeded their budget, reducing context consumption from ~200KB of raw data to ~1KB of results.
Reduced Latency: By orchestrating multiple tool calls within a single execution block, you eliminate most inference passes (e.g., 19+ passes saved in a 20-tool workflow), leading to significant latency improvements.
Token & Accuracy Gains: Internal testing showed a 37% reduction in token consumption on complex research tasks and improved accuracy (e.g., GIA benchmarks improved from 46.5% to 51.2%) due to explicit, programmatic control flow.

3. Tool Use Examples: Defining Usage Patterns for Reliability

JSON Schema is necessary for defining the structural requirements of a tool, but it's often insufficient for defining how the tool should be used in practice.

The Challenge: Ambiguity and Parameter Errors

Schema cannot express critical usage conventions:

Format Ambiguity: What date format should due_date use (YYYY-MM-DD vs. MM/DD/YYYY)?
Correlated Parameters: How do priority level and escalation.sla_hours relate?
Usage Conventions: When should optional, nested structures like reporter.contact be included?

These ambiguities are a primary source of malformed tool calls and inconsistent agent behavior.

The Solution: Concrete Usage Demonstration

Tool Use Examples allow you to include one or more concrete, successful tool invocation objects (input_examples) directly in your tool definition.

By providing examples of successful calls—including a minimal call, a partial call, and a full, complex call—you demonstrate the API's expected behavior and conventions.

Real-Life Use Case and Benefits

API Consistency: For a complex create_ticket API, examples can teach Claude:
- To use "YYYY-MM-DD" for dates.
- To follow a specific ID convention (e.g., "USR-12345").
- That critical priority always requires populating the full escalation object.
Increased Reliability: Claude learns the "intent" behind the schema, leading to more reliable and consistent parameter population, especially for optional fields and nested objects.

Strategic Layering for Optimal Agent Architecture

These three features are designed to be complementary, allowing you to layer them strategically to solve your specific agent bottlenecks:

Bottleneck	Feature to Use	Benefit
Context bloat from tool definitions	Tool Search Tool	Dynamic discovery preserves context and improves accuracy at scale.
Large intermediate results polluting context	Programmatic Tool Calling	Code orchestration ensures only actionable final results enter context.
Parameter errors and malformed calls	Tool Use Examples	Demonstrates usage patterns for reliable and consistent invocation.

By adopting dynamic discovery, code-based orchestration, and usage-pattern learning, you can build truly scalable, accurate, and efficient AI agents capable of mastering even the most complex enterprise workflows. These features are available today in beta for professional developers.

For more technical details and implementation guides, you can read the original article: Introducing advanced tool use on the Claude Developer Platform.

Maximizing WebAI Performance: A Deep Dive into LiteRT.js

Saurav Kumar — Mon, 24 Nov 2025 03:39:21 +0000

The landscape of client-side machine learning is shifting. For years, deploying high-performance models in the browser meant navigating a complex maze of converters, polyfills, and performance bottlenecks. Enter LiteRT.js—Google's newly branded, high-performance WebAI runtime designed specifically for production web applications.

If you are a professional developer looking to run PyTorch, JAX, or TensorFlow models directly in the browser with near-native speeds, this is the runtime you've been waiting for.

What is LiteRT for Web?

LiteRT (formerly TensorFlow Lite) has long been the standard for on-device ML on Android and iOS. LiteRT.js extends this unified runtime to the web. It is not just a wrapper; it is a purpose-built runtime that leverages WebGPU for massive parallel compute capabilities and WebAssembly (Wasm) with XNNPack for optimized CPU execution.

For professional engineers, the value proposition is clear: Unified architecture. The same .tflite model you deploy on Android can now be dropped into your web app, ensuring consistent behavior across platforms.

Core Features for Production Apps

LiteRT.js brings a suite of features strictly targeted at solving "real-life" production constraints:

1. Best-in-Class Hardware Acceleration

LiteRT.js is built to squeeze every drop of performance from the user's device:

WebGPU Support: Leverages the modern WebGPU API for high-throughput parallel processing, significantly outperforming legacy WebGL backends.
XNNPack on Wasm: For devices without powerful GPUs, it falls back to highly optimized CPU inference using XNNPack instructions via WebAssembly.

2. Multi-Framework Compatibility

The days of being locked into a single framework for web deployment are over. LiteRT.js supports:

PyTorch: Direct conversion path to LiteRT (skipping the brittle ONNX -> TF -> TF.js chain).
JAX & TensorFlow: Full support for models exported to the standard .tflite flatbuffer format.

3. Seamless TensorFlow.js Interoperability

If you have an existing TF.js pipeline (e.g., for pre/post-processing), you don't need to rewrite it. LiteRT.js creates a bridge:

Accepts TensorFlow.js Tensors as inputs.
Outputs TensorFlow.js Tensors for downstream tasks.
Allows you to swap only the inference engine while keeping your data plumbing intact.

Technical Deep Dive: Implementation

Let's look at how to implement this in a real-world TypeScript/JavaScript environment.

Step 1: Installation & Setup

You need the core package. You also need to serve the Wasm binaries statically so the browser can fetch them.

npm install @litertjs/core

Step 2: Running a Model (The "Hot Path")

Here is a pattern for loading a model and running inference using the WebGPU backend. This is critical for latency-sensitive apps.

import { loadAndCompile, Tensor } from '@litertjs/core';

// 1. Initialize the runtime
// Ensure you host the 'wasm' folder from node_modules on your server
const model = await loadAndCompile('/models/object_detection.tflite', {
  accelerator: 'webgpu', // Force WebGPU for max speed
});

// 2. Prepare Input Data
// Imagine this comes from an HTMLCanvasElement or Video stream
const rawData = new Float32Array(224 * 224 * 3).fill(0); 

// 3. Create Tensor & Move to GPU Memory
const inputTensor = await new Tensor(rawData, [1, 3, 224, 224]).moveTo('webgpu');

// 4. Inference
const outputs = model.run(inputTensor);

// 5. Retrieve Results
// Move memory back to CPU only when you need to read it
const resultTensor = await outputs[0].moveTo('wasm'); 
const resultData = resultTensor.toTypedArray();

// 6. Cleanup (Crucial for long-running apps!)
inputTensor.delete();
resultTensor.delete();

Step 3: The PyTorch Conversion Workflow

One of the strongest features is the direct conversion. You no longer need to debug intermediate ONNX failures.

import ai_edge_torch
import torchvision
import torch

# Load a standard PyTorch model
resnet18 = torchvision.models.resnet18(torchvision.models.ResNet18_Weights.IMAGENET1K_V1)
sample_input = (torch.randn(1, 3, 224, 224),)

# Convert directly to LiteRT (.tflite)
edge_model = ai_edge_torch.convert(resnet18.eval(), sample_input)
edge_model.export('resnet18_web.tflite')

Real-Life Use Cases for Professional Developers

Why switch to LiteRT.js? Here are three concrete scenarios where this runtime provides a business advantage:

1. Privacy-Preserving Document Processing (FinTech/Legal)

Scenario: A user needs to upload a sensitive ID document (Passport/Driver's License) for KYC verification.
The LiteRT.js Solution:

Use Case: Run an OCR and object detection model (like EfficientDet) entirely in the client's browser.
Benefit: Zero data leaves the device. You redact PII (Personally Identifiable Information) locally before the image is ever uploaded to your server. This drastically simplifies GDPR/HIPAA compliance.

2. Real-Time Video Conferencing Tools

Scenario: Building a custom video platform that requires virtual backgrounds or "low-light mode" correction.
The LiteRT.js Solution:

Use Case: Apply a segmentation model (e.g., DeepLabV3) to every frame of a video stream (30fps).
Benefit: The WebGPU backend is essential here. WebGL often chokes on high-resolution segmentation, but LiteRT.js leverages modern GPU compute shaders to process frames in under 16ms, ensuring no lag in the video feed.

3. Offline-First Field Applications

Scenario: An iPad app for agricultural inspectors analyzing crop disease in remote fields with poor 4G/5G.
The LiteRT.js Solution:

Use Case: Run complex vision models to classify crop health instantly without a server round-trip.
Benefit: By using the standard .tflite format, you can use the exact same model file for the Web app (LiteRT.js) and the native Android/iOS app versions, reducing your MLOps maintenance burden by 50%.

Key Resources

Ready to ship? Use these official resources to fast-track your development:

Docs: LiteRT Web Documentation
GitHub: LiteRT Repository
NPM: @litertjs/core
Watch: LiteRT.js: Google's High Performance WebAI Runtime

🚀 Experience Liftoff: Google Antigravity—The Agent-First IDE Redefining Development

Saurav Kumar — Thu, 20 Nov 2025 04:00:41 +0000

The age of the simple AI "autocomplete" is over. We've entered the era of the Agent-First IDE, and Google's Antigravity is leading the charge. Launched alongside the powerful Gemini 3 model, Antigravity is not just a souped-up VS Code fork; it's a completely new paradigm where AI agents function as autonomous, accountable teammates, operating across your entire development workflow.

For the professional software developer, Antigravity shifts your role from line-by-line implementation to high-level architecture and task delegation. It elevates human judgment by automating the tedious execution, fundamentally changing how fast, and how far, a single engineer can build.

The Core Innovation: Autonomous Agents in Mission Control

Antigravity's biggest differentiator is the shift from an AI assistant that only gives suggestions, to an AI Agent that can autonomously plan, execute, and verify complex tasks across multiple surfaces.

1. Cross-Surface Agentic Control

Your agents are no longer confined to the chat panel. They can operate synchronously across the three core development surfaces:

Code Editor: Writing, refactoring, and fixing code directly in your files.
Terminal: Installing dependencies, running build commands, and debugging tests.
Browser: Running the application, navigating user flows, and visually verifying the output.

Real-Life Use: Instead of manually running the steps to fix a bug, your task is now: "Fix the layout bug on the mobile checkout page, run a local test, and ensure the change doesn't break the desktop view." The agent takes over, edits files, runs the server, drives the integrated browser, and provides a final, verifiable result.

2. Artifacts for Trust and Transparency

Autonomous agents can feel like a black box. Antigravity solves this with Artifacts—structured, verifiable deliverables that replace overwhelming log files with human-readable documentation.

Artifact Type	Description	Real-Life Use
Implementation Plan	A detailed, step-by-step proposal before code is written.	Reviewing Architecture: An agent proposes a full plan for a multi-file refactor. You review the plan, adjust the strategy, and approve before a single line is changed, ensuring architectural alignment.
Browser Recording	A video walkthrough of the agent interacting with the live application.	End-to-End Testing: An agent performs a full user flow (e.g., login, add to cart, checkout) and provides a recorded, verifiable proof that the new feature works as intended.
Code Diffs & Summaries	Clear, organized summaries of all file changes and the agent's reasoning.	PR Generation: Automatically generates a comprehensive pull request description and links the verification artifacts, drastically accelerating code review time.

3. Dual-View Workflow: Editor and Manager View

Antigravity provides two distinct interfaces, catering to different modes of development:

Editor View: The familiar, VS Code-like experience with an integrated agent sidebar for immediate, context-aware assistance and code completions.
Manager View ("Mission Control"): A central hub for orchestrating multiple agents across separate projects or tasks simultaneously. This is where you operate as an architect and project manager.

Real-Life Use: You can delegate a task to a Refactoring Agent to clean up a legacy service while you use the Editor View to implement a new feature. You check the Refactoring Agent's progress and artifacts asynchronously in the Manager View, parallelizing work that previously required constant context-switching.

🔑 Key Features and Capabilities

Antigravity, built on the open-source base of VS Code, layers on several powerful agentic features:

Multi-Model Support: While powered by Gemini 3 Pro, the platform is not locked to one vendor. You can select models like Claude Sonnet 4.5 or GPT-OSS to power your agents.
Built-in Self-Improvement: Agents can learn from past projects, saving successful code snippets, task execution patterns, and architectural decisions to an internal knowledge base, making them more effective over time.
Integrated Feedback Loop: You can add Google Docs-style comments directly onto artifacts (like screenshots or task plans) to redirect the agent without stopping the current run, ensuring continuous feedback and refinement.
Model Context Protocol (MCP): This powerful feature allows the agent to securely connect to external tools and data sources like GitHub, Linear, Notion, and live databases (e.g., MongoDB or Supabase), allowing it to read real-time schemas, logs, and external documentation without manual copy-paste.

🎯 Elevating the Developer's Role: Practical Use Cases

Antigravity fundamentally changes the types of tasks professional developers will focus on. You become the Architect and Reviewer, while the agents handle the execution.

Use Case	Antigravity Agent Action	Developer Focus Shift
Feature Prototyping	Takes a natural language prompt ("Build a responsive dashboard component that shows real-time user metrics.") and scaffolds the entire front-end and back-end logic.	From: Writing boilerplate and setting up dependencies. To: Defining the high-level API contract and UX goals.
Legacy Code Refactoring	Analyzes a large, multi-file codebase, identifies anti-patterns, plans a refactoring strategy, executes the changes, and verifies backward compatibility with tests.	From: Manual, high-risk refactoring efforts. To: Reviewing the agent's risk assessment and validating the architectural decision.
Bug Diagnosis & Fix	Reproduces a reported bug using browser automation, analyzes error logs, identifies the root cause, proposes a code fix, validates the fix with automated testing, and updates documentation.	From: Spending hours reproducing and debugging. To: Reviewing the agent's diagnosis and approving the change.
Integration Testing	Uses the MCP to pull a live API schema from a database, generates mock servers, and writes a full suite of integration tests that validate all endpoint responses against the schema.	From: Writing tedious test boilerplate and mock data. To: Defining the test coverage requirements and reviewing the quality of the generated tests.

Google Antigravity is a declaration that the future of coding is agentic. By granting agents autonomy and accountability through the Artifact system, it enables developers to achieve unprecedented velocity, lifting the entire software development process to a higher, more strategic altitude.

⬇️ Get Started with Antigravity Today

Ready to experience liftoff? The public preview is available for all major desktop platforms.

Official Website: antigravity.google
Direct Download Page: antigravity.google/download

The public preview is available at no charge and is compatible with macOS, Windows, and Linux.

🚀 Exploring Kwala: The No-Code Powerhouse for Blockchain Backend Automation

Saurav Kumar — Tue, 04 Nov 2025 05:47:14 +0000

When I joined the Kwala Hacker House Hackathon, I had no idea that one tool would completely change the way I thought about building blockchain projects — Kwala. Over an intense 8-hour hackathon, my team built Audifi, an AI-powered tool that analyzes smart contracts, finds vulnerabilities, and generates automated test cases.

But the real magic happened when we discovered how Kwala could automate our blockchain backend within minutes — without a single line of server code.

🧩 Introduction

In the Web3 world, building smart contracts and front-ends is only half the story. The backend logic — monitoring blockchain events, orchestrating state changes, scheduling tasks, calling APIs — often becomes the bottleneck.

That’s where Kwala steps in.

Kwala allows developers to build automation and backend workflows for Web3 applications without worrying about servers, polling scripts, or DevOps overhead. You simply define what should happen — and Kwala executes it reliably across chains.

In this article, let’s explore:

What Kwala is
How it works under the hood
Key features and use-cases
Why developers love it
And my experience using it during the hackathon

⚙️ What is Kwala?

At its core, Kwala is a verifiable Web3 workflow automation platform — your programmable backend for decentralized applications.

You can:

Define your backend logic using YAML workflows
Trigger smart contracts, call APIs, or listen to on-chain events
Deploy it without any server or DevOps setup

🏷️ Tagline: “Your programmable Web3 backend — no servers, no DevOps, no infra bloat.”

Kwala is designed for the multi-chain world, making it easier for developers to connect decentralized systems without managing backend infrastructure.

🌐 Learn more: Kwala Network

🏗️ How Kwala Works — Developer Flow & Architecture

Here’s how you can integrate Kwala into your project:

👩‍💻 Developer Workflow

Define a Workflow in YAML You create a .yaml file that declares what triggers your logic and what happens next:

   on:
     event: contract.deployed
   do:
     - action: analyzeContract
     - action: generateTestCases
     - action: notifyTeam

Instead of writing complex backend code, you describe what you want, not how to do it.

Deploy the Workflow
Use Kwala’s dashboard or CLI to deploy your YAML definition.
Runtime Execution
When the event fires (like a contract deployment), Kwala’s execution engine triggers the defined actions — calling smart contracts, APIs, or any automation you defined.
Monitor & Audit
You get detailed logs, execution reports, and verifiable trails — vital for Web3 transparency.

🧱 Under the Hood

Trigger Layer – Listens for on-chain or off-chain events
Execution Engine – Executes defined actions reliably
Validator Nodes – Maintain decentralized execution
Infra Abstraction – No need for servers, scripts, or polling
Cross-Chain Flexibility – Works seamlessly across EVM-compatible networks

Essentially, Kwala turns your YAML files into living backend systems that run autonomously.

🌟 Key Features

✅ Declarative YAML Workflows – Define your logic clearly, with no backend code
✅ Event-Driven Architecture – React to blockchain events or API triggers
✅ Cross-Chain Automation – One workflow for multiple networks
✅ API & Smart Contract Integration – Connect on-chain and off-chain worlds
✅ Verifiable & Auditable – Execution logs ensure trust and transparency
✅ No Infrastructure Needed – No servers, databases, or cron jobs
✅ Perfect for MVPs & Hackathons – Rapid iteration with zero infra setup

💡 Use Cases

Here are some scenarios where Kwala truly shines:

Automated DeFi Monitoring – Trigger actions when price ratios change
NFT Event Automation – When NFT is minted, call APIs or send rewards
Cross-Chain Transactions – Event on Chain A triggers logic on Chain B
Compliance & Audit Workflows – Maintain verifiable event trails
Hackathons & Prototyping – Build production-like backends in hours

During the Kwala Hacker House Hackathon, we leveraged it to automate complex blockchain monitoring flows — which would otherwise have required days of backend work.

⚡ My Experience at Kwala Hacker House Hackathon

At the hackathon, we were challenged to use Kwala as part of our build. At first, I wasn’t sure how it would fit in — but within minutes, I realized its power.

In our project Audifi, we used Kwala to:

Listen to contract deployment events
Trigger our AI-based analysis pipeline
Store detected vulnerabilities automatically in the database

What usually takes hours of backend setup was done in minutes.

For an 8-hour hackathon, Kwala made a real difference — turning our prototype into a functioning, automated blockchain system.

🧠 Why Developers Should Care

Here’s why Kwala matters to Web3 builders:

Benefit	Description
⚙️ No Backend Hassle	Eliminate server setup, cron jobs, and infrastructure headaches
🚀 Faster Builds	Go from idea to working backend in hours
🌐 Multi-Chain Ready	Works across multiple blockchain ecosystems
🔒 Verifiable & Transparent	Every execution can be audited
💰 Cost-Efficient	Pay only for workflows, not servers
🧩 Easy Integration	Connects smart contracts and APIs seamlessly

Whether you’re a solo developer or a startup building on-chain infrastructure, Kwala accelerates your workflow automation journey.

🧭 Getting Started with Kwala

Visit: https://kwala.network
Explore the Docs – Learn the YAML structure for defining workflows
Write a Simple Workflow – Start with “on event → do actions” logic
Deploy to the Playground – Test and refine your automation
Scale Up – Add multi-chain or AI-driven logic as needed

⚖️ Pros & Cons

✅ Pros:

Infrastructure-free backend automation
Declarative, simple, and scalable
Perfect for hackathons, MVPs, and DeFi automation
Transparent, verifiable execution

⚠️ Cons:

Requires learning YAML syntax
Some limits in customization for complex logic
Depends on Kwala’s availability and network reliability

🔮 The Future of Web3 Backends

Kwala represents a shift from Backend as Code to Backend as Workflow.
As Web3 grows, developers will demand faster, auditable, and multi-chain-ready automation tools — exactly where Kwala shines.

Expect to see:

AI-powered workflow recommendations
Pre-built automation templates
Deeper integrations with DeFi and NFT ecosystems
Wider support for non-EVM chains

🏁 Conclusion

If you’re a Web3 developer, startup, or hackathon builder, it’s time to rethink how you handle your backend.

Kwala lets you:
✅ Define your backend logic declaratively
✅ Automate smart contract actions effortlessly
✅ Deploy without servers or infrastructure overhead

During the Kwala Hacker House Hackathon, it helped my team build faster, smarter, and with less complexity — proving that automation is the next evolution of Web3 backend development.

👉 Start building smarter today: https://kwala.network

🧠 Day 30 of #30DaysOfSolidity — Build a Simple Token Exchange (AMM) Using Foundry

Saurav Kumar — Thu, 30 Oct 2025 18:31:02 +0000

Building a decentralized exchange (DEX) might sound complex, but today we’ll create a simple, constant-product Automated Market Maker (AMM) from scratch using Solidity and Foundry — the foundation of DeFi platforms like Uniswap.

This marks the final day of #30DaysOfSolidity, and it’s the perfect way to wrap up the journey — by building your own mini DEX 🚀

💡 What You’ll Learn

How token swaps work without an order book
How to create a liquidity pool and mint LP tokens
How to calculate swap outputs using x * y = k
How to apply trading fees and maintain balance

🧱 Project Overview

Our decentralized exchange allows users to:

Add liquidity — deposit two tokens to form a trading pair.
Swap tokens — trade one token for another using the pool.
Remove liquidity — withdraw tokens by burning LP tokens.

We’ll build three main contracts:

ExchangeFactory – creates and tracks trading pairs.
ExchangePair – manages swaps, liquidity, and reserves.
MockERC20 – simple mintable tokens for testing.

📂 Folder Structure

day-30-solidity/
├─ src/
│  ├─ ERC20.sol
│  ├─ MockERC20.sol
│  ├─ ExchangeFactory.sol
│  └─ ExchangePair.sol
├─ script/
│  └─ Deploy.s.sol
├─ test/
│  └─ Exchange.t.sol
└─ README.md

🧩 Step 1 — Minimal ERC20 Implementation (`ERC20.sol`)

We start with a lightweight ERC20 token for LP tokens used inside pairs.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract ERC20 {
    string public name;
    string public symbol;
    uint8 public immutable decimals = 18;
    uint256 public totalSupply;

    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);

    constructor(string memory _name, string memory _symbol) {
        name = _name;
        symbol = _symbol;
    }

    function _mint(address to, uint256 amount) internal {
        totalSupply += amount;
        balanceOf[to] += amount;
        emit Transfer(address(0), to, amount);
    }

    function _burn(address from, uint256 amount) internal {
        balanceOf[from] -= amount;
        totalSupply -= amount;
        emit Transfer(from, address(0), amount);
    }

    function approve(address spender, uint256 amount) external returns (bool) {
        allowance[msg.sender][spender] = amount;
        emit Approval(msg.sender, spender, amount);
        return true;
    }

    function transfer(address to, uint256 amount) external returns (bool) {
        _transfer(msg.sender, to, amount);
        return true;
    }

    function transferFrom(address from, address to, uint256 amount) external returns (bool) {
        uint256 allowed = allowance[from][msg.sender];
        if (allowed != type(uint256).max) {
            require(allowed >= amount, "ERC20: allowance");
            allowance[from][msg.sender] = allowed - amount;
        }
        _transfer(from, to, amount);
        return true;
    }

    function _transfer(address from, address to, uint256 amount) internal {
        require(balanceOf[from] >= amount, "ERC20: balance");
        balanceOf[from] -= amount;
        balanceOf[to] += amount;
        emit Transfer(from, to, amount);
    }
}

🧩 Step 2 — Mock Tokens (`MockERC20.sol`)

We use mintable tokens for local testing.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "./ERC20.sol";

contract MockERC20 is ERC20 {
    constructor(string memory _name, string memory _symbol) ERC20(_name, _symbol) {}

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

🧩 Step 3 — Exchange Pair Contract (`ExchangePair.sol`)

This is the heart of our AMM.
It uses the constant product formula x * y = k and 0.3% swap fee.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "./ERC20.sol";

interface IERC20Minimal {
    function transferFrom(address from, address to, uint256 amount) external returns (bool);
    function transfer(address to, uint256 amount) external returns (bool);
    function balanceOf(address owner) external view returns (uint256);
}

contract ExchangePair is ERC20 {
    IERC20Minimal public token0;
    IERC20Minimal public token1;

    uint112 private reserve0;
    uint112 private reserve1;

    event Mint(address indexed sender, uint256 amount0, uint256 amount1, uint256 liquidity);
    event Burn(address indexed sender, address indexed to, uint256 amount0, uint256 amount1, uint256 liquidity);
    event Swap(address indexed sender, uint256 amount0In, uint256 amount1In, uint256 amount0Out, uint256 amount1Out, address indexed to);
    event Sync(uint112 reserve0, uint112 reserve1);

    uint256 public constant FEE_NUM = 3;    // 0.3%
    uint256 public constant FEE_DEN = 1000;

    constructor(address _token0, address _token1) ERC20("Simple LP", "sLP") {
        require(_token0 != _token1, "IDENTICAL");
        token0 = IERC20Minimal(_token0);
        token1 = IERC20Minimal(_token1);
    }

    function getReserves() public view returns (uint112, uint112) {
        return (reserve0, reserve1);
    }

    function mint(address to) external returns (uint256 liquidity) {
        uint256 balance0 = token0.balanceOf(address(this));
        uint256 balance1 = token1.balanceOf(address(this));
        uint256 amount0 = balance0 - reserve0;
        uint256 amount1 = balance1 - reserve1;

        if (totalSupply == 0) {
            liquidity = _sqrt(amount0 * amount1);
        } else {
            liquidity = min((amount0 * totalSupply) / reserve0, (amount1 * totalSupply) / reserve1);
        }
        require(liquidity > 0, "INSUFFICIENT_LIQUIDITY");
        _mint(to, liquidity);

        _update(balance0, balance1);
        emit Mint(msg.sender, amount0, amount1, liquidity);
    }

    function burn(address to) external returns (uint256 amount0, uint256 amount1) {
        uint256 _totalSupply = totalSupply;
        uint256 liquidity = balanceOf[msg.sender];
        _burn(msg.sender, liquidity);

        amount0 = (liquidity * token0.balanceOf(address(this))) / _totalSupply;
        amount1 = (liquidity * token1.balanceOf(address(this))) / _totalSupply;

        require(amount0 > 0 && amount1 > 0, "INSUFFICIENT_BURN");

        token0.transfer(to, amount0);
        token1.transfer(to, amount1);

        _update(token0.balanceOf(address(this)), token1.balanceOf(address(this)));
        emit Burn(msg.sender, to, amount0, amount1, liquidity);
    }

    function swap(uint256 amount0Out, uint256 amount1Out, address to) external {
        require(amount0Out > 0 || amount1Out > 0, "NO_OUTPUT");
        (uint112 _reserve0, uint112 _reserve1) = getReserves();

        if (amount0Out > 0) token0.transfer(to, amount0Out);
        if (amount1Out > 0) token1.transfer(to, amount1Out);

        uint256 balance0 = token0.balanceOf(address(this));
        uint256 balance1 = token1.balanceOf(address(this));

        uint256 amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
        uint256 amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
        require(amount0In > 0 || amount1In > 0, "NO_INPUT");

        uint256 balance0Adj = (balance0 * FEE_DEN) - (amount0In * FEE_NUM);
        uint256 balance1Adj = (balance1 * FEE_DEN) - (amount1In * FEE_NUM);
        require(balance0Adj * balance1Adj >= uint256(_reserve0) * uint256(_reserve1) * (FEE_DEN**2), "K");

        _update(balance0, balance1);
        emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
    }

    function _update(uint256 b0, uint256 b1) private {
        reserve0 = uint112(b0);
        reserve1 = uint112(b1);
        emit Sync(reserve0, reserve1);
    }

    function _sqrt(uint256 y) internal pure returns (uint256 z) {
        if (y == 0) return 0;
        uint256 x = y / 2 + 1;
        z = y;
        while (x < z) { z = x; x = (y / x + x) / 2; }
    }

    function min(uint256 a, uint256 b) private pure returns (uint256) {
        return a < b ? a : b;
    }
}

🧩 Step 4 — Factory Contract (`ExchangeFactory.sol`)

Manages creation and registry of pairs.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "./ExchangePair.sol";

contract ExchangeFactory {
    mapping(address => mapping(address => address)) public getPair;
    address[] public allPairs;

    event PairCreated(address indexed token0, address indexed token1, address pair, uint256);

    function createPair(address tokenA, address tokenB) external returns (address pair) {
        require(tokenA != tokenB, "IDENTICAL_ADDRESSES");
        (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
        require(getPair[token0][token1] == address(0), "PAIR_EXISTS");

        ExchangePair newPair = new ExchangePair(token0, token1);
        pair = address(newPair);
        getPair[token0][token1] = pair;
        getPair[token1][token0] = pair;
        allPairs.push(pair);

        emit PairCreated(token0, token1, pair, allPairs.length);
    }

    function allPairsLength() external view returns (uint256) {
        return allPairs.length;
    }
}

🧪 Step 5 — Testing the Exchange (`Exchange.t.sol`)

A quick Foundry test verifying liquidity and swaps.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "forge-std/Test.sol";
import "../src/ExchangeFactory.sol";
import "../src/MockERC20.sol";
import "../src/ExchangePair.sol";

contract ExchangeTest is Test {
    ExchangeFactory factory;
    MockERC20 tokenA;
    MockERC20 tokenB;
    ExchangePair pair;

    function setUp() public {
        factory = new ExchangeFactory();
        tokenA = new MockERC20("Token A", "TKA");
        tokenB = new MockERC20("Token B", "TKB");
        address pairAddr = factory.createPair(address(tokenA), address(tokenB));
        pair = ExchangePair(pairAddr);

        tokenA.mint(address(this), 1_000_000 ether);
        tokenB.mint(address(this), 1_000_000 ether);
    }

    function testLiquidityAndSwap() public {
        tokenA.transfer(address(pair), 1000 ether);
        tokenB.transfer(address(pair), 1000 ether);
        pair.mint(address(this));

        tokenA.transfer(address(pair), 10 ether);
        pair.swap(0, 9 ether, address(this));

        (uint112 r0, uint112 r1) = pair.getReserves();
        assertTrue(r0 > 0 && r1 > 0);
    }
}

⚙️ Run Locally

Install Foundry

   curl -L https://foundry.paradigm.xyz | bash
   foundryup

Clone project

   git clone <your_repo_url>
   cd day-30-solidity

Run tests

   forge test -vv

Deploy

   forge script script/Deploy.s.sol:DeployScript --broadcast --rpc-url <RPC_URL>

📊 How the AMM Maintains Balance

Every swap obeys:

x * y = k

Where:

x and y are the reserves of both tokens.
k is a constant that should never decrease. By adjusting x or y, the price automatically rebalances.

The swap fee slightly increases reserves over time, rewarding liquidity providers.

🧠 What You’ve Learned

Built a mini-Uniswap from scratch
Understood the constant-product formula
Implemented token swaps, mint/burn LP tokens
Used Foundry for professional-grade Solidity testing

🏁 Final Thoughts

This completes Day 30 of #30DaysOfSolidity 🎉
You’ve now built:

A stablecoin
Lending/Borrowing systems
DAOs, Escrow, NFT Marketplaces
and finally — a Decentralized Exchange.

Each day has taken you a step closer to real-world DeFi mastery.

If you found this helpful, drop a ❤️ on Dev.to and share your version!

🪙 Day 29 of #30DaysOfSolidity — Building a Collateral-Backed Stablecoin in Solidity — Step-by-Step Guide

Saurav Kumar — Wed, 29 Oct 2025 21:11:09 +0000

Author: Saurav Kumar
Tags: solidity, defi, stablecoin, ethereum, blockchain
Difficulty: Intermediate → Advanced
Reading Time: ~10 minutes

💡 Introduction

In decentralized finance (DeFi), stablecoins play a crucial role in bridging traditional finance and crypto.
They provide price stability, liquidity, and on-chain utility—acting as the backbone of protocols like MakerDAO (DAI), Aave, and Curve.

In this guide, we’ll build a collateral-backed stablecoin named StableUSD (sUSD) using Solidity and Foundry, demonstrating how to maintain a 1:1 peg to the US dollar through collateralization and oracle-based pricing.

This article is part of my DeFi Engineering Series, where I recreate real-world protocols from scratch.

🧠 What You’ll Learn

How stablecoins maintain their price peg
How to design collateralized minting and redemption flows
How to integrate oracles (mock or Chainlink-style)
How to implement collateralization ratios and burn/mint mechanics
How to test everything using Foundry

📂 Project File Structure

Here’s the Foundry project layout:

day-29-stablecoin/
├─ foundry.toml
├─ .gitignore
├─ script/
│   └─ Deploy.s.sol
├─ src/
│   ├─ StableUSD.sol
│   ├─ OracleManager.sol
│   ├─ CollateralPool.sol
│   ├─ Treasury.sol
│   ├─ MockOracle.sol
│   ├─ MockERC20.sol
│   └─ interfaces/
│       └─ IAggregatorV3.sol
└─ test/
    └─ Stablecoin.t.sol

🧩 System Overview

Component	Description
StableUSD.sol	ERC20 token for sUSD, mint/burn controlled
OracleManager.sol	Connects to Chainlink or mock price feeds
CollateralPool.sol	Core logic for deposits, minting & redemption
Treasury.sol	Admin contract for reserves and fee collection

🏗️ Architecture Diagram

User → CollateralPool → StableUSD  
           ↓  
        OracleManager  
           ↓  
         Treasury

Users deposit collateral (e.g., WETH).
OracleManager provides price data in USD.
CollateralPool mints sUSD tokens based on collateral value.
Treasury manages reserves and stability actions.

⚙️ Setup Commands

forge init day-29-stablecoin
cd day-29-stablecoin
forge install OpenZeppelin/openzeppelin-contracts
forge install foundry-rs/forge-std

🧩 Smart Contracts

📁 `src/interfaces/IAggregatorV3.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IAggregatorV3 {
    function latestRoundData()
        external
        view
        returns (
            uint80,
            int256 answer,
            uint256,
            uint256,
            uint80
        );
}

📁 `src/StableUSD.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

contract StableUSD is ERC20, AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    constructor() ERC20("Stable USD", "sUSD") {
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
    }

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount);
    }

    function burn(address from, uint256 amount) external onlyRole(MINTER_ROLE) {
        _burn(from, amount);
    }
}

✅ Implements ERC20
✅ Controlled mint/burn via roles

📁 `src/OracleManager.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "./interfaces/IAggregatorV3.sol";

contract OracleManager {
    IAggregatorV3 public oracle;

    constructor(address _oracle) {
        oracle = IAggregatorV3(_oracle);
    }

    function getLatestPrice() external view returns (uint256) {
        (, int256 answer,,,) = oracle.latestRoundData();
        require(answer > 0, "Invalid price");
        return uint256(answer);
    }
}

💡 Use Chainlink price feeds for live ETH/USD in production.

📁 `src/MockOracle.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract MockOracle {
    int256 private price;

    constructor(int256 _price) {
        price = _price;
    }

    function latestRoundData()
        external
        view
        returns (uint80, int256, uint256, uint256, uint80)
    {
        return (0, price, 0, 0, 0);
    }

    function updatePrice(int256 _price) external {
        price = _price;
    }
}

✅ Simulates Chainlink oracles for local testing

📁 `src/MockERC20.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MockERC20 is ERC20 {
    constructor(string memory name, string memory symbol) ERC20(name, symbol) {}

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

✅ Mock collateral asset (like WETH) for testing mint/redeem logic

📁 `src/CollateralPool.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "./StableUSD.sol";
import "./OracleManager.sol";

contract CollateralPool {
    IERC20 public collateral;
    StableUSD public stable;
    OracleManager public oracle;

    uint256 public constant COLLATERAL_RATIO = 150; // 150%
    mapping(address => uint256) public collateralBalance;

    constructor(IERC20 _collateral, StableUSD _stable, OracleManager _oracle) {
        collateral = _collateral;
        stable = _stable;
        oracle = _oracle;
    }

    function deposit(uint256 amount) external {
        require(amount > 0, "Invalid amount");
        collateral.transferFrom(msg.sender, address(this), amount);
        collateralBalance[msg.sender] += amount;
    }

    function mint(uint256 amountCollateral) external {
        require(collateralBalance[msg.sender] >= amountCollateral, "Insufficient collateral");

        uint256 price = oracle.getLatestPrice();
        uint256 usdValue = (amountCollateral * price) / 1e8;
        uint256 mintAmount = (usdValue * 100) / COLLATERAL_RATIO;

        stable.mint(msg.sender, mintAmount * 1e18);
    }

    function redeem(uint256 sUSDAmount) external {
        stable.burn(msg.sender, sUSDAmount);

        uint256 price = oracle.getLatestPrice();
        uint256 collateralToReturn = (sUSDAmount * 1e8 * COLLATERAL_RATIO) / (price * 100);

        require(collateralBalance[msg.sender] >= collateralToReturn, "Not enough collateral");
        collateralBalance[msg.sender] -= collateralToReturn;
        collateral.transfer(msg.sender, collateralToReturn);
    }
}

⚡ Implements over-collateralized mint/redeem flow
⚡ Maintains peg using oracle price
⚡ 150% ratio ensures safety

📁 `src/Treasury.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Treasury {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    function withdraw(address token, address to, uint256 amount) external {
        require(msg.sender == owner, "Not authorized");
        (bool ok,) = token.call(abi.encodeWithSignature("transfer(address,uint256)", to, amount));
        require(ok, "Transfer failed");
    }
}

✅ Simple treasury for system fund management

📁 `script/Deploy.s.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Script.sol";
import "../src/StableUSD.sol";
import "../src/OracleManager.sol";
import "../src/CollateralPool.sol";
import "../src/MockERC20.sol";
import "../src/MockOracle.sol";

contract Deploy is Script {
    function run() external {
        vm.startBroadcast();

        MockERC20 collateral = new MockERC20("Wrapped ETH", "WETH");
        MockOracle oracle = new MockOracle(1800e8);
        StableUSD stable = new StableUSD();
        OracleManager oracleManager = new OracleManager(address(oracle));
        CollateralPool pool = new CollateralPool(collateral, stable, oracleManager);

        stable.grantRole(stable.MINTER_ROLE(), address(pool));

        vm.stopBroadcast();
    }
}

✅ Deploys all components in one transaction

📁 `test/Stablecoin.t.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/StableUSD.sol";
import "../src/CollateralPool.sol";
import "../src/OracleManager.sol";
import "../src/MockERC20.sol";
import "../src/MockOracle.sol";

contract StablecoinTest is Test {
    StableUSD stable;
    OracleManager oracle;
    CollateralPool pool;
    MockERC20 collateral;

    function setUp() public {
        collateral = new MockERC20("Wrapped ETH", "WETH");
        stable = new StableUSD();
        oracle = new OracleManager(address(new MockOracle(1800e8)));
        pool = new CollateralPool(IERC20(address(collateral)), stable, oracle);
        stable.grantRole(stable.MINTER_ROLE(), address(pool));
    }

    function testMintStablecoin() public {
        collateral.mint(address(this), 1 ether);
        collateral.approve(address(pool), 1 ether);
        pool.deposit(1 ether);
        pool.mint(1 ether);
        assertGt(stable.balanceOf(address(this)), 0);
    }
}

✅ Tests deposit → mint flow
✅ Confirms minting works using oracle-based pricing

🧪 Test & Run

forge build
forge test -vv

🧮 Peg Example

If 1 ETH = $1800 and collateral ratio = 150%,
then 1 ETH mints:

(1800 * 100 / 150) = 1200 sUSD

🧠 Key Learnings

✅ How stablecoins maintain a peg
✅ Using oracles to stabilize token value
✅ Over-collateralization mechanics
✅ Writing and testing DeFi smart contracts

🛡️ Security & Design Notes

Always use verified Chainlink oracles in production.
Implement liquidation logic for under-collateralized users.
Add pause and governance controls for protocol safety.
Track debt positions per user in a full system.

🚀 Next Steps

Multi-collateral vaults (ETH, USDC, WBTC)
Dynamic interest and stability fees
DAO-based parameter governance
Integration with Uniswap for peg stabilization

🧭 Conclusion

Stablecoins are the core monetary layer of DeFi — building one from scratch deepens your understanding of price oracles, collateralization, and supply control.

This StableUSD demo shows how trustless monetary systems can maintain stability purely through code and math.

🗳️ Day 28 of #30DaysOfSolidity — Build a DAO Voting System (Decentralized Governance)

Saurav Kumar — Wed, 29 Oct 2025 20:38:23 +0000

In today’s challenge, we’ll build a DAO Voting System — the backbone of Decentralized Governance.
It’s like a digital democracy where members can propose, vote, and execute decisions — all powered by smart contracts.

Let’s dive into how DAOs (Decentralized Autonomous Organizations) function on-chain and build our own using Solidity + Foundry.

💡 What is a DAO?

A DAO (Decentralized Autonomous Organization) is a community-led entity with no central authority.
Every decision — like protocol upgrades or treasury spending — is made through proposals and votes recorded on-chain.

Our DAO will:

Allow members to create proposals.
Let members vote for or against proposals.
Automatically execute successful proposals.

🧱 Project Structure

Here’s the layout for our DAO project:

day-28-solidity/
├─ src/
│  └─ SimpleDAO.sol
├─ test/
│  └─ SimpleDAO.t.sol
├─ script/
│  └─ deploy.s.sol
├─ foundry.toml
└─ README.md

⚙️ Smart Contract — `SimpleDAO.sol`

Below is the full Solidity code implementing our DAO logic 👇

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

/// @title SimpleDAO - member-based governance for proposals & voting
/// @notice Demonstrates decentralized decision-making and on-chain governance.
contract SimpleDAO {
    event MemberAdded(address indexed member);
    event MemberRemoved(address indexed member);
    event ProposalCreated(uint256 indexed id, address indexed proposer, uint256 startTime, uint256 endTime, string description);
    event VoteCast(address indexed voter, uint256 indexed proposalId, bool support);
    event ProposalExecuted(uint256 indexed id);

    struct Proposal {
        uint256 id;
        address proposer;
        address[] targets;
        uint256[] values;
        bytes[] calldatas;
        string description;
        uint256 startTime;
        uint256 endTime;
        uint256 forVotes;
        uint256 againstVotes;
        bool executed;
        bool canceled;
    }

    mapping(address => bool) public isMember;
    uint256 public memberCount;

    mapping(uint256 => Proposal) public proposals;
    uint256 public proposalCount;
    mapping(uint256 => mapping(address => bool)) public hasVoted;

    uint256 public votingPeriod;
    uint256 public quorum;
    address public admin;

    modifier onlyAdmin() {
        require(msg.sender == admin, "Only admin");
        _;
    }

    modifier onlyMember() {
        require(isMember[msg.sender], "Not a member");
        _;
    }

    constructor(uint256 _votingPeriodSeconds, uint256 _quorum) {
        votingPeriod = _votingPeriodSeconds;
        quorum = _quorum;
        admin = msg.sender;
    }

    function addMember(address _member) external onlyAdmin {
        require(!isMember[_member], "Already member");
        isMember[_member] = true;
        memberCount++;
        emit MemberAdded(_member);
    }

    function removeMember(address _member) external onlyAdmin {
        require(isMember[_member], "Not member");
        isMember[_member] = false;
        memberCount--;
        emit MemberRemoved(_member);
    }

    function propose(
        address[] calldata targets,
        uint256[] calldata values,
        bytes[] calldata calldatas,
        string calldata description
    ) external onlyMember returns (uint256) {
        require(targets.length > 0, "Empty proposal");

        proposalCount++;
        uint256 id = proposalCount;

        proposals[id] = Proposal({
            id: id,
            proposer: msg.sender,
            targets: targets,
            values: values,
            calldatas: calldatas,
            description: description,
            startTime: block.timestamp,
            endTime: block.timestamp + votingPeriod,
            forVotes: 0,
            againstVotes: 0,
            executed: false,
            canceled: false
        });

        emit ProposalCreated(id, msg.sender, block.timestamp, block.timestamp + votingPeriod, description);
        return id;
    }

    function vote(uint256 proposalId, bool support) external onlyMember {
        Proposal storage p = proposals[proposalId];
        require(block.timestamp <= p.endTime, "Voting ended");
        require(!hasVoted[proposalId][msg.sender], "Already voted");

        hasVoted[proposalId][msg.sender] = true;
        if (support) p.forVotes++;
        else p.againstVotes++;

        emit VoteCast(msg.sender, proposalId, support);
    }

    function execute(uint256 proposalId) external {
        Proposal storage p = proposals[proposalId];
        require(block.timestamp > p.endTime, "Voting not ended");
        require(!p.executed, "Already executed");
        require(p.forVotes >= quorum && p.forVotes > p.againstVotes, "Proposal failed");

        p.executed = true;
        for (uint256 i = 0; i < p.targets.length; i++) {
            (bool success, ) = p.targets[i].call{value: p.values[i]}(p.calldatas[i]);
            require(success, "Execution failed");
        }

        emit ProposalExecuted(proposalId);
    }

    receive() external payable {}
}

🧪 Testing the DAO (Foundry)

Testing ensures our proposal → vote → execute flow works perfectly.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "forge-std/Test.sol";
import "../src/SimpleDAO.sol";

contract DummyTarget {
    event Done(address sender);
    function doSomething() external {
        emit Done(msg.sender);
    }
}

contract SimpleDAOTest is Test {
    SimpleDAO dao;
    DummyTarget target;

    address alice = address(0xA11CE);
    address bob   = address(0xB0B);

    function setUp() public {
        dao = new SimpleDAO(1 hours, 2);
        dao.addMember(alice);
        dao.addMember(bob);
        target = new DummyTarget();
    }

    function testProposalLifecycle() public {
        vm.prank(alice);
        address ;
        targets[0] = address(target);
        uint256 ;
        values[0] = 0;
        bytes ;
        calldatas[0] = abi.encodeWithSelector(DummyTarget.doSomething.selector);

        vm.prank(alice);
        uint256 id = dao.propose(targets, values, calldatas, "Trigger doSomething()");

        vm.warp(block.timestamp + 10);
        vm.prank(alice);
        dao.vote(id, true);
        vm.prank(bob);
        dao.vote(id, true);

        vm.warp(block.timestamp + 1 hours + 1);
        dao.execute(id);
    }
}

✅ Run test:

forge test -vv

🧭 How It Works

Admin adds members who can vote.
Members create proposals describing actions the DAO should take.
Voting starts immediately after proposal creation.
Members vote For or Against the proposal.
Once the voting period ends, if quorum is met and “for” votes win, the proposal executes automatically.

🧩 Example Scenario

Imagine a community treasury DAO with 10 members:

A proposal is created to donate 2 ETH to an education project.
Members vote.
If majority agrees and quorum is reached, funds are sent automatically!

🛡️ Security Notes

Only members can propose or vote.
Quorum and majority ensure fairness.
Execution is atomic — if any call fails, the entire transaction reverts.
This version uses admin control for simplicity, but production DAOs should use token-based voting and timelocks.

⚡ Try It Yourself

Deploy it locally using Foundry:

forge create src/SimpleDAO.sol:SimpleDAO --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> --constructor-args 3600 2

Then use Cast to call methods:

cast send <DAO_ADDRESS> "addMember(address)" <YOUR_MEMBER_ADDRESS> --private-key <PRIVATE_KEY>

🚀 Future Enhancements

You can level up this DAO with:

🪙 ERC20-based token voting (snapshot)
⏱️ Timelocks for proposal execution delay
🧾 Proposal cancellation / expiry
🗳️ Off-chain voting via signatures (gasless)

🎯 Summary

In this project, you learned how to:

Create and manage proposals
Implement on-chain voting logic
Execute decentralized governance decisions

This forms the core foundation of DAOs — transparent, autonomous, and democratic organizations on blockchain.

💬 Final Thoughts

DAOs are the future of collective decision-making.
By mastering these core governance concepts, you can build your own decentralized organizations that run purely by community consensus.

🪙 Day 27 of #30DaysOfSolidity — Build a Staking & Yield Farming Platform in Solidity

Saurav Kumar — Wed, 29 Oct 2025 20:30:56 +0000

Turn your tokens into a source of passive income 💰
Learn how staking and yield farming work by building your own reward distribution system on Ethereum!

🧭 Overview

In this project, we’ll build a Staking Rewards System — where users deposit tokens and earn periodic rewards in another token.

It’s just like a digital savings account that pays interest in tokens — demonstrating one of the core mechanisms in DeFi (Decentralized Finance).

🧱 Project Structure

day-27-staking-rewards/
├─ foundry.toml
├─ src/
│  ├─ MockERC20.sol
│  └─ StakingRewards.sol
├─ script/
│  └─ Deploy.s.sol
└─ test/
   └─ StakingRewards.t.sol

We’ll use Foundry for smart contract testing and deployment — it’s fast, lightweight, and ideal for local blockchain development.

⚙️ Step 1 — Setup

Install Foundry:

curl -L https://foundry.paradigm.xyz | bash
foundryup

Initialize the project:

forge init day-27-staking-rewards
cd day-27-staking-rewards

💰 Step 2 — Create a Mock Token

We’ll create a mock ERC20 token for both staking and rewards.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MockERC20 is ERC20 {
    constructor(string memory name, string memory symbol, uint256 initialSupply)
        ERC20(name, symbol)
    {
        _mint(msg.sender, initialSupply);
    }

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

🏦 Step 3 — Build the StakingRewards Contract

Here’s the core of our yield farming system.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract StakingRewards is Ownable, ReentrancyGuard {
    using SafeERC20 for IERC20;

    IERC20 public immutable stakeToken;
    IERC20 public immutable rewardToken;

    uint256 public totalSupply;
    mapping(address => uint256) public balances;

    uint256 public rewardPerTokenStored;
    uint256 public lastUpdateTime;
    uint256 public rewardRate;
    uint256 private constant PRECISION = 1e18;

    mapping(address => uint256) public userRewardPerTokenPaid;
    mapping(address => uint256) public rewards;

    event Staked(address indexed user, uint256 amount);
    event Withdrawn(address indexed user, uint256 amount);
    event RewardPaid(address indexed user, uint256 reward);
    event RewardRateUpdated(uint256 oldRate, uint256 newRate);

    constructor(address _stakeToken, address _rewardToken) {
        stakeToken = IERC20(_stakeToken);
        rewardToken = IERC20(_rewardToken);
        lastUpdateTime = block.timestamp;
    }

    modifier updateReward(address account) {
        _updateRewardPerToken();
        if (account != address(0)) {
            rewards[account] = earned(account);
            userRewardPerTokenPaid[account] = rewardPerTokenStored;
        }
        _;
    }

    function _updateRewardPerToken() internal {
        if (totalSupply == 0) {
            lastUpdateTime = block.timestamp;
            return;
        }
        uint256 time = block.timestamp - lastUpdateTime;
        uint256 rewardAccrued = time * rewardRate;
        rewardPerTokenStored += (rewardAccrued * PRECISION) / totalSupply;
        lastUpdateTime = block.timestamp;
    }

    function notifyRewardAmount(uint256 reward, uint256 duration)
        external
        onlyOwner
        updateReward(address(0))
    {
        require(duration > 0, "duration>0");
        rewardToken.safeTransferFrom(msg.sender, address(this), reward);
        uint256 newRate = reward / duration;
        emit RewardRateUpdated(rewardRate, newRate);
        rewardRate = newRate;
    }

    function stake(uint256 amount) external nonReentrant updateReward(msg.sender) {
        require(amount > 0, "amount>0");
        totalSupply += amount;
        balances[msg.sender] += amount;
        stakeToken.safeTransferFrom(msg.sender, address(this), amount);
        emit Staked(msg.sender, amount);
    }

    function withdraw(uint256 amount) public nonReentrant updateReward(msg.sender) {
        require(amount > 0, "amount>0");
        totalSupply -= amount;
        balances[msg.sender] -= amount;
        stakeToken.safeTransfer(msg.sender, amount);
        emit Withdrawn(msg.sender, amount);
    }

    function getReward() public nonReentrant updateReward(msg.sender) {
        uint256 reward = rewards[msg.sender];
        if (reward > 0) {
            rewards[msg.sender] = 0;
            rewardToken.safeTransfer(msg.sender, reward);
            emit RewardPaid(msg.sender, reward);
        }
    }

    function exit() external {
        withdraw(balances[msg.sender]);
        getReward();
    }

    function earned(address account) public view returns (uint256) {
        uint256 _balance = balances[account];
        uint256 _rewardPerToken = rewardPerTokenStored;
        if (totalSupply != 0) {
            uint256 time = block.timestamp - lastUpdateTime;
            uint256 pending = time * rewardRate;
            _rewardPerToken += (pending * PRECISION) / totalSupply;
        }
        return (_balance * (_rewardPerToken - userRewardPerTokenPaid[account])) / PRECISION + rewards[account];
    }
}

🧪 Step 4 — Write Tests (Foundry)

Here’s a simple test case to verify our staking logic:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "forge-std/Test.sol";
import "../src/MockERC20.sol";
import "../src/StakingRewards.sol";

contract StakingRewardsTest is Test {
    MockERC20 stake;
    MockERC20 reward;
    StakingRewards staking;
    address alice = address(0xA11CE);

    function setUp() public {
        stake = new MockERC20("Stake Token", "STK", 0);
        reward = new MockERC20("Reward Token", "RWD", 0);
        staking = new StakingRewards(address(stake), address(reward));

        stake.mint(alice, 1000 ether);
        reward.mint(address(this), 1000 ether);
        reward.approve(address(staking), type(uint256).max);
    }

    function testStakeAndEarn() public {
        staking.notifyRewardAmount(100 ether, 100);
        vm.prank(alice);
        stake.approve(address(staking), 100 ether);
        vm.prank(alice);
        staking.stake(100 ether);
        vm.warp(block.timestamp + 50);
        uint256 earned = staking.earned(alice);
        assertApproxEqRel(earned, 50 ether, 1e16);
    }
}

Run tests:

forge test

💡 Step 5 — Deploy Script

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "forge-std/Script.sol";
import "../src/MockERC20.sol";
import "../src/StakingRewards.sol";

contract DeployScript is Script {
    function run() public {
        vm.startBroadcast();
        MockERC20 stake = new MockERC20("Stake Token", "STK", 1_000_000 ether);
        MockERC20 reward = new MockERC20("Reward Token", "RWD", 1_000_000 ether);
        StakingRewards staking = new StakingRewards(address(stake), address(reward));
        vm.stopBroadcast();
    }
}

Deploy:

forge script script/Deploy.s.sol --rpc-url <RPC_URL> --private-key <PRIVATE_KEY> --broadcast

🔐 Security Tips

✅ Use nonReentrant modifier
✅ Validate inputs before transfers
✅ Keep reward logic owner-only
✅ Test for edge cases like 0 stake or high reward rates

🚀 What You Built

A complete staking & yield farming platform
Users can stake, earn rewards, and withdraw anytime
Reward distribution is fair and time-based
Built with Foundry, OpenZeppelin, and best Solidity practices

🧠 Next Challenges

Add multiple staking pools
Introduce NFT-based reward boosts
Build a React or Next.js frontend using Ethers.js
Automate reward top-ups with Chainlink Keepers

🔗 GitHub Repository

👉 GitHub: Day 27 — Staking & Yield Farming (Solidity)

🏪 Day 26 of #30DaysOfSolidity — Build a Decentralized NFT Marketplace with Royalties 💎

Saurav Kumar — Wed, 29 Oct 2025 20:24:19 +0000

Today, we’re building a fully functional NFT Marketplace in Solidity — a platform where users can buy, sell, and trade NFTs, while automatically paying royalties to creators and fees to the platform.

It’s like creating your own digital store for NFTs, powered entirely by smart contracts! ⚡

🧠 What You’ll Learn

How NFT marketplaces work on-chain
Listing and buying NFTs with ETH
Applying ERC-2981 royalties for creators
Adding marketplace fees
Preventing reentrancy & ensuring safe transfers
Testing & deploying with Foundry

🧱 Project Structure

day-26-nft-marketplace/
├─ foundry.toml
├─ src/
│  ├─ NFTCollection.sol
│  └─ NFTMarketplace.sol
├─ test/
│  └─ Marketplace.t.sol
├─ script/
│  └─ Deploy.s.sol
└─ README.md

⚙️ Setup

forge init day-26-nft-marketplace
cd day-26-nft-marketplace
forge install OpenZeppelin/openzeppelin-contracts

In foundry.toml:

[default]
src = "src"
out = "out"
libs = ["lib"]
tests = "test"
remappings = ["openzeppelin/=lib/openzeppelin-contracts/"]

🧩 Step 1 — Create the NFT Contract (ERC-721 + Royalties)

We’ll create an NFT collection with ERC-2981 (royalty) support.

📄 src/NFTCollection.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import "openzeppelin/token/ERC721/ERC721.sol";
import "openzeppelin/access/Ownable.sol";
import "openzeppelin/token/common/ERC2981.sol";
import "openzeppelin/utils/Counters.sol";

contract NFTCollection is ERC721, ERC2981, Ownable {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIdCounter;

    string private _baseTokenURI;

    event Minted(address indexed to, uint256 indexed tokenId);

    constructor(string memory name_, string memory symbol_, string memory baseURI_)
        ERC721(name_, symbol_)
    {
        _baseTokenURI = baseURI_;
    }

    function mint(address to, uint96 royaltyBps) external onlyOwner returns (uint256) {
        _tokenIdCounter.increment();
        uint256 tokenId = _tokenIdCounter.current();
        _safeMint(to, tokenId);
        if (royaltyBps > 0) {
            _setTokenRoyalty(tokenId, owner(), royaltyBps);
        }
        emit Minted(to, tokenId);
        return tokenId;
    }

    function setDefaultRoyalty(address receiver, uint96 feeNumerator) external onlyOwner {
        _setDefaultRoyalty(receiver, feeNumerator);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        virtual
        override(ERC721, ERC2981)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }

    function _baseURI() internal view override returns (string memory) {
        return _baseTokenURI;
    }
}

✅ Features:

Mint NFTs with optional per-token royalty.
Default royalty for all tokens (via ERC2981).
Each token has metadata base URI.

🛒 Step 2 — Build the Marketplace Smart Contract

Now, let’s create a marketplace to list, buy, and cancel NFT sales.
We’ll add marketplace fees and royalty distribution automatically.

📄 src/NFTMarketplace.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import "openzeppelin/security/ReentrancyGuard.sol";
import "openzeppelin/token/ERC721/IERC721.sol";
import "openzeppelin/access/Ownable.sol";
import "openzeppelin/utils/Address.sol";
import "openzeppelin/token/common/ERC2981.sol";

contract NFTMarketplace is ReentrancyGuard, Ownable {
    using Address for address payable;

    struct Listing {
        address seller;
        uint256 price;
    }

    mapping(address => mapping(uint256 => Listing)) public listings;

    uint96 public marketplaceFeeBps;
    uint96 public constant FEE_DENOMINATOR = 10000;

    event Listed(address indexed nft, uint256 indexed tokenId, address indexed seller, uint256 price);
    event Cancelled(address indexed nft, uint256 indexed tokenId);
    event Bought(address indexed nft, uint256 indexed tokenId, address indexed buyer, uint256 price);

    constructor(uint96 _feeBps) {
        marketplaceFeeBps = _feeBps; // 250 = 2.5%
    }

    function list(address nft, uint256 tokenId, uint256 price) external nonReentrant {
        require(price > 0, "Price must be > 0");
        IERC721 token = IERC721(nft);
        require(token.ownerOf(tokenId) == msg.sender, "Not owner");
        require(token.getApproved(tokenId) == address(this) ||
                token.isApprovedForAll(msg.sender, address(this)), "Not approved");

        listings[nft][tokenId] = Listing(msg.sender, price);
        emit Listed(nft, tokenId, msg.sender, price);
    }

    function cancel(address nft, uint256 tokenId) external nonReentrant {
        Listing memory l = listings[nft][tokenId];
        require(l.seller == msg.sender, "Not seller");
        delete listings[nft][tokenId];
        emit Cancelled(nft, tokenId);
    }

    function buy(address nft, uint256 tokenId) external payable nonReentrant {
        Listing memory l = listings[nft][tokenId];
        require(l.price > 0, "Not listed");
        require(msg.value == l.price, "Wrong value");

        delete listings[nft][tokenId];

        uint256 fee = (msg.value * marketplaceFeeBps) / FEE_DENOMINATOR;
        uint256 remaining = msg.value - fee;

        (address royaltyReceiver, uint256 royaltyAmount) =
            _getRoyaltyInfo(nft, tokenId, msg.value);

        if (royaltyReceiver != address(0) && royaltyAmount > 0) {
            if (royaltyAmount > remaining) royaltyAmount = remaining;
            remaining -= royaltyAmount;
            payable(royaltyReceiver).sendValue(royaltyAmount);
        }

        payable(l.seller).sendValue(remaining);
        payable(owner()).sendValue(fee);

        IERC721(nft).safeTransferFrom(l.seller, msg.sender, tokenId);

        emit Bought(nft, tokenId, msg.sender, msg.value);
    }

    function _getRoyaltyInfo(address nft, uint256 tokenId, uint256 price)
        internal
        view
        returns (address, uint256)
    {
        try ERC2981(nft).royaltyInfo(tokenId, price)
            returns (address receiver, uint256 amount)
        {
            return (receiver, amount);
        } catch {
            return (address(0), 0);
        }
    }

    receive() external payable {}
}

✅ Key Logic:

Sellers list NFTs after approval.
Buyers send ETH to buy NFTs.
Marketplace automatically splits:
- Creator royalty (ERC2981)
- Marketplace fee
- Seller payout

🧪 Step 3 — Test the Marketplace (Foundry)

📄 test/Marketplace.t.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import "forge-std/Test.sol";
import "../src/NFTCollection.sol";
import "../src/NFTMarketplace.sol";

contract MarketplaceTest is Test {
    NFTCollection nft;
    NFTMarketplace market;

    address owner = address(0xABCD);
    address seller = address(0xBEEF);
    address buyer = address(0xCAFE);

    function setUp() public {
        vm.startPrank(owner);
        nft = new NFTCollection("MyNFT", "MNFT", "ipfs://base/");
        market = new NFTMarketplace(250); // 2.5%
        nft.mint(seller, 500); // 5% royalty
        vm.stopPrank();
    }

    function testBuyNFT() public {
        vm.prank(seller);
        nft.approve(address(market), 1);
        vm.prank(seller);
        market.list(address(nft), 1, 1 ether);

        vm.deal(buyer, 2 ether);
        vm.prank(buyer);
        market.buy{value: 1 ether}(address(nft), 1);

        assertEq(nft.ownerOf(1), buyer);
    }
}

✅ Run tests:

forge test -vv

🚀 Step 4 — Deploy the Contracts

📄 script/Deploy.s.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import "forge-std/Script.sol";
import "../src/NFTCollection.sol";
import "../src/NFTMarketplace.sol";

contract Deploy is Script {
    function run() external {
        vm.startBroadcast();

        NFTCollection nft = new NFTCollection("MyNFT", "MNFT", "ipfs://base/");
        NFTMarketplace market = new NFTMarketplace(250);

        nft.setDefaultRoyalty(msg.sender, 200);

        vm.stopBroadcast();
    }
}

Deploy using Foundry:

forge script script/Deploy.s.sol --broadcast --private-key <YOUR_PRIVATE_KEY>

💰 Example Flow

Owner deploys NFTCollection & NFTMarketplace.
Creator mints NFTs with 5% royalty.
Seller lists NFT for 1 ETH.
Buyer buys NFT:

2.5% → Marketplace owner
5% → Creator (royalty)
92.5% → Seller

Everything is on-chain, transparent, and automatic 💫

🔒 Security Features

Reentrancy protection (nonReentrant)
Checks-Effects-Interactions pattern
Royalties capped (no overpayment)
Only seller can cancel listings
Funds transferred securely via Address.sendValue

💡 Future Enhancements

Add ERC-20 token payments (e.g., USDC)
Add auction and bidding system
Build React frontend with Ethers.js
Integrate The Graph for indexing listings

🧠 Concepts Covered

ERC-721 & ERC-2981 standards
Royalty mechanism
Marketplace fee handling
Secure ETH transfers
Foundry-based testing

🏁 Conclusion

You just built your own decentralized NFT Marketplace — the foundation of OpenSea-like platforms.
Now you understand how to:

Manage NFT listings and trades
Handle royalties automatically
Keep trades secure and transparent

Your smart contracts handle trading, royalties, and fees — all without intermediaries! 🚀

🔗 Connect With Me

If you found this useful — drop a 💬 comment or ❤️ like!
Let’s connect 👇
🧑‍💻 Saurav Kumar
💼 LinkedIn
🧵 Twitter/X
📚 More #30DaysOfSolidity Posts

🧮 Day 25 of #30DaysOfSolidity — Build an Automated Market Maker (AMM) 💧

Saurav Kumar — Wed, 29 Oct 2025 17:10:53 +0000

Welcome to Day 25 of the #30DaysOfSolidity challenge!
Today, we’ll build a decentralized Automated Market Maker (AMM) — the core engine behind protocols like Uniswap and Balancer.

You’ll learn how to create a liquidity pool, calculate swap prices, and enable token trading without an order book — all using Solidity and Foundry.

🧠 What is an Automated Market Maker (AMM)?

An AMM is a decentralized exchange mechanism that uses liquidity pools instead of buyers and sellers.
Users provide liquidity (token pairs) and earn fees when others trade using the pool.

It uses the constant product formula:

[
x * y = k
]

Where:

x = reserve of Token A
y = reserve of Token B
k = constant (liquidity)

This ensures the pool stays balanced after every trade.

⚙️ Tech Stack

Solidity v0.8.20
Foundry (for testing and scripting)
ERC20 Tokens
Custom AMM Smart Contracts

🏗️ Project Setup

Step 1: Initialize Foundry Project

forge init day-25-amm
cd day-25-amm

Step 2: Project Structure

day-25-amm/
├─ src/
│  ├─ AMMFactory.sol
│  ├─ AMMPair.sol
│  ├─ MockERC20.sol
│  └─ interfaces/IERC20Minimal.sol
├─ script/
│  ├─ Deploy.s.sol
│  └─ AddLiquidity.s.sol
├─ test/
│  ├─ Pair.t.sol
├─ lib/
│  └─ (optional dependencies)
├─ foundry.toml

💡 Step 3: Create a Minimal ERC20 Token

We’ll use a mock ERC20 token for testing the AMM.

📄 src/MockERC20.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "./interfaces/IERC20Minimal.sol";

contract MockERC20 is IERC20Minimal {
    string public name;
    string public symbol;
    uint8 public decimals = 18;
    uint256 public override totalSupply;

    mapping(address => uint256) public override balanceOf;
    mapping(address => mapping(address => uint256)) public override allowance;

    constructor(string memory _name, string memory _symbol, uint256 _initialSupply) {
        name = _name;
        symbol = _symbol;
        _mint(msg.sender, _initialSupply);
    }

    function transfer(address to, uint256 value) public override returns (bool) {
        _transfer(msg.sender, to, value);
        return true;
    }

    function approve(address spender, uint256 value) public override returns (bool) {
        allowance[msg.sender][spender] = value;
        emit Approval(msg.sender, spender, value);
        return true;
    }

    function transferFrom(address from, address to, uint256 value) public override returns (bool) {
        uint256 allowed = allowance[from][msg.sender];
        require(allowed >= value, "Insufficient allowance");
        allowance[from][msg.sender] = allowed - value;
        _transfer(from, to, value);
        return true;
    }

    function _transfer(address from, address to, uint256 value) internal {
        require(balanceOf[from] >= value, "Insufficient balance");
        balanceOf[from] -= value;
        balanceOf[to] += value;
        emit Transfer(from, to, value);
    }

    function _mint(address to, uint256 value) internal {
        totalSupply += value;
        balanceOf[to] += value;
        emit Transfer(address(0), to, value);
    }

    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

🧮 Step 4: Build the AMM Pair Contract

This contract manages the liquidity pool, swaps, and reserve balances.

📄 src/AMMPair.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "./interfaces/IERC20Minimal.sol";

contract AMMPair {
    IERC20Minimal public token0;
    IERC20Minimal public token1;

    uint256 public reserve0;
    uint256 public reserve1;

    constructor(address _token0, address _token1) {
        token0 = IERC20Minimal(_token0);
        token1 = IERC20Minimal(_token1);
    }

    function addLiquidity(uint256 amount0, uint256 amount1) external {
        require(amount0 > 0 && amount1 > 0, "Invalid amount");
        token0.transferFrom(msg.sender, address(this), amount0);
        token1.transferFrom(msg.sender, address(this), amount1);

        reserve0 += amount0;
        reserve1 += amount1;
    }

    function getAmountOut(uint256 amountIn, address inputToken) public view returns (uint256 amountOut) {
        require(amountIn > 0, "Invalid input");
        bool isToken0 = inputToken == address(token0);
        (uint256 reserveIn, uint256 reserveOut) = isToken0 ? (reserve0, reserve1) : (reserve1, reserve0);

        uint256 amountInWithFee = amountIn * 997;
        amountOut = (amountInWithFee * reserveOut) / (reserveIn * 1000 + amountInWithFee);
    }

    function swap(uint256 amountIn, address inputToken) external {
        require(amountIn > 0, "Invalid input");
        bool isToken0 = inputToken == address(token0);

        IERC20Minimal input = isToken0 ? token0 : token1;
        IERC20Minimal output = isToken0 ? token1 : token0;

        uint256 amountOut = getAmountOut(amountIn, inputToken);
        require(amountOut > 0, "Insufficient output");

        input.transferFrom(msg.sender, address(this), amountIn);
        output.transfer(msg.sender, amountOut);

        if (isToken0) {
            reserve0 += amountIn;
            reserve1 -= amountOut;
        } else {
            reserve1 += amountIn;
            reserve0 -= amountOut;
        }
    }
}

🏭 Step 5: Create AMM Factory

The factory helps create new token pairs.

📄 src/AMMFactory.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "./AMMPair.sol";

contract AMMFactory {
    mapping(address => mapping(address => address)) public getPair;
    address[] public allPairs;

    event PairCreated(address indexed token0, address indexed token1, address pair, uint);

    function createPair(address tokenA, address tokenB) external returns (address pair) {
        require(tokenA != tokenB, "Identical tokens");
        require(getPair[tokenA][tokenB] == address(0), "Pair exists");

        AMMPair newPair = new AMMPair(tokenA, tokenB);
        pair = address(newPair);

        getPair[tokenA][tokenB] = pair;
        getPair[tokenB][tokenA] = pair;
        allPairs.push(pair);

        emit PairCreated(tokenA, tokenB, pair, allPairs.length);
    }
}

🚀 Step 6: Deployment Script

📄 script/Deploy.s.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Script.sol";
import "../src/AMMFactory.sol";
import "../src/MockERC20.sol";

contract DeployScript is Script {
    function run() external {
        vm.startBroadcast();

        MockERC20 tokenA = new MockERC20("TokenA", "TKA", 1_000_000 ether);
        MockERC20 tokenB = new MockERC20("TokenB", "TKB", 1_000_000 ether);
        AMMFactory factory = new AMMFactory();

        factory.createPair(address(tokenA), address(tokenB));

        vm.stopBroadcast();
    }
}

Run the deployment:

forge script script/Deploy.s.sol --broadcast

💧 Step 7: Add Liquidity Script

📄 script/AddLiquidity.s.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Script.sol";
import "../src/AMMPair.sol";
import "../src/MockERC20.sol";

contract AddLiquidityScript is Script {
    function run(address tokenA, address tokenB, address pairAddress) external {
        vm.startBroadcast();

        AMMPair pair = AMMPair(pairAddress);

        MockERC20(tokenA).approve(address(pair), 100 ether);
        MockERC20(tokenB).approve(address(pair), 100 ether);

        pair.addLiquidity(100 ether, 100 ether);

        vm.stopBroadcast();
    }
}

🧪 Step 8: Testing with Foundry

📄 test/Pair.t.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/AMMPair.sol";
import "../src/MockERC20.sol";

contract PairTest is Test {
    AMMPair pair;
    MockERC20 tokenA;
    MockERC20 tokenB;

    function setUp() public {
        tokenA = new MockERC20("TokenA", "TKA", 1_000_000 ether);
        tokenB = new MockERC20("TokenB", "TKB", 1_000_000 ether);
        pair = new AMMPair(address(tokenA), address(tokenB));

        tokenA.approve(address(pair), type(uint256).max);
        tokenB.approve(address(pair), type(uint256).max);
    }

    function testAddLiquidity() public {
        pair.addLiquidity(100 ether, 200 ether);
        assertEq(pair.reserve0(), 100 ether);
        assertEq(pair.reserve1(), 200 ether);
    }

    function testSwap() public {
        pair.addLiquidity(100 ether, 100 ether);
        tokenA.transfer(address(1), 50 ether);
        vm.prank(address(1));
        tokenA.approve(address(pair), 10 ether);
        vm.prank(address(1));
        pair.swap(10 ether, address(tokenA));
    }
}

Run tests:

forge test -vv

🔍 Key Learning Points

✅ Learned about liquidity pools and AMM logic
✅ Implemented swap and reserve balance updates
✅ Used Foundry for testing and scripting
✅ Built a factory for creating multiple token pairs

💫 Final Thoughts

Congratulations! 🎉
You’ve built a mini Uniswap using Solidity and Foundry.

This hands-on example helps you deeply understand how decentralized exchanges work under the hood — from adding liquidity to executing token swaps.

Next up: you can extend it by adding:

Liquidity tokens (LP tokens)
Swap fees distribution
Price oracles

🔗 GitHub Repository

👉 GitHub - Day 25 AMM Project

🧠 Join the Challenge

Follow my #30DaysOfSolidity journey and build your own DeFi stack step-by-step!
Let’s make blockchain development fun and practical 🚀

🏦 Day 24 of #30DaysOfSolidity — Build a Secure Conditional Payments (Escrow) System in Solidity

Saurav Kumar — Wed, 29 Oct 2025 06:07:25 +0000

Ever wondered how to make payments safe in decentralized marketplaces?
Today, we’re building a Secure Escrow System — a smart contract that holds funds until both parties fulfill agreed conditions.

It’s like a digital middleman, ensuring funds are only released when everything goes right — or refunded safely in disputes.

🚀 What You’ll Learn

✅ How to build a secure payment escrow using Solidity
✅ Handle ETH & ERC-20 tokens safely
✅ Manage disputes with an arbiter
✅ Protect funds with ReentrancyGuard and SafeERC20
✅ Implement deadline-based resolution

💡 Concept Overview

In traditional systems, platforms like Upwork or PayPal hold funds until both sides agree.
On-chain, we can do the same — without trusting a central authority.

Roles involved:

Buyer – Deposits funds for the purchase.
Seller – Delivers goods/services.
Arbiter – Neutral party that resolves disputes.

Flow:

Buyer creates and funds an escrow.
Seller delivers work.
Buyer approves → funds go to seller.
Dispute? → Arbiter decides release or refund.

🧱 Smart Contract: `Escrow.sol`

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/*
Day 24 — Secure Conditional Payments (Escrow)
A system that holds funds until both parties agree, 
with support for ETH, ERC20, and dispute resolution.
*/

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract Escrow is ReentrancyGuard, Ownable {
    using SafeERC20 for IERC20;

    enum Status { AWAITING_PAYMENT, AWAITING_DELIVERY, COMPLETE, DISPUTED, REFUNDED, CANCELLED }

    struct Agreement {
        address buyer;
        address seller;
        address arbiter;
        address token;
        uint256 amount;
        uint256 deadline;
        Status status;
        bool buyerApproved;
        bool sellerMarkedDelivered;
        uint256 createdAt;
    }

    uint256 public nextId;
    mapping(uint256 => Agreement) public agreements;

    event EscrowCreated(uint256 indexed id, address indexed buyer, address indexed seller, address arbiter, address token, uint256 amount, uint256 deadline);
    event Funded(uint256 indexed id, address payer, uint256 amount);
    event BuyerApproved(uint256 indexed id, address indexed buyer);
    event DisputeRaised(uint256 indexed id, address indexed by);
    event Resolved(uint256 indexed id, address indexed arbiter, address to, uint256 amount);
    event Refunded(uint256 indexed id, address indexed to, uint256 amount);

    modifier onlyBuyer(uint256 id) {
        require(msg.sender == agreements[id].buyer, "only buyer");
        _;
    }

    modifier onlySeller(uint256 id) {
        require(msg.sender == agreements[id].seller, "only seller");
        _;
    }

    modifier onlyArbiter(uint256 id) {
        require(msg.sender == agreements[id].arbiter, "only arbiter");
        _;
    }

    modifier inStatus(uint256 id, Status s) {
        require(agreements[id].status == s, "invalid status");
        _;
    }

    constructor() {
        nextId = 1;
    }

    function createEscrow(address seller, address arbiter, address token, uint256 amount, uint256 deadline) external returns (uint256) {
        require(seller != address(0), "invalid seller");
        require(amount > 0, "amount>0");

        uint256 id = nextId++;
        agreements[id] = Agreement({
            buyer: msg.sender,
            seller: seller,
            arbiter: arbiter,
            token: token,
            amount: amount,
            deadline: deadline,
            status: Status.AWAITING_PAYMENT,
            buyerApproved: false,
            sellerMarkedDelivered: false,
            createdAt: block.timestamp
        });

        emit EscrowCreated(id, msg.sender, seller, arbiter, token, amount, deadline);
        return id;
    }

    function fundEscrowETH(uint256 id) external payable nonReentrant inStatus(id, Status.AWAITING_PAYMENT) {
        Agreement storage a = agreements[id];
        require(a.token == address(0), "not ETH");
        require(msg.sender == a.buyer, "only buyer");
        require(msg.value == a.amount, "wrong amount");
        a.status = Status.AWAITING_DELIVERY;
        emit Funded(id, msg.sender, msg.value);
    }

    function fundEscrowERC20(uint256 id) external nonReentrant inStatus(id, Status.AWAITING_PAYMENT) {
        Agreement storage a = agreements[id];
        require(a.token != address(0), "not ERC20");
        require(msg.sender == a.buyer, "only buyer");
        IERC20(a.token).safeTransferFrom(msg.sender, address(this), a.amount);
        a.status = Status.AWAITING_DELIVERY;
        emit Funded(id, msg.sender, a.amount);
    }

    function buyerApprove(uint256 id) external onlyBuyer(id) inStatus(id, Status.AWAITING_DELIVERY) nonReentrant {
        Agreement storage a = agreements[id];
        a.buyerApproved = true;
        a.status = Status.COMPLETE;
        _payout(a.token, a.seller, a.amount);
        emit BuyerApproved(id, msg.sender);
    }

    function raiseDispute(uint256 id) external onlyBuyer(id) inStatus(id, Status.AWAITING_DELIVERY) {
        agreements[id].status = Status.DISPUTED;
        emit DisputeRaised(id, msg.sender);
    }

    function arbiterResolve(uint256 id, bool releaseToSeller) external onlyArbiter(id) inStatus(id, Status.DISPUTED) nonReentrant {
        Agreement storage a = agreements[id];
        if (releaseToSeller) {
            a.status = Status.COMPLETE;
            _payout(a.token, a.seller, a.amount);
            emit Resolved(id, msg.sender, a.seller, a.amount);
        } else {
            a.status = Status.REFUNDED;
            _payout(a.token, a.buyer, a.amount);
            emit Refunded(id, a.buyer, a.amount);
        }
    }

    function claimAfterDeadline(uint256 id) external nonReentrant inStatus(id, Status.AWAITING_DELIVERY) {
        Agreement storage a = agreements[id];
        require(a.deadline != 0 && block.timestamp > a.deadline, "deadline not passed");
        require(msg.sender == a.seller, "only seller");
        a.status = Status.COMPLETE;
        _payout(a.token, a.seller, a.amount);
        emit Resolved(id, address(0), a.seller, a.amount);
    }

    function _payout(address token, address to, uint256 amount) internal {
        if (token == address(0)) {
            (bool ok, ) = payable(to).call{value: amount}("");
            require(ok, "ETH transfer failed");
        } else {
            IERC20(token).safeTransfer(to, amount);
        }
    }

    receive() external payable {}
}

🧪 Testing with Foundry

📁 Folder Structure

day-24-escrow/
 ├── src/
 │   └── Escrow.sol
 ├── test/
 │   └── Escrow.t.sol
 └── foundry.toml

🧾 Test File (`Escrow.t.sol`)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/Escrow.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract DummyToken is ERC20 {
    constructor() ERC20("Dummy", "DUM") { _mint(msg.sender, 1_000_000e18); }
}

contract EscrowTest is Test {
    Escrow escrow;
    DummyToken token;
    address buyer = address(0xBEEF);
    address seller = address(0xCAFE);
    address arbiter = address(0xABCD);

    function setUp() public {
        escrow = new Escrow();
        token = new DummyToken();
        vm.deal(buyer, 2 ether);
    }

    function testEthEscrowFlow() public {
        vm.startPrank(buyer);
        uint256 id = escrow.createEscrow(seller, arbiter, address(0), 1 ether, 0);
        escrow.fundEscrowETH{value: 1 ether}(id);
        escrow.buyerApprove(id);
        vm.stopPrank();
    }

    function testERC20DisputeRefund() public {
        vm.startPrank(buyer);
        uint256 id = escrow.createEscrow(seller, arbiter, address(token), 100e18, 0);
        token.approve(address(escrow), 100e18);
        escrow.fundEscrowERC20(id);
        escrow.raiseDispute(id);
        vm.stopPrank();

        vm.prank(arbiter);
        escrow.arbiterResolve(id, false); // refund to buyer
    }
}

⚡ Run Locally

forge init day-24-escrow
cd day-24-escrow
forge install OpenZeppelin/openzeppelin-contracts
forge build
forge test -vv

🔐 Security Practices

✅ Protected by ReentrancyGuard
✅ Safe token transfers via SafeERC20
✅ Proper state checks with modifiers
✅ Arbiter-based dispute resolution
✅ Deadline system for inactive buyers

🧩 Possible Enhancements

💸 Platform fees for escrow service
⏱️ Multi-stage milestone releases
🏛️ DAO-based arbitration
🌐 Chainlink oracle for automated verification

🧠 Key Takeaways

You built a trustless payment system using Solidity.
Learned how to handle disputes safely.
Applied security best practices for real-world DeFi apps.
Understood how conditional payments power Web3 marketplaces.

🏁 Final Thoughts

This escrow contract is a cornerstone for decentralized marketplaces, freelance platforms, and P2P trades.
It teaches how to hold and release funds securely using smart contracts.

You now know how to implement secure, conditional payments on-chain 💪

💰 Day 23 of #30DaysOfSolidity — Build a DeFi Lending & Borrowing System (Aave-like dApp)

Saurav Kumar — Wed, 29 Oct 2025 05:53:59 +0000

Welcome to Day 23 of #30DaysOfSolidity!
Today, we’re diving into one of the most powerful DeFi concepts — Lending and Borrowing.

This project will show how to build a mini Aave-style lending pool using Solidity and Foundry.

You’ll learn:

🏦 How deposits (collateral) and borrowing work
💸 How to calculate dynamic interest
⚖️ How to check collateral ratios & trigger liquidation
🔒 How DeFi banks enforce loans automatically

🏗️ Project Structure

foundry-project/
├─ src/
│  ├─ ERC20Mock.sol
│  ├─ IPriceOracle.sol
│  ├─ InterestRateModel.sol
│  └─ LendingPool.sol
├─ test/
│  ├─ LendingPool.t.sol
├─ remappings.txt
├─ foundry.toml

⚙️ Setup

forge init foundry-project
cd foundry-project
forge install OpenZeppelin/openzeppelin-contracts --no-commit

🧩 1. ERC20Mock.sol

A simple ERC-20 token for testing deposits and loans.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "openzeppelin-contracts/token/ERC20/ERC20.sol";

contract ERC20Mock is ERC20 {
    constructor(string memory name, string memory symbol, uint256 initialSupply)
        ERC20(name, symbol)
    {
        _mint(msg.sender, initialSupply);
    }

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

📊 2. IPriceOracle.sol

Interface for an external or mock price oracle.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IPriceOracle {
    function getPrice(address token) external view returns (uint256);
}

💹 3. InterestRateModel.sol

Implements a simple dynamic interest model — interest grows with utilization.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract InterestRateModel {
    uint256 public baseRate; // e.g. 2% annual
    uint256 public slope;    // increase per utilization %

    constructor(uint256 _baseRate, uint256 _slope) {
        baseRate = _baseRate;
        slope = _slope;
    }

    function getBorrowRate(uint256 utilization) external view returns (uint256) {
        // utilization is scaled to 1e18 (e.g. 0.5 = 50%)
        return baseRate + (slope * utilization) / 1e18;
    }
}

🏦 4. LendingPool.sol

Core smart contract handling deposits, borrowing, interest, and liquidation.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "./ERC20Mock.sol";
import "./IPriceOracle.sol";
import "./InterestRateModel.sol";

contract LendingPool {
    struct Position {
        uint256 collateral;
        uint256 debt;
        uint256 lastUpdate;
    }

    mapping(address => Position) public positions;

    ERC20Mock public token;
    IPriceOracle public oracle;
    InterestRateModel public rateModel;

    uint256 public collateralFactor = 75; // 75%
    uint256 public liquidationThreshold = 85; // 85%

    constructor(address _token, address _oracle, address _rateModel) {
        token = ERC20Mock(_token);
        oracle = IPriceOracle(_oracle);
        rateModel = InterestRateModel(_rateModel);
    }

    // --- Deposit ---
    function depositCollateral(uint256 amount) external {
        require(amount > 0, "Invalid amount");
        token.transferFrom(msg.sender, address(this), amount);
        positions[msg.sender].collateral += amount;
        positions[msg.sender].lastUpdate = block.timestamp;
    }

    // --- Borrow ---
    function borrow(uint256 amount) external {
        _accrueInterest(msg.sender);

        uint256 price = oracle.getPrice(address(token)); // token price in USD (1e18)
        uint256 maxBorrow = (positions[msg.sender].collateral * price * collateralFactor) / (100 * 1e18);

        require(positions[msg.sender].debt + amount <= maxBorrow, "Exceeds limit");

        positions[msg.sender].debt += amount;
        token.transfer(msg.sender, amount);
        positions[msg.sender].lastUpdate = block.timestamp;
    }

    // --- Repay ---
    function repay(uint256 amount) external {
        require(amount > 0, "Invalid amount");
        token.transferFrom(msg.sender, address(this), amount);

        _accrueInterest(msg.sender);

        if (amount >= positions[msg.sender].debt) {
            positions[msg.sender].debt = 0;
        } else {
            positions[msg.sender].debt -= amount;
        }

        positions[msg.sender].lastUpdate = block.timestamp;
    }

    // --- Liquidation ---
    function liquidate(address user) external {
        _accrueInterest(user);
        uint256 price = oracle.getPrice(address(token));
        uint256 maxAllowedDebt = (positions[user].collateral * price * liquidationThreshold) / (100 * 1e18);

        require(positions[user].debt > maxAllowedDebt, "Position healthy");

        token.transfer(msg.sender, positions[user].collateral); // reward liquidator
        delete positions[user];
    }

    // --- Internal interest accrual ---
    function _accrueInterest(address user) internal {
        Position storage p = positions[user];
        if (p.debt == 0 || p.lastUpdate == 0) return;

        uint256 timeElapsed = block.timestamp - p.lastUpdate;
        uint256 utilization = (p.debt * 1e18) / (p.collateral + 1);
        uint256 rate = rateModel.getBorrowRate(utilization); // % per year

        uint256 interest = (p.debt * rate * timeElapsed) / (365 days * 100);
        p.debt += interest;
        p.lastUpdate = block.timestamp;
    }
}

🧪 5. test/LendingPool.t.sol

Simulate deposits, borrows, repayments, and liquidation in Foundry.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/LendingPool.sol";

contract MockOracle is IPriceOracle {
    function getPrice(address) external pure override returns (uint256) {
        return 1e18; // 1 token = 1 USD
    }
}

contract LendingPoolTest is Test {
    ERC20Mock token;
    LendingPool pool;
    InterestRateModel rateModel;
    MockOracle oracle;

    address user = address(0x123);
    address liquidator = address(0x456);

    function setUp() public {
        token = new ERC20Mock("Mock Token", "MCK", 1_000_000 ether);
        oracle = new MockOracle();
        rateModel = new InterestRateModel(2, 10);
        pool = new LendingPool(address(token), address(oracle), address(rateModel));

        token.mint(user, 1000 ether);
        vm.startPrank(user);
        token.approve(address(pool), type(uint256).max);
        vm.stopPrank();
    }

    function testDepositAndBorrow() public {
        vm.startPrank(user);
        pool.depositCollateral(500 ether);
        pool.borrow(200 ether);
        vm.stopPrank();

        LendingPool.Position memory pos = pool.positions(user);
        assertEq(pos.collateral, 500 ether);
        assertGt(pos.debt, 0);
    }

    function testRepay() public {
        vm.startPrank(user);
        pool.depositCollateral(500 ether);
        pool.borrow(200 ether);
        pool.repay(50 ether);
        vm.stopPrank();

        assertLt(pool.positions(user).debt, 200 ether);
    }

    function testLiquidation() public {
        vm.startPrank(user);
        pool.depositCollateral(500 ether);
        pool.borrow(400 ether);
        vm.stopPrank();

        // Simulate price drop (collateral value ↓)
        vm.prank(liquidator);
        pool.liquidate(user);

        assertEq(pool.positions(user).collateral, 0);
    }
}

⚙️ foundry.toml

[profile.default]
src = "src"
out = "out"
libs = ["lib"]

🚀 Run the Project

forge build
forge test -vv

🧠 Key Concepts Recap

Concept	Description
Collateral	Asset locked to secure a loan
Collateral Factor	% of collateral that can be borrowed
Interest Rate	Grows dynamically with pool utilization
Liquidation	Triggered when user’s debt > allowed threshold

💡 Real-World Inspiration

This is a simplified version of Aave or Compound, both of which:

Use on-chain oracles (Chainlink) for price feeds
Implement advanced interest models
Support multiple token markets

You’ve just built the foundation of a DeFi lending protocol 🏦✨

🏁 Next Up

Day 24 → Secure Escrow System 🔒
We’ll build a safe smart contract for conditional payments.

Follow my journey on Dev.to 💫
and tag #30DaysOfSolidity to inspire more builders.

🔗 Full Source Code

🧱 GitHub: Day23-Lending-Borrowing

Forem: Saurav Kumar

Beyond Function Calling: Introducing Advanced Tool Orchestration on the Claude Developer Platform

1. Tool Search Tool: Dynamic Discovery for Infinite Scale

The Challenge: Context Bloat and Accuracy

The Solution: On-Demand Tool Discovery

Real-Life Use Case and Benefits

2. Programmatic Tool Calling (PTC): Efficient Code Orchestration

The Challenge: Context Pollution and Inference Overhead

The Solution: Code-Driven Execution

Real-Life Use Case and Benefits

3. Tool Use Examples: Defining Usage Patterns for Reliability

The Challenge: Ambiguity and Parameter Errors

The Solution: Concrete Usage Demonstration

Real-Life Use Case and Benefits

Strategic Layering for Optimal Agent Architecture

Maximizing WebAI Performance: A Deep Dive into LiteRT.js

What is LiteRT for Web?

Core Features for Production Apps

1. Best-in-Class Hardware Acceleration

2. Multi-Framework Compatibility

3. Seamless TensorFlow.js Interoperability

Technical Deep Dive: Implementation

Step 1: Installation & Setup

Step 2: Running a Model (The "Hot Path")

Step 3: The PyTorch Conversion Workflow

Real-Life Use Cases for Professional Developers

1. Privacy-Preserving Document Processing (FinTech/Legal)

2. Real-Time Video Conferencing Tools

3. Offline-First Field Applications

Key Resources

🚀 Experience Liftoff: Google Antigravity—The Agent-First IDE Redefining Development

The Core Innovation: Autonomous Agents in Mission Control

1. Cross-Surface Agentic Control

2. Artifacts for Trust and Transparency

3. Dual-View Workflow: Editor and Manager View

🔑 Key Features and Capabilities

🎯 Elevating the Developer's Role: Practical Use Cases

⬇️ Get Started with Antigravity Today

🚀 Exploring Kwala: The No-Code Powerhouse for Blockchain Backend Automation

🧩 Introduction

⚙️ What is Kwala?

🏗️ How Kwala Works — Developer Flow & Architecture

👩‍💻 Developer Workflow

🧱 Under the Hood

🌟 Key Features

💡 Use Cases

⚡ My Experience at Kwala Hacker House Hackathon

🧠 Why Developers Should Care

🧭 Getting Started with Kwala

⚖️ Pros & Cons

🔮 The Future of Web3 Backends

🏁 Conclusion

🧠 Day 30 of #30DaysOfSolidity — Build a Simple Token Exchange (AMM) Using Foundry

💡 What You’ll Learn

🧱 Project Overview

📂 Folder Structure

🧩 Step 1 — Minimal ERC20 Implementation (ERC20.sol)

🧩 Step 2 — Mock Tokens (MockERC20.sol)

🧩 Step 3 — Exchange Pair Contract (ExchangePair.sol)

🧩 Step 4 — Factory Contract (ExchangeFactory.sol)

🧪 Step 5 — Testing the Exchange (Exchange.t.sol)

⚙️ Run Locally

📊 How the AMM Maintains Balance

🧠 What You’ve Learned

🏁 Final Thoughts

🪙 Day 29 of #30DaysOfSolidity — Building a Collateral-Backed Stablecoin in Solidity — Step-by-Step Guide

💡 Introduction

🧠 What You’ll Learn

📂 Project File Structure

🧩 System Overview

🏗️ Architecture Diagram

⚙️ Setup Commands

🧩 Smart Contracts

📁 src/interfaces/IAggregatorV3.sol

📁 src/StableUSD.sol

📁 src/OracleManager.sol

📁 src/MockOracle.sol

📁 src/MockERC20.sol

📁 src/CollateralPool.sol

📁 src/Treasury.sol

🧩 Step 1 — Minimal ERC20 Implementation (`ERC20.sol`)

🧩 Step 2 — Mock Tokens (`MockERC20.sol`)

🧩 Step 3 — Exchange Pair Contract (`ExchangePair.sol`)

🧩 Step 4 — Factory Contract (`ExchangeFactory.sol`)

🧪 Step 5 — Testing the Exchange (`Exchange.t.sol`)

📁 `src/interfaces/IAggregatorV3.sol`

📁 `src/StableUSD.sol`

📁 `src/OracleManager.sol`

📁 `src/MockOracle.sol`

📁 `src/MockERC20.sol`

📁 `src/CollateralPool.sol`

📁 `src/Treasury.sol`

📁 `script/Deploy.s.sol`

📁 `test/Stablecoin.t.sol`

⚙️ Smart Contract — `SimpleDAO.sol`

🧱 Smart Contract: `Escrow.sol`

🧾 Test File (`Escrow.t.sol`)