DEV Community: Aditya41205

Uniswap V3 swapping functions

Aditya41205 — Wed, 16 Jul 2025 16:30:52 +0000

Uniswap V3 Swapping Functions Explained

Uniswap V3 is the most advanced AMM (Automated Market Maker) on Ethereum, providing efficient on-chain swapping for ERC20 tokens. When working with Uniswap from a smart contract, you interact with the router interface—specifically, ISwapRouter—to perform swaps programmatically.

This blog will break down each major swap function (and their parameters!), so you can choose the right tool for your scenario and build powerful DeFi integrations.

The Four Core Uniswap V3 Swapping Methods

Uniswap V3's ISwapRouter exposes four primary ways to swap tokens:

exactInputSingle
exactInput
exactOutputSingle
exactOutput

Let’s explain each in detail.

1. `exactInputSingle`: Single Pool, Exact Input Amount

Purpose:

Swap a known amount of tokenIn for as much tokenOut as possible, all via a single Uniswap V3 pool.

Signature:

function exactInputSingle(ExactInputSingleParams calldata params) external payable returns (uint256 amountOut);

Parameters (packed in a struct):

tokenIn: Address of input token (e.g., DAI).
tokenOut: Address of output token (e.g., WETH).
fee: Pool fee (500, 3000, or 10000 for 0.05%, 0.3%, 1%).
recipient: Where to send the output tokens.
amountIn: The fixed amount of tokenIn to swap.
amountOutMinimum: Minimum amount of tokenOut you will accept (prevents frontrunning/slippage).
sqrtPriceLimitX96: Optional. Sets a price boundary for the swap (0 for no limit).

Usage in Practice:

Simple swaps (DAI↔WETH, USDC↔USDT, etc.) without routing through multiple pairs.

Example scenario: Swap exactly 1000 DAI to receive the maximum possible amount of WETH.

2. `exactInput`: Multi-hop, Exact Input Amount

Purpose:

Swap a known amount of tokenIn for as much as possible of a final tokenOut, possibly routing through several pools (multi-hop swap).

Signature:

function exactInput(ExactInputParams calldata params) external payable returns (uint256 amountOut);

Parameters (in a struct):

path: Bytes data encoding token and fee sequence, e.g., tokenA, feeAB, tokenB, feeBC, tokenC.
recipient: Who receives the output tokens.
amountIn: The fixed amount of tokenIn for the whole route.
amountOutMinimum: Minimum acceptable output.

Path Example (DAI → WETH → WBTC):

abi.encodePacked(DAI, uint24(3000), WETH, uint24(3000), WBTC)

Usage in Practice:

For swaps not directly supported in a single pool (e.g., DAI→WETH→WBTC), or to find the best route through intermediary assets.

3. `exactOutputSingle`: Single Pool, Exact Output Amount

Purpose:

Receive an exact amount of tokenOut while spending as little as possible of tokenIn, via a single Uniswap pool.

Signature:

function exactOutputSingle(ExactOutputSingleParams calldata params) external payable returns (uint256 amountIn);

Parameters:

tokenIn: Address of input token.
tokenOut: Address of output token.
fee: Pool fee.
recipient: Recipient of the output tokens.
amountOut: The desired, exact output amount of tokenOut.
amountInMaximum: The most input tokens you’ll allow to be spent (slippage protection).
sqrtPriceLimitX96: Optional price boundary (set to 0 for no limit).

Usage in Practice:

You need exactly e.g. 1 ETH, but want to spend the minimum DAI possible, and you're willing to cap total input due to price impact or slippage.

4. `exactOutput`: Multi-hop, Exact Output Amount

Purpose:

Receive an exact amount of tokenOut via multiple pools, spending as little input as needed (but no more than your set maximum).

Signature:

function exactOutput(ExactOutputParams calldata params) external payable returns (uint256 amountIn);

Parameters:

path: Bytes encoding the swap route from output to input (i.e., reversed compared to exactInput!).
recipient: Who gets the output.
amountOut: The precise amount of output tokens you want.
amountInMaximum: The maximum input tokens you’re willing to spend.

Example path for WBTC (output) ← WETH ← DAI (input):

abi.encodePacked(WBTC, uint24(3000), WETH, uint24(3000), DAI)

(Note: Multi-hop exactOutput paths are reversed!)

Usage in Practice:

Useful for use-cases where you need to guarantee a specific payment amount in the output token (e.g., for NFT or fixed-price purchases), optimizing how little input you spend.

Struct Table

Function	Parameter Struct Name	Path Format	Guarantees
exactInputSingle	ExactInputSingleParams	N/A	Exact input
exactInput	ExactInputParams	[tokenIn, fee, tokenMid, ...]	Exact input
exactOutputSingle	ExactOutputSingleParams	N/A	Exact output
exactOutput	ExactOutputParams	[tokenOut, fee, tokenMid, ...] reverse!	Exact output

Key Design Patterns and Safety

Always fill in amountOutMinimum/amountInMaximum to guard against front-running and sandwich attacks.
Approve the router contract for any tokens you supply (IERC20(tokenIn).approve(...)).
sqrtPriceLimitX96 is almost always safe at 0 unless you want to enforce a strict price boundary.
For multi-hop routes, ensure each pool (each hop) has liquidity!

Conclusion

Uniswap V3's router gives you immense flexibility :

Use exactInputSingle for simple, one-hop max-output swaps.
Use exactInput for complex swaps through several pools with a fixed input.
Use exactOutputSingle and exactOutput when you know exactly what you want to receive and want to cap your spending.

With this understanding, you can integrate efficient, robust DeFi swaps into your own contracts and dApps!

Further Reading:

Happy swapping!

Uniswap V2 Decoded: A Complete Guide with Code Examples

Aditya41205 — Sun, 29 Jun 2025 07:35:53 +0000

Uniswap V2 revolutionized decentralized trading by introducing automated market makers (AMMs) that enable permissionless token swapping and liquidity provision. In this comprehensive guide, we'll decode the core mechanics of Uniswap V2 with practical code examples that you can implement today.

Understanding Uniswap V2 Architecture

Uniswap V2 implements a core/periphery architecture that separates essential functionality from user-friendly interfaces. The core contracts handle the fundamental trading logic and secure liquidity pools, while periphery contracts like the Router provide safety checks and ease-of-use features.

Core vs Periphery Design

The minimalist core contracts contain only logic strictly necessary to secure liquidity, while periphery contracts handle trader security and user experience. This modular approach allows external helpers to be improved and replaced without migrating liquidity.

// Core: Minimal, secure, immutable
contract UniswapV2Pair {
    // Essential trading logic only
}

// Periphery: User-friendly, upgradeable
contract UniswapV2Router02 {
    // Safety checks and convenience functions
}

Setting Up Your Contract

To interact with Uniswap V2, you need to create an instance of the router contract:

pragma solidity ^0.8.0;

import "@uniswap/v2-periphery/contracts/interfaces/IUniswapV2Router02.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract UniswapV2Integration {
    address private constant ROUTER = 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D;
    IUniswapV2Router02 public uniswapV2Router;

    constructor() {
        uniswapV2Router = IUniswapV2Router02(ROUTER);
    }
}

Key Components:

Router Address: The official Ethereum mainnet address of UniswapV2Router02
Interface Declaration: Defines all available router functions
Instance Creation: Enables calling router functions in your contract

Adding Liquidity: Becoming a Liquidity Provider

