Assess if it's even worth keeping legacy ABI/protocol sequence in clrfund contracts.
daodesigner opened this issue · comments
So I just finished reading though all the V1 contracts, writing up initial thoughts in pseudo code as to the order things happen in before/after at a high level. MACI 1.0 is (understandably) a breaking change and I think our team is currently underestimating the downstream impacts, given the already hacked together contracts used in clrfund and changes to MACI internally.
- Read through all V1 contracts.
- Rough out new Protocol Sequence
- Determine Technical Debt vs TTM
Pseudo code (mostly to keep track for my own notes using handwavy Solidity Inheritance)
Currently we do :
Deploy MACIFactory(libs, params, etc) -->
Deploy FundingRoundFactory(MACI Factory, registries, config, ...) -->
Method FundingRoundFactory.deployFundingRound {
Deploys MaciContract(registries, config, ...)
Deploys FundingRoundContract(MACIContract, ...)
} -->
New FundingRound Contract {
Implicitly maps MACI Vote options to Recipient Registry Ids which are indexed as an increasing integer sequence
Calculates Initial Voice Credits via hard coded method
Makes calls to MACI signup to give voice credits (does MACI signup on contribution if allowed by registry)
Makes calls to MACI when user votes (does MACI publishMessage on submitMessageBatch)
Calculates Donation as: matchingPoolSize * _tallyResult / totalVotes + _spent * voiceCreditFactor
Allows anyone to pull payments to recipientRegistry[_voteOptionIndex] given valid proof as input
}
now we can do:
Deploy ConcreteImplementation is QuadraticFunding is MACI ( proxyInstance, SignUpGatekeeper InitialVoiceCreditProxy, RecipientSignUpGatekeeper, MACIConfig) -->
New ConcreteImplementation Contract {
Makes calls to MACI signup once for Contributors on signUp method
Calculates Initial Voice Credits through InitialVoiceCreditProxy on signUp
Tracks the current Quadratic Funding Round (maps round #--> FundingRound --> Poll )
Increases/Resets Voice Credit balance on contribution each round (other wise have to sign up again each round anyway) //think we call this "top-ups?"
} -->
Method QuadraticFunding.newMACIRound {
messageAqFactory.deploy(...) --> New AccQueue
pollFactory.deploy(AccQueue) --> New Poll (AccQueue)
deploy FundingRound(Poll, ERC20Token, SignUpGatekeeper, RecipientSignUpGatekeeper, coordinator)
} -->
New FundingRound Contract {
Implicitly maps Poll Vote options to Recipient Registry Ids which are indexed as an increasing integer sequence
Makes calls to MACI* indirectly via Poll when user votes (does calls to AccQueue on Poll.publishMessage)
Calculates Donation as: matchingPoolSize * _tallyResult / totalVotes + _spent * voiceCreditFactor
Allows anyone to pull payments to recipientRegistry[_voteOptionIndex] given valid proof as input
}
completed napkin implementation