-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Proposal: Confidential Permanent-Delegate Extension #6880
Comments
Great! Thanks for a great write-up. I agree that this is also well-motivated. One thing to note is that there is no mechanism to enforce that a single This extension will actually be a lot simpler to implement than confidential mint/burn since there are no zero-knowledge proofs involved. We just require that the account extension holds the encryption of the |
Proposed feature
Token-2022 adds the token-extension of confidential transfers. For normal token transfers Token-2022 further adds the permanent-delegate extension, which allows granting a signer the authority to move tokens from any token account belonging to a mint at will. This functionality is however not present for confidential balances.
Adding an authority with "root-access" should also be possible for the confidential balances of a mint.
Why is this needed
The use of confidential balances lends itself especially well for the tokenization of assets in a more regulated environment. At Iron we’re using Token Extensions to issue tokenized bank deposits, which comes with a wide range of possible regulatory and business processes to consider. Within this context it can be necessary to not just freeze accounts of holders, but also to move tokens to different token accounts or burn them. For this a permanent delegate able to move confidential balances is needed.
Proposed solution
A
confidential-permanent-delegate
extension, which adds an authority with the ability to move tokens in the confidential balance of any token account from the mint.There is one main problem to adding this logic, which is that to move funds in a confidential balance the balance encryption keys (
ElGamalKeypair
&AeKey
) are required to generate the relevant zk-proofs. So in order for the permanent delegate to be able to move funds, these secret keys have to be shared with the holder of the authority.The proposed solution to the secret sharing issue is to by default set the
approved
flag on the confidential balance to false if theconfidential-permanent-delegate
is activated on a mint. The normalApprove
instruction would then also be disabled and the approving of accounts could only be done via anApproveAccount
instruction processed within the new extension.This approval would have to be signed by the permanent delegate and only go through if a proof of knowledge of the encryption keys is provided alongside it. For this process the extension would add the public key of an asymmetric encryption key-pair to the mint's data, which would be used to encrypt the
ElGamalKeypair
&AeKey
and post them to chain where the permanent delegate could then read them.On mints with the
confidential-permanent-delegate
enabled, the token account creation flow would then be as follows:ElGamalKeypair
&AeKey
and post them to chainApproveAccount
instruction which evaluates the generated proofs, compares the provided keys to those in the token account and approves the token account if everything is in orderThe text was updated successfully, but these errors were encountered: