Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

Assignment #4

Due By: March 22, 2026

Please submit your homework as a single attachment on the Canvas class website.

Note: this assignment will be key to your final project. You’ll need to know how to do so since you’ll be required to create and further develop a smart contract for your final project!

---

Part 1 (20 points)

Decentralized Autonomous Organizations (DAOs) are blockchain-based organizations where decisions are made through transparent on-chain voting instead of centralized management. Many blockchain projects use governance tokens that allow holders to propose and vote on changes such as protocol upgrades, funding allocations, or policy rules.

Your company is developing a community governance platform for a decentralized organization that manages digital infrastructure. Members of the DAO hold governance tokens, and these tokens give them the right to participate in voting on proposals. You will create two interacting smart contracts.

1. GovernanceToken (ERC20) – a token used to represent voting power.

2. DAOProposal (Voting Contract) – manages proposals and voting.

The goal is to simulate how token holders participate in decentralized decision-making using smart contracts.
You are encouraged to use OpenZeppelin libraries or the contracts provided in this assignment files, where appropriate, but you must implement the core voting logic yourself.
You are to use remix IDE for this assignment and deploy contracts to Remix VM or Sepolia Network and document your development process.
Your DAO governance system should function as follows:

1. AGovernanceToken contract is deployed.

2. Tokens are minted to DAO members.

3. TheDAOVoting contract is deployed and given the address of the GovernanceToken contract.

4. Token holders can submit proposals.

5. Token holders votefor or against proposals.

6. The voting power of a user is based on theirtoken balance.

Recommended Workflow in Remix IDE

Before beginning the assignment, students are encouraged to follow the workflow below to ensure the contracts interact correctly.

1. Deploy theGovernanceToken contract.

2. Mint governance tokens to several accounts available in Remix VM.

3. Demonstrate a successful token transfer between two accounts.

4. Deploy theDAOProposal contract using the address of the deployed GovernanceToken.

5. Create a proposal using the createProposal(...) function.

6. Cast votes from multiple accounts using the vote(...) function.

7. Use a read function such as getProposal(proposalId) to observe the proposer, deadline, status, and vote counts.

This sequence reflects the typical lifecycle of a DAO governance system.

Remix IDE Navigation Tip

When interacting with deployed contracts in Remix:

● Use theDeploy & Run Transactions tab.

● After deployment, contracts will appear in theDeployed Contracts section.

● Expand the deployed contract to access its functions.

 

● Use theAccount selector at the top of Remix to simulate different users voting or transferring tokens.

Step 1 – Deploy the Governance Token

Deploy an ERC20 token that will represent voting power in the DAO.
Requirements:

● Use either OpenZeppelin ERC20 implementation or the one provided in the files of this project.

● Mint tokens to few addresses on remix or on sepolia.

These tokens will be used to determine voting power in the governance contract.

Design Considerations for you

- Tokenomics ( Max Supply, Distribution Mechanism)

Provide screenshots demonstrating the successful execution of:

● Successful token transfer between accounts.

Step 2 – Implementation and deployment the DAO Voting Contract

Create a contract calledDAOVoting.
The constructor must receive the address of the GovernanceToken contract. The contract must have the features defined for a system described above.

Implementation of Proposal Creation (Optimized Storage)

Implement thecreateProposal() function to ensure that only the following essential fields are stored on-chain:, Below is an example structure but you are encouraged to innovate and keep the solidity contract gas optimized.

Documentation Requirement (Screenshots)

Provide screenshots demonstrating the successful execution of:

1. A call to the createProposal(...) function.

2. A read function (e.g., getProposal(proposalId)) displaying the proposer, deadline, status, and vote counts.

Design choices left to you:

● Should anyone create proposals?

● Or should the proposer hold a minimum number of tokens?

Step 4 – Implementation of Token-Weighted Voting

Token holders shall possess the capacity to votein favor of or against a submitted proposal.
Implement a function signature, such as:

vote(uint proposalId, bool support)Where:

