Current Proposed Implementation from spec:
I would love some review from @KurtMerbeth @aminlatifi
Contract Architecture:
Create a deposit contract that receives GIV tokens and will manage the whitelist of eligible Giveth Pro projects- aliased by their project recipient address. Depositors are also allowed to withdraw their GIV from the contract at any time.
Variables:
owner - address - the contract owner address
depositToken - address - the address of the GIV token or deposit token
priceControllerRole - bytes - contains the role hash for the PRICE_CONTROLLER role
upgradePrice - uint256 - the current price a depositor must deposit in GIV to make a project eligible for Giveth Pro
recipientProject - struct - this is identified of a mapping related to the recipientAddress, holds three variables:
depositAmount - uint256 - the amount of GIV tokens deposited, this will be the amount returned to the depositor when they withdraw from the contract
depositorAddress - address - the address of the depositor, this is the address tokens are returned to when calling withdraw - only this address can call the withdraw function for a given recipientProject
Roles:
Owner - The owner/admin of the contract
Can upgrade the contract
Do we want the owner to be able to change the depositorAddress for projects? In case a project owner loses access to their keys.
Price Controller - An address that has permission to call changePrice
Could be a smart contract or automated system at some point in the future
Potential problem
Only allowing one deposit per project could make it so that someone besides the project owner has control of the upgrade status.
Some changes proposed
Perhaps we can take a page out of @Griff Green ‘s suggestion of tokenizing giveth PRO eligibility.
If we use a simple ERC-1155 template (mint, burn, transfer) then would it be possible to alias a tokenID (for an NFT) to a projectID on Giveth??
We can create a nested mapping for each tokenID to the depositorAddress (the minter) with a subsequent mapping of the depositPrice which represents the upgradePrice at time of deposit. The NFT owner can burn their NFT and claim their depositPrice for a specific depositorAddress (if msg.sender === depositorAddress) back in GIV tokens
Multiple people can mint an NFT for a given projectID(TokenID) as long as each minter pays the current upgradePrice
we can make a transfer function that will also update the depositorAddress to the recipient of the NFT, effectively transferring ownership of the GIV denominated in depositPrice.
We can then check a given project’s eligibility by querying the balanceOf of a certain tokenID (project ID) - if the balanceOf is > 0 then we can consider at least one person has still deposited tokens on behalf of a given project
Current Proposed Implementation from spec: I would love some review from @KurtMerbeth @aminlatifi
Contract Architecture:
Create a deposit contract that receives GIV tokens and will manage the whitelist of eligible Giveth Pro projects- aliased by their project recipient address. Depositors are also allowed to withdraw their GIV from the contract at any time.
Variables:
owner- address - the contract owner addressdepositToken- address - the address of the GIV token or deposit tokenpriceControllerRole- bytes - contains the role hash for the PRICE_CONTROLLER roleupgradePrice- uint256 - the current price a depositor must deposit in GIV to make a project eligible for Giveth ProrecipientProject- struct - this is identified of a mapping related to the recipientAddress, holds three variables:depositAmount- uint256 - the amount of GIV tokens deposited, this will be the amount returned to the depositor when they withdraw from the contractdepositorAddress- address - the address of the depositor, this is the address tokens are returned to when callingwithdraw- only this address can call thewithdrawfunction for a givenrecipientProjectRoles:
changePricePotential problem
Only allowing one deposit per project could make it so that someone besides the project owner has control of the upgrade status.
Some changes proposed
Perhaps we can take a page out of @Griff Green ‘s suggestion of tokenizing giveth PRO eligibility.
If we use a simple ERC-1155 template (mint, burn, transfer) then would it be possible to alias a tokenID (for an NFT) to a projectID on Giveth??
We can create a nested mapping for each tokenID to the depositorAddress (the minter) with a subsequent mapping of the depositPrice which represents the upgradePrice at time of deposit. The NFT owner can burn their NFT and claim their depositPrice for a specific depositorAddress (if msg.sender === depositorAddress) back in GIV tokens
Multiple people can mint an NFT for a given projectID(TokenID) as long as each minter pays the current upgradePrice
we can make a transfer function that will also update the depositorAddress to the recipient of the NFT, effectively transferring ownership of the GIV denominated in depositPrice.
We can then check a given project’s eligibility by querying the balanceOf of a certain tokenID (project ID) - if the balanceOf is > 0 then we can consider at least one person has still deposited tokens on behalf of a given project