-
Notifications
You must be signed in to change notification settings - Fork 43
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
Add custom proposal type that will add options #29
Comments
This will have the downside of the proposer of the proposal paying fairly significant amounts in fees to write the option parameters to storage_vars. Another, more generic possibility, usable by others and nice for anything one-off, which avoids upgrades of the governance contract itself, is using library_call – the submitter will propose a new custom proposal that will simply call a specific function of a declared contract. The declared contract is only used for its logic, it is still all executed in the context of the governance contract. This lets us block ourselves from shooting us in the foot by upgrading the contract with a wrong version and also gives unlimited possibilities to others using the governance contract, only problem being that this code wouldn't be audited. Let's call this 'generic one-off proposal'. Another possibility is to add new custom proposal types that use logic likewise as with the one-off proposals, but their calldata is the payload of the proposal. This is 'proposal to library_call previously defined contract at address x with calldata x', essentially what was meant with 'custom proposals'. |
Here is a more thorough description: Generic external proposalsubmit_proposal takes a new prop_type ID, payload is class hash of a class to be called via library_call. The function apply_passed proposal detects the new proposal type and if the currently passed proposal is Generic External, it uses library_call with parameters (class hash, selector) to execute the proposal. The selector should correspond to Custom external proposalThis proposal type is not urgently needed, but its functionality would be: A new function submit_custom_proposal takes now payload (class hash of class to be called) and calldata. This calldata should be saved into Volition when it is available in Starknet, but standard storage vars will suffice for now. The possibility of encoding the calldata into a hash and then validating them against the hash was also discussed internally, but dropped due to complexity. In apply_passed_proposal, this the payload class hash should be called with the payload calldata. |
Hi, I would like to try this one ! |
@StarkFishinator could you share a discord/telegram handle so that we chat a little more? |
Generic external proposalLibrary calls $payload class hash at function Custom external proposalAllows definition, in governance code, of 'custom' proposals. A custom proposal type has:
Any custom proposal's payload is calldata. If passed, on execution, the class hash and function selector (these are compiled into the governance) will get libcalled with the proposal payload. So for example, to propose to add options, you would call governance with: submit_custom_proposal(6 (option adding custom proposal type), [0x1245, 0x7321, 0x631, ...]) where the array is calldata containing volatilities, strike prices, quote/base tokens, etc. |
Added pseudocode on branch custom-proposal-type. Note that tests for the implemented functionality are also part of any issue. |
The task is to create a custom proposal for in the governance that will serve the Carmine Options AMM
The custom proposal will add new options to the Carmine Options AMM.
This custom proposal will also serve as an example for other custom proposals that might be build in the governance smart contracts, in case other protocols decide to adopt this governance smart contracts.
"Flow" from user perspective
Create custom proposal -> invoke function
submit_custom_proposal
in the governancec. This is similar tosubmit_proposal
. Thesubmit_custom_proposal
will be implemented in this task in the governance. It will take on following parameters1.1) payload parameter will determine "what will happen" what function in the Carmine Options AMM will be called.
1.2) calldata is a list of structs, where each struct defines an option. This calldata should be saved into Volition when it is available in Starknet, but standard storage vars will suffice for now. The possibility of encoding the calldata into a hash and then validating them against the hash was also discussed internally, but dropped due to complexity and future volition.
1.3) governance will store this information internally in a storage_var(s) and it will append proposal ID which will be automatically generated as an increment of the previous ID
users vote on the proposal
assuming the proposal is accepted (if not, discard and move on)
3.1) Anyone can apply the proposal with
apply_passed_proposal
. This takes on the ID of the proposal and in case of the proposal has been already applied it does nothing.3.2) The
apply_passed_proposal
will find both the payload and calldata to be appllied (make sure it can distinguish the generic from custom proposal)3.3) Based on the payload identification (in this case) a function "create_new_options" on the Carmine Options AMM will be called with the calldata information.
3.4) The
create_new_options
will issue new option tokens and add those tokens to the Carmine Options AMM. This function IS EXPECTED TO BE IMPLEMENTED IN THIS TASK TOO as a separate PR in the https://github.com/CarmineOptions/protocol-cairo1/ repo (not yet deployed cairo 1 smart contracts).Note
Initially we were discussing a design where teh create_new_options would be in a separate smart contract and the options would be added through a call via library_call on the external class with the payload. The class is identified through the stored class hash.
Note 2
Below 2 comments from @tensojka are informative and the relevant stuff has been incorporated to this description. Originally the comments were meant for a different design (as per Note above) and now are informative.
The text was updated successfully, but these errors were encountered: