[OTE-816] Update Revshare logic for affiliates #2298
Conversation
|
Warning Rate limit exceeded@teddyding has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 29 minutes and 13 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes involve significant modifications to the revenue sharing functionality within the protocol. Key alterations include the removal of the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
| @@ -856,52 +856,6 @@ func TestKeeper_GetAllRevShares_Invalid(t *testing.T) { | |||
| require.NoError(t, err) | |||
| }, | |||
| }, | |||
| { | |||
| name: "Total fees shared exceeds net fees from market mapper and affiliates", | |||
There was a problem hiding this comment.
These tests wont work anymore
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Outside diff range and nitpick comments (2)
protocol/x/revshare/keeper/revshare.go (2)
Line range hint
227-251: Update unit tests to cover changes ingetAffiliateRevSharesThe function
getAffiliateRevSharesnow returns an additional*big.IntrepresentingaffiliateFeesShared. Ensure that unit tests are updated or added to cover this new return value and to verify the correctness ofaffiliateFeesSharedin various scenarios.
227-227: Document the new return value ingetAffiliateRevSharesUpdate the function comment for
getAffiliateRevSharesto include information about the new*big.Intreturn valueaffiliateFeesShared. This helps maintain clarity for future maintainers.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (3)
- protocol/x/revshare/keeper/revshare.go (3 hunks)
- protocol/x/revshare/keeper/revshare_test.go (8 hunks)
- protocol/x/subaccounts/keeper/transfer_test.go (1 hunks)
Additional comments not posted (5)
protocol/x/revshare/keeper/revshare_test.go (2)
Line range hint
337-364: LGTM!The changes in the test cases consistently reduce the expected
QuoteQuantumsfor various recipients and fee sources. This suggests a deliberate adjustment in the revenue share calculation, potentially to align with updated business requirements or to optimize the distribution of fees among the participants.The reductions appear to be proportional across the test cases, maintaining the overall integrity of the revenue share logic. The updated values should be verified against the intended revenue share model to ensure accuracy.
Line range hint
848-860: Verify the reason for removing the test cases.The test cases that specifically checked for exceeding net fees from market mappers and affiliates have been removed. This suggests a change in the validation logic or requirements related to these entities.
Please confirm the following:
- Is the validation for exceeding net fees from market mappers and affiliates still necessary? If not, please provide the rationale for removing these test cases.
- Are there any alternative mechanisms in place to validate the fee distribution for market mappers and affiliates?
Ensuring comprehensive test coverage is crucial for maintaining the integrity of the revenue share system. If the removed test cases are no longer relevant, please consider adding comments to document the reasons for their removal.
protocol/x/subaccounts/keeper/transfer_test.go (1)
1503-1506: LGTM!The updated expected balances for the fee module account, market mapper account, affiliate account, and unconditional rev share account are calculated correctly based on the respective revenue share percentages.
protocol/x/revshare/keeper/revshare.go (2)
184-184: EnsuregetMarketMapperRevSharehandles updated net fees correctlyPassing the adjusted
netFeesSubAffiliateFeesSharedtogetMarketMapperRevShareis appropriate. Verify thatgetMarketMapperRevSharecorrectly handles cases where the net fees might be reduced due to affiliate fee sharing.
Line range hint
227-251: Ensure all callers handle the new return value fromgetAffiliateRevSharesWith the addition of the new return value
*big.Int, verify that all callers ofgetAffiliateRevShareshave been updated to handle the extra return parameter to prevent potential runtime errors.Run the following script to identify all usages of
getAffiliateRevShares:Verification successful
To ensure a comprehensive verification, we need to perform two additional checks. First, let's search for any other potential usages of the function, and then we'll examine the context around the function call we found.
Changes to
getAffiliateRevShareshave been correctly implementedThe verification process has confirmed that the new return value from
getAffiliateRevSharesis being properly handled in its only usage within the codebase. The function call correctly assigns three variables, including the newaffiliateFeesSharedreturn value, which is then used in subsequent calculations. No other calls to this function were found in the codebase, so no further updates are necessary.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all usages of `getAffiliateRevShares` to ensure they are handling the new return value. # Search for the function calls in the Go codebase. rg --type go --fixed-strings 'getAffiliateRevShares(' -A 2Length of output: 550
Script:
#!/bin/bash # Search for any mentions of 'getAffiliateRevShares' in the entire codebase rg --type go 'getAffiliateRevShares' # Show more context around the function call we found rg --type go --fixed-strings 'getAffiliateRevShares(' -B 5 -A 10Length of output: 2723
| affiliateRevShares, affiliateFeesShared, err := k.getAffiliateRevShares(ctx, fill, affiliatesWhitelistMap) | ||
| if err != nil { | ||
| return types.RevSharesForFill{}, err | ||
| } | ||
|
|
||
| unconditionalRevShares, err := k.getUnconditionalRevShares(ctx, netFees) | ||
| netFeesSubAffiliateFeesShared := big.NewInt(0).Sub(netFees, affiliateFeesShared) | ||
| unconditionalRevShares, err := k.getUnconditionalRevShares(ctx, netFeesSubAffiliateFeesShared) |
There was a problem hiding this comment.
Verify that netFeesSubAffiliateFeesShared is non-negative after subtraction
Subtracting affiliateFeesShared from netFees may result in netFeesSubAffiliateFeesShared becoming negative if affiliateFeesShared exceeds netFees. This could lead to unexpected behavior in subsequent revenue share calculations.
Consider adding a check to ensure netFeesSubAffiliateFeesShared is not negative, or handle scenarios where it could be zero or negative appropriately.
| } | ||
|
|
||
| takerAffiliateAddr, feeSharePpm, exists, err := k.affiliatesKeeper.GetTakerFeeShare( | ||
| ctx, takerAddr, affiliatesWhitelistMap) | ||
| if err != nil { | ||
| return nil, err | ||
| return nil, big.NewInt(0), err |
There was a problem hiding this comment.
Return nil for affiliateFeesShared when an error occurs
In the error case at line 237, consider returning nil for affiliateFeesShared instead of big.NewInt(0). This makes it clear that the value is invalid due to the error, aligning with common Go practices.
Apply this diff to adjust the return value:
-return nil, big.NewInt(0), err
+return nil, nil, errCommittable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| return nil, big.NewInt(0), err | |
| return nil, nil, err |
| @@ -171,17 +171,17 @@ func (k Keeper) GetAllRevShares( | |||
| makerFees := fill.MakerFeeQuoteQuantums | |||
There was a problem hiding this comment.
Let's also change REV_SHARE_FEE_SOURCE_NET_FEE to REV_SHARE_FEE_SOURCE_NET_PROTOCOL_REVENUE to disambiguate
NET_FEE could be understood as taker fee minus rebates
|
|
||
| totalFeesShared := big.NewInt(0) | ||
| takerFees := fill.TakerFeeQuoteQuantums | ||
| makerFees := fill.MakerFeeQuoteQuantums | ||
| netFees := big.NewInt(0).Add(takerFees, makerFees) | ||
|
|
||
| affiliateRevShares, err := k.getAffiliateRevShares(ctx, fill, affiliatesWhitelistMap) | ||
| affiliateRevShares, affiliateFeesShared, err := k.getAffiliateRevShares(ctx, fill, affiliatesWhitelistMap) | ||
| if err != nil { | ||
| return types.RevSharesForFill{}, err |
There was a problem hiding this comment.
Comment on caller function persistMatchedOrders:
Instead propagating error returned from GetAllRevShares (which would ultimately fail the match transaction), it's better to just pass in empty RevSharesForFill to DistributeFees. This way if any rev share calculation encounters issue, the chain will continue to be able to process matches (without rev share).
Order matching + rev share both working > Only order matching working > Order matching not working
There was a problem hiding this comment.
sounds good. I'll add some error logs to catch in case it fails
There was a problem hiding this comment.
Did we do this in this PR? Or plan to do in another one?
There was a problem hiding this comment.
This is done in the PR . Check here. Also updated tests in revshare_test.go
There was a problem hiding this comment.
Oh, the original comment was suggesting that we keep GetAllRevShares behavior as this but handle error differently in persistMatchedOrders, since it's the caller responsibility to determine what to do with the returned error from GetAllRevShares
Changing GetAllRevShares behavior works too but we are changing the signature/expectation of the function (e.g. it doesn't make sense to have this function return error anymore, it's always nil)
We should either:
- Keep
GetAllRevSharesas is, and just log out error (don't propogate errors further up) inpersistMatchedOrders. - Fully change signature of
GetAllRevSharesso it doesn't return errors anymore, maybe even rename it toGetAllValidRevShares
The first seems slightly cleaner to me since we just need one error log instead of multiple
| if err != nil { | ||
| return types.RevSharesForFill{}, err | ||
| } | ||
|
|
||
| unconditionalRevShares, err := k.getUnconditionalRevShares(ctx, netFees) | ||
| netFeesSubAffiliateFeesShared := big.NewInt(0).Sub(netFees, affiliateFeesShared) |
There was a problem hiding this comment.
| netFeesSubAffiliateFeesShared := big.NewInt(0).Sub(netFees, affiliateFeesShared) | |
| netFeesSubAffiliateFeesShared := new(big.Int).Sub( | |
| netFees, | |
| affiliateFeesShared, | |
| ) |
| @@ -1500,10 +1500,10 @@ func TestDistributeFees(t *testing.T) { | |||
| MonthlyRollingTakerVolumeQuantums: 1_000_000, | |||
| }, | |||
| expectedSubaccountsModuleAccBalance: big.NewInt(100), // 600 - 500 | |||
| expectedFeeModuleAccBalance: big.NewInt(2888), // 2500 + 500 - 50 | |||
| expectedMarketMapperAccBalance: big.NewInt(50), // 10% of 500 | |||
| expectedFeeModuleAccBalance: big.NewInt(2892), // 2500 + 500 - 108 | |||
There was a problem hiding this comment.
Realized that we aren't purely testing DistributeFees function in here, but it's more of an e2e test on affiliate + rev share + distribute fees. This isn't the best practice - should have a function that exclusively tests DistributeFees, which doesn't rely on affiliatesKeeper or revshareKeeper. (We should also remove delete the revShareKeeper on subaccountsKeeper
| @@ -332,23 +332,23 @@ func TestKeeper_GetAllRevShares_Valid(t *testing.T) { | |||
| }, | |||
There was a problem hiding this comment.
For my understanding, how did we set up the tier for Bob in this test case? Didn't find anything related in the setUp()
There was a problem hiding this comment.
bob address has coins already setup here for staking. This just puts bob at the max tier
There was a problem hiding this comment.
I see, could we document in the unit test? Not very obvious to reader
| @@ -420,33 +420,33 @@ func TestKeeper_GetAllRevShares_Valid(t *testing.T) { | |||
| }, | |||
There was a problem hiding this comment.
Comment on line 411: negative unconditional and market mapper doesn't make sense - did you mean maker fee is negative
| RevShareType: types.REV_SHARE_TYPE_UNCONDITIONAL, | ||
| QuoteQuantums: big.NewInt(1_600_000), | ||
| QuoteQuantums: big.NewInt(1_300_000), |
There was a problem hiding this comment.
At least for one of the test cases, could we add comment on math behind these expected values? For example,
QuoteQuantums: big.NewInt(1_300_000), // (10 - 2 - 10 * 0.15) * 20% = 1.3
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
protocol/x/subaccounts/keeper/transfer_test.go (1)
1512-1513: Consider adding comments for clarity.The expected balances for the market mapper and affiliate have been updated. To improve readability and maintainability, consider adding comments explaining how these values are calculated based on the new revenue sharing model.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (3)
- protocol/x/revshare/keeper/revshare.go (7 hunks)
- protocol/x/revshare/keeper/revshare_test.go (10 hunks)
- protocol/x/subaccounts/keeper/transfer_test.go (13 hunks)
Files skipped from review as they are similar to previous changes (2)
- protocol/x/revshare/keeper/revshare.go
- protocol/x/revshare/keeper/revshare_test.go
Additional comments not posted (2)
protocol/x/subaccounts/keeper/transfer_test.go (2)
1510-1511: Verify the fee distribution calculation.The expected fee module balance has been updated from
2950to2892. Please ensure that this new value is correct and consistent with the updated revenue sharing model. Consider adding a comment explaining the calculation for better clarity.#!/bin/bash # Verify the fee distribution calculation in other test cases rg --type go "expectedFeeModuleAccBalance.*big.NewInt\([0-9]+\)" protocol/x/subaccounts/keeper/transfer_test.go
1520-1558: Review the new revenue sharing structure.A new
revSharefield has been added with detailed revenue sharing information. This is a significant change that introduces more complexity to the test case. Please ensure that:
- The
RevSharesForFillstruct is correctly populated.- The
AffiliateRevSharevalues are consistent with the expected affiliate balance.- The
FeeSourceToQuoteQuantumsandFeeSourceToRevSharePpmmaps are correctly set up.- The
AllRevSharesslice contains all the expected revenue shares.Additionally, consider adding comments to explain the reasoning behind these specific values and how they relate to the expected balances.
| setRevenueShare: true, | ||
| revShareExpiration: 100, | ||
| }, | ||
| "success - market mapper rev share expired": { |
There was a problem hiding this comment.
Removing this since its an e2e test. Added an equivalent test in revshare_test.go
There was a problem hiding this comment.
The test in revshare_test.go broke - looks like there was already an existing test which was commented out
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (2)
protocol/x/revshare/keeper/revshare_test.go (2)
661-661: Simplify the expression for setting expired timestamp.The expression
ctx.BlockTime().Unix() + -1can be simplified toctx.BlockTime().Unix() - 1for better readability.Apply this diff to simplify the expression:
- ExpirationTs: uint64(ctx.BlockTime().Unix() + -1), + ExpirationTs: uint64(ctx.BlockTime().Unix() - 1),
Line range hint
762-762: Correct theProductIdassignment in the fill struct.In the
fillstruct,ProductIdis assignedmarketIdinstead ofperpetualId. This may lead to incorrect product identification during tests.Apply this diff to fix the assignment:
- ProductId: marketId, + ProductId: perpetualId,
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (9)
- protocol/app/app.go (0 hunks)
- protocol/testutil/keeper/clob.go (0 hunks)
- protocol/testutil/keeper/listing.go (0 hunks)
- protocol/testutil/keeper/sending.go (0 hunks)
- protocol/testutil/keeper/subaccounts.go (0 hunks)
- protocol/x/revshare/keeper/revshare_test.go (11 hunks)
- protocol/x/subaccounts/keeper/keeper.go (1 hunks)
- protocol/x/subaccounts/keeper/transfer_test.go (12 hunks)
- protocol/x/subaccounts/types/expected_keepers.go (0 hunks)
Files not reviewed due to no reviewable changes (6)
- protocol/app/app.go
- protocol/testutil/keeper/clob.go
- protocol/testutil/keeper/listing.go
- protocol/testutil/keeper/sending.go
- protocol/testutil/keeper/subaccounts.go
- protocol/x/subaccounts/types/expected_keepers.go
Files skipped from review as they are similar to previous changes (1)
- protocol/x/subaccounts/keeper/transfer_test.go
Additional comments not posted (6)
protocol/x/subaccounts/keeper/keeper.go (4)
Line range hint
1-62: Summary of review findings and next steps
There is an inconsistency between the AI-generated summary and the provided code regarding the removal of
revShareKeeper. This needs to be clarified.The current implementation of the
Keeperstruct andNewKeeperfunction appears to be consistent and functional. However, we need clarification on how the revenue sharing logic for affiliates is now being handled.The remaining functions (
GetIndexerEventManager,Logger, andInitializeForGenesis) seem unchanged and should continue to function correctly.Next steps:
a) Clarify the actual changes made to the revenue sharing logic for affiliates.
b) Verify that allNewKeeperfunction calls throughout the codebase are consistent with its current implementation.
c) Perform a general code health check, including running relevant tests and usage verification.
d) Update the PR description to accurately reflect the changes made in this file.Please address these points and run the suggested verification scripts to ensure the consistency and correctness of the changes.
Line range hint
51-62: Remaining functions look good, consider a general code health checkThe
GetIndexerEventManager,Logger, andInitializeForGenesisfunctions appear to be unchanged and should continue to function correctly. However, given the changes to theKeeperstruct andNewKeeperfunction, it would be prudent to perform a general code health check.Consider running the following checks:
- Ensure all tests related to these functions are passing:
go test ./protocol/x/subaccounts/... -run "TestGetIndexerEventManager|TestLogger|TestInitializeForGenesis"
- Verify that these functions are still being used correctly throughout the codebase:
rg --type go -e 'GetIndexerEventManager\(\)' -e 'Logger\(' -e 'InitializeForGenesis\(' protocol/Please review the results of these checks to ensure the overall health of the subaccounts module.
Line range hint
31-49: NewKeeper function implementation is consistent, but usage verification neededThe current implementation of the
NewKeeperfunction is consistent with theKeeperstruct definition. However, given the mentioned removal of therevShareKeeperparameter, we should verify that all calls toNewKeeperthroughout the codebase have been updated accordingly.To ensure that all usages of
NewKeeperare consistent with its current signature, please run the following script:#!/bin/bash # Description: Check for NewKeeper function calls in the codebase echo "Searching for NewKeeper function calls:" rg --type go 'NewKeeper\s*\(' protocol/ # Expected results: # All NewKeeper function calls should match the current signature without the revShareKeeper parameter. # Any mismatches should be investigated and updated.Please review the script output to confirm that all
NewKeepercalls are consistent with the current implementation.
Line range hint
19-29: Keeper struct implementation looks good, but clarification neededThe current implementation of the
Keeperstruct appears to be well-structured and consistent. However, given the PR title "[OTE-816] Update Revshare logic for affiliates" and the mentioned removal of therevShareKeeperfield, we need clarification on how the revenue sharing functionality for affiliates is now being handled.Could you please provide information on:
- How the revenue sharing logic for affiliates is implemented without the
revShareKeeper?- Are there any other files or modules that now handle this functionality?
To help with this, you can run the following script to search for relevant code:
Please review the script output and provide the necessary clarification.
Verification successful
Verified Removal of
revShareKeeperThe removal of the
revShareKeeperfield from theKeeperstruct inprotocol/x/subaccounts/keeper/keeper.gois appropriate. Revenue sharing functionality is now managed by theRevShareKeeperin theapp/app.gomodule, ensuring centralized handling without impacting thesubaccountsmodule.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for revenue sharing or affiliate-related code echo "Searching for revenue sharing or affiliate-related code:" rg --type go -i '(revshare|revenue.?shar|affiliate)' protocol/x/subaccounts/Length of output: 5313
protocol/x/revshare/keeper/revshare_test.go (2)
426-426: Add explanation for expectedQuoteQuantumsvalues.Please include comments that explain the calculations behind the expected
QuoteQuantumsvalues. This will enhance the readability and maintainability of the test cases by making the expected results clearer.
893-895: Declare theerrvariable to prevent compilation errors.In the
setupfunction, the variableerris used without prior declaration. This will cause a compilation error. Use:=to declare and assignerrwhen callingSetMarketMapperRevenueShareParams.Apply this diff to fix the problem:
- err = keeper.SetMarketMapperRevenueShareParams(ctx, types.MarketMapperRevenueShareParams{ + err := keeper.SetMarketMapperRevenueShareParams(ctx, types.MarketMapperRevenueShareParams{ Address: constants.AliceAccAddress.String(), RevenueSharePpm: 950_000, // 95% ValidDays: 1, })Likely invalid or redundant comment.
| return types.RevSharesForFill{}, nil | ||
| } | ||
|
|
||
| if netFeesSubAffiliateFeesShared.Sign() <= 0 { |
There was a problem hiding this comment.
Nit: move to immediately below line 129
There was a problem hiding this comment.
Actionable comments posted: 1
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (3)
- protocol/x/clob/keeper/process_single_match.go (2 hunks)
- protocol/x/revshare/keeper/revshare.go (6 hunks)
- protocol/x/revshare/keeper/revshare_test.go (12 hunks)
Files skipped from review as they are similar to previous changes (2)
- protocol/x/revshare/keeper/revshare.go
- protocol/x/revshare/keeper/revshare_test.go
| if err != nil { | ||
| revSharesForFill = revsharetypes.RevSharesForFill{} | ||
| log.ErrorLog(ctx, "error getting rev shares for fill", "error", err) | ||
| } |
There was a problem hiding this comment.
Consider revising the error handling strategy for GetAllRevShares
The addition of error handling for GetAllRevShares is a good practice. However, the current implementation might mask potential issues:
- The function continues execution with an empty
revSharesForFillstruct when an error occurs. - The error is logged but not propagated, which could lead to silent failures in revenue sharing calculations.
Consider the following suggestions:
- Evaluate whether continuing with an empty
revSharesForFillis appropriate in all scenarios. - Consider propagating the error or adding a mechanism to flag that revenue sharing couldn't be calculated.
- Add a comment explaining the rationale behind this error handling approach for future maintainers.
Here's a potential alternative implementation:
revSharesForFill, err := k.revshareKeeper.GetAllRevShares(ctx, fillForProcess, affiliatesWhitelistMap)
if err != nil {
- revSharesForFill = revsharetypes.RevSharesForFill{}
- log.ErrorLog(ctx, "error getting rev shares for fill", "error", err)
+ // Log the error
+ log.ErrorLog(ctx, "error getting rev shares for fill", "error", err)
+ // Consider whether to return the error or continue with a flag
+ return takerUpdateResult, makerUpdateResult, affiliateRevSharesQuoteQuantums,
+ fmt.Errorf("failed to get rev shares: %w", err)
}This approach would propagate the error, allowing the caller to decide how to handle it.
Committable suggestion was skipped due to low confidence.
| } | ||
| netFeesSubAffiliateFeesShared := new(big.Int).Sub(netFees, affiliateFeesShared) | ||
| if netFeesSubAffiliateFeesShared.Sign() <= 0 { | ||
| log.ErrorLog(ctx, "net fees sub affiliate fees shared is less than or equal to 0") | ||
| return types.RevSharesForFill{}, nil | ||
| return types.RevSharesForFill{}, err |
There was a problem hiding this comment.
What err are we returning here?
affanv14
force-pushed
the
affan/update-revshare
branch
from
84a8cdb to
53b26b2
Compare
Changelist
[Describe or list the changes made in this PR]
Test Plan
[Describe how this PR was tested (if applicable)]
Author/Reviewer Checklist
state-breakinglabel.indexer-postgres-breakinglabel.PrepareProposalorProcessProposal, manually add the labelproposal-breaking.feature:[feature-name].backport/[branch-name].refactor,chore,bug.Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Keeperstruct by removing unnecessary dependencies related to revenue sharing.RevShareKeeperinterface and associated parameters from various components, simplifying interactions within the system.