Checking that an upgrade is correct and is compatible with the currently deployed governance state. This will check that for example AMM contract is being upgraded with an AMM contract and not by a token contract.

Generic governance upgrades are inherently risky, because it’s an upgrade of the contract itself. Before application of a passed generic proposal, a test will be run that library calls a health check function on the governance (or core protocol, governance token,...) contract to ensure that it’s truly a contract of the same type (of version higher than current to ensure no incompatibilities).

• in files frontend/src/components/NewProposalForm.tsx & frontend/src/components/Proposal.tsx
• Braavos wallet connection only works on HTTPS or localhost
• transaction goes through but an error is returned by the SDK

Extend treasury.cairo to support setting up TWAMM orders on Ekubo. This is a complex task.

Definition of Done

The Cairo code works as expected, has nearly full test coverage, is reasonably documented (docstrings or similar suffice) and readable.

Extend treasury.cairo to support deposit and withdraw to/from Nostra. support for multiple tokens (ETH, USDC, USDT, STRK, WBTC)

You can use the feature of depositing into Carmine liquidity pools in treasury.cairo as inspiration.

Definition of Done

The Cairo code works as expected, has nearly full test coverage, is reasonably documented (docstrings or similar suffice) and readable. An end-to-end integration test is provided.

Research staking curves of various protocol and select one staking curve and implement it in staking.cairo

Expected skill level: experienced Cairo and/or smart contract developer. This is a complex task.

Definition of Done

The Cairo code works as expected, has nearly full test coverage, is reasonably documented (docstrings or similar suffice) and readable.

https://mirror.xyz/carminefinance.eth/zzcdtidYRhyvFH5cgPpUbeUyDC7kKEz5Gzs51nUr9GM

https://mirror.xyz/carminefinance.eth/pKsak7qgv7N9HhRkhz564RQ0B7NuucSZIZR_XRDSTSE

Essentially remove all the mentions of CARM/Carmine and similar.

Part of the result should be that any protocol will be able to release their own governance.

We need to add the following functionality to the frontend:

When adding a new proposal, there should be multiple new options

• to distribute a given token from the treasury to a given address.
• it should be explained that to distribute tokens, it should be sent to an external defispring-like contract, the user should be pointed here for documentation.
• deposit tokens to Nostra/zkLend (arbitrary proposal that calls treasury should be used for this)
• withdraw tokens from Nostra/zkLend. The user will supply all the required parameters for the proposal.

When opening a already live proposal that distributes funds from Treasury, it should be shown what parameters it has – is it a proposal to distribute tokens, to withdraw from Nostra/zkLend?

therefore if I set the selector to "0x01" (in config), the event with selector 0x1 will not be caught

this issue can wait

Prepare a governance proposal that renames CARM to veCARM.

The goal is to allow for staking the Carmine token. The present day CARM (after this task is done and applied veCARM) is non-transferable, many users already have it and the token will become the staked one.

Issuance of new (transferable) token will be implemented in a separate github-issue.

In #44 , a list of missing tests was created. These tests should be implemented.

Claimed by @Nerrolol

According to tests/README.md

This is a continuation of #61

Implement a comment submission and retrieval feature for proposals in the Konoha governance toolkit. This feature should allow govtoken holders to submit IPFS addresses as comments on proposals and retrieve these comments. Ensure this functionality integrates with the Proposals component to only allow commenting on live proposals and handles only the IPFS hashes, not the actual content.

Expected skill: Cairo developer medior

Steps:

Implement a new component (discussion.cairo) with add and retrieve comment functions, ensuring proposals that are being commented on are live. It should depend on the Proposals component for fetching get_live_proposals().
Implement storage mechanisms for IPFS hashes of comments.
Update tests in tests/proposals.cairo to cover the new functionality.
This clear and structured approach should help a newcomer understand and implement the feature effectively. For more details, please refer to the repository

Definition of Done

The Cairo code works as expected, has nearly full test coverage, is reasonably documented (docstrings or similar suffice) and readable.

Refer to CONTRIBUTING.md for information on claiming the task.

Vesting smart contract is already in progress

The vesting component should be extended to support streaming of any token.

Definition of Done

