Description

We do not want protostar releases to impact our CI (and our tests).

Suggested Evolution

We need to specify a fixed version of protostar to counter the current behavior of the install.sh script which installs the latest release.

Acceptance Criteria

• When I set an oldest protostar version localy, it installs the spcified version (returned by protostar --version)

Additional context

A feature is provided by protostar in their install.sh script (source)

Description

Define and Design the Carbonable Offseting Certificate.

Questions

• Which kind of Token ? (ERC-721, ERC-1155, ERC-3525, etc...)
• How is digitalized the offset certificate of the certifier ?
• Which data need to be on-chain ? off-chain ?
• Where do we store the documents / information ? (IPFS, other ?)

Acceptance Criteria

• All the questions need to be answer
• An exhaustive list of metadata must be provided (on-chain AND off-chain)
• The UI of the Carbonable certificate need to be done on Figma

Collect and adapt the script from starkvest to ease the deployment.

Note: assign to Bal7hazar

• add a function in the smart contract to set the merkle root, callable only by owner
• remove mapping storage
• split the buy function in 2 functions, one for the public buy and one for the whitelisted buy. The reason is that they will take different arguments, the whitelisted buy needs the merkle proof
• handle the verification of the merkle proof (see also cairo-merkle-distributor)

Requirements: benchmark data storage costs from other projects to evaluate the opportuniy

Note: If we decide to keep living with the current situation, we may need to add a remove_from_whitelist option to keep data as clean as possible and avoid sybil.

Opportunity: By default the storage var of the merkle root will be 0 until an update of the root, we could use this behavior to trigger the fact that the pre-sale is open.

Description

Implement the retrieve of NFTs from a Farming Project Pool during the unlock period

Rules

• Rule: A Carbonable NFT can be retrieved only from a Yield farming OR an Offset farming pool per period
• Rule: The granularity in the Yielder is 1 Carbonable NFT

Acceptance Criteria

• Implement the Rules
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Description

Pausable feature can be useful to freeze a contract under attack for instance.

Acceptance Criteria

• Relevant contracts can be pausablle

Description

Implement the deposit of NFTs, received after funding a Project, in a Farming Project Pool.

Deposit one NFT by one NFT.

Rules

• Rule: A Carbonable NFT can be deposit only in a Yield farming OR an Offset farming pool per period
• Rule: The granularity in the Offseter is 1 Carbonable NFT

Acceptance Criteria

• Implement the Rules
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

In the current version it misses protostar install before the compilation topic

• add a function in the smart contract to set the merkle root, callable only by owner

To improve the process and avoid errors, we should try to add the deployment directly in a github action.

