Add metadata fields to DAO contracts and proposals; consider comments in Vote requests

[ya7on]

Is your feature request related to a problem

Currently, Skipper contracts do not include a metadata field. It's unclear whether we actually need this field, but it might be worth discussing.

Additionally, the current Vote request structure does not support a "comment" field, which prevents users from providing context or reasoning behind their votes.

Describe the solution you'd like

• Add an optional metadata field to DAO contracts and proposals.
• Follow the approach used in the Jetton standard, which supports both on-chain and off-chain metadata. In the off-chain case, the metadata is represented as a URI (e.g., HTTP or IPFS link to a JSON file).
• An alternative approach is to send the metadata as a plain message (e.g. set_metadata) without storing it in the contract. This avoids gas costs associated with storage. Instead, indexers can scan the transaction history and treat the most recent metadata message as the current one. This offers a low-cost solution while still allowing UIs and external tools to access up-to-date metadata.
• Add an optional comment field to the Vote request, allowing voters to explain or annotate their vote.

Describe alternatives you've considered

• Keep the current design and rely on external systems (e.g., frontends or off-chain metadata stores) to associate metadata with DAOs, proposals, and votes.
• Store metadata off-chain and publish only hashes or links on-chain for integrity and lookup.

Additional context

@iamIcarus — let's discuss whether the metadata field is truly necessary and what specific use cases it would support.

[iamIcarus]

@ya7on although it could potentially be misused, users will eventually adapt into it and could become a fun engagement for users. I'm for it if we can provide this as optional feature, not sure the priority given the usage (nice-to-have feature) this will have on initial release 🤔?

What's your thoughts on this?

[ya7on]

I completely agree with you that this is not a critical feature at all. I think we can implement it a bit later — no need to rush it.
Just wanted to bring up the topic for consideration. And so that we don’t forget to implement it in the future when there’s time for it.