The Cairo code works as expected, has nearly full test coverage, is reasonably documented (docstrings or similar suffice) and readable.

See CONTRIBUTING.md

Currently, custom proposals can be voted on, but they can't be added.

A function add_new_custom_proposal_type, callable only internally (or by the contract itself) should be added, which finds the first free custom_proposal_type ID and saves the payload there.

The constructor should be amended to accept and array with custom proposal configurations.

Carmine Options AMM DAO will allow for staking CARM token.

The process to get there is not a direct one, but it is not complicated.

This task assumes #46 is already implemented and accepted by the governance.

The task is to prepare a governance proposal that will create and issue new ERC20 token, called CARM, with 100mil max supply, 18 deximals. Within the proposal the token will not only be issued, but it will also have governance smart contract to be set the owner and governance will be updated so that it can handle the potential upgrades of the new token.

Description

The current airdrop_tests.cairo file contains quasi-broken tests, with many tests commented out. The goal is to make these tests functional. Reference the defispring repository, which contains a similar, tested contract developed based on the current airdrop contract.

Tasks

1. Uncomment and Fix Tests in airdrop_tests.cairo

2. Reference defispring Repository:

   • Use the defispring repository as a reference to understand the testing approach.
   • Ensure the tests in airdrop_tests.cairo exceed the robustness and coverage of those in defispring.

3. Generate Test Data Using carmine-api-airdrop:

   • Utilize the carmine-api-airdrop to create the Merkle tree and generate proofs.
   • Use this test data in the airdrop_tests.cairo.

Resources

• Airdrop Tests (quasi-broken): airdrop_tests.cairo
• Airdrop Component Code: airdrop.cairo
• Similar Tested Contract (defispring): defispring Repository
• Merkle Tree and Proof Generation: carmine-api-airdrop
• Test Cases Description: README
• Testing utils: https://github.com/CarmineOptions/konoha/blob/master/tests/setup.cairo

Acceptance Criteria

• All tests in airdrop_tests.cairo are uncommented, functional, and pass.
• Tests cover all specified cases in the README.
• Test data generated using carmine-api-airdrop is correctly integrated into the tests.
• scarb fmt

Please make sure to keep the testing structure consistent and ensure the tests are comprehensive and robust. Use functions from setup.cairo and do not duplicate them, extend if needed.

We need to add modular integration tests for Konoha that can be used to test deployed instances. This will make it easier for the protocols using it to verify Konoha is working correctly and to gain confidence upgrading it.

Tasks

• Create a new file tests/integration_tests.cairo with the following functions:
  • deploy_governance(classhash, token_recipient): Deploys the governance contract
  • upgrade(gov_address, tokenholders, new_classhash): Upgrades a governance contract to a new classhash
  • healthcheck(gov_address, tokenholders): Runs a series of checks on a deployed governance contract
• Create a new file tests/integration_test_runner.cairo that uses the above functions to test upgrading the current Konoha Sepolia deployment to the latest master

Pseudocode

tests/integration_tests.cairo:

fn deploy_governance(classhash, token_recipient):
    Deploy governance contract with given classhash and token recipient – use functions from setup.cairo here
    Return deployed contract address

fn upgrade(gov_address, tokenholders: Span<ContractAddress>, new_classhash):
    For each tokenholder:
        Vote to upgrade governance contract to new_classhash
    Assert that proposal passes, then:
        Apply the upgrade

fn healthcheck(gov_address, tokenholders):
    Submit new signal proposal
    Check proposal appears in get_live_proposals
    Verify get_proposal_details is correct
    For each tokenholder:
        Vote on the proposal
        Check get_vote_counts updates correctly
    Warp time and check that the proposal has passed

tests/integration_test_runner.cairo:

#[test]
#[fork("SEPOLIA")]
fn test_upgrade_sepolia_konoha():
    current_gov_address = 0x056dfcfa3c33c7a6852479f241f0cbbd2405791164754f16c0dcd90de13da059
    tokenholders = Array of Sepolia Konoha tokenholders – copy from https://sepolia.starkscan.co/token/0x02b91dd683bc4bcae7a9c5d0cbeba0e8d62fa657742e4640f1e8163dc10e9bd7#holders
    
    healthcheck(current_gov_address, tokenholders)
    
    new_classhash = declare current Governance.cairo 
    upgrade(current_gov_address, tokenholders, new_classhash)

    healthcheck(current_gov_address, tokenholders)