● support = true signifies a vote in favor.

● support = false signifies a vote against.

A user's voting weight shall be determined by theirtoken balance within the GovernanceToken contract.

Critical stipulations:

● Each unique address shall be permitted to cast only one vote per proposal.

● Voting shall be permissible exclusively prior to the established deadline.

Screenshot Requirement

Provide a screenshot demonstrating the following:

● A minimum of five votes cast on a single proposal (for and against).

● Screenshot of Read call to the EVM for data on a proposal.

The voting weight of each participant is determined by the number of governance tokens they hold. Because ERC20 tokens use18 decimal places, vote counts returned from the contract may appear as large numbers when viewed directly in Remix.

Design Considerations
You are encouraged to design the system in a way thatprevents common issues such as duplicate voting or voting after deadlines.

The contract should incorporate Solidity features in a gas optimized manner including: ( Do not add unnecessary code which may blow up gas costs.) 

● Structs

● Mappings

● Events

● Modifiers

● External contract calls

● Timestamps (block.timestamp)

You are required to upload the contract files along with your assignment.

Questions

Q1) What happens if a user attempts to votetwice on the same proposal?
Explain how your contract prevents this behavior.

Q2) Suggesttwo additional features or improvements that could make this governance system more secure or scalable.What is the consequence if a user attempts to cast a duplicate vote on the same proposal?

Part 2 (20 points) - no need to deploy those contracts to the testnet.

Implement the functionality of a staking contract that involves both ERC20 and ERC721 tokens

Your company has decided to develop a staking protocol, and you have been tasked with managing it. You have access to the ERC20.sol and ERC721.sol contract files as well as the StakingNFT.sol contract for staking NFTs. When a user stakes their NFT, they will receive rewards of one wei per minute. There is no need to deploy the contracts on the testnet.

Before running any function on the  StakingNFT contract, you need to interact with both ERC721 (NFT) and ERC20 contracts. First, you need to deploy both contracts ERC721 (NFT) and ERC20.

Before you can stake an NFT, you need to have a few things set up. Here is a step-by-step explanation:

    1. Deploy anERC20 token contract to be used as the reward token. This utility token is used to pay the rewards to the users who stake their NFTs. We can use OpenZeppelin's implementation of ERC20 and ERC721 to deploy them.

       - Mint some tokens to the StakingNFT contract address. (Fund theNFTStaking contract with reward tokens)

    2. Deploy anERC721 token contract that users will stake.

       - Mint at least one NFT to your account. This NFT will be used for staking.

    3. Deploy theNFTStaking contract, and you need to provide the addresses of the ERC721 and ERC20 contracts you previously deployed.

       - The constructor requires two parameters: `_nftContract` (the address of the deployed NFT contract) and `_rewardToken` (the address of the reward ERC20 token).

    4. Approve the NFT for staking, so before staking an NFT, you need to approve the staking contract to transfer your NFT on your behalf. You can call the `approve` function on the NFT contract, passing the address of the staking contract and the token ID of the NFT you want to stake.

       - Example: onapprove function : (staking contract address, nft token ID).

Once all these steps are completed, users can start staking their NFTs using thestake function. Users can then claim their rewards using the claimRewards function,  and un-stake their NFTs using the un-stake function.

Part 1) There are three questions inNFTStakingcontract, go through the file and start implementing. (Please attach only yourNFTStakingsmart contract file)

Part 2) What happens if a user tries to un-stake without stacking an NFT?

Part 3) Are there any additional functionality or changes you would need to add to improve the staking contract? Why? (you don’t need to write any code) 

Part 3 (Optional)

We’re going to create a smart contract that enables us to read the real price feeds into a smart contract on the Spolia test network.

We need to copy thePriceFeeds.sol contract and deploy it.

Deploy thePriceFeeds contract

 

Deploy the contract and Make sure toinclude the link of the deployment transaction from etherscan

Click on all functions and take a screenshot of the price that each function returns, andexplain in one to two sentences why we need to use the correct feed address.