Tokenizer - Hanmpark42 Tokens (FT42 / T42)

A Web3 project for the 42 “Tokenizer” subject with both the mandatory fixed-supply token and a multisig-controlled variant.

📌 Overview

The repository now contains two ERC-20 implementations so evaluators can validate both the mandatory requirements and the optional multisig bonus:

• Token42.sol → Token42 (T42): the mandatory, fixed-supply ERC-20. All 42,000 tokens are minted once to the deployer; there is no further minting path.
• HanmparkToken42.sol → Hanmpark42 (FT42): a multisig-aware ERC-20. The constructor mints the initial 42,000 tokens to the multisig contract, and any further minting must be approved and executed by that multisig.
• TokenizerMultiSig.sol: the companion multisignature contract that owns FT42 minting (and can optionally call other admin functions if added later).

Quick contract references (Sepolia)

• Token42 (T42): 0xA0C7c058dF4b77e7D7B8781bc47F69CFeC615e7f
• Hanmpark42 (FT42): 0xA934fbfe6721D4814DB94485F43438Cb199F44aD
• TokenizerMultiSig: 0x3dF1760a6418aCF663492214B74D1e5db398a706

If you redeploy, replace the addresses above everywhere you see them (README + docs) so evaluators can follow along easily.

📚 1. Technologies and Concepts Used

🔗 1.1 What is a Blockchain?

A blockchain is a decentralized network of computers that share a synchronized, tamper-proof ledger of transactions.

Key properties:

• Decentralized: no central server
• Immutable: data cannot be modified once stored
• Transparent: anyone can verify transactions
• Secure: protected by cryptography

In this project, the blockchain stores all token data, including:

• balances
• total supply
• transfer history
• the smart contract code itself

The subject requires deploying the token to a public blockchain, not a local one.

🧾 1.2 What is a Token?

A token is a digital asset managed by a smart contract on a blockchain. ERC-20/BEP-20 tokens represent:

• currency
• loyalty points
• in-app assets
• governance rights
• anything the contract defines

➡ Yes, an ERC-20 token is a cryptocurrency, even without real-world value. ➡ It does not replace ETH — ETH is still needed to pay gas.

This project requires respecting a standard such as ERC-20 (for Ethereum) or BEP-20 (for BNB Chain).

🔐 1.3 Token Standard: ERC-20

The ERC-20 standard defines mandatory functions so that wallets, exchanges, and block explorers know how to interact with the token.

Examples of required functions:

• totalSupply()
• balanceOf(address)
• transfer(address,uint256)
• approve(address,uint256)
• transferFrom(address,uint256)
• allowance(address,address)

OpenZeppelin provides secure and audited implementations, which I used to avoid risks.

⚙️ 1.4 What is a Smart Contract?

A smart contract is a program deployed on the blockchain. It controls:

• token minting
• balances
• transfers
• permissions (owner, minter, etc.)

In ERC-20 tokens, balances are stored using:

mapping(address => uint256) balances;

Once deployed, the smart contract becomes immutable — its logic cannot be changed unless upgrade mechanisms are built in.

🧠 1.5 Solidity

Solidity is the programming language used to write smart contracts on EVM-compatible blockchains.

Used to define:

• token metadata
• logic for minting and transferring
• ownership (using Ownable)
• supply rules

🛠 1.6 Development Tools

The subject allows using Remix, Hardhat, Truffle, or ChainIDE.

I used:

✔ Remix IDE

• Browser-based
• Fast compilation
• Easy deployment on Sepolia
• No local environment setup needed

✔ MetaMask

Used for:

• Managing accounts
• Signing transactions
• Connecting Remix to Sepolia
• Receiving test ETH to pay gas

✔ Sepolia Testnet

• Ethereum’s main test network
• Free ETH using faucets
• Safe for development

🌐 1.7 RPC Endpoints

A blockchain RPC endpoint is the URL MetaMask uses to communicate with the blockchain.

This allows MetaMask or Remix to send transactions to Sepolia.

RPC = the gateway between your wallet and the blockchain.

⛽ 1.8 Gas, ETH, and Tokens

Gas

Computational cost of executing a transaction.

ETH (native coin)

Required to pay gas fees.

Tokens (FT42)

Your token is not used to pay gas. It is just an asset managed by a smart contract.

Sending 10 FT42 still requires ETH to pay for the transfer.