Note: we could use github variables to handle protostar version also (improvement of #51)

Benchmark from other starknet projects to see what and how it is done outside.

Libraries

• cairomate: a bit outdated but logic remains
• astraly: very complete

Benchmark vaults (ERC-4626)

Sources:

• https://eips.ethereum.org/EIPS/eip-4626

cairomate: a bit outdated but logic remains
astraly: very complete

Known Cairo Implementations:

• koloz192
• auditless
• milancermak

Description

To ensure consistency between Github repos of Carbonable, a common Github process and setup must be created.
This PR add configuration files of Issues Template and specifics Labels for the Issues

Acceptance Criteria

• List of Issues Template when creating a new Issues.
• List of Labels in Issues tab corresponding to teh labels in carbonable_labels.json

Description

Implement the deposit of NFTs, received after funding a Project, in a Farming Project Pool.

Rules

• Rule: A Carbonable NFT can be deposit only in a Yield farming OR an Offset farming pool per period
• Rule: The granularity in the Yielder is 1 Carbonable NFT

Acceptance Criteria

• Implement the Rules
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Description

IPFS data have been reupdated with a carbonable shared account.
IPFS links in assets must be changed accordinly.

Description

To prepare the final deployement we need to chose the latest assets

What code could be improved?

assets/badges

To handle the case where some reserved spots won't be minted due to unexpected events (such as B2B withdrawal).

As an admin, we want the ability to move some slots from reserved supply into public supply.

To proceed, we need to be able to decrease the reserved supply (only decrease).

Three scenarios:

1. 🎉

set_reserved_supply_for_mint(reserved_supply_for_mint : felt)

Which fails if the new reserved_supply_for_mint is ge to the stored one

Note: less explicit name, easier to use since math are done by the contract

2. ❤️

decrease_reserved_supply_for_mint(slots : felt)

Which fails if slots is gt than the stored one

Note: more explicit name, admin needs to ensure math before the usage

3. 🚀

set_decreased_reserved_supply_for_mint(reserved_supply_for_mint : felt)

Which fails if the new reserved_supply_for_mint is ge to the stored one

Note: name too long?

With the current state, there is not way for the contract to know if the user has already minted his whitelisted slots or not, allowing the user to mint his slots as much as he wants.

To fix this situation we need a storage variable storing how many slots a user has already minted.
This information is then compared during the whitelist buy to ensure user to not mint more than his whitelisted slots.

Note: with this fix, the gas used to store values are spread by user (which is different from the initial situation where the contract has to setup the whole map before the whitelist sale)

With the current situation, and because NFT project is defined in the constructor of the Minter contract, we have to deploy a new minter contract for each NFT projects.

Allowing to change the nft contract address in the Minter contract will make it reusable for each new projects.

Note: If we decide to implement it, we have to be very careful to reset the merkle root (set to 0, as the initial state of the storage var) to "reset" the whitelist. This reset must be called each time a new NFT project address is set to reduce the risk.

EDIT:

This behavior could also be conflictual with the fact than the token owners can burn their token using the native burn ERC-721 function.

Doing a burn will result in decrease the total_supply and then allow the minter contract to mint a brand new token.

However, this ability will be available only until the minter contract is linked to the NFT contract if we implement this feature.

I don't understand why the following code is actually working:

Here is the IERC20 contract from openzepplin depencency:

@external
func transferFrom{
        syscall_ptr : felt*,
        pedersen_ptr : HashBuiltin*,
        range_check_ptr
    }(
        sender: felt,
        recipient: felt,
        amount: Uint256
    ) -> (success: felt):
    ERC20.transfer_from(sender, recipient, amount)
    return (TRUE)

And here is a call of the transferFrom function from here in the mint contract regarding the payment during the buy function.

# Do ERC20 transfer
let (transfer_success) = IERC20.transferFrom(
    payment_token_address, caller, contract_address, amount
)

So basically there are 4 arguments provided where IERC20 expects 3, but actually tests works so I'm probably misunderstanding something.

Description

Implement a function which:
Give the percentage (%) of Carbon Credit of a Project, for a given address, is entitled to receive for the current period.

This function calculates the number of NFTs deposited by the address and returns the amount of Carbon Credit it will receive for this period for this Project.

Acceptance Criteria

• Implement the function
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Whitelist sale open argument is not more required during the deployement of the minter contract.

Deploy script must be adapted accordingly.

In the current version, payment token is provided to the constructor and cannot be modified later (the only way is to deploy a new contract).

To ensure the contract to not be impacted by any external news regarding which payment token we choose, we could add a setter to let the owner chose to change the payment token at any time.

Note sure if there is any political reason to not do this.

Description

As a dev I want to have a doc generated from code

Suggested Documentation

Code relationships : https://github.com/FuzzingLabs/thoth
Doc generator : https://github.com/onlydustxyz/kaaper

Acceptance Criteria

• Doc is generated through a CI job
• Doc is hosted on github pages

Description

Implement the Starkvest Smart Contract to "Claim" the Yield reward (in Stablecoin) for an address.

Acceptance Criteria

• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

excalidraw - Farming Interface Claiming

Description

Implement a function to return the number of NFTs locked for a project to be Yield.

Acceptance Criteria

• Implement the function
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

• implement script to generate the merkle tree and the root from a JSON whitelist (each leaf is the concatenation of the address and the number of whitelisted slots)
• implement CLI tool to add whitelist entries in a JSON file
• implement a library to generate the merkle proof from: address, number of slots and merkle tree

Technology:

• JS as much as possible to be usable by the front, here a sample allowing to manage the hashing method (which must match the cairo way to verify prooves).
• Python else

Description

Upgrade Starkvest contract into Cairo 0.10.1

Acceptance Criteria

• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Proposition

The propopsition is mainly motivated by the growth of new features and SOC.
Since we are adding more and more contracts and features, it could be interesting to refactor tests.

Integration tests

Integration tests focus on nominal usages by default, this is what aim the test_nominal_cases files of each contract.

We also want to test specific behaviors by chaining actions between contracts, this will be the purpose of the test_specific_cases file of each contract.

Notes:

• I think protostar generate a single instance of what the __setup__ returns for each test files which could slow down tests and increase memory usage
• we need to check how to factorize the __setup__ cheatcode

Unit tests

Unit tests focus on the nominal cases and expect revert tests, since several tests are required per new functionnality (according to the number of exception raised by the function), there is an opportunity to spread tests per functionnality.

Note: A new library.cairo file could store shared code (as the one in the integration tests).

Folder structure diagram

tests/
├── integrations/
│   ├── library.cairo
│   ├── minter/
│   │   └── test_nominal_cases.cairo
│   │   └── test_specific_cases.cairo
│   ├── yielder/
│   │   └── test_nominal_cases.cairo
│   │   └── test_specific_cases.cairo
│   ├── .../
├── mocks/
│   └── erc20.cairo
├── units/
│   ├── library.cairo
│   ├── minter/
│   │   ├── test_decrease_reserved_supply_for_mint.cairo
│   │   ├── test_...
│   │   ├── test_airdrop.cairo
│   │   ├── test_whitelist_buy.cairo
│   │   └── test_public_buy.cairo
│   ├── yielder/
│   │   └── test_...

• Create integration tests (benchmark from starkvest) for the mechanism and reproduce the same scenarios that unit tests.

Description

Implement Locking and Unlocking Period for Farming Project Pool.

Rules

• Rule: When a Farming pool period start, Users can NOT retrieve their Carbonable NFT until they are unlock by the Yield farming pool
• Rule: before the end of the current period, User can claimed their Carbonable NFT
• Rule: If User does NOT claim their Carbonable NFT of the current period, the same configuration will be apply for the next period for this Farming Project Pool

Acceptance Criteria

• Implement the Rules
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

Add any other context or screenshots about the feature request here.

Description

Implement the Certificate Smart Contract to "Claim" the Offset Certificate as Proof of Offseting

Acceptance Criteria

• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Description

Implement the farming feature.
Implement according tests.

Acceptance Criteria

• Old tests keep woring
• New tests work

• add a number of reserved slot for aidrop (manage another storage var to handle this reserved slots number, don't forget to take it into account while buying)
• add airdrop function, callable only by owner, with parameters: quantity, recipient. Something like:

func airdrop{syscall_ptr : felt*, pedersen_ptr : HashBuiltin*, range_check_ptr}(
    to : felt, quantity : felt
) -> (success : felt):
    ...
    something similar to buy function wihtout ERC20 transfers
    ...
    call mint_n
    ...
    transfer from owner to to
    ...
end

• add missing withdraw function
• add corresponding unit test and add a step in the e2e test

Description

Implement a function, for an address, to trigger the Offseting of his Carbon Credit.

Questions

• The address need to Offset for each of his project ?
• Can we trigger the Offseting for all the Projects in the same time ?

Acceptance Criteria

• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Description

A 0.10 version has been released, we need to upgrade our contracts accordingly.

What code could be improved?

All cairo files.

Acceptance Criteria

• Tests works with latest Cairo version.

Additional context

• Release note with script to migrate: https://github.com/starkware-libs/cairo-lang/releases/tag/v0.10.0
• Prerequisites: OZ migration, Protostar migration.

Description

Implement the retrieve of NFTs from a Farming Project Pool during the unlock period

Rules

• Rule: A Carbonable NFT can be retrieved only from a Yield farming OR an Offset farming pool per period
• Rule: The granularity in the Yielder is 1 Carbonable NFT

Acceptance Criteria

• Implement the Rules
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Since the future stacking contract will probably need information about NFT metadata, we will need to have these information on chain and linked to the ERC-721 collection.

Proposition:

A struct that handle attributes

struct Metadata:
    member image_url : felt*
    member external_url : felt
    member description : felt*
    member name : felt*
    member holder : felt*
    member certifier : felt*
    member country : felt*
    member expiration : felt
    member background_color: felt
    member animation_url: felt*
    member background_color: felt*
    member youtube_url: felt*
end

A variable storage to store the metadata

@storage_var
func metadata() -> (res : Metadata):
end

A view for each attribute

@view
func image_url() -> (res : felt*):
end

@view
func external_url() -> (res : felt):
end

All attributes set once in the constructor.

Note: source to existing metadata (Juno contracts)

EDIT - Benchmark about long string management in cairo

• https://github.com/topology-gg/caistring
• https://github.com/sekai-studio/starknet-libs/tree/main/src/sekai_libs/string
• https://github.com/CairOpen/cairopen-contracts

According to the #45 PR, we will need to set up all metadata settings into the carbonable project before the ownership transfer.

Inputs could be set in the deploy config file to be updated easily.

EDIT : add an option to avoid to transfer the ownership from admin to minter, such as --no-transfer

In the current situation all deployed contracts are owned by the admin address, therefore we have to manually transfer the ownership of the nft contract from admin to minter contract.

Using starknet invoke we should be able to handle thise automatically after deployments.

Description

Implement a function to return the number of NFTs locked for a project to be Offset.

Acceptance Criteria

• Implement the function
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Description

A new version of protostar has been released, we must upgrade it.

What code could be improved?

Github workflows mainly

Acceptance Criteria

• CI test keeps working

Description

Implement a function which:
Give the percentage (%) of share of a Project, for a given address, is entitled to receive for the current period.

This function calculates the number of NFTs deposited by the address and returns the amount of share it will receive for this period for this Project.

Acceptance Criteria

• Implement the function
• Implement unit tests for each functions
• Implement integration tests for each functions
• If needed, write the documentation associated with the functions and events exposed

Additional context

excalidraw - Farming schema

Description

To secure ownership transfer, we can add a feature to ask the new owner to accept the ownership before processing the transfer.

Feature: OpenZeppelin!505

Acceptance Criteria

• Relevant smart contracts adopts the new feature.

Description

To reward community, we want to propose on chain status such a badges.

We are going to use ERC-1155 to support badges.

Acceptance Criteria

• As a user I can receive/mint (TBD) as badge for a duty.

Additional context

• ruleslabs a direct implementation of the standard.
• Astraly
• dewi-tim

• deployment script
• deploy everything to Goerli

Description

With the new Cairo 0.10.0 we have to update our smart contract code to keep up-to-date.

Because we will have to go through all the code, it could be a good opportunity to refactor additionnal code according to latest guidelines.

Upgrade the following deps:

• openzeppellin v0.4.0
• protostar v0.5.0

Few ideas:

• Move protostar version from secrets to job env (to avoid to have failing CIs in PRs)
• Add unit_256 checks for all Uint256 inputs (see function in OZ ERC-1155)
• Re-entrancy security improvment (guard feature when interfaces are used in contracts)
• Check-Effect-Interaction compliance when transfer ERC-20 tokens
• Constructor to Initializer for libraries
• _iter suffix for loops
• Move owner assertions from library to contracts

What code could be improved?

All cairo files and python files (Cairo 0.10.0 also change python version from 3.7 to 3.9)

Acceptance Criteria

• Tests on refactored code succeed
• Deployements on refactored code succeed

Additional context

OZ released a new version of their contracts according to the new cairo version.
A new version of protostar has been released supporting cairo version.

We need a new release of Cairopen before the migration.

A 0.3.1 protostar version has been released which makes our tests fail.

Description

Market places need contractURI view to display collection metadata

Acceptance Criteria

• Collection images (banner and image) are displayed correctly on marketplaces