See the Contributor Guidelines for how to get started working on this issue.

This issue is WIP and needs review!

Create a treasury smart contract within Carmine Governance.

It has to be a separate smart contract, the reason so that funds will be easily distinguishable from security pool (we will have that down the line).

The Treasury smart contract will be fully managed by the governance. Expect most of the work will happen in the Governance smart contracts.

Treasury will contain many different ERC20 tokens and has to be able to manage that.

Required features (standardized proposals):

• Send money to address (specify receiver address, amount, token)
• Allow address to claim money (specify receiver address, amount, token)
• Allow treasury to provide liquidity to Carmine Options AMM liquidity pools, include withdraw functionality.

Feel free to comment on the expected proposals.

Currently, delegation doesn't work with staking at all. It needs to be redone to work with the new linear decay based staking (#113).

When counting adjusted voting power, votes from people who delegated to the voter should be counted too.

The adjusted voting power (including delegated votes) should be counted in such a way to not depend on the total number of people who delegated to the voter. (O(1) not O(n))

You should also have decreased voting power if you delegated your voting power.

Double-counting votes when undelegating should not be possible. (Once, the person you delegated to votes, then you undelegate, then you vote – the second vote should fail and vice versa.)

Definition of Done

Unit Tests Implementation

Implement unit tests for the following scenarios:

• Apply a passed proposal: Ensure a proposal marked as passed is correctly applied.
• Apply already applied proposal: Ensure the contract rejects reapplying a proposal that has already been applied.
• Apply failed proposal: Ensure the contract rejects applying a proposal that did not pass.
• Apply non-existent proposal: Ensure the contract rejects applying a proposal that does not exist.
  Integration Tests Implementation

Integration tests

• Successful contract upgrade: Simulate a successful contract upgrade via a passed proposal and verify the new implementation is in effect.
• Custom proposal execution: Simulate the execution of a custom proposal and verify the specified action is correctly performed.
• Revert on failed upgrade: Simulate an upgrade that should fail (e.g., due to invalid parameters) and verify the contract state is reverted to its pre-upgrade state.
• Event emission: Verify the appropriate events (Upgraded, etc.) are correctly emitted during successful and failed upgrade attempts.

Documentation and Contribution Guidelines

Ensure all new tests are documented and are formatted with scarb fmt.

Contribution Guidelines
Please refer to CONTRIBUTING.md for info on how to claim the task.

Note to Contributors:

Ensure you run all tests and verify their correctness before submitting your pull request.
Include detailed descriptions and comments in your code to explain the purpose and functionality of each test.
If you encounter any issues or have questions, feel free to open an issue or reach out to me in the Telegram group.
Thank you for your contributions!

Create a section of README with checklist that contains all the missing integration tests and missing unit tests.

The list should contain reasonable explanation of the tests - what is being tested and expected outcome.

This list will serve as a base for further issues.

Core proposal functionality should be documented from a usage/deployment perspective.

• various contract types
• adding custom proposals
• arbitrary proposals
• when do proposals pass, express proposal passing, the different quorums

Code documentation (to be generated in the future) is outside the scope of this task.

Extend treasury.cairo to support deposit and withdraw to/from ZkLend. support for multiple tokens (ETH, USDC, USDT, STRK, WBTC)

You can use the feature of depositing into Carmine liquidity pools in treasury.cairo as inspiration.

Definition of Done

The Cairo code works as expected, has nearly full test coverage, is reasonably documented (docstrings or similar suffice) and readable. An end-to-end integration test is provided.

This task is dependent on completing https://github.com/CarmineOptions/governance/issues/49

There may be some parties that should not contain a significant economic and voting power over the protocol but they may have significant amount of CARM.

These parties voting power and economic power should be limited:

• the limitation should be done per group of addresses
• there can be multiple such groups
• on voting and for these addresses the governance will check the total amount of veCARM issued and the amount given group has, in case the relative ratio exceeds the set limit it the voting power of the address will be set to this limit

