[DIS] Community Fund DAO v1.1 Web5 优化提案/ Community Fund DAO v1.1 Web5 Optimization Proposal

CKB Community Fund DAO
97

Thank you for your availability @zz_tovarishch, @yixiu.ckbfans.bit & @david-fi5box, please keep in mind that these are questions from me personally, as part of the Community.

Let’s start with address binding: https://docs.ccfdao.org/en/docs/developer-docs/architecture/address-binding

Workflow Steps:

  1. Generate BindInfo: Create a message containing the target Script and the current timestamp (Unix milliseconds)
  2. Serialize to Hex: Convert the BindInfo to a molecule-encoded hex string with 0x prefix
  3. Sign Message: Use an offline wallet (e.g., Neuron) to sign the hex string
  4. Combine BindInfoWithSig: Combine bind_info and sig into a single structure
  5. Submit Transaction: Use a web wallet to transfer CKB to yourself, placing BindInfoWithSig in the witness field
  6. Backend Verification: Scanner verifies the signature and checks if the timestamp is within ±20 minutes of the block time
  7. Store Binding: If valid, store to database; later timestamps from the same source address will update the existing binding
  8. Query API: Frontend retrieves binding relationships through REST endpoints

My questions are:

  1. Which kind of addresses / locks are currently supported or forecasted?
  2. Who decides which kind of addresses / locks are supported?
  3. Is this decision arbitrary or there are some reasonable rules and the lock just need to satisfy them?
  4. Can a lock integration be developed as a Github Pull Request by third parties devs?

Let’s make a few examples, how and why the following locks could be supported or not?

Any single one of these locks can hold a user (or possibly multiple users in multisig) NervosDAO deposit and (while arguably technically difficult) it could make sense for CommunityDAO to allow them to vote.

At this point one could argue that any lock should be supported, not so fast. Let’s make some counter-examples:

These counter-examples commingle assets from multiple users (which could be ok in itself, see multisigs). The issue is more in how these individual users are able to express their own vote intention.

At this point I see two opposite solutions regarding voting on Community DAO proposals for these categories:

  1. Allow them to have their own internal vote and then report the result as a single representative vote. This internal voting doesn’t need to follow Community DAO rules: say for example that all the members decide of their own free will to delegate to a representative (say for example an internal rule clear when joining such group), nothing wrong with that.

  2. Alternatively, do not allow these addresses where the individual owner voting disposition cannot be reasonably determined at the time of vote using Community DAO rules. If this path is chosen, then the rules must be clear and sensible, determined well-ahead of time.

Phroi

2 Likes