Skip to content

Allow bypassing referrer fee in all donation scenarios#400

Merged
akaia-shadowfox merged 5 commits intostagingfrom
399-allow-bypassing-referrer-fee-in-all-donation-scenarios
Jun 2, 2025
Merged

Allow bypassing referrer fee in all donation scenarios#400
akaia-shadowfox merged 5 commits intostagingfrom
399-allow-bypassing-referrer-fee-in-all-donation-scenarios

Conversation

@akaia-shadowfox
Copy link
Copy Markdown
Collaborator

@akaia-shadowfox akaia-shadowfox commented Jun 2, 2025

Summary by CodeRabbit

  • New Features

    • Added the ability to bypass referral fees when making donations and matching pool contributions, with new checkboxes and updated UI to reflect this option.
    • Referral fee bypass is now supported in both donation and matching pool contribution forms and summaries.
  • Improvements

    • Increased the default precision for displaying fractional amounts in token conversions.
    • Reordered the display of referral fees in donation summaries for improved clarity.
    • Enhanced fee breakdown calculations for greater accuracy and configurability.
    • Improved form structure and UI consistency in matching pool contribution modals.
    • Updated profile ownership detection to require user sign-in.
  • Bug Fixes

    • Disabled token selection when updating an existing campaign to prevent unintended changes.
  • Chores

    • Cleaned up unused imports and improved code readability in several components.
  • Documentation

    • Updated environment example comments for clarity.

@akaia-shadowfox akaia-shadowfox self-assigned this Jun 2, 2025
@vercel
Copy link
Copy Markdown

vercel Bot commented Jun 2, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
potlock-next-app ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 2, 2025 6:29pm

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jun 2, 2025

Walkthrough

This update introduces explicit handling and bypass options for referral fees in donation and matching pool contribution flows, refines campaign form token selection logic, and improves fee calculation consistency. Several schema and hook types are extended for new fields, and UI components are updated to reflect these changes. Minor improvements to form structure and profile ownership logic are also included.

Changes

File(s) Change Summary
.env.example Updated comment markers from ##? to ##* for certain sections; no functional changes.
src/common/lib/format.ts Increased default fractional digits in indivisibleUnitsToFloat from 2 to 4.
src/entities/campaign/components/CampaignForm.tsx,
src/entities/campaign/hooks/forms.ts
Campaign form now explicitly handles ftId, improves token selection logic, and updates hook parameter types.
src/features/donation/components/modal-confirmation-screen.tsx,
src/features/donation/components/summary.ts,
src/features/donation/components/single-recipient-success.tsx
Added/refined fee bypass options, reordered referral fee in summary, cleaned up imports and variable names.
src/features/donation/hooks/breakdowns.ts Refactored fee breakdown logic, added bypassReferralFee, improved calculation consistency, updated storage fee approximation.
src/features/donation/hooks/form.ts,
src/features/donation/models/schemas.ts
Added bypassReferralFee field to donation form schema and logic.
src/features/matching-pool-contribution/components/MatchingPoolContributionModal.tsx,
src/features/matching-pool-contribution/hooks/forms.ts,
src/features/matching-pool-contribution/model/schemas.ts
Added bypass option and logic for referral fee, refactored form handling, updated schema and types.
src/layout/profile/components/summary.tsx Tightened profile ownership check to require viewer sign-in.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant DonationForm
    participant FeeBreakdownHook
    participant WalletSession

    User->>DonationForm: Fill form (amount, bypass options)
    DonationForm->>WalletSession: Get referrerAccountId
    DonationForm->>FeeBreakdownHook: Pass amount, bypassProtocolFee, bypassReferralFee, referrerAccountId
    FeeBreakdownHook-->>DonationForm: Return fee amounts (protocol, referral, etc.)
    DonationForm-->>User: Show fee breakdown with bypass options
    User->>DonationForm: Submit
    DonationForm->>Backend: Submit donation with selected bypass options
Loading
sequenceDiagram
    participant User
    participant MatchingPoolForm
    participant FeeCalculation
    participant WalletSession

    User->>MatchingPoolForm: Fill form (amount, bypass fee checkboxes)
    MatchingPoolForm->>WalletSession: Get referrerAccountId
    MatchingPoolForm->>FeeCalculation: Pass amount, bypassReferralFee, bypassProtocolFee, etc.
    FeeCalculation-->>MatchingPoolForm: Return calculated fees
    MatchingPoolForm-->>User: Show updated fee breakdown
    User->>MatchingPoolForm: Submit
    MatchingPoolForm->>Backend: Submit contribution with bypass flags