Write a chapter of documentation as a markdown file in docs/ directory. One chapter = one component. First study the code, then document how to use it and how to customize it, if applicable. This documentation should be aimed at protocols looking to use Konoha and assume knowledge of Cairo Components.

Expected skill level: Junior Cairo developer

This issue can be assigned to multiple persons, multiple people can work on different parts of the docs in parallel.

Definition of Done

The documentation is clear, readable, not obviously written by AI, documents all available customizations when using the component and give simple usage instructions.

Assignment

This issue will be assigned to multiple contributors as each works on their own chapter.

Assigned so far:

• airdrop @Joy-Adah
• proposals @raizo07
• token @AnoukRImola
• vesting @more-of-odeh
• upgrades @Ayoazeez26
• treasury @fishonamos

Description

Extend the current React frontend to support viewing and adding comments to proposals. This involves fetching comment data from IPFS, displaying it, and allowing users to add new comments. The new comments will be submitted to IPFS via a backend service, and the resulting IPFS hash will be used to update the proposal on the blockchain.

Expected skill level: Junior Frontend Developer

Tasks

Frontend

1. Fetch Comments from IPFS:

   • Modify the Proposal component to fetch IPFS file hashes from the contract.
   • Download comment content from IPFS.
   • Display comments along with the submitter's address or Starknet.ID and their governance token balance.

2. Add Comments to Proposals:

   • Add a form to the Proposal component for submitting new comments.
   • On form submission, call the backend with the comment text.
   • Receive the IPFS file hash from the backend.
   • Prompt the user to confirm the transaction in their wallet to update the proposal with the new comment hash.

Pointers

Frontend Code

• Proposal Component:

  • File: frontend/src/components/Proposal.tsx
  • Modify to include fetching and displaying comments.
  • Add form for submitting new comments.

• New Proposal Form:

  • File: frontend/src/components/NewProposalForm.tsx
  • Reference for form handling and contract interaction.

Definition of Done

The frontend is fully static and ready to be deployed, is formatted according to VSCode Typescript Format command

See CONTRIBUTING.md for information on claiming the task and how to work.

Probably, this would receive Event webhooks from Apibara / Starkscan API and send notifications either through email or Telegram.

It would suffice for this to be a simple serverless microservice, it would be even better if this required no infrastructure setup at all.

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.

Create a fully static web app that allows users to add proposals and vote on current proposals. All data will be fetched via RPCs from the chain.

There are already some delegation functionalities in proposals.cairo, but they are commented out. Get them to work and add tests, see tests/README.md for description of required tests

Desktop

• Windows 11 pro
• Firefox browser

Issue
The "Connect Wallet" feature is only functional for one wallet (Braavos). The second wallet option (Argent) is not working and fails to establish a connection.

Steps to Reproduce

1. Open the website: https://konoha.vote/.
   2, Navigate to the "Connect Wallet" button located in the top-right corner of the page.
2. Click on the "Connect Wallet" button to open the wallet connection options.
3. Attempt to connect using the "Connect Argent" option.

Priority Level
High - This issue prevents users from connecting with the Argent wallet, which could significantly impact the user experience and limit the usability of the website for Argent wallet users.

Expected Result:
Both the "Connect Braavos" and "Connect Argent" wallet options should be functional and should successfully establish a connection.

Actual Result:
Only the "Connect Braavos" option is functional. The "Connect Argent" option fails to establish a connection and is not working.

Recommendation:
Address this issue to ensure that both wallet connection options are functional.

This backend receives the text of a proposal, the address of the proposee and converts the address to starknet.id if available. Then it creates a JSON with these two (or three if the submitter has a starknet.id) pieces of info and submits it to IPFS. Once the IPFS hash is computed, it should be returned to the caller. Then the backend uploads it to IPFS and pins it with a pinning API or your choice.

Expected skill level: Junior Backend developer

Definition of Done

The backend is written in one of Python, Typescript, Rust, Go. The code is formatted correctly and is ready to be deployed. It has been tested, either with the frontend if available or with curl or similar. The backend returns the IPFS hash before the upload is finished and finishes the upload asynchronously. The code has been reviewed by someone from Carmine Finance.