CarmineOptions / konoha

A toolkit for DAO-like governance on Starknet
Apache License 2.0
23 stars 33 forks source link

Add custom proposal type that will add options #29

Open MarekHauzr opened 7 months ago

MarekHauzr commented 7 months ago

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

1) Create custom proposal -> invoke function submit_custom_proposal in the governancec. This is similar to submit_proposal. The submit_custom_proposal will be implemented in this task in the governance. It will take on following parameters 1.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

2) users vote on the proposal

3) 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.

tensojka commented 7 months ago

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'.

tensojka commented 7 months ago

Here is a more thorough description:

Generic external proposal

submit_proposal takes a new prop_type ID, payload is class hash of a class to be called via library_call. The function execute_generic_external_proposal should be called on the external class.

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 execute_generic_external_proposal.

Custom external proposal

This 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.

StarkFishinator commented 4 months ago

Hi, I would like to try this one !

MarekHauzr commented 4 months ago

@StarkFishinator could you share a discord/telegram handle so that we chat a little more?

tensojka commented 4 months ago

Generic external proposal

Library calls $payload class hash at function execute_generic_external_proposal with no calldata (params).

Custom external proposal

Allows 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.

tensojka commented 4 months ago

@StarkFishinator @toufic0710

Added pseudocode on branch custom-proposal-type. Note that tests for the implemented functionality are also part of any issue.