flow-pie/chamaa.api

smart contracts based proposal

Open

#92 创建于 2025年11月9日

在 GitHub 查看
 (0 评论) (0 反应) (0 负责人)HTML (4 fork)auto 404
help wanted

仓库指标

Star
 (3 star)
PR 合并指标
 (PR 指标待抓取)

描述

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

贡献者指南