Loading

Possibly related PRs

  • PotLock/potlock-nextjs-app#388: Adds FT support for campaigns, including ft_id fields and contract client methods, which directly relates to the explicit ftId handling and campaign form changes in this PR.

Suggested reviewers

  • Ebube111

Poem

Hopping through forms, a new fee appears,
Referral can be bypassed, let’s all give cheers!
Tokens more precise, with four digits to show,
Campaigns pick their FT, as onward we go.
Rabbits rejoice—less fees in the field,
For every donation, more joy to yield!
🐇✨

✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@akaia-shadowfox akaia-shadowfox marked this pull request as ready for review June 2, 2025 18:29
@akaia-shadowfox akaia-shadowfox requested a review from Ebube111 as a code owner June 2, 2025 18:29
@akaia-shadowfox akaia-shadowfox removed the request for review from Ebube111 June 2, 2025 18:29
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🔭 Outside diff range comments (1)
src/features/donation/hooks/form.ts (1)

222-229: 🛠️ Refactor suggestion

⚠️ Potential issue

Fix missing dependency in useCallback.

The onSubmit callback uses inputs.bypassReferralFee but the dependency array doesn't include this field, which could lead to stale closure issues.

Apply this diff to fix the dependency array:

-    [campaign?.recipient, isCampaignDonation, onSubmitError, params, viewer?.referrerAccountId],
+    [campaign?.recipient, isCampaignDonation, onSubmitError, params, viewer?.referrerAccountId],

Note: Since inputs is the parameter of the callback function, it doesn't need to be in the dependency array. However, ensure that all external variables used within the callback are properly included in the dependencies.

🧹 Nitpick comments (1)
src/entities/campaign/components/CampaignForm.tsx (1)

72-74: Address the performance TODO comment.

The existing TODO comment highlights a significant performance issue where the effect runs on every render, which can substantially impact UX and performance. This should be prioritized for refactoring.

Would you like me to help implement the useEnhancedForm approach or create an issue to track this performance optimization task?

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d840196 and ed943f1.

