Encrypted Proposals
For proposals requiring privacy until their execution, the Governance App Template allows for encrypted proposals that use symmetric and asymmetric keys. This ensures sensitive details remain confidential until a proposal is finalized.
Data to be encrypted
-
Human readable metadata, explaining why the proposal should be approved
-
The actions to execute if the proposal passes
Encryption Steps
-
A user signs a static payload using his/her wallet. The resulting hash is used as a 256-bit private key to generate an ephemeral, in-memory key pair
-
One of the multisig members generates a random symmetric key and uses it to encrypt the metadata and the actions
-
The member fetches the public keys corresponding to the current Security Council members
-
For each member’s public key, he uses it to encrypt the key from step (1)
-
This generates a payload with:
-
The (symmetrically) encrypted metadata and proposals
-
The (asymmetrically) encrypted keys that only each member can recover
-
-
The payload is pinned on IPFS
-
The IPFS URI is published as the proposal metadata
-
The hash of the unencrypted metadata is also published as part of the proposal
-
Decryption Steps
-
One of the multisig members fetches the proposal, along with the pinned IPFS metadata
-
The member signs the same predefined payload to generate the in-memory key pair
-
The user locates the key that was encrypted for his/her wallet
-
He then uses it as the symmetric key to decrypt the metadata and the proposal actions