The addLiquidity() function allows you to provide liquidity to trading pairs and earn fees from every trade.

Function Signature

function addLiquidity(
    address tokenA,
    address tokenB,
    uint amountADesired,
    uint amountBDesired,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline
) external returns (uint amountA, uint amountB, uint liquidity);

Parameter Breakdown

tokenA/tokenB: Contract addresses of the tokens to pair
amountADesired/amountBDesired: Your preferred deposit amounts
amountAMin/amountBMin: Minimum amounts (slippage protection)
to: Address receiving LP tokens
deadline: Transaction expiration timestamp

Practical Implementation

function addLiquidityToPool(
    address tokenA,
    address tokenB,
    uint256 amountA,
    uint256 amountB
) external {
    // Approve router to spend tokens
    IERC20(tokenA).approve(address(uniswapV2Router), amountA);
    IERC20(tokenB).approve(address(uniswapV2Router), amountB);

    // Add liquidity with 5% slippage tolerance
    uniswapV2Router.addLiquidity(
        tokenA,
        tokenB,
        amountA,
        amountB,
        amountA * 95 / 100,  // 5% slippage protection
        amountB * 95 / 100,  // 5% slippage protection
        msg.sender,          // LP tokens to caller
        block.timestamp + 300 // 5 minute deadline
    );
}

Internal Mechanics: How addLiquidity() Works

Understanding the internal _addLiquidity() function reveals the sophisticated logic behind liquidity provision:

Pair Creation Check

if (IUniswapV2Factory(factory).getPair(tokenA, tokenB) == address(0)) {
    IUniswapV2Factory(factory).createPair(tokenA, tokenB);
}

Reserve-Based Calculations

For existing pairs, the function maintains price ratios:

amountBOptimal = amountADesired.mul(reserveB) / reserveA;

if (amountBOptimal <= amountBDesired) {
    (amountA, amountB) = (amountADesired, amountBOptimal);
} else {
    amountAOptimal = amountBDesired.mul(reserveA) / reserveB;
    (amountA, amountB) = (amountAOptimal, amountBDesired);
}

CREATE2 Address Calculation

Uniswap V2 uses deterministic addresses for gas efficiency:

pair = address(uint(keccak256(abi.encodePacked(
    hex'ff',
    factory,
    keccak256(abi.encodePacked(token0, token1)),
    hex'96e8ac4277198ff8b6f785478aa9a39f403cb768dd02cbee326c3e7da348845f'
))));

Removing Liquidity: Exiting Your Position

The removeLiquidity() function allows you to withdraw your tokens by burning LP tokens:

function removeLiquidity(
    address tokenA,
    address tokenB,
    uint liquidity,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline
) external returns (uint amountA, uint amountB);

Implementation Example

function removeLiquidityFromPool(
    address tokenA,
    address tokenB,
    uint256 liquidityAmount
) external {
    address pair = IUniswapV2Factory(factory).getPair(tokenA, tokenB);

    // Approve router to spend LP tokens
    IERC20(pair).approve(address(uniswapV2Router), liquidityAmount);

    // Remove liquidity
    uniswapV2Router.removeLiquidity(
        tokenA,
        tokenB,
        liquidityAmount,
        0, // Accept any amount of tokenA
        0, // Accept any amount of tokenB
        msg.sender,
        block.timestamp + 300
    );
}

Token Swapping: The Heart of DeFi Trading

The swapExactTokensForTokens() function enables precise token exchanges:

function swapExactTokensForTokens(
    uint amountIn,
    uint amountOutMin,
    address[] calldata path,
    address to,
    uint deadline
) external returns (uint[] memory amounts);

Advanced Swap Implementation

function swapTokens(
    address tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 slippagePercent
) external {
    // Approve router
    IERC20(tokenIn).approve(address(uniswapV2Router), amountIn);

    // Calculate minimum output with slippage
    address[] memory path = new address[](2);
    path[0] = tokenIn;
    path[1] = tokenOut;

    uint[] memory amountsOut = uniswapV2Router.getAmountsOut(amountIn, path);
    uint amountOutMin = amountsOut[1] * (100 - slippagePercent) / 100;

    // Execute swap
    uniswapV2Router.swapExactTokensForTokens(
        amountIn,
        amountOutMin,
        path,
        msg.sender,
        block.timestamp + 300
    );
}

Multi-Hop Swapping

For tokens without direct pairs, Uniswap routes through intermediate tokens:

function multiHopSwap(uint256 amountIn) external {
    address[] memory path = new address[](3);
    path[0] = USDC_ADDRESS;  // Start with USDC
    path[1] = WETH_ADDRESS;  // Route through WETH
    path[2] = DAI_ADDRESS;   // End with DAI

    IERC20(USDC_ADDRESS).approve(address(uniswapV2Router), amountIn);

    uniswapV2Router.swapExactTokensForTokens(
        amountIn,
        0, // Calculate proper minimum in production
        path,
        msg.sender,
        block.timestamp + 300
    );
}

LP Token Economics: Understanding Your Returns

When you provide liquidity, you receive ERC-20 LP tokens representing your pool share:

LP Token Characteristics

Proportional ownership of the entire pool
Fee accumulation from every trade (0.3% in V2)
Redeemable for underlying tokens plus earned fees

Profitability Factors

// Your share calculation
uint256 yourPoolShare = (yourLPTokens * 100) / totalLPSupply;
uint256 yourTokenAShare = (poolReserveA * yourPoolShare) / 100;
uint256 yourTokenBShare = (poolReserveB * yourPoolShare) / 100;

Security Considerations and Best Practices

Always Use Slippage Protection

// Bad: No slippage protection
uniswapV2Router.swapExactTokensForTokens(amountIn, 0, path, to, deadline);

// Good: Proper slippage protection
uint256 amountOutMin = expectedAmount * 95 / 100; // 5% slippage
uniswapV2Router.swapExactTokensForTokens(amountIn, amountOutMin, path, to, deadline);

Implement Proper Deadlines

// Bad: No deadline
uint deadline = type(uint).max;

// Good: Reasonable deadline
uint deadline = block.timestamp + 300; // 5 minutes

Handle Approvals Securely

function safeApprove(address token, address spender, uint256 amount) internal {
    IERC20(token).approve(spender, 0); // Reset to 0 first
    IERC20(token).approve(spender, amount);
}

Complete Integration Example

Here's a comprehensive contract that demonstrates all major Uniswap V2 interactions:

pragma solidity ^0.8.0;

import "@uniswap/v2-periphery/contracts/interfaces/IUniswapV2Router02.sol";
import "@uniswap/v2-core/contracts/interfaces/IUniswapV2Factory.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract UniswapV2Manager {
    IUniswapV2Router02 public immutable uniswapV2Router;
    IUniswapV2Factory public immutable uniswapV2Factory;

    constructor() {
        uniswapV2Router = IUniswapV2Router02(0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D);
        uniswapV2Factory = IUniswapV2Factory(0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f);
    }

    function addLiquidity(
        address tokenA,
        address tokenB,
        uint256 amountA,
        uint256 amountB,
        uint256 slippage
    ) external returns (uint256, uint256, uint256) {
        IERC20(tokenA).transferFrom(msg.sender, address(this), amountA);
        IERC20(tokenB).transferFrom(msg.sender, address(this), amountB);

        IERC20(tokenA).approve(address(uniswapV2Router), amountA);
        IERC20(tokenB).approve(address(uniswapV2Router), amountB);

        uint256 amountAMin = amountA * (100 - slippage) / 100;
        uint256 amountBMin = amountB * (100 - slippage) / 100;

        return uniswapV2Router.addLiquidity(
            tokenA,
            tokenB,
            amountA,
            amountB,
            amountAMin,
            amountBMin,
            msg.sender,
            block.timestamp + 300
        );
    }

    function removeLiquidity(
        address tokenA,
        address tokenB,
        uint256 liquidity,
        uint256 slippage
    ) external returns (uint256, uint256) {
        address pair = uniswapV2Factory.getPair(tokenA, tokenB);
        IERC20(pair).transferFrom(msg.sender, address(this), liquidity);
        IERC20(pair).approve(address(uniswapV2Router), liquidity);

        // Get current reserves to calculate minimums
        (uint256 reserveA, uint256 reserveB,) = IUniswapV2Pair(pair).getReserves();
        uint256 totalSupply = IERC20(pair).totalSupply();

        uint256 amountAMin = (reserveA * liquidity / totalSupply) * (100 - slippage) / 100;
        uint256 amountBMin = (reserveB * liquidity / totalSupply) * (100 - slippage) / 100;

        return uniswapV2Router.removeLiquidity(
            tokenA,
            tokenB,
            liquidity,
            amountAMin,
            amountBMin,
            msg.sender,
            block.timestamp + 300
        );
    }

    function swapExactTokensForTokens(
        address tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 slippage
    ) external returns (uint256[] memory) {
        IERC20(tokenIn).transferFrom(msg.sender, address(this), amountIn);
        IERC20(tokenIn).approve(address(uniswapV2Router), amountIn);

        address[] memory path = new address[](2);
        path[0] = tokenIn;
        path[1] = tokenOut;

        uint256[] memory amountsOut = uniswapV2Router.getAmountsOut(amountIn, path);
        uint256 amountOutMin = amountsOut[1] * (100 - slippage) / 100;

        return uniswapV2Router.swapExactTokensForTokens(
            amountIn,
            amountOutMin,
            path,
            msg.sender,
            block.timestamp + 300
        );
    }
}

Conclusion

Uniswap V2's elegant design combines simplicity with powerful functionality. By understanding the core mechanics of liquidity provision, token swapping, and the underlying mathematical models, developers can build sophisticated DeFi applications that leverage automated market makers.

The key to successful Uniswap V2 integration lies in:

Proper slippage protection to prevent unfavorable trades
Secure token approvals to maintain user fund safety
Efficient routing for optimal swap execution
Understanding LP economics for sustainable liquidity provision

Whether you're building a DEX aggregator, yield farming protocol, or simple token swap interface, Uniswap V2's battle-tested infrastructure provides the foundation for reliable decentralized trading.

Remember to always test your implementations thoroughly on testnets before deploying to mainnet, and consider the gas costs and user experience implications of your design choices.

Freelancing in Web3

Aditya41205 — Mon, 16 Jun 2025 05:53:48 +0000

How I Got Paid to Freelance in Web3 — Without Selling My Soul

Freelancing in Web3 sounds like a dream: paid in crypto, working async, and building on bleeding-edge tech. But the reality? It’s chaotic, fast-paced, and full of noise.

Here’s what I learned from landing and completing my first serious freelance project in the space — no hype, just signal.

🚀 Why Web3 Freelancing Is Different

In Web2, freelancing is mostly about shipping interfaces. In Web3, you're often shipping protocol logic, smart contracts, and dApps — things that directly move value and can't afford to break.

You're not just a developer — you're an engineer with a kill switch.

This means:

Clients are more careful (or should be).
Security matters more than speed.
Your code can literally be part of a live economy.

🔍 How I Landed My First Gig

I didn’t spam job boards. Here’s what worked:

Build in Public: I was posting my dev progress — no fluff, just commits and testnet links.
Niche Down: I focused hard on smart contracts and dApps, not just “blockchain dev”.
DM-Ready Profile: My pinned post showed what I’d built. No need for fancy portfolios.

Eventually, someone reached out who needed a trustless game mechanic built. Perfect fit.

💸 The Deal

Without going into specifics (NDA), here’s how we structured it:

Fixed Price — for scope clarity.
Crypto Payment — stablecoins. Fast, no middlemen.
Smart Contract Audit Light — I did my own internal review before handing it over.
No Long Meetings — everything async. Purely technical comms.

This is how freelancing should be.

🧠 Lessons Learned

Don’t Work Without a Wallet Address
Get 50% up front or agree to escrow. Trustless doesn’t mean naive.
Contracts Are Law
Code is literally law in Web3. One bug = client loses funds = your fault. Test, then test again.
Clarity > Everything
Scope creep kills Web3 projects. Define exactly what you’re building, down to the contract methods.
Post-Delivery ≠ Ghosting
Stick around a few days for bugfixes. It builds reputation.

🛠️ Tech Stack (Generalized)

Solidity / Cairo for contracts
React + Wagmi / StarkNet.js for frontend
Testnets + Faucet-fu
Hardhat / Foundry / Protostar for dev workflow

🧭 Where I'm Headed Next

Freelancing in Web3 is viable — but only if you're selective. I’m now focusing more on:

Building my own zk-integrated dApps
Taking on fewer, higher-impact contracts
Contributing to open source where possible

If you’re looking to start freelancing in Web3, here's my advice:

Build something weird and real. Show it. Stay curious. Be trustworthy. The work will find you.

💬 DM-Friendly

I'm open to:

Collaborating on side projects
Giving advice to new devs entering Web3

Feel free to reach out.

🧠 Deep Dive Into DAOs: The Next Evolution of Human Coordination

Aditya41205 — Tue, 10 Jun 2025 16:12:42 +0000

In 2015, Ethereum launched with a vision: to be the "world computer" — a decentralized platform where anyone can deploy code that no single party controls. Out of that vision emerged one of the most powerful constructs in the crypto ecosystem: DAOs, or Decentralized Autonomous Organizations.

More than just buzzwords, DAOs are reshaping how we collaborate, govern, and build shared value. Let’s explore what DAOs are, how they work, real-world examples, their underlying tech, challenges, and the immense potential they hold.

🏠 What Is a DAO?

A DAO is a digital, community-led organization governed by rules encoded as smart contracts. Unlike traditional companies that rely on CEOs, boards, and middle managers, DAOs operate without centralized leadership.

Key Traits of a DAO:

Decentralized: No single entity controls the organization.
Autonomous: Rules and operations are automated through smart contracts.
Transparent: All actions (votes, transactions) are recorded on-chain.
Token-governed: Governance tokens give members voting power.

In essence: DAOs are like cooperatives built in code — trustless, borderless, and self-executing.

🛠️ How DAOs Work

The architecture of a DAO is typically composed of:

1. Smart Contracts

These enforce rules, manage funds, execute votes, and perform tasks autonomously. On Ethereum, Solidity is most common. On StarkNet, DAOs may be built using Cairo, leveraging zk-rollups for scalability and privacy.

2. Governance Tokens

Members receive ERC-20 tokens (like \$UNI or \$COMP) representing voting power. These tokens can be earned, bought, or distributed.

3. Proposal Mechanism

Anyone can submit proposals (e.g., to fund a project, change rules). Each proposal has a voting period and quorum requirements.

4. Voting Systems

1 Token = 1 Vote (common, but plutocratic)
Quadratic Voting (weights small holders more fairly)
Delegated Voting (token holders delegate votes to active participants)

5. Treasury Management

DAO treasuries hold crypto assets and disburse funds via proposals. Tools like Gnosis Safe or on-chain escrow contracts are common.

🌐 Why DAOs Matter

DAOs aren't just a new governance model — they offer a paradigm shift in how people organize, build, and make decisions together:

✅ Trustless Coordination: Replace backroom deals with open, transparent processes.
🌍 Global & Permissionless: Anyone with an internet connection can contribute.
☁️ Composability: DAOs can integrate directly with DeFi, NFTs, identity layers, and more.
🩏 Incentive Alignment: Tokenomics ensure that contributors benefit when the DAO succeeds.

🚀 Real-World DAOs in Action

1. Uniswap DAO

Controls the Uniswap protocol and its \$3B treasury. Holders of \$UNI propose and vote on changes like fee toggles, new features, and grants.

2. MakerDAO

Manages DAI, the most used decentralized stablecoin. Votes on risk parameters, collateral assets, and protocol changes.

3. Gitcoin DAO

Coordinates funding for open-source public goods. Uses quadratic funding to maximize impact.

4. ENS DAO

Governs the Ethereum Name Service, which maps readable names like vitalik.eth to wallet addresses.

5. Nouns DAO

A cultural experiment where 1 NFT = 1 vote. Funds public goods, art, and open web initiatives.

🛠️ Tech Stack Behind DAOs

DAOs leverage an ecosystem of decentralized infrastructure:

Smart Contracts: Solidity, Cairo, Move
Frontends: React + ethers.js / starknet.js
Governance Platforms: Snapshot, Tally, Agora, JokeRace
Treasury Tools: Gnosis Safe, Zodiac Modules
Identity/Delegation: ENS, Gitcoin Passport, EAS (Ethereum Attestation Service)

On StarkNet, Cairo-based DAOs may use zk-based voting or rollup-native execution logic to improve scalability and reduce costs.

⚡ DAO Challenges

Despite their promise, DAOs face several issues:

❌ Voter Apathy

Most token holders don’t vote. Low participation can lead to governance capture by whales or insiders.

📅 Governance Gridlock

Without strong leadership, decision-making can stall. DAOs need clear processes and proposal templates.

🚪 Legal Uncertainty

DAOs exist in a regulatory gray zone. Some states (like Wyoming) recognize them legally; most don’t.

🪨 Security Risks

Bugs in contracts or governance logic (see: The DAO hack of 2016) can cause catastrophic losses.

🔁 Forkability

Because DAOs are open-source and on-chain, factions can fork away (e.g., Sushi from Uniswap). This can fragment communities.

🌧️ The Future of DAOs

We are still in the early days of DAO design. But exciting trends are emerging:

ZK Governance: Voting with privacy using zero-knowledge proofs (StarkNet, Semaphore)
Reputation-based Voting: Weigh votes by merit, not wealth (e.g., soulbound tokens)
Cross-chain DAOs: Operating across multiple chains via bridges or Layer 0s
AI x DAOs: Using agents to draft proposals, summarize debates, or manage operations
DAO2DAO Coordination: DAOs collaborating like nations or companies do

💼 Should You Join or Build a DAO?

Yes — if you want to:

Contribute meaningfully to a mission you care about
Learn how decentralized coordination works
Help build better governance systems
Experiment with incentive design, tokenomics, and power distribution

You don’t need permission. You just need initiative.

📄 Final Thoughts

DAOs are not just tools — they’re social revolutions encoded into smart contracts. They challenge our assumptions about leadership, ownership, and accountability.

While imperfect today, they are evolving fast. The next wave of DAOs may govern not just crypto protocols, but universities, art collectives, cities, and even nation-states.

The future won’t be built by CEOs in boardrooms. It will be coded by communities on-chain.

If you're curious, start by joining a DAO, voting on a proposal, or contributing to one. If you're bold, build one yourself.

The era of decentralized organizations has just begun.

L2 <-> L1 Tokens Bridging

Aditya41205 — Sat, 24 May 2025 17:14:06 +0000

Complete Guide to Token Bridging: L1 ↔ L2

What is Bridging?

Bridging is the process of moving tokens or assets between different blockchain networks. In the context of Ethereum and Starknet:

L1 (Layer 1): Ethereum mainnet - the main blockchain
L2 (Layer 2): Starknet - a scaling solution built on top of Ethereum

Why Do We Need Bridging?

Scalability: L2 networks like Starknet offer faster and cheaper transactions
Interoperability: Users want to move assets between different networks
Ecosystem Access: Different DeFi applications exist on different layers

How Bridging Works

Bridging doesn't actually "move" tokens between chains. Instead, it uses a lock-and-mint mechanism:

L1 → L2 (Deposit):
- Lock/burn tokens on L1
- Send a message to L2
- Mint equivalent tokens on L2
L2 → L1 (Withdrawal):
- Burn tokens on L2
- Send a message to L1
- Unlock/mint tokens on L1

Architecture Overview

┌─────────────────┐    Message     ┌─────────────────┐
│   Ethereum L1   │ ◄────────────► │   Starknet L2   │
│                 │                │                 │
│ TokenBridge.sol │                │ TokenBridge.cairo│
│ MintableToken   │                │ MintableToken   │
└─────────────────┘                └─────────────────┘

Key Components

1. Token Contracts

L1 Token: ERC20-like contract on Ethereum that can mint/burn
L2 Token: Starknet contract that can mint/burn
Both represent the same asset on different layers

2. Bridge Contracts

L1 Bridge: Ethereum contract that handles L1 operations
L2 Bridge: Starknet contract that handles L2 operations
Both communicate via cross-chain messaging

3. Messaging System

L1 → L2: Uses Starknet's sendMessageToL2 function
L2 → L1: Uses Starknet's send_message_to_l1_syscall

Implementation Deep Dive

L2 (Starknet) Implementation

1. Token Interface

#[starknet::interface]
pub trait IMintableToken<TContractState> {
    fn mint(ref self: TContractState, account: ContractAddress, amount: u256);
    fn burn(ref self: TContractState, account: ContractAddress, amount: u256);
}

2. Bridge Interface

#[starknet::interface]
pub trait ITokenBridge<TContractState> {
    fn bridge_to_l1(ref self: TContractState, l1_recipient: EthAddress, amount: u256);
    fn set_l1_bridge(ref self: TContractState, l1_bridge_address: EthAddress);
    fn set_token(ref self: TContractState, l2_token_address: ContractAddress);
}

3. Key Functions

Bridging to L1 (Withdrawal):

fn bridge_to_l1(ref self: ContractState, l1_recipient: EthAddress, amount: u256) {
    // 1. Burn tokens on L2
    IMintableTokenDispatcher { contract_address: self.l2_token.read() }
        .burn(caller_address, amount);

    // 2. Send message to L1
    let mut payload: Array<felt252> = array![
        l1_recipient.into(), amount.low.into(), amount.high.into(),
    ];
    syscalls::send_message_to_l1_syscall(self.l1_bridge.read(), payload.span())
        .unwrap_syscall();
}

Handling Deposits from L1:

#[l1_handler]
pub fn handle_deposit(
    ref self: ContractState, 
    from_address: felt252, 
    account: ContractAddress, 
    amount: u256,
) {
    // 1. Verify message came from L1 bridge
    assert(from_address == self.l1_bridge.read(), Errors::EXPECTED_FROM_BRIDGE_ONLY);

    // 2. Mint tokens on L2
    IMintableTokenDispatcher { contract_address: self.l2_token.read() }
        .mint(account, amount);
}

L1 (Ethereum) Implementation

1. Key Functions

Bridging to L2 (Deposit):

function bridgeToL2(uint256 recipientAddress, uint256 amount) external payable {
    // 1. Burn tokens on L1
    token.burn(msg.sender, amount);

    // 2. Split uint256 for Cairo compatibility
    (uint128 low, uint128 high) = splitUint256(amount);
    uint256[] memory payload = new uint256[](3);
    payload[0] = recipientAddress;
    payload[1] = low;
    payload[2] = high;

    // 3. Send message to L2
    snMessaging.sendMessageToL2{value: msg.value}(
        l2Bridge,
        l2HandlerSelector,
        payload
    );
}

Consuming Withdrawals from L2:

function consumeWithdrawal(
    uint256 fromAddress,
    address recipient,
    uint128 low,
    uint128 high
) external {
    // 1. Recreate payload
    uint256[] memory payload = new uint256[](3);
    payload[0] = uint256(uint160(recipient));
    payload[1] = uint256(low);
    payload[2] = uint256(high);

    // 2. Consume message from L2
    snMessaging.consumeMessageFromL2(fromAddress, payload);

    // 3. Mint tokens on L1
    uint256 amount = (uint256(high) << 128) | uint256(low);
    token.mint(recipient, amount);
}

Data Serialization

Why Split uint256?

Cairo uses felt252 (252-bit field elements), while Solidity uses uint256. To bridge a uint256:

function splitUint256(uint256 value) private pure returns (uint128 low, uint128 high) {
    low = uint128(value & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF);
    high = uint128(value >> 128);
}

On Starknet side:

// Received as amount.low and amount.high
// Automatically reconstructed as u256

Transaction Flow Examples

Depositing (L1 → L2)

User calls bridgeToL2(starknet_address, 100) on L1
L1 Bridge burns 100 tokens from user
L1 Bridge sends message to L2: [starknet_address, 100_low, 100_high]
Starknet Sequencer automatically calls handle_deposit on L2
L2 Bridge mints 100 tokens to user's Starknet address

Withdrawing (L2 → L1)

User calls bridge_to_l1(ethereum_address, 50) on L2
L2 Bridge burns 50 tokens from user
L2 Bridge sends message to L1: [ethereum_address, 50_low, 50_high]
User manually calls consumeWithdrawal(l2_bridge, ethereum_address, 50_low, 50_high) on L1
L1 Bridge mints 50 tokens to user's Ethereum address

Security Considerations

Access Control

Only bridge contracts can mint/burn tokens
Only governors can update bridge addresses
Validate all message sources

Message Validation

// Always verify message source
assert(from_address == self.l1_bridge.read(), Errors::EXPECTED_FROM_BRIDGE_ONLY);

Amount Validation

// Prevent zero amounts
assert(amount.is_non_zero(), Errors::INVALID_AMOUNT);

Timing and Gas Costs

L1 → L2 (Deposits)

Time: ~10-20 minutes
Cost: Ethereum gas + L2 message fee
Automatic: Sequencer calls L1 handler automatically

L2 → L1 (Withdrawals)

Time: ~2-8 hours (state proof generation)
Cost: L2 gas + Ethereum gas for consumption
Manual: User must call consumeWithdrawal

Testing Strategy

Unit Tests

Test token minting/burning
Test message payload construction
Test access control

Integration Tests

Test full deposit flow
Test full withdrawal flow
Test edge cases and failures

Mock Contracts

Use simple mock tokens that emit events instead of managing balances:

fn mint(ref self: ContractState, account: ContractAddress, amount: u256) {
    self.emit(Minted { account, amount });
}

Common Pitfalls

Wrong Selector: L2 handler selector must match exactly
Data Serialization: uint256 must be split for Cairo
Message Source: Always validate message sender
Timing: L2→L1 messages need manual consumption
Gas Estimation: L1→L2 requires payment for L2 execution

Best Practices

Use Events: Emit detailed events for off-chain tracking
Validate Inputs: Check addresses and amounts
Access Control: Implement proper governance
Error Handling: Provide clear error messages
Documentation: Document selector calculations and message formats

This architecture provides a secure, efficient way to bridge tokens between Ethereum and Starknet, enabling users to access applications on both layers while maintaining asset security.

Building a Merkle Tree Airdrop System on Starknet: A Complete Guide

Aditya41205 — Fri, 23 May 2025 19:33:18 +0000

Building a Merkle Tree Airdrop System on Starknet: A Complete Guide

Learn how to create an efficient, gas-optimized airdrop system using Merkle trees with JavaScript and Cairo smart contracts

Introduction

Airdrops have become a cornerstone of Web3 projects for distributing tokens to communities. However, traditional airdrop mechanisms can be extremely gas-intensive when dealing with thousands of recipients. Enter Merkle trees – a cryptographic data structure that allows us to verify membership in a large dataset with minimal on-chain storage and computation.

In this comprehensive guide, we'll build a complete Merkle tree-based airdrop system on Starknet, covering everything from generating proofs off-chain to verifying them on-chain with Cairo smart contracts.

What Are Merkle Trees and Why Use Them?

A Merkle tree is a binary tree where:

Each leaf represents a data element (in our case, an airdrop recipient)
Each internal node contains the hash of its children
The root represents the entire dataset

Benefits for airdrops:

✅ Gas Efficiency: Store only the root hash on-chain instead of all recipient data
✅ Scalability: Handle millions of recipients with minimal on-chain footprint
✅ Privacy: Recipients' data isn't publicly visible until they claim
✅ Flexibility: Easy to update or modify recipient lists

Project Architecture

Our system consists of three main components:

JavaScript Generator: Creates Merkle trees and generates proofs
Cairo Smart Contract: Verifies proofs and handles claims on-chain
Integration Layer: Connects off-chain computation with on-chain verification

Setting Up the Development Environment

First, let's set up our project structure:

mkdir starknet-merkle-airdrop
cd starknet-merkle-airdrop
npm init -y
npm install starknet-merkle-tree starknet

Update your package.json:

{
  "type": "module",
  "scripts": {
    "generate-tree": "node generate-tree.js",
    "test-verification": "node test-verification.js"
  },
  "dependencies": {
    "starknet-merkle-tree": "^latest",
    "starknet": "^6.0.0"
  }
}

Building the Off-Chain Merkle Tree Generator

Create generate-tree.js to handle tree generation and proof creation:

import * as Merkle from "starknet-merkle-tree";
import fs from "fs";

// Define airdrop recipients with their allocation data
const airdropData = [
  ['0x7e00d496e324876bbc8531f2d9a82bf154d1a04a50218ee74cdd372f75a551a', '1000000000000000000', '0'], // 1 ETH
  ['0x53c615080d35defd55569488bc48c1a91d82f2d2ce6199463e095b4a4ead551', '2000000000000000000', '0'], // 2 ETH
  ['0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef', '500000000000000000', '1'],  // 0.5 ETH
  ['0x5678901234567890abcdef1234567890abcdef1234567890abcdef1234567890', '750000000000000000', '0']   // 0.75 ETH
];

console.log('🌳 Generating Merkle tree...');

// Create tree using Poseidon hash (optimized for Starknet)
const tree = Merkle.StarknetMerkleTree.create(airdropData, Merkle.HashType.Poseidon);

console.log(`✅ Tree created with ${airdropData.length} leaves`);
console.log(`📋 Merkle Root: ${tree.root}`);

// Generate and store proofs for all recipients
const proofs = {};
const claims = [];

for (let i = 0; i  {
    fn verify_proof(
        self: @TContractState,
        proof: Array,
        leaf: felt252
    ) -> bool;
    fn verify_claim(
        self: @TContractState,
        proof: Array,
        address: ContractAddress,
        amount: u256,
        additional_data: felt252
    ) -> bool;
    fn get_merkle_root(self: @TContractState) -> felt252;
    fn set_merkle_root(ref self: TContractState, new_root: felt252);
}

#[starknet::contract]
mod MerkleVerifier {
    use super::IMerkleVerifier;
    use starknet::{ContractAddress, get_caller_address};
    use core::poseidon::poseidon_hash_span;
    use core::array::ArrayTrait;
    use starknet::storage::{StoragePointerReadAccess, StoragePointerWriteAccess};

    #[storage]
    struct Storage {
        merkle_root: felt252,
        owner: ContractAddress,
    }

    #[event]
    #[derive(Drop, starknet::Event)]
    enum Event {
        ProofVerified: ProofVerified,
        RootUpdated: RootUpdated,
    }

    #[derive(Drop, starknet::Event)]
    struct ProofVerified {
        #[key]
        leaf: felt252,
        verified: bool,
    }

    #[derive(Drop, starknet::Event)]
    struct RootUpdated {
        old_root: felt252,
        new_root: felt252,
    }

    #[constructor]
    fn constructor(ref self: ContractState, owner: ContractAddress, merkle_root: felt252) {
        self.owner.write(owner);
        self.merkle_root.write(merkle_root);
    }

    #[abi(embed_v0)]
    impl MerkleVerifierImpl of IMerkleVerifier {
        fn verify_proof(
            self: @ContractState,
            proof: Array,
            leaf: felt252
        ) -> bool {
            let root = self.merkle_root.read();
            self._verify_merkle_proof(proof.span(), leaf, root)
        }

        fn verify_claim(
            self: @ContractState,
            proof: Array,
            address: ContractAddress,
            amount: u256,
            additional_data: felt252
        ) -> bool {
            let leaf_hash = self._compute_leaf_hash(address, amount, additional_data);
            self.verify_proof(proof, leaf_hash)
        }

        fn get_merkle_root(self: @ContractState) -> felt252 {
            self.merkle_root.read()
        }

        fn set_merkle_root(ref self: ContractState, new_root: felt252) {
            let caller = get_caller_address();
            assert(caller == self.owner.read(), 'Only owner can update root');

            let old_root = self.merkle_root.read();
            self.merkle_root.write(new_root);

            self.emit(RootUpdated { old_root, new_root });
        }
    }

    #[generate_trait]
    impl InternalImpl of InternalTrait {
        fn _verify_merkle_proof(
            self: @ContractState,
            proof: Span,
            leaf: felt252,
            root: felt252
        ) -> bool {
            let mut computed_hash = leaf;
            let mut i = 0;

            while i  felt252 {
            // Hash format: [address, amount_low, amount_high, additional_data]
            let mut hash_data = ArrayTrait::new();
            hash_data.append(address.into());
            hash_data.append(amount.low.into());
            hash_data.append(amount.high.into());
            hash_data.append(additional_data);

            poseidon_hash_span(hash_data.span())
        }

        fn _is_left_node(self: @ContractState, a: felt252, b: felt252) -> bool {
            let a_u256: u256 = a.into();
            let b_u256: u256 = b.into();
            a_u256 < b_u256
        }
    }
}

Testing the Integration

Create test-verification.js to test our complete system:

import { Account, Contract, RpcProvider } from "starknet";
import fs from "fs";

async function testMerkleVerification() {
    // Load generated data
    const proofs = JSON.parse(fs.readFileSync("./proofs.json", "utf8"));
    const treeData = JSON.parse(fs.readFileSync("./merkle_tree.json", "utf8"));

    console.log("🧪 Testing Merkle verification...");
    console.log(`📋 Root: ${treeData.root}`);

    // Test data
    const testAddress = "0x7e00d496e324876bbc8531f2d9a82bf154d1a04a50218ee74cdd372f75a551a";
    const testProof = proofs[testAddress];

    if (!testProof) {
        console.error("❌ No proof found for test address");
        return;
    }

    console.log(`🎯 Testing address: ${testAddress}`);
    console.log(`💰 Amount: ${testProof.amount}`);
    console.log(`🔐 Proof: [${testProof.proof.join(', ')}]`);

    // Here you would call your deployed contract
    // const result = await contract.verify_claim(
    //     testProof.proof,
    //     testAddress,
    //     { low: testProof.amount, high: "0x0" },
    //     testProof.additionalData
    // );

    console.log("✅ Test data prepared for contract verification");
}

testMerkleVerification().catch(console.error);

Deployment and Usage

Step 1: Generate Your Merkle Tree

npm run generate-tree

Step 2: Deploy the Contract

Use the generated root hash when deploying your Cairo contract.

Step 3: Verify Claims

Users can now claim their airdrops by providing their proof, which the contract will verify against the stored root.

Key Features and Benefits

🚀 Gas Efficiency

Only stores a single 32-byte root hash on-chain
Verification requires minimal computation
Scales to millions of recipients without increasing gas costs

🔒 Security

Cryptographically secure proof system
Impossible to forge valid proofs without the original data
Owner-controlled root updates for flexibility

🎯 User Experience

Recipients only need their proof to claim
No need to submit all recipient data on-chain
Fast verification process

Real-World Applications

This Merkle tree system can be used for:

Token Airdrops: Distribute governance or utility tokens
NFT Allowlists: Manage whitelist access for minting
Reward Systems: Distribute rewards based on participation
Access Control: Gate access to exclusive features or content

Optimization Tips

For Large Datasets

Use batch processing for tree generation
Implement pagination for proof distribution
Consider using IPFS for storing large proof sets

For Gas Optimization

Use Poseidon hashing (optimized for Starknet)
Minimize proof verification loops
Batch multiple claims when possible

Conclusion

Merkle trees provide an elegant solution for scalable, gas-efficient airdrops on Starknet. By combining off-chain computation with on-chain verification, we can handle massive recipient lists while maintaining security and minimizing costs.

The system we've built demonstrates the power of cryptographic data structures in solving real-world blockchain challenges. Whether you're launching a new token or rewarding your community, this Merkle tree implementation provides a robust foundation for your airdrop needs.

What's Next?

Consider extending this system with:

Multi-token support for complex airdrop scenarios
Time-based claiming with expiration dates
Delegation mechanisms for third-party claiming
Integration with frontend dApps for seamless user experience

🚀 Building and Interacting with a StarkNet Contract using React and StarkNet.js

Aditya41205 — Sun, 18 May 2025 18:35:36 +0000

🧠 Introduction

As blockchain scalability becomes increasingly important, Layer 2 solutions are gaining momentum. Among them, StarkNet stands out due to its use of zero-knowledge proofs (ZK-STARKs) to enable scalable and secure computations. However, StarkNet development involves a unique stack — from Cairo smart contracts to frontend integration via StarkNet.js.

In this article, you'll learn how to:

Write a Cairo 1.0 smart contract with access control.
Deploy it on the StarkNet testnet.
Build a frontend using React.
Connect it to wallets like Argent X or Braavos.
Interact with the contract using StarkNet.js.

🧱 Writing the Cairo Smart Contract

Let’s start with a simple secure counter contract.

Only the contract owner can increment the counter, while anyone can view it.

🧾 Contract Code (Cairo 1.0)

#[starknet::interface]
trait ICounterContract<TContractState> {
    fn get_counter(self: @TContractState) -> u32;
    fn increase_counter(ref self: TContractState);
}

#[starknet::contract]
mod counter {
    use starknet::storage::{StoragePointerReadAccess, StoragePointerWriteAccess};
    use starknet::get_caller_address;
    use starknet::ContractAddress;

    #[storage]
    struct Storage {
        counter: u32,
        owner: ContractAddress,
    }

    #[constructor]
    fn constructor(ref self: ContractState, x: u32, owner: ContractAddress) {
        self.counter.write(x);
        self.owner.write(owner);
    }

    #[abi(embed_v0)]
    impl abc of super::ICounterContract<ContractState> {
        fn get_counter(self: @ContractState) -> u32 {
            self.counter.read()
        }

        fn increase_counter(ref self: ContractState) {
            let caller = get_caller_address();
            let owner = self.owner.read();
            assert(caller == owner, 'Owner can only call');
            let current = self.counter.read();
            self.counter.write(current + 1);
        }
    }
}

🔍 Key Features

Access Control: increase_counter is restricted to the owner.
View Function: get_counter is publicly accessible.
Constructor: Initializes counter value and sets the contract owner.

You can compile this with Scarb, and deploy using tools like starkli.

🌐 Building the React Frontend

Now, let’s build a minimal React frontend to interact with the smart contract.

🛠 Tools Used

React for UI
StarkNet.js for smart contract interactions
RpcProvider to read blockchain state
window.starknet to connect wallet extensions like Argent X or Braavos

📁 1. Setting Up the Project

npx create-react-app starknet-dapp
cd starknet-dapp
npm install starknet

🧩 2. Complete React Code

import React, { useEffect, useState } from "react";
import { RpcProvider, Contract } from "starknet";

const CONTRACT_ADDRESS = "0xYOUR_CONTRACT_ADDRESS"; // Replace with actual deployed address
const ABI = [/* ABI JSON here */];

const rpc = new RpcProvider({
  nodeUrl: "https://starknet-sepolia.g.alchemy.com/starknet/version/rpc/v0_8/YOUR_API_KEY",
});

function App() {
  const [walletConnected, setWalletConnected] = useState(false);
  const [counter, setCounter] = useState(null);
  const [contract, setContract] = useState(null);
  const [userAddress, setUserAddress] = useState("");

  const connectWallet = async () => {
    if (!window.starknet) {
      alert("Install Argent X or Braavos");
      return;
    }

    try {
      await window.starknet.enable();
      const account = window.starknet.account;
      const ctr = new Contract(ABI, CONTRACT_ADDRESS, account);
      setContract(ctr);
      setWalletConnected(true);
      setUserAddress(account.address.slice(0, 6) + "..." + account.address.slice(-4));
    } catch (err) {
      console.error("Wallet connection failed:", err);
    }
  };

  const fetchCounter = async () => {
    try {
      const readContract = new Contract(ABI, CONTRACT_ADDRESS, rpc);
      const res = await readContract.get_counter();
      setCounter(res.toString(10));
    } catch (err) {
      console.error("Failed to fetch counter:", err);
    }
  };

  const increaseCounter = async () => {
    try {
      const tx = await contract.increase_counter();
      await rpc.waitForTransaction(tx.transaction_hash);
      fetchCounter();
    } catch (err) {
      console.error("Transaction failed:", err);
    }
  };

  return (
    <div className="App">
      <h1>StarkNet Counter</h1>
      {!walletConnected ? (
        <button onClick={connectWallet}>Connect Wallet</button>
      ) : (
        <>
          <p>Connected: {userAddress}</p>
          <button onClick={fetchCounter}>Get Counter</button>
          <p>Counter: {counter !== null ? counter : "Not fetched"}</p>
          <button onClick={increaseCounter}>Increase Counter</button>
        </>
      )}
    </div>
  );
}

export default App;

🔄 Interaction Flow

1. Connect Wallet

Uses window.starknet.enable() to initiate connection.

2. Read Counter

Uses RpcProvider and a read-only Contract instance.

3. Write to Counter

Uses Contract with the connected wallet account to call increase_counter().

✅ Deployment & Testing

Once your contract is deployed:

Use Voyager to inspect it.
Interact using your React dApp.
Refer to StarkNet.js docs for more interaction patterns.
Use starkli for testing locally.

🧠 Learnings and Best Practices

Split Read/Write Logic: Use RpcProvider for reads, and wallet account for writes.
Use Clean ABIs: Flatten or manually simplify ABI if needed.
Wallet Support: Ensure compatibility with Argent X & Braavos.
Handle Errors: Wrap all async calls with try/catch.

Interactions:

                   Wallet connection

                        Interface

                   Invoking Read function

                  Invoking Write function

🧾 Conclusion

With the rise of ZK-powered Layer 2s, StarkNet offers a powerful and developer-friendly ecosystem for writing scalable dApps.

You just:

Wrote a secure Cairo contract ✅
Deployed it on StarkNet testnet ✅
Built a full React frontend ✅
Integrated wallet connectivity ✅
Interacted with it using StarkNet.js ✅

Using OpenZeppelin in StarkNet contracts

Aditya41205 — Sat, 17 May 2025 05:46:52 +0000

Introduction

StarkNet is rapidly becoming a go-to Layer 2 scaling solution for Ethereum, bringing massive scalability and low fees to decentralized applications. At its core, StarkNet uses Cairo — a powerful new language designed specifically for writing provable, efficient smart contracts.

But writing smart contracts from scratch is time-consuming and error-prone. That’s where OpenZeppelin comes in. OpenZeppelin is widely trusted for providing battle-tested, reusable contract components on Ethereum. Now, OpenZeppelin is bringing the same security and modularity to StarkNet with a growing set of Cairo contracts.

In this post, I’ll show you how to build an ERC20 token on StarkNet by leveraging OpenZeppelin’s Cairo components. We’ll walk through an example contract step-by-step, highlighting key StarkNet concepts along the way.

Why Use OpenZeppelin on StarkNet?

OpenZeppelin contracts help you:

Save Development Time: You don’t need to reinvent the wheel or debug low-level logic like token transfers or storage management.

Increase Security: The code is audited and battle-tested by a huge community.

Follow Best Practices: OpenZeppelin enforces standards, reducing subtle bugs and ensuring interoperability.

Write Modular Code: Components can be composed and extended easily, which fits perfectly with StarkNet’s contract architecture.

Code Breakdown: Your ERC20 Token Contract

Here’s a simplified example of an ERC20 token contract that uses OpenZeppelin Cairo components:

You should include openzeppelin in Scarb.toml.

[dependencies]
openzeppelin = { git = "https://github.com/OpenZeppelin/cairo-contracts.git" }

Contract:

#[starknet::interface]
trait IERC<ContractState> {

fn minting(
        ref self: ContractState,
        recipient: starknet::ContractAddress,
        amount: u256
    );
}
#[starknet::contract]
mod MyERC20Token {
    use openzeppelin::token::erc20::{ERC20Component, ERC20HooksEmptyImpl};
    use starknet::ContractAddress;
    component!(path: ERC20Component, storage: erc20, event: ERC20Event);
    #[abi(embed_v0)]
    impl ERC20MixinImpl = ERC20Component::ERC20Impl<ContractState>;

    impl ERC20InternalImpl = ERC20Component::InternalImpl<ContractState>;
    #[storage]
    struct Storage {
        #[substorage(v0)]
        erc20: ERC20Component::Storage,
    }
    #[event]
    #[derive(Drop, starknet::Event)]
    enum Event {
        #[flat]
        ERC20Event: ERC20Component::Event,
    }
    #[constructor]
    fn constructor(
        ref self: ContractState,
        fixed_supply: u256,
        recipient: ContractAddress
    ) {
        let name = "Test";
        let symbol = "TST";
        self.erc20.initializer(name, symbol);
        self.erc20.mint(recipient, fixed_supply);
    }
    #[abi(embed_v0)]
    impl t of super::IERC<ContractState> {
        fn minting(
            ref self: ContractState,
            recipient: ContractAddress,
            amount: u256
        ) {
            self.erc20.mint(recipient, amount);
        }
    }
}

Breaking Down the Contract

Defining the Interface IERC
The IERC trait defines an interface for minting tokens:

#[starknet::interface]
trait IERC<ContractState> {

    fn minting(
        ref self: ContractState,
        recipient: starknet::ContractAddress,
        amount: u256
    );
}

The minting function lets external callers mint tokens to a specified recipient address.
The #[abi(embed_v0)] macro generates ABI code so this function can be called externally.

Contract Module and Imports

Inside the MyERC20Token module, we import OpenZeppelin’s ERC20 component and StarkNet address utilities:

use openzeppelin::token::erc20::{ERC20Component, ERC20HooksEmptyImpl};

use starknet::ContractAddress;

Composing with component!

component!(path: ERC20Component, storage: erc20, event: ERC20Event);

This macro pulls in OpenZeppelin’s ERC20 logic, storage, and events into your contract under the name erc20.
It helps modularize your contract by reusing battle-tested components.

Storage Definition

#[storage]
struct Storage {
    #[substorage(v0)]
    erc20: ERC20Component::Storage,
}

The contract’s storage embeds OpenZeppelin’s ERC20 storage.
The #[substorage(v0)] attribute allows versioned, modular storage management.

Event Wrapping

#[event]
#[derive(Drop, starknet::Event)]
enum Event {
    #[flat]
    ERC20Event: ERC20Component::Event,
}

Your contract wraps OpenZeppelin’s ERC20 events so it can emit them properly on StarkNet.

Constructor: Initialize and Mint

#[constructor]
fn constructor(
    ref self: ContractState,
    fixed_supply: u256,
    recipient: ContractAddress
) {
    let name = "Test";
    let symbol = "TST";
    self.erc20.initializer(name, symbol);
    self.erc20.mint(recipient, fixed_supply);
}

On deployment, the contract sets the token name and symbol.
It immediately mints the entire fixed_supply to the recipient address.

Minting Implementation

#[abi(embed_v0)]
impl t of super::IERC<ContractState> {
    fn minting(
        ref self: ContractState,
        recipient: ContractAddress,
        amount: u256
    ) {
        self.erc20.mint(recipient, amount);
    }
}

This implements the minting method from the IERC interface.
It calls the OpenZeppelin mint function to mint tokens after deployment.

Deploying and Interacting with the Contract

To deploy:
Compile the contract with the Cairo compiler targeting StarkNet.

Deploy the contract to StarkNet testnet or a local devnet.
Call the constructor with your fixed supply and recipient address.

To interact:

Use the minting function to mint additional tokens to any address after deployment.

Use standard ERC20 calls (transfer, approve, balanceOf) inherited from OpenZeppelin’s ERC20 component.

Conclusion

Using OpenZeppelin’s Cairo components on StarkNet significantly speeds up development of secure, standard-compliant smart contracts. This example shows how easily you can compose and extend OpenZeppelin’s battle-tested ERC20 token implementation on StarkNet.

If you want to build robust Layer 2 dApps, leveraging OpenZeppelin on StarkNet is a smart choice. Feel free to check out the OpenZeppelin Cairo repository and experiment with the components.

Drop a comment if you have questions or want more tutorials on StarkNet Cairo smart contracts!

DEV Community: Aditya41205

Uniswap V3 swapping functions

Uniswap V3 Swapping Functions Explained

The Four Core Uniswap V3 Swapping Methods

1. exactInputSingle: Single Pool, Exact Input Amount

2. exactInput: Multi-hop, Exact Input Amount

3. exactOutputSingle: Single Pool, Exact Output Amount

4. exactOutput: Multi-hop, Exact Output Amount

Struct Table

Key Design Patterns and Safety

Conclusion

Uniswap V2 Decoded: A Complete Guide with Code Examples

Understanding Uniswap V2 Architecture

Core vs Periphery Design

Setting Up Your Contract

Adding Liquidity: Becoming a Liquidity Provider

Function Signature

Parameter Breakdown

Practical Implementation

Internal Mechanics: How addLiquidity() Works

Pair Creation Check

Reserve-Based Calculations

CREATE2 Address Calculation

Removing Liquidity: Exiting Your Position

Implementation Example

Token Swapping: The Heart of DeFi Trading

Advanced Swap Implementation

Multi-Hop Swapping

LP Token Economics: Understanding Your Returns

LP Token Characteristics

Profitability Factors

Security Considerations and Best Practices

Always Use Slippage Protection

Implement Proper Deadlines

Handle Approvals Securely

Complete Integration Example

Conclusion

Freelancing in Web3

How I Got Paid to Freelance in Web3 — Without Selling My Soul

🚀 Why Web3 Freelancing Is Different

🔍 How I Landed My First Gig

💸 The Deal

🧠 Lessons Learned

🛠️ Tech Stack (Generalized)

🧭 Where I'm Headed Next

💬 DM-Friendly

🧠 Deep Dive Into DAOs: The Next Evolution of Human Coordination

🏠 What Is a DAO?

Key Traits of a DAO:

🛠️ How DAOs Work

1. Smart Contracts

2. Governance Tokens

3. Proposal Mechanism

4. Voting Systems

5. Treasury Management

🌐 Why DAOs Matter

🚀 Real-World DAOs in Action

1. Uniswap DAO

2. MakerDAO

3. Gitcoin DAO

4. ENS DAO

5. Nouns DAO

🛠️ Tech Stack Behind DAOs

⚡ DAO Challenges

❌ Voter Apathy

📅 Governance Gridlock

🚪 Legal Uncertainty

🪨 Security Risks

🔁 Forkability

🌧️ The Future of DAOs

💼 Should You Join or Build a DAO?

📄 Final Thoughts

L2 <-> L1 Tokens Bridging

Complete Guide to Token Bridging: L1 ↔ L2

What is Bridging?

Why Do We Need Bridging?

How Bridging Works

Architecture Overview

Key Components

1. Token Contracts

1. `exactInputSingle`: Single Pool, Exact Input Amount

2. `exactInput`: Multi-hop, Exact Input Amount

3. `exactOutputSingle`: Single Pool, Exact Output Amount

4. `exactOutput`: Multi-hop, Exact Output Amount