Open
Conversation
…ing investment amounts - Introduced the KARMA contract as a soulbound points token. - Implemented minting functionality restricted to addresses with MINTER_ROLE. - Added pausable features with roles for pausing and unpausing the contract. - Enforced soulbound transfer restrictions to prevent wallet-to-wallet transfers. - Included error handling for invalid admin and mint inputs.
…, burning, pausing, and access control - Introduced a new test suite for the KARMA contract to validate core functionalities. - Implemented tests for constructor behavior, minting and burning operations, and role-based access control. - Ensured proper handling of edge cases, including reverts for invalid operations and role restrictions. - Verified the soulbound nature of the token by testing transfer restrictions.
0xrafasec
requested review from
Suvadra-Barua,
rana-ccp,
rayedsikder and
sania-ccp
rayedsikder
requested changes
Feb 24, 2026
Member
rayedsikder
left a comment
rayedsikder
left a comment
There was a problem hiding this comment.
I think the mint function should be manually callable rather than minting automatically. The token contract should track how much has been raised, and then allow points to be redeemed by the platform admin (i.e., the Karma wallet).
…d amount retrieval - Introduced the IKarmaTreasury interface to facilitate reading the total raised amount for token claims. - Included a function signature for getRaisedAmount() to return the total raised amount as a uint256 value. - This interface will be utilized by the KARMA contract to manage token claims effectively.
… and token claiming functionality - Introduced a treasury address to manage claims based on raised amounts. - Added functions to set the treasury and claim tokens, ensuring only valid operations are executed. - Implemented events for treasury updates and token claims to enhance transparency. - Included error handling for scenarios where the treasury is not set or no tokens are available to claim.
- Introduced a mock treasury contract to facilitate testing of token claims based on raised amounts. - Implemented various test cases to validate the claimTokens function, including scenarios for invalid inputs, treasury management, and event emissions. - Ensured comprehensive coverage for edge cases, such as reverts when the treasury is not set or when claims are made to the zero address. - Verified that the total minted amount against raised funds starts at zero and increments correctly with valid claims.
Collaborator
Author
Adjusted as requested. 💯 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey @rayedsikder, I'm opening an initial PR for the discussion Rayed and I had about the KARMA token, which will be used as points and later burned to convert into $OAK.
@rayedsikder I'm leaving the part on how it will be minted for us to discuss. I don't know if you want to proceed here. For me, what makes more sense is for the treasure to call the function in the contract, to be atomic. But I didn't find that within our scope, and it would require extra development.
Waiting for your feedback on the SC and input on this and other things that may come up.
For those also reviewing, some content:
The flow would be:
Karma transfer to bridge $100,000 -> Bridge transfer to Treasure contract $100,000 minus taxes -> Mints 100,000 KARMA tokens.
Later:
100,000 KARMA tokens are burned to be X% of $OAK tokens
PS: I'm sending to
mainbecause I didn't know which was the valid one to fork. I created the contract and test. If we integrate with other contracts, I can create the integration test too.Cheers!