📒 Files selected for processing (14)
  • .env.example (1 hunks)
  • src/common/lib/format.ts (1 hunks)
  • src/entities/campaign/components/CampaignForm.tsx (3 hunks)
  • src/entities/campaign/hooks/forms.ts (4 hunks)
  • src/features/donation/components/modal-confirmation-screen.tsx (6 hunks)
  • src/features/donation/components/single-recipient-success.tsx (3 hunks)
  • src/features/donation/components/summary.tsx (1 hunks)
  • src/features/donation/hooks/breakdowns.ts (4 hunks)
  • src/features/donation/hooks/form.ts (2 hunks)
  • src/features/donation/models/schemas.ts (1 hunks)
  • src/features/matching-pool-contribution/components/MatchingPoolContributionModal.tsx (9 hunks)
  • src/features/matching-pool-contribution/hooks/forms.ts (3 hunks)
  • src/features/matching-pool-contribution/model/schemas.ts (1 hunks)
  • src/layout/profile/components/summary.tsx (1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (5)
src/features/donation/components/single-recipient-success.tsx (1)
src/common/lib/format.ts (1)
  • indivisibleUnitsToFloat (16-20)
src/entities/campaign/components/CampaignForm.tsx (1)
src/common/constants.ts (1)
  • NATIVE_TOKEN_ID (114-114)
src/features/matching-pool-contribution/hooks/forms.ts (3)
src/features/matching-pool-contribution/model/schemas.ts (1)
  • MatchingPoolContributionInputs (14-14)
src/common/constants.ts (1)
  • FIFTY_TGAS (135-135)
src/common/lib/format.ts (1)
  • parseNearAmount (7-7)
src/entities/campaign/hooks/forms.ts (2)
src/common/types.ts (2)
  • ByCampaignId (118-120)
  • TokenId (101-101)
src/common/constants.ts (1)
  • NATIVE_TOKEN_ID (114-114)
src/features/donation/hooks/breakdowns.ts (6)
src/features/donation/types.ts (2)
  • WithTotalAmount (45-47)
  • DonationBreakdown (49-62)
src/features/donation/models/schemas.ts (1)
  • DonationSubmitParams (72-76)
src/common/contracts/core/donation/index.ts (1)
  • donationContractHooks (7-7)
src/common/contracts/core/utils.ts (2)
  • feePercentsToBasisPoints (8-9)
  • feeBasisPointsToPercents (5-6)
src/common/contracts/core/constants.ts (1)
  • TOTAL_FEE_BASIS_POINTS (1-1)
src/common/constants.ts (1)
  • NATIVE_TOKEN_ID (114-114)
🔇 Additional comments (40)
.env.example (2)

1-1: Consistent comment marker update for Deployment environment
The ##* prefix replaces the old ##? marker, standardizing section headers without impacting any environment variables.


8-8: Consistent comment marker update for Debugging and testing section
Similarly, updating to ##* maintains uniformity across the file. No functional/configuration changes introduced.

src/layout/profile/components/summary.tsx (1)

124-124: Excellent security improvement!

Adding the viewer.isSignedIn check to the ownership determination logic is a solid security enhancement. This ensures that profile ownership requires both proper authentication AND account ID matching, preventing potential scenarios where someone could manipulate account IDs without being properly signed in.

src/entities/campaign/components/CampaignForm.tsx (3)

39-39: Good: Explicit ftId parameter passing.

The explicit passing of ftId parameter to useCampaignForm improves clarity and aligns with the hook's updated signature. The fallback logic existingData?.ft_id ?? NATIVE_TOKEN_ID is appropriate.


76-78: Improved: More precise ft_id synchronization logic.

The updated condition isNonNullish(existingData.ft_id) && ftId !== existingData.ft_id is more precise than the previous implementation, preventing unnecessary form resets when the existing data doesn't have a specific token ID.


322-322: Good: Disable token selection during updates.

Disabling the TokenSelector during campaign updates (isUpdate) is a sensible UX decision that prevents token changes after campaign creation, which aligns with the backend logic that omits ft_id from update operations.

src/entities/campaign/hooks/forms.ts (4)

11-11: Good: Updated import types for better type safety.

The import changes from CampaignId to ByCampaignId and addition of TokenId type improve type safety and align with the updated parameter structure.


20-24: Well-designed: Flexible parameter type and function signature.

The new CampaignFormParams type that extends Partial<ByCampaignId> and adds optional ftId creates a clean, flexible interface. The updated function signature properly supports both campaign creation and updates.


35-35: Good: Parameterized default token ID.

Using ftId ?? NATIVE_TOKEN_ID as the default value allows the form to respect the passed token ID while maintaining a sensible fallback. This supports the use case where existing campaigns may have different token types.


194-194: Excellent: Conditional ft_id inclusion logic.

The conditional inclusion of ft_id only for new campaigns (isNewCampaign) is well-designed. This prevents token type changes during campaign updates, which makes sense from both a business logic and data integrity perspective.

src/features/donation/models/schemas.ts (1)

61-61: LGTM! Consistent schema enhancement for referral fee bypass.

The addition of bypassReferralFee field follows the established pattern of other fee bypass flags and correctly defaults to false for backward compatibility. This change aligns perfectly with the PR objective to allow bypassing referrer fees in donation scenarios.

src/features/donation/components/summary.tsx (1)

46-51: Improved fee display ordering.

Moving the "Referrer Fee" entry to appear after "Protocol Fee" creates a more logical flow in the fee breakdown display. This UI improvement enhances user experience without affecting any functionality.

src/common/lib/format.ts (1)

20-20:

Details

❓ Verification inconclusive

Verify impact of increased precision on existing consumers.

Increasing the default fractional digits from 2 to 4 improves precision for fee calculations, which supports the referral fee bypass functionality. However, this is a global change that affects all consumers of indivisibleUnitsToFloat.

Please ensure that existing consumers can handle the increased precision or explicitly specify their required precision.


🏁 Script executed:

#!/bin/bash
# Description: Find all usages of indivisibleUnitsToFloat to assess impact of precision change
# Expected: Most usages should be compatible, but some might depend on 2-digit precision

echo "Searching for all usages of indivisibleUnitsToFloat..."
rg -A 3 -B 1 "indivisibleUnitsToFloat" --type ts --type tsx

echo -e "\nSearching for usages that might specify custom fracDigits..."
rg -A 2 "indivisibleUnitsToFloat.*,.*," --type ts --type tsx

Length of output: 434


🏁 Script executed:

#!/bin/bash
# Re-run usage search without relying on ripgrep’s built-in type filters

echo "1) All usages of indivisibleUnitsToFloat in .ts/.tsx files:"
rg -g '*.ts' -g '*.tsx' -n "indivisibleUnitsToFloat"

echo -e "\n2) Usages passing a custom fracDigits argument:"
# Match calls where a second numeric literal is supplied
rg -g '*.ts' -g '*.tsx' -n -e 'indivisibleUnitsToFloat\([^,]*,\s*[0-9]' 

Length of output: 5523


Verify global default precision change

All 30+ existing calls to indivisibleUnitsToFloat(amount, decimals) will now format with 4 decimal places by default. No consumers currently pass a custom fracDigits, so this change affects every usage.

• Representative call sites:

  • src/entities/voting-round/components/leaderboard.tsx
  • src/features/donation/hooks/form.ts & related success components
  • src/entities/campaign/components/*
  • src/entities/_shared/token/hooks/data.ts & value-summary.tsx

Please review any downstream UI layouts, exports, or integrations that may assume 2-digit precision and either confirm that 4 decimals is acceptable everywhere or explicitly pass a 2-digit fracDigits where needed.

src/features/donation/components/single-recipient-success.tsx (2)

22-22: Good cleanup of unused import.

Removing the unused rootPathnames import improves code cleanliness.


106-109: Consistent variable renaming improves clarity.

The renaming from referralFeeFinalAmountFloat to referralFeeAmountFloat removes redundant terminology and aligns with the referral fee bypass functionality. The corresponding parameter update maintains consistency throughout the component.

Also applies to: 117-117

src/features/donation/hooks/form.ts (1)

86-88: LGTM: New bypass fields added correctly.

The addition of bypassProtocolFee and bypassReferralFee boolean fields with default values of false is consistent with the PR objective to allow bypassing referrer fees.

src/features/matching-pool-contribution/model/schemas.ts (3)

1-1: Good refactor: Using named imports for better readability.

The change from importing the entire z namespace to individual validators improves code readability and potentially reduces bundle size.


10-10: LGTM: New bypass referral fee field added.

The addition of bypassReferralFee boolean field with default false is consistent with the PR objective and aligns with similar changes in the donation schema.


14-14:

Details

✅ Verification successful

Verify the FromSchema type utility.

The change from z.infer to FromSchema appears to be part of a broader refactoring. Ensure that FromSchema provides the same type inference capabilities and is properly implemented.


🏁 Script executed:

#!/bin/bash
# Description: Verify the FromSchema utility type and its usage
# Expected: Find the definition of FromSchema and check if it's properly typed

# Search for FromSchema definition
ast-grep --pattern 'type FromSchema$$$'

# Search for other usages of FromSchema vs z.infer to check consistency
rg -A 2 -B 2 "FromSchema|z\.infer"

Length of output: 11407


FromSchema is a direct alias for z.infer; type inference remains correct.

Verified in src/common/types.ts that:

  • export type { infer as FromSchema } from "zod";

This means FromSchema<typeof matchingPoolFundingSchema> is identical to z.infer<typeof matchingPoolFundingSchema>. No further action required.

src/features/matching-pool-contribution/components/MatchingPoolContributionModal.tsx (4)

62-76: Good separation of fee calculation logic.

The separation of initial fee amounts from final amounts (considering bypass flags) improves code clarity and makes the fee calculation logic easier to understand and maintain.


149-171: Well-implemented conditional referral fee bypass UI.

The conditional rendering of the referral fee bypass checkbox (only when referrerFeePercentage > 0) is appropriate and prevents unnecessary UI clutter when there's no referral fee to bypass.


88-89: Good form structure improvement.

The addition of a native <form> element nested within the existing Form component improves form semantics and accessibility.


199-213: Standardized fee label capitalization.

The standardization of fee labels ("Protocol Fee," "Chef Fee," and "Referrer Fee") improves UI consistency.

src/features/matching-pool-contribution/hooks/forms.ts (3)

5-5: Import type change looks correct.

The change from FormSubmitHandler to SubmitHandler appears to be a standard React Hook Form type import update.


25-32: Conditional referrer logic implemented correctly.

The logic to conditionally set referrer_id to undefined when bypassReferralFee is true, otherwise use viewer.referrerAccountId, correctly implements the bypass functionality.


28-32:

Details

✅ Verification successful

Verify form data structure change.

The change from accessing nested data properties (e.g., formData.data.message) to direct properties (e.g., formData.message) suggests a significant change in the form data structure. Ensure this aligns with the schema updates and doesn't break existing functionality.

Also applies to: 39-39, 78-78


🏁 Script executed:

#!/bin/bash
# Description: Verify the form data structure and its usage
# Expected: Check how MatchingPoolContributionInputs type is structured

# Search for the schema definition and type structure
ast-grep --pattern 'const matchingPoolFundingSchema = $$$'

# Search for other usages of form data in matching pool contribution files
rg -A 3 -B 3 "formData\." src/features/matching-pool-contribution/

Length of output: 3387


Form data schema verified
The matchingPoolFundingSchema in src/features/matching-pool-contribution/model/schemas.ts declares message, amountNEAR, bypassProtocolFee, bypassReferralFee, and bypassChefFee as top-level properties, so using formData.message, formData.amountNEAR, etc., is correct and aligns with the schema.

src/features/donation/components/modal-confirmation-screen.tsx (7)

26-26: LGTM: Clean wallet session integration.

The import of useWalletUserSession is appropriate for accessing wallet user data needed for referral fee handling.


49-49: LGTM: Proper wallet user session usage.

The wallet user session hook is correctly instantiated for accessing referrer account information.


53-67: LGTM: Form watch array properly extended.

The addition of bypassReferralFee to the watched form fields is consistent with the existing pattern and necessary for reactive UI updates.


93-99: LGTM: Allocation breakdown hook integration.

The hook correctly receives the new referrerAccountId from wallet user session and bypassReferralFee flag. The parameter ordering matches the hook's expected interface.


148-172: LGTM: Consistent fee bypass UI pattern.

The protocol fee bypass checkbox follows the established pattern and is properly gated by isFeeBypassAllowed.


198-215: LGTM: Chef fee bypass properly gated.

The chef fee bypass checkbox correctly includes the isFeeBypassAllowed condition alongside existing pot donation checks.


217-239: LGTM: Campaign creator fee bypass properly gated.

The campaign creator fee bypass checkbox correctly includes the isFeeBypassAllowed condition alongside existing campaign and fee percentage checks.

src/features/donation/hooks/breakdowns.ts (7)

3-8: LGTM: Clean import additions.

The new imports for Pot, donationContractHooks, and fee conversion utilities are appropriate for the enhanced functionality.


17-26: LGTM: Type definition properly extended.

The DonationAllocationParams type correctly includes the new bypassReferralFee and referrerAccountId parameters, maintaining consistency with the existing pattern.


35-39: LGTM: Parameter defaults are appropriate.

The bypassReferralFee parameter has a sensible default of false, maintaining backward compatibility.


40-40: LGTM: Improved data fetching pattern.

Using donationContractHooks.useConfig() provides better integration with the donation contract system.


49-67: LGTM: Protocol fee calculation logic is sound.

The refactored protocol fee calculation correctly handles both final amounts and percentage-based calculations. The logic properly falls back to basis points when final amounts aren't provided.


74-99: LGTM: Referral fee calculation with bypass support.

The referral fee calculation logic correctly:

  • Handles the bypass flag to set fee to 0
  • Calculates initial basis points from campaign, pot, or donation config
  • Supports final amount overrides with proper percentage calculations
  • Maintains consistency with the protocol fee pattern

150-150: LGTM: Storage fee approximation logic.

The storage fee approximation correctly differentiates between NEAR native tokens and other tokens with appropriate fee estimates.

Comment thread src/features/donation/components/modal-confirmation-screen.tsx
Comment thread src/features/donation/components/modal-confirmation-screen.tsx
@akaia-shadowfox akaia-shadowfox merged commit d2dc439 into staging Jun 2, 2025
3 of 5 checks passed
@akaia-shadowfox akaia-shadowfox deleted the 399-allow-bypassing-referrer-fee-in-all-donation-scenarios branch June 2, 2025 18:45
@coderabbitai coderabbitai Bot mentioned this pull request Jun 4, 2025
akaia-shadowfox added a commit that referenced this pull request Jun 12, 2025
* Implement campaign creator fee bypass mechanism

* Fix project allocation calculation

* Apply code review suggestion

* Allow bypassing referrer fee in all donation scenarios (#400)

* hotfix: Provide correct referrer account id

* hotfix: Respect campaign's `allow_fee_avoidance`

* hotfix: Pass campaign creator id to campaign FT donation flow

* Stabilize fee calculation

* Disable profile setup on staging

* Use Pinata for campaign banner uploads (#408)

* Reduce SWR revalidation rate for contracts

* Reduce SWR revalidation rate for contracts

* hotfix: Adjust campaign settings form hydration condition

* hotfix: Don't display error for stale data
& Remove console spam

* Change campaigns overview heading

* Change campaigns overview heading

---------

Co-authored-by: Ebube111 <ebubeagwaze@gmail.com>
@coderabbitai coderabbitai Bot mentioned this pull request Jul 28, 2025
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.

1 participant