🏗 2. Project Structure (as required by the subject)

project-root/
│
├── README.md                # This file
├── code/                    # Solidity contract(s)
│   ├── HanmparkToken42.sol   # FT42 with multisig-controlled minting
│   ├── Token42.sol           # Mandatory fixed-supply token (T42)
│   └── TokenizerMultiSig.sol # Owners approve minting + admin calls
│
├── deployment/              # Deployment scripts, ABI, addresses
│   └── deployment_guide.md   # How to deploy + verify each contract
│
└── documentation/           # Usage guide, screenshots, explanations
    └── how_to_use_token.md

This follows the required layout from the subject.

🚀 3. Token Details

Mandatory token – Token42 (T42)

• File: code/Token42.sol
• Name / Symbol: token42 / T42
• Supply: Fixed at 42,000 * 10^18, minted once to the deployer
• Mint/Burn: Not available (immutable supply after deployment)
• Network: Sepolia
• Deployed address: 0xA0C7c058dF4b77e7D7B8781bc47F69CFeC615e7f

Multisig-aware token – Hanmpark42 (FT42)

• File: code/HanmparkToken42.sol
• Name / Symbol: hanmpark42 / FT42
• Supply: Starts at 42,000 * 10^18, minted to the multisig
• Minting: Only callable by the multisig contract via mint(address,uint256)
• Admin: Multisig address can be rotated with updateMultisig(address)
• Network: Sepolia
• Deployed address: 0xA934fbfe6721D4814DB94485F43438Cb199F44aD

Multisignature controller – TokenizerMultiSig

• File: code/TokenizerMultiSig.sol
• Purpose: Owns FT42 minting and any other admin calls you choose to route through it
• Core flow: Owners submit a transaction → other owners approve → contract auto-executes once approvals ≥ threshold
• Helper: submitMint(token,to,amount,minApprovals) builds and queues a call to mint on HanmparkToken42
• Network: Sepolia
• Deployed address: 0x3dF1760a6418aCF663492214B74D1e5db398a706

🧪 4. How I Deployed Everything

1. TokenizerMultiSig

   • Picked owner addresses and approval threshold (e.g., 2-of-3).
   • Deployed TokenizerMultiSig first so its address could be passed to the FT42 constructor.

2. HanmparkToken42 (FT42)

   • Deployed HanmparkToken42 with the multisig address as the constructor argument.
   • The initial 42,000 FT42 minted directly to the multisig contract, so only multisig actions can distribute or mint more.

3. Token42 (T42)

   • Deployed Token42 for the mandatory part.
   • Entire supply minted to the deployer; no admin hooks remain.

4. Verification
   Verified each contract on Sepolia Etherscan with compiler 0.8.27 and matching optimization settings.

5. Wallet setup
   Added both token trackers in MetaMask using their contract addresses.

See deployment/deployment_guide.md for exact Remix + MetaMask clicks.

📄 5. Documentation

Located in the /documentation folder:

• How to import both tokens into MetaMask
• How to interact with T42 (fixed supply)
• How to interact with FT42 and request a mint via the multisig
• How to test transfers, balances, and allowances
• How to re-deploy and verify each contract

🔐 6. Multisig Minting Flow (implemented)

• Owners call submitMint(token, to, amount, minApprovals) on TokenizerMultiSig.
• The submission auto-approves for the caller and emits an event with the txId.
• Other owners call approveTx(txId) until approvals ≥ minApprovals.
• Once the threshold is reached, the multisig automatically executes the queued mint call on HanmparkToken42.
• Because minting is behind the multisig, no single owner can inflate supply alone.

🎯 7. Reasoning Behind Choices

• ERC-20: Most common, well supported, simplest to learn
• OpenZeppelin: Secure, audited, industry standard
• Sepolia: Cheapest and easiest testnet for Ethereum
• Remix: Minimal setup, ideal for this project
• Token name with “42”: Required by the subject

📝 8. Conclusion

This project was an introduction to Web3 development, showcasing:

• blockchain fundamentals
• smart contract creation
• ERC-20 token standards
• decentralized storage of data
• deployment on a public blockchain
• integration with MetaMask
• how to wrap privileged operations (minting) behind a multisig for safety

It demonstrates that you can create a cryptocurrency and deploy it globally with only a few tools — without any backend or centralized server, while still keeping minting guarded by multiple approvals when needed.