I have observed that the current submission template for Governance Actions (GAs), which includes sections for Title, Abstract, Motivation, and Rationale , does not provide space to identify the proposing team or individual behind the submission. This omission makes it difficult for DReps to understand and verify the source, credibility, and track record of the proposer—all of which are important for informed deliberation and accountability.
Recommendation name(s), relevant experience, affiliations (if any), and optionally a contact method or social handle for transparency and follow-up.
Including this information would enhance accountability, build trust in the process, and provide valuable context for DReps and the community to more effectively evaluate proposals. I encourage the community and Intersect governance facilitators to consider updating the template accordingly.
Warm regards,Seidu Ziblim
CC:@Cardano-Foundation
There has been some discussion (still not concluded) about how to properly authenticate proposal submitters here (cc @ATADA ):
opened 05:32PM - 01 Feb 25 UTC
Let me first point everybody to this thread here:
[Replay Vulnerability in Gover… nance Action Metadata](https://github.com/cardano-foundation/CIPs/issues/970)
Thanks to @Crypto2099 @Quantumplation @Ryun1 for the inputs.
In short: With the upcoming governance actions like treasury withdrawals there will be imposers to try and trick voters to vote for an action that has stolen/copied the metadata.
My proposal consists of a few changes/additions that makes it more unlikely that it would go thru undetected and to keep it managable also in environments that are not timesynced or that depend on the current slotnumber of the chain.
# Needed additions in CIP100 and its childs (CIP108/119/etc)
## 1 - Add an additional field "depositReturnAddress"
A good indicator for the owner/submitter of an action is the depositReturnAddress (StakeAddress). Why? Because the 100kADA deposit amount are paid back to this address after the action got enacted/refused/timedout.
Therefore a new field should be included **within** the `body` to represent this address. f.e. `"depositReturnAddress": "stake1xxxxxx"`
The deposit return StakeAddress is known to the author before the submit or the signing process. Its not slotnumber dependent it can be done in unsynced offline environments too. There is no timelimit on such a data, no need to submit the metadata within a given timeframe. It makes it easy to compare the set StakeAddress with the one in the action itself. No need to query other databases to figure out the slotnumber when the action was submitted or removed.
This alone is not enough, we also need to make sure that the body was not modified by a potential imposer at all. For that we also need point 2.
## 1b - Include all receiving addresses of a treasury withdrawal within the metadata
As @Crypto2099 pointed out, the treasury withdrawal actions are most likely the ones we have to take most care of.
So, for a treasury withdrawal we can than also require that all the Addresses that are supposed to receive treasury funds via that action, must be included in an extra array and listed in the metadata itself.
Again to bake this into the canonized body hash signature, we need the next step.
## 2 - Make the authors signature mandatory
In order to detect a modified `body` content an so change in the canonized hash, a signature is mandatory.
We can discuss which kind of action metadata must contain at least one signature, like leaving it open for info-actions. But for actions like a hardfork-initation, committee-update, no-confidence and especially treasury withdrawal we need to have a signature as a must.
The used key for the signature is open to the choice of the author. It can be some key that is already public and known by the chain, or a totally different one.
There is no change needed in existing tooling that provide authors signing already. The important new information is in the new `depostiReturnAddress` field within the `body`
Signing via the `CIP-0008/0030` method should be rolled out to all governance metadata content. The `authorWitnessAlgorithm` should also be renamed into `CIP-0030` for those kinds of signatures, to make sure everyone uses the established set of parameters in the signing/verification process we already know from the CIP-0030 message-signing implementations. These are:
```
kty (1) - must be set to OKP (1)
kid (2) - Optional, if present must be set to the same value as in the Sig_structures protectedHeader_cbor via map entry (4)
alg (3) - must be set to EdDSA (-8)
crv (-1) - must be set to Ed25519 (6)
x (-2) - must be set to the public key bytes of the key used to sign the Sig_structure
```
There should be a way for DReps, SPOs and the CC-Members to try to verify the identity of the proposer. For that we need the next step.
## 3 - Provide an identity entry to make the verification possible
To make it somehow possible for the voters (DReps, SPOs and CC-Members) to verify the identity, there should be at least one `Identity` entry/link (we have those kinds already) which points to a source of truth to compare the used `publicKey` of the signature(s). We could also do this vai an `Other` entry.
----
## Steps to verify the used metadata
1. Check the anchorHash(fileHash) of the metadata to be identical with the used one for the action itself. If not -> invalid metadata -> voters should not vote
2. Check the overall metadata jsonld structure and content to be valid. If not -> invalid metadata -> voters should not vote
3. Check that all signatures in the metadata are valid. There must be at least one signature. If not -> invalid metadata -> voters should not vote
4. Check that there is a field `depositReturnAddress` within the `body` which is identical to the one that is set to be used in the governance action itself. If not -> invalid metadata -> voters should not vote
5. In case of a treasury withdrawal, check that all listed receiving addresses in the action are also listed in the array of receiving addresses in the metadata. If not -> invalid metadata -> voters should not vote
In case someone really tries to impose someone else by using the same metadata link or just copy and paste it as a whole, it also means that such an imposer used the same depositReturnAddress for the action proposal. So the deposit amount of 100kADA are than already lost and on its way to the original owner of the metadata. Its highly unlikely that someone would do this intentionally imo.
In case there is such an "imposer" action on the chain, the `Identity` entrie(s) come into play. These still point to the original destination of the original author. So the original author can f.e. host a list of submitted actions ids on there, or simply deny that he/she has submitted an imposer action. In such cases, the voters can deny to vote on such an action and it can also be marked as "scam" on the various platforms/explorers/social-channels.
Adding also als receiving addresses for a treasury withdrawal within the metadata itself makes it basically impossible for an imposer to get funds.
----
Overall, its a very simple method to implement these enhancements without the need to host additional services on and/or offchain to track actions via nonce values, etc.
1 Like