Allow Fundraisers to Specify ERC20 Token for Fundraising

[zain171m]

Description

Currently, the Benefaction Platform only supports raising funds in the native currency of the blockchain, which is sent as msg.value. We want to enhance this functionality by allowing fundraisers to specify an ERC20 contract address if they wish to raise funds in a specific token. This change involves modifications to both the smart contract and the UI.

---

Task Scope

1. Smart Contract Update

• Add functionality for fundraisers to provide an ERC20 token contract address during fundraising setup.
• If an ERC20 token address is specified:
  • The contract should ensure contributions are made in the specified token.
  • Update internal accounting uint256 fundingRaised to track contributions in the ERC20 token instead of native currency.
• If no ERC20 token address is provided, the contract should default to using the blockchain's native currency (e.g., Ether for Ethereum).

2. UI Update

• Update the fundraiser creation form to include an optional field for entering the ERC20 token contract address.
• If a token address is provided:
  • Ensure the user contributes in the specified token during fundraising.
• If no token address is specified, proceed with the existing flow for native currency.

---

Acceptance Criteria

• Fundraisers can specify an ERC20 token address during the creation of a fundraising campaign.
• The smart contract correctly handles contributions in either the specified ERC20 token or the native currency.
• The UI allows fundraisers to specify a token address and ensures contributors adhere to the specified currency type.

---

Technical Notes

• Use the ERC20 interface (IERC20) to interact with the token in the smart contract.

---

Additional Context

This enhancement is crucial for making the platform more versatile and accommodating for fundraisers who prefer raising funds in specific tokens rather than the native currency.

[Zahnentferner]

@zain171m , I am not sure whether having a single contract that can handle both native currency and ERC20 tokens is the best way to proceed. An alternative would be to have two separate contracts and, depending on what the user chooses in the UI, let the factory decide which of the two contracts to deploy.

But, as I said, I'm not 100% convinced that one alternative is better than the other. I see advantages and disadvantages in both.