flow-pie / flow-pie/chamaa.api

smart contracts based proposal

Open
#92 0 comments 0 reactions 0 assignees View on GitHub
help wanted
Dominant language
HTML
Stars
3
Forks
4
PR merge metrics
No merged PRs in 30d

Description

### Objective
Create on-chain smart contract(s) to handle proposals lifecycle and act as authoritative source for proposal state (optionally trigger contract-side actions on approval).

### Description
Design and implement Solidity contracts that represent proposals and record votes immutably. Contracts should allow proposals to be created (or receive an anchored hash from backend), store votes (or reference off-chain votes), and expose finalization functions. Contracts should be gas-efficient and include safety checks (only group members, prevent double voting). Consider modular design: a ProposalManager + adapters for actions (loan disbursement module).

### Key Tasks
- Design `ProposalManager.sol`:
- `createProposal(bytes32 proposalHash, uint256 start, uint256 end, uint256 quorum, uint256 threshold)`
- `vote(uint256 proposalId, bool support)` (or `castVote` with voting power)
- `finalize(uint256 proposalId)`
- Events: `ProposalCreated`, `VoteCast`, `ProposalFinalized`
- Decide whether votes are stored fully on-chain or only anchors are stored and votes are validated off-chain + final result anchored.
- Implement membership checks (mapping of member addresses per group) or rely on backend-synchronized membership registry.
- Implement tests (Hardhat/Foundry) for edge cases: double vote, late votes, quorum not met.
- Optimize gas: minimize storage writes, use bitmaps or compressed vote storage if needed.

### Acceptance Criteria
- [ ] Contract compiles and passes unit tests
- [ ] Can create a proposal and cast votes in test environment
- [ ] Finalize returns correct outcome (approved/rejected) respecting quorum and threshold
- [ ] ABI and contract address stored for backend consumption
- [ ] Gas usage reviewed (no unnecessary storage operations)

### Tech Notes / Suggestions
- Use Hardhat + ethers.js for dev, testing, and deployment
- Consider upgradeability pattern only if necessary (be mindful of complexity)
- If group membership is large, consider hybrid approach: on-chain anchors + off-chain votes to reduce gas

### Labels
`blockchain`, `smart-contracts`, `feature`, `testing`

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.