Lab #3: Blockchain-Based Ecosystems: Memecoins & Stablecoins Development, Attack Simulation, and Auditing
Lastname: ______________         First name:____________Date_______ TA_Prove_Yes/No

1. Overview

This lab guides students through designing, implementing, deploying, testing, and auditing a simple memecoin (ERC‑20) and a minimal ecosystem around it (liquidity pool, simple governance, and a front-end). The lab emphasizes on hands‑on smart contract development, off‑chain assets, tampering/attack simulation, and understanding security tradeoffs.

Students will:

·        Build a token

·        Deploy it to a local testnet

·        Create a Uniswap-style liquidity pair

·        Implement simple governance

·        Simulate common memecoin attacks like rug‑pull, unauthorized minting, honeypot

·        Detect attacks and propose mitigations.

2. Lab Environment Setup

You will be running our code locally using Visual Studio Code to edit our code and using the terminal to run commands. I will reference the code using a file name as label or function name in cases where we have more than a function inside a file. Below are the tools we would be using

·        Node.js v16+ and npm

·        Hardhat local node (an Ethereum local chain)

·        Ethers.js

·        MetaMask (for manual UI testing) or a local script wallet

·        Python 3.8+ for off‑chain helper scripts

3. Tasks (Lab Steps)

Part 1: Mime Coin

Task 0 – Environment & Setup

1.     Would be using google colab run the project with link here https://colab.research.google.com/drive/1VINdl7L0S1r1L1L7pxvsJdVbVTlASvVT?usp=sharing

Screenshots/copies of compiled contracts and deployed addresses (token, router/pair, governance contract)

Task 1 – Create a basic ERC-20 memecoin

1.     Implement Memecoin.sol (ERC‑20) with these features:

a.      name, symbol, decimals.

b.     initialSupply minted to deployer.

c.      mint function restricted to onlyOwner.

d.     burn function available to any holder.

e.      setMaxWallet(uint256) (optional anti‑whale).

2.     Deploy and record the token address and owner address.

Contract file, deployed address, transaction hashes, and a short explanation of tokenomics chosen

Task 2 – Add simple tokenomics and on‑chain rules

1.     Add configurable transaction fee (tax) on transfers that routes to a treasury address.

2.     Implement enableTrading() gating so token is non‑transferable until the owner opens trading (useful for launch control).

3.     Add excludeFromFees(address) and isExcludedFromFees(address) logic.

Show expected token transfer behavior before and after enableTrading() and with fee exemptions

Code snippets, test results, and observations.

 

Task 3 – Provide liquidity & interact with an Automated Market Maker (AMM) integration

1.     Using a Uniswap v2 fork or the provided simplified AMM, create a token–ETH pair and add liquidity programmatically from your deployer account

2.     Show the token price after adding liquidity.

Script used to add liquidity, transaction hashes, and a screenshot of the pair state (reserves and price).

 

Task 4 – Attack simulations & tamper exercises

This mirrors the vulnerability and tamper simulations from Project 1 but adapted to tokens.

1.     Unauthorized Minting / Owner Key Leak simulation

a.      Create a second (attacker) signer and simulate that signer calling mint() (if onlyOwner is removed or the owner key is compromised). Demonstrate supply inflation and its effect on price.

2.     Rug‑pull simulation

a.      Owner adds liquidity and then withdraws all liquidity from the pool (or transfers treasury tokens and removes liquidity). Show how token price collapses and holders are stuck with worthless tokens.

3.     Honeypot / Transfer Revert

a.      Introduce a buggy transfer logic that allows buys but prevents sells (simulate a honeypot). Demonstrate a transaction that fails on sell.

4.     Front‑end social engineering simulation

a.      Show how a malicious UI could trick users to approve unlimited allowance or sign a permit that transfers tokens. Demonstrate by interacting with a script that calls approve(spender, type(uint256).max) and then transferFrom.

For each simulation:

·       Run tests showing the exploit succeeds (or fails if protections exist).

·       Recompute on‑chain states (supply, balances, reserves) and show the exact mismatch (before/after)

Scripts, test output, and explanation of the exploit.

Task 5 – Detection and mitigation of attack

·        Write unit tests that assert invariants such as total supply cap, owner balance limits, and that enableTrading gating prevents transfers pre‑launch.

·        Implement fixes: reintroduce onlyOwner on mint, add timelock for owner actions, add a renounceOwnership() demonstration and explain consequences.

Test suite results, fixed contract versions, and an audit summary

Part 2: Stable Coin: Students will build a simplified Collateralized Stablecoin

Task 0 – The Stablecoin Creation

Create the assets and the pricing mechanism.

1.     StableCoin.sol: A standard ERC-20 (symbol: USDM) where mint and burn are restricted to the Vault contract.

2.     MockOracle.sol: A simple contract that stores a variable ethPriceUSD.

Task 1 – The Vault (Minting & Redeeming)

Allow users to deposit ETH and borrow USDM against it.

1.     Deposit/Mint:

a.      User sends ETH.

b.     Contract calculates USD value using MockOracle.

c.      Checks if (ETH Value / Mint Amount) >= 1.5

d.     Mints USDM to user.

2.     Repay/Withdraw:

a.      User approves and sends USDM back to Vault.

b.     Vault burns USDM.

c.      Vault returns equivalent ETH to user.

Calculate the Health Factor if the position is at risk of attack using ETH collateral amount * ETH Price / USDM Minted

 

Task 2 – Attack Simulation: The Death Spiral

Simulate what happens when the collateral asset crashes like the DeFi exploits.

1.     Set Oracle price of ETH to $3000.

2.     User A deposits 1 ETH ($3000 value) and mints 2000 USDM. (Ratio: 1.5).

3.     The attacker (or market conditions) calls MockOracle.setPrice(1500).

4.     User A’s collateral is now worth $1500, but they owe 2000 USDM. The system is under-collateralized.

5.     User A decides never to repay the loan because keeping the 2000 USDM is more profitable than getting back $1500 of ETH. The protocol is now insolvent.

Include screenshot of each step

 

Task 3 – Detection & Mitigation of the Death Spial Attack

How the code of how you would detect this attack and mitigate the attack from happening