Skip to content

2.0/rc#14

Closed
rayedsikder wants to merge 81 commits intomainfrom
2.0/rc
Closed

2.0/rc#14
rayedsikder wants to merge 81 commits intomainfrom
2.0/rc

Conversation

@rayedsikder
Copy link
Member

No description provided.

- Rename `s_selectedPlatformHash` to `isSelectedPlatform
- Add mapping s_isApprovedPlatform
- Rename `s_approvedplatformHash` to `s_approvedPlatformHashes`
- Remove event `CampaignInfoPlatformSelected`
- Add error `CampaignInfoPlatformAlreadyApproved`
- Add view function `checkIfPlatformApproved`
- Improve validations, and replace && logic with ||
- Fix updateGoalAmount() logic
- Add restriction to not allow already approved platform to be updated
- Reset fees to 0 when platform is no longer a selected platform in `updateSelectedPlatform`
- Add check in `_setPlatformInfo` to not allow setting platform info more than once
- Update mapping for `s_isApprovedPlatform` in `_setPlatformInfo`
- Remove redundant validation `platformIsListed`and `ZERO_BYTES` check in `getPlatformDataOwner`
- Remove redundant validation `platformAdminAddress` in `enlistPlatform`
- Optimize logic and remove redundant validation of `s_platformDataOwner` comparison
- Optimize validation in `removePlatformData`
mahabubAlahi and others added 29 commits May 26, 2025 13:18
- Add indexing for selected events
- Remove redundant storage variable
- Reorder _pledge function
   - Perform all checks first
   - Update state variables
   - Only then interact with external contracts (TOKEN transfer)
- Remove unnecessary storage use
- Shift fee calculation from withdraw to pledge
- Add new fee calculation logic
- Block disburseFee functionality till refund period is over
- Add campaign owner support for updating deadline and goal amount
- Adjust claim refund and withdraw function according to the changes
- Add support for setting the payment gateway fee by the platform admin
- Add a facade function `setFeeAndPledge` to combine fee setting and pledge for the platform admin
- Update pledge functionality to accommodate payment gateway fee calculation
Co-authored-by: mahabubAlahi <mahabub@ccprotocol.xyz>
- Key Features
  - Core Architecture

    - `ICampaignPaymentTreasury` - Interface defining the payment treasury contract standards
    - `BasePaymentTreasury` - Abstract base contract with shared treasury functionality
    - `PaymentTreasury` - Concrete implementation with campaign-specific logic
    - `Modular Design` - Inherits from `CampaignAccessChecker` and `PausableCancellable` for access control and state management

  - Payment Management

    - `Payment Creation`: Secure payment creation with expiration timestamps
    - `Payment Confirmation`: Batch and individual payment confirmation system
    - `Payment Cancellation`: Administrative payment cancellation with amount tracking
    - `Expiration Handling`: Automatic validation of payment expiration times

  - Treasury Operations

    - `Fund Tracking`: Separate tracking of pending, confirmed, and available payment amounts
    - `Refund System`: Comprehensive refund processing for confirmed payments
    - `Fee Distribution`: Automated protocol and platform fee calculation and disbursement
    - `Withdrawal Management`: Controlled fund withdrawal after fee disbursement

- Implementation Details
    - State Management
```JS
struct PaymentInfo {
    address buyerAddress;
    bytes32 itemId;
    uint256 amount;
    uint256 expiration;
    bool isConfirmed;
}
```

  - Key Storage Variables

    - `s_pendingPaymentAmount` - Total amount in pending payments
    - `s_confirmedPaymentAmount` - Total amount in confirmed payments
    - `s_availableConfirmedPaymentAmount` - Available amount after fee deductions
    - `s_feesDisbursed` - Flag tracking fee disbursement status

- Core Functions
  - Payment Operations

    - `createPayment()` - Create new payments with validation
    - `cancelPayment()` - Cancel individual payments
    - `confirmPayment()` - Confirm individual payments
    - `confirmPaymentBatch()` - Batch payment confirmation for gas efficiency

- Treasury Operations

    - `disburseFees()` - Calculate and distribute protocol/platform fees
    - `withdraw()` - Withdraw remaining funds after fee disbursement
    - `claimRefund()` - Process refunds for confirmed payments
    - `getAvailableRaisedAmount()` - Get the current available treasury balance

- Administrative Functions

    - `pauseTreasury()` - Pause treasury operations
    - `unpauseTreasury()` - Resume treasury operations
    - `cancelTreasury()` - Cancel treasury (platform admin or owner)

- Technical Features
  - Access Control

    - `Platform Admin Controls`: Payment creation, confirmation, cancellation
    - `Owner Controls`: Treasury cancellation permissions

- Error Handling

    - `PaymentTreasuryInvalidInput` - Invalid function parameters
    - `PaymentTreasuryPaymentAlreadyExist` - Duplicate payment ID
    - `PaymentTreasuryPaymentAlreadyExpired` - Expired payment operations
    - `PaymentTreasuryFeeNotDisbursed` - Withdrawal before fee disbursement
    - `PaymentTreasuryUnAuthorized` - Access control violations

- Testing Coverage

    - `Unit Tests`: Individual function testing with edge cases
    - `Integration Tests`: End-to-end payment and treasury workflows
    - `Access Control Tests`: Permission and authorization validation
    - `State Management Tests`: Pause/cancel state transitions
    - `Fee Calculation Tests`: Accurate fee distribution verification

---------

Co-authored-by: mahabubAlahi <mahabub@ccprotocol.xyz>
Co-authored-by: AdnanHKx <adnan@ccprotocol.xyz>
* Fix incorrect description of the `claimFund` function (#6)

  (immunefi)(issue#06)
  - Updated the NatSpec comment for claimFund()

* Refactor `platformDataKey` parameter validation optimization (#7)

  (immunefi)(issue#09)
  - Move `platformDataKey` parameter validation to an earlier stage of the `createCampaign` flow

* Add configuring platform data during `updateSelectedPlatform` (#8)

  (immunefi)(issue#10)

* Add creator's non-zero validation during `createCampaign` (#9)

  (immunefi)(issue#16)

* Add zero validation for `platformDataValue` in `createCampaign` (#10)

  (immunefi)(issue#12)

* Add reward value zero validation in pledge (#11)

  (immunefi)(issue#14)

* Fix `updateDeadline` allowing past deadline that blocks `claimRefund` (#12)

  (immunefi)(issue#05)
  - Added check to ensure new deadline is after current block timestamp

* Fix blocking KeepWhatsRaised pledge functions via front-running (#13)

  (immunefi)(issue#04)
  - Add internal pledge ID generation using msg.sender and pledgeId

* Add fee configuration via configure treasury (#14)

  (immunefi)(issue#11)
  - Update configure treasury to support fee values
  - Add getter function for fee value

* Add campaign data validation in configure treasury (#15)

  (immunefi)(issue#20)
  - Update fee values js doc
  - Update custom error

* Fix Gateway fee bypass (#16)

  (immunefi)(issue#19)
  - When `setFeeAndPledge` is called, tokens are transferred from the admin's wallet (msg.sender)
  - When `pledgeWithoutAReward` or `pledgeForAReward` is called directly, tokens are transferred from the backer's wallet

* Add expected fee description in create campaign jsdoc (#17)

  (immunefi)(issue#03)

* Refactor withdrawal and pledge calculation (#19)

  (immunefi)(issue#15)
  (immunefi)(issue#18)

  - Restrict access to the withdrawal function so that only the campaign owner and platform administrator can use it.
  - Move the protocol fee calculation from the withdrawal process to the pledge stage.
  - For withdrawals:
    - Partial Withdrawals:
       - Conditions: amount > 0 and amount + fees ≤ available balance.
       - The creator must specify the exact withdrawal amount, and the system will ensure there are sufficient funds to cover both the withdrawal and the fees.

    - Final Withdrawals:
      - Conditions: available balance > 0 and fees ≤ available balance.
      - The creator can withdraw the entire remaining balance. The system will check if there are enough funds to cover the fees and will then provide the remainder to the creator.

---------

Co-authored-by: mahabubAlahi <mahabub@ccprotocol.xyz>
…ipts (#20)

* Update test files for KeepWhatsRaised treasury
  - Remove platformData setup and switch to empty arrays for the new treasury flow
  - It accommodates a new fee storage flow

* Update KeepWhatsRaised deployment script

* Update address(this) to deployerAddress in the AllOrNothing deploy script to avoid deployment compatibility issues with newer versions of forge
* Refactor buyer address with buyer id in payment (#25)

* Refactor buyer address with buyer id in payment

* Fix payment treasury tests

* Update payment and refund

- Add support for crypto payment
- Add direct claim refund for buyer

* Fix the disbursement fee and withdrawal functionality

- Add support for multiple withdrawals with perfect fee disbursement

* Fix potential payment ID collusion part

* Add input validation to `claimRefund` function in PaymentTreasury

* Update `claimRefund(paymentId)` in payment treasury

- Add support for a platform admin who can call claimRefund on behalf of buyers
- Update the jsdoc
- Leverage this claim refund function in the payment treasury contract

* Fix redundant fee disbursement logic

* Add payment management function overrides to PaymentTreasury

- createPayment
- createCryptoPayment
- cancelPayment
- confirmPayment
- confirmPaymentBatch

* Refactor `createCryptoPayment` function name to `processCryptoPayment`

- Better reflects the immediate processing and confirmation of crypto payments

* Refactor withdraw and disburseFee in payment treasury

* Add extra validation to `claimRefund` in payment treasury
Co-authored-by: AdnanHKx <adnan@ccprotocol.xyz>
* Add phantom balances fix and additional unit tests

* Add batch payment gas test script

* Gas optimization for batch payment
- Consolidate the transfer of protocol admin rights to ensure ownership is correctly assigned to final addresses.
- Update logging to provide clearer output regarding ownership transfers for GlobalParams and CampaignInfoFactory.
- Change environment variable name from TEST_USD_ADDRESS to TOKEN_ADDRESS for consistency across scripts.
* Add multi-token support

* Update deployment and test scripts, fix decimal normalization issue in reward and fee calculation

* Make core contracts UUPS upgradeable with namespaced storage layout

* Update documentation

* Update solc and OpenZeppelin lib versions, fix ERC7201 storage location hashes and implement Context pattern

* Add OpenZeppelin upgradeable contracts submodule

- Added a new submodule for OpenZeppelin upgradeable contracts to the project.
- Updated .gitmodules to include the path and URL for the new submodule.

* Refactor storage implementation for core contracts

- Introduced dedicated storage libraries for AdminAccessChecker, CampaignInfoFactory, GlobalParams, and TreasuryFactory to utilize ERC-7201 namespaced storage.
- Updated contract methods to access storage using the new library functions, enhancing modularity and maintainability.
- Removed inline storage definitions from contracts to streamline code and improve clarity.

---------
Co-authored-by: AdnanHKx <adnan@ccprotocol.xyz>
Co-authored-by: Mahabub Alahi <mahabub@ccprotocol.xyz>
…ntTreasury (#34)

* Update environment configuration and add Celo Sepolia RPC endpoint

* Add CELO_SEPOLIA_RPC_URL to env.example for new network support
* Update foundry.toml with celo_sepolia RPC endpoint

* Add batch payment functionality to PaymentTreasury

- Introduced `createPaymentBatch` method in `ICampaignPaymentTreasury` interface for creating multiple payment entries in a single transaction.
- Implemented the `createPaymentBatch` function in `PaymentTreasury` and `BasePaymentTreasury` with necessary validations and event emissions.
- Added unit tests for batch payment creation, including scenarios for input validation and error handling.

* Add payment token support in batch payment functionality

- Updated the `createPaymentBatch` method in `ICampaignPaymentTreasury` to include an array of payment tokens.
- Modified the implementation in `PaymentTreasury` and `BasePaymentTreasury` to handle payment tokens, including necessary validations.
- Enhanced unit tests to cover scenarios with multiple payment tokens and validate token acceptance during payment creation.

* Add DataRegistryKeys and DataRegistryHelper contracts

- Introduced `DataRegistryKeys` library for centralized storage of dataRegistry keys, ensuring consistency and preventing key collisions.
- Added `DataRegistryHelper` abstract contract to facilitate access and validation of dataRegistry values from `GlobalParams`, including a method to retrieve the buffer time.

* Add TimeConstrainedPaymentTreasury contract

- Introduced `TimeConstrainedPaymentTreasury` contract that extends `BasePaymentTreasury`, incorporating time-based constraints for payment operations.
- Implemented functions to check time validity before creating, processing, and confirming payments, ensuring actions are only allowed within specified timeframes.

* Add integration and unit tests for TimeConstrainedPaymentTreasury

- Introduced integration tests for `TimeConstrainedPaymentTreasury`, covering payment creation, processing, cancellation, and time constraint validations.
- Added unit tests to ensure correct behavior of payment operations within specified timeframes, including batch payment functionality and edge cases.
- Implemented helper functions for setting up test scenarios, including funding users and managing time constraints.
- Enhanced test coverage for refund claims, fee disbursement, and withdrawal operations, ensuring compliance with time constraints.

* Update environment configuration by removing Alfajores references

- Removed Alfajores RPC URL and chain ID from env.example to streamline configuration.
- Updated foundry.toml by removing the Alfajores RPC endpoint, reflecting the current network support.
* Add time constraints for campaign creation

* Fix unauthorized caller issue in tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants