Skip to content
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

Open
MarekHauzr opened this issue Nov 28, 2023 · 6 comments
Open

Add custom proposal type that will add options #29

MarekHauzr opened this issue Nov 28, 2023 · 6 comments
Assignees
Labels
claimed Someone has already expressed interest in this task

Comments

@MarekHauzr
Copy link
Member

MarekHauzr commented Nov 28, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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.

@MarekHauzr MarekHauzr added the help wanted Extra attention is needed label Feb 19, 2024
@StarkFishinator
Copy link
Collaborator

Hi, I would like to try this one !

@StarkFishinator StarkFishinator self-assigned this Feb 20, 2024
@MarekHauzr
Copy link
Member Author

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

@tensojka
Copy link
Contributor

tensojka commented Feb 21, 2024

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:

  • class hash to libcall
  • function selector to libcall
  • corresponding proposal type id

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 tensojka added claimed Someone has already expressed interest in this task and removed help wanted Extra attention is needed labels Feb 23, 2024
@tensojka
Copy link
Contributor

@StarkFishinator @toufic0710

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
claimed Someone has already expressed interest in this task
Projects
None yet
Development

No branches or pull requests

3 participants