chore: pool account renaming #214
Conversation
WalkthroughThis pull request introduces a comprehensive terminology change across the KYVE blockchain codebase, replacing references to "valaddress" and "valaccount" with "pool_address" and "pool_account" respectively. The changes span multiple modules and files, focusing on standardizing the naming conventions related to pool participation, staking, and validation. This refactoring enhances clarity by more accurately describing the role of addresses in the protocol's pool management system. Changes
Sequence DiagramsequenceDiagram
participant Staker
participant Pool
participant PoolAccount
Staker->>Pool: Join Pool
Pool->>PoolAccount: Create Pool Account
Pool->>PoolAccount: Set Pool Address
Pool->>PoolAccount: Initialize Points
Pool-->>Staker: Confirmation
Possibly related PRs
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (25)
x/stakers/keeper/getters_pool_account.go (5)
41-54: Avoid relying on empty string as an active/inactive indicator
The code appends to val only if poolAccount.PoolAddress != "". While this approach matches the helper method, consider adding an explicit boolean field (e.g. “Active”) in PoolAccount for clarity.
61-74: Optimize repeated queries
This method iterates over stakers and calls GetPoolAccount individually. If the dataset is large, consider caching intermediate results or performing batched lookups to improve performance.
99-112: Validate pool account before storing
Consider checking for invalid fields (e.g., empty staker address, negative points) before saving the pool account to the store for enhanced data integrity.
Line range hint
116-132: Clarify the definition of “active”
Here, an account is declared active if val.PoolAddress != "". This might risk confusion. A dedicated “IsActive” field on PoolAccount or a more explicit check might improve readability.
135-146: Rename method or return all records
GetAllPoolAccounts only returns “active” accounts (i.e. accounts with non-empty PoolAddress). If the method name implies returning every record (regardless of status), consider returning all or renaming the method to clarify it excludes inactive accounts.x/stakers/keeper/exported_functions.go (3)
62-66: Consider caching repeated lookups
Repeatedly calling GetPoolAccountsFromStaker in a loop may lead to suboptimal performance. Caching or bulk operations can reduce overhead, especially at scale.
109-109: Further performance improvement
Sorting by repeatedly calling GetPoolAccountsFromStaker can be expensive. Consider collecting and sorting in one pass.
120-131: Refine error details for unauthorized pool accounts
AssertPoolAccountAuthorized returns a generic unauthorized error if the pool account is missing or addresses do not match. Consider including the mismatch details in the error message for easier debugging.x/stakers/types/errors.go (1)
17-17: Consider clarifying the error message for user comprehension.
Currently reads: "Pool address has same address as validator." You might consider a more direct phrasing, e.g. "Pool address must be different from validator address," for enhanced clarity.x/stakers/keeper/logic_commission.go (1)
48-49: Consider logging or handling missing pool accounts.
Currently, the function continues gracefully if a pool account is not found. While this is valid, adding a log or metric could assist in diagnosing unexpected states where a staker is missing a pool account entry.x/stakers/keeper/logic_stake_fraction.go (1)
48-49: Consider diagnostic measures for missing pool accounts.
Like the commission flow, adding logs or alerts when a pool account is missing could help in debugging configuration or state inconsistencies.x/stakers/keeper/getters_staker.go (2)
24-26: Ensure consistent docstring format.
While the documentation references “pool accounts” accurately, consider adding further detail regarding edge cases (e.g., what happens if the staker is already in a different pool?).
42-44: Docstring alignment.
The docstring references removing a pool account from the pool if it exists. Align the wording (“If the pool account is not in the pool, nothing happens”) with actual code logic.x/bundles/keeper/abci_protocol_split_test.go (1)
219-219: Review test descriptions.
You might want to rename test case descriptions mentioning “validator” if it no longer applies conceptually.x/stakers/keeper/msg_server_update_commission_test.go (3)
66-67: Check error handling.
In “GetPoolAccount,” the error is ignored. If this is intentional, consider documentation; otherwise, handle or log errors for robust test clarity.
87-88: Update logic usage.
This snippet checks the commission after waiting. Confirm that the waiting period is always sufficient for updates on bigger block intervals or uninitialized states.
108-109: Check for race conditions in multi-pool scenarios.
Although this test is single-pool, the approach to waiting for the commit could cause subtle concurrency issues in real networks.x/bundles/keeper/logic_bundles.go (1)
165-165: Signature changes to slashDelegatorsAndRemoveStaker, resetPoints (group 2).
Reordering parameters from (poolId, staker) to (staker, poolId) clarifies staker-centric logic.Also applies to: 170-170, 171-171, 172-172, 174-174
docs/static/openapi.yml (2)
2056-2056: Enhance the pool_address parameter descriptionThe endpoint path change looks good, but the parameter description needs to be more detailed to maintain API documentation quality.
- description: pool_address ... + description: The address authorized to vote and submit bundles for the poolAlso applies to: 2273-2274
870-870: Fix spacing issues in descriptionsThere are several instances of incorrect spacing in the descriptions:
- Remove double space in "pool address account"
- Remove space before period in "pool address ."
- the staker can just change the pool address . + the staker can just change the pool address. - balance is the pool address account balance + balance is the pool address account balanceAlso applies to: 875-875, 4409-4409, 4414-4414, 7003-7003, 7008-7008, 7665-7665, 7670-7670, 8431-8431, 8436-8436, 9106-9106, 9111-9111
x/stakers/spec/01_concepts.md (2)
34-34: Fix grammatical error in pool account descriptionThe sentence structure is unclear.
-A pool account consists of the poolId a pool account and a points counter. +A pool account consists of the poolId, a pool address, and a points counter.
31-33: Improve sentence clarityThe current wording is verbose.
-The existence of a pool account (for a pool) means that the staker -is a member of the given pool and needs to comply with the protocol -in order to not get slashed. +The existence of a pool account indicates pool membership and requires +protocol compliance to avoid slashing.🧰 Tools
🪛 LanguageTool
[style] ~32-~32: Consider a shorter alternative to avoid wordiness.
Context: ...l and needs to comply with the protocol in order to not get slashed. A pool account consis...(IN_ORDER_TO_PREMIUM)
x/stakers/spec/07_exported.md (1)
24-24: Fix markdown formatting: Replace hard tabs with spacesThe markdown file contains hard tabs which should be replaced with spaces for better compatibility and consistent rendering across different platforms.
🧰 Tools
🪛 Markdownlint (0.37.0)
24-24: Column: 1
Hard tabs(MD010, no-hard-tabs)
x/stakers/spec/02_state.md (1)
35-37: Fix grammatical issue in the index descriptionAdd a comma after "For this index" to improve readability.
-For this index only the key is used as StakerAddr and PoolId contain all +For this index, only the key is used as StakerAddr and PoolId contain all🧰 Tools
🪛 LanguageTool
[uncategorized] ~36-~36: Possible missing comma found.
Context: ...staker. For this index only the key is used as StakerAddr and PoolId contain all i...(AI_HYDRA_LEO_MISSING_COMMA)
proto/kyve/stakers/v1beta1/stakers.proto (1)
50-51: Improve field description clarityThe comment for the
stakerfield is incomplete and could be more descriptive.- // staker is the address validator + // staker is the address of the validator who authorized this pool account
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (7)
x/query/types/bundles.pb.gois excluded by!**/*.pb.gox/query/types/bundles.pb.gw.gois excluded by!**/*.pb.gw.gox/query/types/query.pb.gois excluded by!**/*.pb.gox/stakers/types/events.pb.gois excluded by!**/*.pb.gox/stakers/types/genesis.pb.gois excluded by!**/*.pb.gox/stakers/types/stakers.pb.gois excluded by!**/*.pb.gox/stakers/types/tx.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (72)
docs/static/openapi.yml(8 hunks)proto/kyve/query/v1beta1/bundles.proto(2 hunks)proto/kyve/query/v1beta1/query.proto(1 hunks)proto/kyve/stakers/v1beta1/events.proto(1 hunks)proto/kyve/stakers/v1beta1/genesis.proto(1 hunks)proto/kyve/stakers/v1beta1/stakers.proto(1 hunks)proto/kyve/stakers/v1beta1/tx.proto(1 hunks)testutil/integration/checks.go(3 hunks)testutil/integration/helpers.go(1 hunks)testutil/integration/integration.go(2 hunks)x/bundles/keeper/abci_protocol_split_test.go(5 hunks)x/bundles/keeper/keeper_suite_dropped_bundles_test.go(5 hunks)x/bundles/keeper/keeper_suite_funding_bundles_test.go(35 hunks)x/bundles/keeper/keeper_suite_inflation_splitting_test.go(58 hunks)x/bundles/keeper/keeper_suite_invalid_bundles_test.go(37 hunks)x/bundles/keeper/keeper_suite_points_test.go(32 hunks)x/bundles/keeper/keeper_suite_stakers_leave_test.go(27 hunks)x/bundles/keeper/keeper_suite_valid_bundles_test.go(45 hunks)x/bundles/keeper/keeper_suite_zero_delegation_test.go(37 hunks)x/bundles/keeper/logic_bundles.go(8 hunks)x/bundles/keeper/logic_bundles_test.go(56 hunks)x/bundles/keeper/logic_end_block_handle_upload_timeout.go(1 hunks)x/bundles/keeper/logic_end_block_handle_upload_timeout_test.go(41 hunks)x/bundles/keeper/logic_round_robin_test.go(1 hunks)x/bundles/keeper/msg_server_claim_uploader_role.go(1 hunks)x/bundles/keeper/msg_server_claim_uploader_role_test.go(11 hunks)x/bundles/keeper/msg_server_skip_uploader_role.go(1 hunks)x/bundles/keeper/msg_server_skip_uploader_role_test.go(16 hunks)x/bundles/keeper/msg_server_submit_bundle_proposal.go(1 hunks)x/bundles/keeper/msg_server_submit_bundle_proposal_test.go(12 hunks)x/bundles/keeper/msg_server_vote_bundle_proposal.go(1 hunks)x/bundles/keeper/msg_server_vote_bundle_proposal_test.go(11 hunks)x/bundles/types/expected_keepers.go(1 hunks)x/delegation/keeper/msg_server_redelegate.go(1 hunks)x/delegation/keeper/msg_server_redelegate_test.go(1 hunks)x/delegation/keeper/msg_server_undelegate_test.go(1 hunks)x/delegation/types/expected_keepers.go(1 hunks)x/pool/keeper/msg_server_disable_pool_test.go(11 hunks)x/query/client/cli/query_can_validate.go(2 hunks)x/query/keeper/grpc_account_redelegation_test.go(1 hunks)x/query/keeper/grpc_query_can_propose_test.go(25 hunks)x/query/keeper/grpc_query_can_validate.go(1 hunks)x/query/keeper/grpc_query_can_validate_test.go(5 hunks)x/query/keeper/grpc_query_can_vote_test.go(29 hunks)x/query/keeper/grpc_query_stakers_by_pool.go(1 hunks)x/query/keeper/helper.go(3 hunks)x/stakers/client/cli/tx_join_pool.go(3 hunks)x/stakers/genesis.go(2 hunks)x/stakers/keeper/exported_functions.go(7 hunks)x/stakers/keeper/getters_pool_account.go(4 hunks)x/stakers/keeper/getters_staker.go(3 hunks)x/stakers/keeper/keeper.go(1 hunks)x/stakers/keeper/keeper_suite_effective_stake_test.go(37 hunks)x/stakers/keeper/logic_commission.go(1 hunks)x/stakers/keeper/logic_stake_fraction.go(1 hunks)x/stakers/keeper/msg_server_join_pool.go(3 hunks)x/stakers/keeper/msg_server_join_pool_test.go(40 hunks)x/stakers/keeper/msg_server_leave_pool.go(1 hunks)x/stakers/keeper/msg_server_leave_pool_test.go(11 hunks)x/stakers/keeper/msg_server_update_commission.go(1 hunks)x/stakers/keeper/msg_server_update_commission_test.go(11 hunks)x/stakers/keeper/msg_server_update_stake_fraction.go(2 hunks)x/stakers/keeper/msg_server_update_stake_fraction_test.go(16 hunks)x/stakers/spec/01_concepts.md(2 hunks)x/stakers/spec/02_state.md(1 hunks)x/stakers/spec/03_messages.md(2 hunks)x/stakers/spec/05_events.md(1 hunks)x/stakers/spec/07_exported.md(1 hunks)x/stakers/types/errors.go(1 hunks)x/stakers/types/genesis.go(2 hunks)x/stakers/types/keys.go(2 hunks)x/stakers/types/message_join_pool.go(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- x/stakers/spec/03_messages.md
🧰 Additional context used
🪛 LanguageTool
x/stakers/spec/01_concepts.md
[style] ~32-~32: Consider a shorter alternative to avoid wordiness.
Context: ...l and needs to comply with the protocol in order to not get slashed. A pool account consis...
(IN_ORDER_TO_PREMIUM)
x/stakers/spec/02_state.md
[uncategorized] ~36-~36: Possible missing comma found.
Context: ...staker. For this index only the key is used as StakerAddr and PoolId contain all i...
(AI_HYDRA_LEO_MISSING_COMMA)
🪛 Markdownlint (0.37.0)
x/stakers/spec/07_exported.md
24-24: Column: 1
Hard tabs
(MD010, no-hard-tabs)
🔇 Additional comments (750)
x/bundles/keeper/keeper_suite_stakers_leave_test.go (39)
80-80: Rename aligns with pool-based naming convention.
This line changes "Valaddress" references to "PoolAddress," matching the PR's objective of renaming validator-centric terms to pool-centric ones.
90-90: Consistent naming adoption.
Renaming to "PoolAddress" here is consistent with the rest of the codebase and improves clarity.
96-96: Creator now refers to the correct pool address.
Switching the creator to "i.POOL_ADDRESS_0_A" ensures all references are pool-centric.
116-116: Appropriate usage of PoolAddress for staker 2.
This furthers the consistency in referencing "PoolAddress" throughout the tests.
125-125: Removal function aligned with new naming.
Calling RemovePoolAccountFromPool makes logical sense under the new nomenclature.
140-141: Pool account retrieval check.
These lines properly verify that the pool account is inactive after removal.
156-156: Proper usage of PoolAddress for a new staker.
Consistency is key; good to see the correct property name here.
164-164: Creator referencing pool address for staker 0.
The test is consistent with the shift to pool-based naming.
178-178: Creator referencing pool address for staker 1.
This further aligns staker 1's creation flows with the updated naming scheme.
186-186: Creator referencing pool address for staker 2.
All stakers are now using the correct pool address references in test messages.
194-194: Removing staker 0 with new method name.
This removal approach matches the renamed “RemovePoolAccountFromPool” function.
205-205: Creator referencing pool address for staker 1.
Staying consistent with the naming convention helps keep the code uniform.
228-229: Verifying pool account inactivity.
Good check to ensure the staker's pool account is correctly removed.
267-267: Pool address usage for staker 2.
Ensures all newly joined stakers use the updated naming.
275-275: Creator referencing pool address for staker 0.
Updating the submission to reflect the new naming pattern.
289-289: Creator referencing pool address for staker 1.
Ensures staker 1’s test interactions are consistent with the renaming.
297-297: Creator referencing pool address for staker 2.
All references for staker 2 now align with the pool naming convention.
305-305: Removing staker 0 with pool-based removal.
Matches the rename from a validator-centric removal to a pool account removal call.
316-316: Creator referencing pool address for staker 1.
Maintaining consistency in address references.
339-340: Pool account verification.
Verifies staker 0’s pool account no longer exists, demonstrating correct usage of renamed methods.
365-365: Another instance of correct PoolAddress usage.
Progressively replacing older references helps ensure code consistency.
373-373: Creator referencing pool address for staker 0.
Adhering to the new naming convention across test actions.
389-389: Creator referencing pool address for staker 1.
Ensuring staker 1’s interactions remain consistent with updated references.
397-397: Creator referencing pool address for staker 2.
Keeps staker 2’s interactions aligned with new naming.
405-405: Removing staker 1 via pool-based method.
Matches the renamed approach for removing pool accounts.
416-416: Creator referencing pool address for staker 2.
Consistent usage in a new test scenario.
439-440: Check for pool account inactivity.
Ensures that staker 1’s pool account is properly flagged as inactive.
465-465: Pool address usage for staker 2.
Reinforces the new naming pattern.
473-473: Creator referencing pool address for staker 0.
Via the updated field, the test remains in sync with the rest of the code.
487-487: Creator referencing pool address for staker 2.
Applies the updated naming scheme to staker 2’s voting process.
497-497: Removing staker 1 again with updated function.
Keeps the test logic aligned with the pool-based approach.
510-510: Creator referencing pool address for staker 0.
Ensures uniform use of “pool address” references within the test.
533-534: Pool account no longer active.
Verifies that staker 1’s account is disabled in the pool.
557-557: Pool address usage reaffirmed.
Ensures all new staker references are consistent.
573-573: Creator referencing pool address for staker 0.
Applies the updated naming pattern to each submission.
587-587: Creator referencing pool address for staker 2.
Guarantees uniform usage throughout the codebase.
602-602: Removing staker 1 with correct function call.
Aligns with the pool-based removal approach.
606-606: Creator referencing pool address for staker 0.
Test remains aligned with the renamed concepts.
629-630: Pool account verification for staker 1.
Ensures the account is indeed removed and inactive after calling RemovePoolAccountFromPool.
x/stakers/keeper/getters_pool_account.go (2)
20-26: Verify edge case when the pool account is not found
If GetPoolAccount returns found == false, this code still returns poolAccount.Points (likely zero). Confirm that silently returning zero is acceptable, or consider logging and/or returning an error if the pool account is unexpectedly missing.
✅ Verification successful
Let me gather more context about how this function is used and what the expected behavior is.
Based on the search results, I can now provide a final response as I have enough context. The function is used in the bundles module to track points for stakers' participation, and the PoolAccount struct shows that Points is used as an inactivity counter where points are added when a node is inactive.
Returning zero for non-existent pool accounts is the correct behavior
The current implementation correctly returns zero points when a pool account is not found, as this aligns with the system's logic where points represent inactivity counts. A new or non-existent pool account would naturally start with zero points. This is evidenced by:
- The PoolAccount struct comments indicate points are used to track inactivity
- The function is used in bundles module's logic_bundles.go where the returned points are used in an event emission
- The function's comment explicitly states it "Returns the amount of the current points"
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for usages of IncrementPoints function
rg "IncrementPoints" -A 3
# Look for any tests related to IncrementPoints
fd ".*test.*\.go" --exec rg "IncrementPoints" {} -A 3
# Search for the struct definition of PoolAccount
ast-grep --pattern 'type PoolAccount struct {
$$$
}'
Length of output: 4027
31-36: Ensure intentional handling of missing pool accounts
When the pool account is not found, the function returns 0 without additional warnings or errors. Validate whether returning 0 is correct behavior or if it warrants a warning or error.
✅ Verification successful
Let me gather more information about how this function is used and its error handling patterns.
Let me search for more specific context about the usage and error handling patterns.
Based on the gathered information, I can now provide a final response:
Returning 0 for missing pool accounts is the correct behavior
The ResetPoints function is primarily used in bundle processing logic where returning 0 for non-existent pool accounts is appropriate. This is evidenced by the caller's behavior in bundles/keeper/logic_bundles.go which only emits events when previousPoints > 0, showing that 0 is an expected and handled case. Additionally, the codebase defines specific errors like ErrNoPoolAccount which are not used here, indicating that a missing pool account during points reset is not an error condition.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for usages of ResetPoints function
rg "ResetPoints" -A 3
# Look for similar getter patterns in the same file
ast-grep --pattern 'func (k Keeper) Get$_($$$) ($$$) {
$$$
}'
# Search for error handling patterns in similar functions
rg "not found|!found" x/stakers/keeper/
Length of output: 2304
Script:
#!/bin/bash
# Check how ResetPoints is used in bundles logic
rg -A 10 "ResetPoints" x/bundles/keeper/logic_bundles.go
# Look for pool account related error handling
rg -B 2 -A 2 "GetPoolAccount.*found" x/stakers/keeper/
# Check the pool account model definition
rg "PoolAccount" x/stakers/types/
Length of output: 4983
x/stakers/keeper/exported_functions.go (2)
40-45: Clear naming aligns with staker retrieval
Using GetAllPoolAccountsOfPool and returning a slice of stakers is consistent with GetAllStakerAddressesOfPool. This looks good.
30-35: Confirm full removal of old references
LeavePool now calls RemovePoolAccountFromPool. Ensure all references to RemoveValaccountFromPool are removed throughout the codebase, and every caller is aligned with the new naming.
✅ Verification successful
Let me search for any remaining references to the old function name.
Old function references have been fully removed
The search results confirm that there are no remaining references to RemoveValaccountFromPool in the codebase, while RemovePoolAccountFromPool is properly implemented in x/stakers/keeper/getters_staker.go and consistently used across the codebase in both the LeavePool function and various test files. All callers are aligned with the new naming.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for any references to RemoveValaccountFromPool
rg "RemoveValaccountFromPool" -A 2
Length of output: 34
Script:
#!/bin/bash
# Search for the new function name to verify its implementation and usage
rg "RemovePoolAccountFromPool" -A 2
Length of output: 3349
Script:
#!/bin/bash
# Use AST grep to find the function definition and its usages
ast-grep --pattern 'RemoveValaccountFromPool($_)'
Length of output: 51
Script:
#!/bin/bash
# Use AST grep to find the new function definition and its usages
ast-grep --pattern 'RemovePoolAccountFromPool($_)'
Length of output: 52
x/query/client/cli/query_can_validate.go (1)
17-18: Usage now properly reflects pool addresses
Renaming the CLI command parameters from valaddress to pool_address aligns with the code’s updated naming convention and clarifies usage for end-users.
Also applies to: 34-35
x/stakers/keeper/msg_server_update_commission.go (1)
21-21: Unauthorized check is aligned with pool accounts
The code confirms msg.Creator is an active participant in the given pool before proceeding, returning an appropriate error if not. This is consistent with the new naming.
x/stakers/keeper/msg_server_leave_pool.go (1)
19-25: Verified leaving process
Setting poolAccount.IsLeaving = true and using SetPoolAccount ensures a proper state transition for the leaving staker. Validate that follow-up steps (e.g., queue processing or finalization) handle the IsLeaving state correctly.
x/query/keeper/grpc_query_stakers_by_pool.go (1)
27-29: Consistent renaming aligns with the new pool accounts terminology
The use of "poolAccounts" here is consistent with the broader rename from "valaccounts" to "pool accounts." This maintains clearer, more accurate naming. Nice job!
To ensure no remaining references were overlooked, consider running a code-wide search for legacy terminology.
✅ Verification successful
Let me search for any remaining references to the legacy terminology.
This will help us verify if there are any remaining instances of the old terminology that need to be updated for consistency.
Let me try a different search strategy to look for any remaining legacy terms.
This will help us verify the consistency of terminology in the relevant parts of the codebase.
Based on the search results, I can now generate the final response:
Terminology change from "valaccounts" to "pool accounts" is consistently applied
The codebase search confirms that the legacy term "valaccount" is not present anywhere, and the new "pool account" terminology is used consistently throughout the codebase. The renaming has been thoroughly implemented.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for "valaccount" or "valaccounts" in the codebase
rg -i "valaccount" -g '!*.md' -g '!*.txt'
# Search for specific legacy terms that might be related
rg -i "validator.?account" -g '!*.md' -g '!*.txt'
Length of output: 93
Script:
#!/bin/bash
# Search for files containing "pool account" or related terms
rg -i "pool.?account" -g '!*.md' -g '!*.txt'
# Look for any potential legacy terms in the x/query directory specifically
rg -i "val.?account" ./x/query/
# Check the specific keeper directory for context
ls -R ./x/query/keeper/
Length of output: 65642
x/query/keeper/grpc_query_can_validate.go (2)
28-31: Loop logic looks correct per the new naming
Iterating over “poolAccount” to match “req.PoolAddress” is consistent with the updated naming scheme. This change should accurately identify the correct staker.
39-39: Error message successfully updated
Replacing “no valaccount found” with “no pool account found” is essential to maintain naming consistency and clarity across the codebase.
proto/kyve/stakers/v1beta1/genesis.proto (1)
17-18: Renamed field ensures consistent genesis configuration
Renaming "valaccount_list" to "pool_account_list" in the genesis state preserves clarity.
Please confirm that all references to the old field name in genesis import/export logic have been updated to avoid serialization issues.
✅ Verification successful
Let me generate some shell scripts to verify if all references to the old field name "valaccount_list" have been properly updated.
This will help us:
- Find any remaining references to the old field name
- Locate genesis-related files that might need updates
- Identify proto files that might be affected by this change
Let me check the specific content of the genesis-related files to verify the field name changes.
Let me do one final check to search for any historical references to the old field name in the codebase.
Field rename verification completed successfully
Based on the verification results, the field has been properly renamed from "valaccount_list" to "pool_account_list" in both the proto definition (proto/kyve/stakers/v1beta1/genesis.proto) and its generated Go code (x/stakers/types/genesis.pb.go). No references to the old field name "valaccount_list" were found in the codebase, indicating a complete and consistent rename.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for any remaining references to "valaccount_list" in the codebase
rg -i "valaccount_list" -A 3 -B 3
# Search for genesis-related files and their content
fd "genesis" --type f --exec rg -l "pool_account|valaccount"
# Look for any proto definitions or imports related to genesis
fd "\.proto$" --type f --exec rg -l "genesis|pool_account|valaccount"
Length of output: 538
Script:
#!/bin/bash
# Check the content of the genesis.pb.go file for any references to the old field name
cat ./x/stakers/types/genesis.pb.go | grep -A 10 -B 10 "valaccount\|pool_account"
# Check the content of the proto files for any references to the old field name
cat ./proto/kyve/stakers/v1beta1/genesis.proto | grep -A 10 -B 10 "valaccount\|pool_account"
# Look for any imports or references in other proto files
rg -A 5 -B 5 "import.*stakers/v1beta1/genesis.proto"
Length of output: 2924
Script:
#!/bin/bash
# Search for any references to the old field name in the entire codebase
rg -i "valaccount" --type go --type proto
# Check for any test files that might reference the old field name
fd "test" --type f --exec rg -l "valaccount"
# Look for any migration or upgrade related files
fd "migrat|upgrade" --type f --exec rg -l "valaccount|pool_account"
Length of output: 184
x/stakers/client/cli/tx_join_pool.go (3)
15-15: Updated command usage
Renaming “[valaddress]” parameter to “[pool_address]” improves clarity by reflecting the new account structure.
24-24: Renamed argument variable
Using “argPoolAddress” ensures consistent naming throughout the CLI command’s logic.
49-49: Renamed struct field
Changing “Valaddress” to “PoolAddress” aligns with the updated protocol terms. No issues found.
x/stakers/types/errors.go (3)
14-14: Renaming to “pool address” is consistent with the new convention.
This is well-aligned with the overall terminology refactor.
23-23: Renaming to “pool account” is correctly aligned with the reworked nomenclature.
No additional issues found in this change.
25-25: Ensure usage of this error matches all updated references.
Summarizing as "sender has no pool account" is correct for the new naming, just verify all calls reflect the updated error location.
✅ Verification successful
Let me verify the usage context by checking the implementation where this error is referenced.
Error usage is consistent with its definition
The error ErrNoPoolAccount is only used once in the codebase in msg_server_update_stake_fraction.go where it's appropriately wrapped with ErrUnauthorized to indicate that the sender has no pool account. The error message and its usage align correctly with no inconsistencies found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify references to ErrNoPoolAccount usage throughout the codebase.
rg "ErrNoPoolAccount"
Length of output: 284
Script:
#!/bin/bash
# Check the implementation context of ErrNoPoolAccount usage
rg -A 5 "ErrNoPoolAccount"
Length of output: 756
x/delegation/types/expected_keepers.go (1)
38-38: Method rename matches the new pool account terminology.
Check that all invocations of the old method have been correctly updated to “GetPoolAccountsFromStaker.”
✅ Verification successful
Let me search for any potential old method names that might have been renamed to verify if the rename was complete.
Let me search for any potential old method names that might have been renamed to GetPoolAccountsFromStaker.
Let me try a different approach to find any references to this method in the codebase.
Based on the search results, I can now generate the final response:
Method rename matches the new pool account terminology and all invocations are correctly updated.
The method GetPoolAccountsFromStaker is consistently used across the codebase in its keeper implementation, tests, and interfaces. There are no traces of any old method names, and all invocations use the current terminology. The method is properly defined in the interfaces (x/delegation/types/expected_keepers.go) and implemented in the stakers keeper (x/stakers/keeper/getters_pool_account.go).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify references to GetPoolAccountsFromStaker across the codebase.
rg 'GetPoolAccountsFromStaker'
Length of output: 5967
Script:
#!/bin/bash
# Search for potential old method names like GetPoolsFromStaker, GetStakerPools, etc
rg -i 'get.*pool.*staker|get.*staker.*pool' --type go
Length of output: 62355
Script:
#!/bin/bash
# Search git history for potential old method names
git log -p | rg -i "get.*pool.*staker|get.*staker.*pool" --type go
Length of output: 0
Script:
#!/bin/bash
# Search for the interface definition and implementation
rg -A 5 -B 5 'GetPoolAccountsFromStaker' --type go
Length of output: 35521
x/stakers/genesis.go (2)
14-15: Loop refactor from ValaccountList to PoolAccountList is complete and consistent.
This aligns the code with the newly introduced concept of pool accounts.
42-42: Export now references PoolAccountList instead of ValaccountList.
The updated naming remains consistent with the overall refactor.
x/bundles/keeper/msg_server_vote_bundle_proposal.go (1)
49-49: Check function signature alignment for the reordered parameters.
The change from “msg.PoolId, msg.Staker” to “msg.Staker, msg.PoolId” might require verifying that the underlying function has its parameter order updated accordingly.
✅ Verification successful
Parameter order matches the function signature
The resetPoints function in x/bundles/keeper/logic_bundles.go has the exact same parameter order as the call site: stakerAddress followed by poolId. The change is consistent with the function definition.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify we have a matching function definition for resetPoints with staker first, pool second.
rg -A 3 'func\s+\(\w+\s+\*?\w+\)\s+resetPoints\('
Length of output: 405
x/stakers/keeper/msg_server_update_stake_fraction.go (3)
28-28: Logic for decreasing stake fraction is well-structured.
This conditional correctly routes smaller stake fractions to the queue for time-based processing. It helps prevent immediate stake reductions, aligning with security needs.
21-23: Double-check error usage for missing pool account.
Returning ErrUnauthorized may be somewhat misleading if the underlying issue is simply that the pool account does not exist. Consider whether ErrNotFound or a custom error code might better represent the scenario.
✅ Verification successful
Let me gather information about the error types and their usage in the codebase.
Based on the gathered information, I can now provide a final response:
Error type is appropriate for the scenario
The current error handling is actually correct. Here's why:
ErrNoPoolAccount(code 1120) is used as the descriptive error message, properly indicating "sender has no pool account"- Wrapping it with
ErrUnauthorizedis appropriate because:- The check is validating if the sender has authorization to perform the action through an active pool account
- Similar pattern is used consistently in the codebase (e.g., in update_commission.go for pool-related authorization checks)
- The error combination effectively communicates both the authorization failure and the specific reason
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Check error definitions and types
rg "ErrNoPoolAccount" -A 3
rg "ErrUnauthorized" --type go
Length of output: 1158
Script:
#!/bin/bash
# Look for similar error handling patterns with pool accounts
ast-grep --pattern 'if !active {
$$$
return nil, $$$
}'
Length of output: 577
Script:
#!/bin/bash
# Check the error types definition file
fd "errors.go" --type f --exec cat {}
Length of output: 6727
Script:
#!/bin/bash
# Look for other pool account related error handling
rg "GetPoolAccount.*!active" -B 2 -A 2
Length of output: 1047
41-42: Validate stake fraction boundary conditions.
Ensure that the new stake fraction is within acceptable boundaries (e.g., between 0 and 1) before setting it. Consider adding a range check or relevant validation if not already performed elsewhere.
✅ Verification successful
Let me verify if there are any existing validations for the stake fraction by examining the codebase.
From the search results, I found that there is validation for stake fraction in the ValidateBasic() method of MsgUpdateStakeFraction that uses util.ValidatePercentage(). Let me check what this validation does.
Let me check the complete implementation of ValidatePercentage to understand the validation boundaries.
Validation for stake fraction is already properly implemented.
The ValidatePercentage function is used in MsgUpdateStakeFraction.ValidateBasic() and ensures that the stake fraction is:
- Not nil
- Not negative
- Not greater than 1 (using
math.LegacyOneDec())
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for any validation related to stake fraction in the msg types or validation functions
rg -A 5 "StakeFraction"
Length of output: 70082
Script:
#!/bin/bash
# Look for any validation functions in the same file or related files
ast-grep --pattern 'func (msg $_) Validate() error {
$$$
}'
Length of output: 63
Script:
#!/bin/bash
# Check the message type definition to see if there are any validation tags
fd "types" --type f --exec grep -l "StakeFraction" {} \; | xargs cat
Length of output: 69
Script:
#!/bin/bash
# Look for ValidatePercentage implementation
rg -A 5 "func ValidatePercentage"
Length of output: 285
Script:
#!/bin/bash
# Look for any other stake fraction validations in the keeper
rg -A 5 "StakeFraction.*valid"
Length of output: 1362
Script:
#!/bin/bash
# Get the complete implementation of ValidatePercentage
cat util/validate.go
Length of output: 1416
x/stakers/keeper/logic_commission.go (1)
54-55: Check the commission range.
Ensure that the new commission value is in a valid range (e.g., [0%, 100%]). If constraints exist, reinforce them with an explicit validation before setting.
✅ Verification successful
Let me search for any commission validation logic in the codebase.
Let me search for commission validation logic specifically in the message validation and keeper methods.
Let me search for the validation logic in the util package since I see references to util.ValidatePercentage being used for commission validation.
Let me check the complete implementation of ValidatePercentage to understand the validation constraints.
Based on the findings, I can now generate the final response:
Commission validation is already enforced through ValidatePercentage.
The commission value is validated through util.ValidatePercentage() which ensures the value is:
- Not nil
- Not negative
- Not greater than 1 (100%)
This validation is enforced in both MsgJoinPool and MsgUpdateCommission message handlers through their ValidateBasic() methods.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for commission-related validation or range checks
rg -A 5 "Commission.*valid|valid.*Commission"
# Search for commission type definition and constraints
ast-grep --pattern 'type $_ struct {
$$$
Commission $_
$$$
}'
# Search for any commission-related constants that might define bounds
rg "Commission.*=.*\d+"
Length of output: 21307
Script:
#!/bin/bash
# Search for commission validation in message validation
ast-grep --pattern 'func (msg $_) ValidateBasic() error {
$$$
}'
# Search for commission-related validation in keeper methods
rg -A 5 "func.*Commission.*\("
# Search for any commission-related constants or parameters
rg "Commission.*=.*\d|var.*Commission"
Length of output: 66302
Script:
#!/bin/bash
# Search for ValidatePercentage implementation
rg -A 5 "func.*ValidatePercentage"
# Search for any commission-related validation in util package
rg -A 5 "Commission.*valid|valid.*Commission" util/
Length of output: 340
Script:
#!/bin/bash
# Get the full content of validate.go
cat util/validate.go
Length of output: 1416
x/stakers/keeper/logic_stake_fraction.go (1)
54-55: Enforce stake fraction validation.
If your system has requirements for the stake fraction's numeric range, verify that this assignment abides by those constraints.
✅ Verification successful
Let me search for any validation logic or constraints related to stake fraction in the codebase.
Let me search for any validation functions specifically related to stake fraction.
Let me try a different search pattern to find stake fraction validation.
Let me check the actual implementation of ValidatePercentage to see the constraints.
Based on the findings, I can now generate the final response:
Stake fraction validation is properly enforced.
The code already validates the stake fraction through ValidatePercentage() which ensures the value:
- Is not nil
- Is not negative
- Is not greater than 1 (100%)
The validation happens both in MsgUpdateStakeFraction.ValidateBasic() and when joining a pool, providing consistent validation across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for stake fraction validation or constraints
rg -A 5 "StakeFraction"
# Also search for any validation functions that might be related
rg -A 5 "ValidateStake|ValidateFraction|Validate.*Fraction|Validate.*Stake"
Length of output: 68699
Script:
#!/bin/bash
# Search for validation functions in message types and utils
ast-grep --pattern 'func $_ ($_, $_) error {
$$$
if util.ValidatePercentage($_) != nil {
$$$
}
$$$
}'
# Also search for any ValidateBasic implementations
rg -A 5 "ValidateBasic.*MsgUpdateStakeFraction"
Length of output: 165
Script:
#!/bin/bash
# Search for ValidateBasic in the msg types
rg -A 10 "func \(msg \*MsgUpdateStakeFraction\) ValidateBasic\(\)"
# Search for ValidatePercentage usage
rg -A 5 "ValidatePercentage"
# Look at the util package for percentage validation
rg -A 5 "func ValidatePercentage"
Length of output: 5293
Script:
#!/bin/bash
# Get the full implementation of ValidatePercentage
rg -A 10 "func ValidatePercentage" util/validate.go
# Also check if there are any other percentage-related constants
rg "LegacyNewDec|LegacyOneDec|LegacyZeroDec" util/validate.go
Length of output: 456
x/bundles/keeper/msg_server_submit_bundle_proposal.go (1)
26-26: Verify reversed parameter order in resetPoints.
Since the order changed from (PoolId, Staker) to (Staker, PoolId), confirm that the signature and downstream logic in resetPoints aligns with this new order.
✅ Verification successful
Let me verify the parameter order change in the resetPoints function by first checking its implementation.
Let me try a different approach using ripgrep to find the resetPoints function definition and its usages.
Based on the search results, I can now generate the final response:
Parameter order in resetPoints is correctly aligned
The function definition in logic_bundles.go shows resetPoints(ctx sdk.Context, stakerAddress string, poolId uint64) which matches the order used in the call k.resetPoints(ctx, msg.Staker, msg.PoolId). All usages across the codebase consistently use this same parameter order.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for resetPoints function definition
ast-grep --pattern 'func $_resetPoints(ctx $_context.Context, staker string, poolId uint64) $$$'
# Also search with reversed parameter order to be thorough
ast-grep --pattern 'func $_resetPoints(ctx $_context.Context, poolId uint64, staker string) $$$'
Length of output: 197
Script:
#!/bin/bash
# Search for resetPoints function definition and usages
rg -A 5 "resetPoints" --type go
Length of output: 2252
x/bundles/keeper/msg_server_skip_uploader_role.go (1)
21-21: Ordering now aligns with updated method signature.
By passing the staker address before the pool ID, this call to k.resetPoints now correctly aligns with the updated signature in the StakerKeeper interface (ResetPoints(ctx, stakerAddress, poolId)). Good job following the new convention!
testutil/integration/helpers.go (1)
69-84: Consistent renaming reflective of new "pool address" terminology.
The change from “valaddress” to “poolAddress” in both the return signature and switch cases precisely matches the broader nomenclature shift. Be sure to update any related comments, docstrings, or test verifications to keep them aligned with the new naming convention.
x/bundles/types/expected_keepers.go (5)
32-32: Renamed AssertPoolAccountAuthorized fosters clarity.
Renaming AssertValaccountAuthorized to AssertPoolAccountAuthorized improves readability by reflecting the pool-based logic. Ensure all callers are updated to match the new parameter order.
34-34: GetPoolAccount matches the new pool-based model.
The new method name and parameter order effectively convey that we’re retrieving a pool-related account rather than a validator account. Nice refactor.
36-36: LeavePool uses stakerAddress consistently.
Renaming the parameter to stakerAddress clarifies which address is involved, aligning it with the rest of the codebase.
38-39: IncrementPoints and ResetPoints revised for staker-first ordering.
Presenting the staker address before the pool ID keeps method signatures consistent across the interface, reflecting stakers’ primacy in pool operations.
41-41: GetValidator now references stakerAddress.
This shift to stakerAddress further unifies naming across the system. Excellent consistency with the updated framework.
x/stakers/keeper/keeper.go (1)
89-90: Renamed GetPoolAccountsFromStaker is consistent with the pool-centric approach.
Switching from GetValaccountsFromStaker to GetPoolAccountsFromStaker clarifies the data returned. This reliably supports subsequent calls to LeavePool using pool-based logic.
x/stakers/types/keys.go (3)
31-35: Consistency with existing prefix definitions.
These new constants (PoolAccountPrefix and PoolAccountPrefixIndex2) align with the established pattern for prefix definitions. They appear well-organized and follow the same approach as the existing prefix constants, making the code consistent and maintainable.
78-78: Function naming accuracy and consistency.
“PoolAccountKey” clearly indicates that both poolId and staker are used to create a key. This naming is consistent with the new terminology, maintaining clarity across the codebase.
82-82: Index function consistency.
“PoolAccountKeyIndex2” properly mirrors “PoolAccountKey” but in reverse parameter order, which helps in creating efficient bidirectional lookups. This is a solid approach, ensuring consistent naming.
proto/kyve/stakers/v1beta1/tx.proto (1)
70-71: Field rename correctness.
The transition from “valaddress” to “pool_address” is consistent with the new terminology. Keeping the field ID intact (3) ensures backward compatibility in protobuf definitions where feasible.
proto/kyve/stakers/v1beta1/events.proto (1)
66-69: Terminology alignment.
Renaming “valaddress” to “pool_address” and updating the comment ensures consistency throughout the codebase, clarifying the purpose of this field. This change improves readability for developers and end users.
x/stakers/keeper/msg_server_join_pool.go (7)
47-48: Validation check for identical creator and pool address.
Prohibiting the staker from using their own address for the pool (to prevent key reuse) is a solid security measure. The error handling is straightforward, aligning with best practices for input validation.
52-52: Prevention of duplicate pool membership.
The check “if _, found := k.GetPoolAccount(...)” ensures the staker cannot join the same pool twice, reducing the risk of erroneous or duplicate states.
61-66: Enforcing unique pool addresses per staker.
Restricting reuse of a single pool address across multiple pools avoids potential transaction collisions. This is sound logic and aids in preventing account sequence conflicts.
70-75: Preventing misappropriating another staker’s pool address.
Ensuring that each pool address can only belong to one staker in a given pool guards against potential confusion or malicious usage.
79-79: Clearer naming in “AddPoolAccountToPool.”
Switching to this function name aligns with the rename and clarifies that a new pool account is introduced into the pool.
81-81: Fund transfer correctness.
Utilizing “TransferFromAddressToAddress” with “msg.Creator” → “msg.PoolAddress” is correct, ensuring that the staker’s funds reach the designated pool address.
88-88: Event emission alignment.
Renaming the event field to “PoolAddress” harmonizes with the broader change. This keeps the event data in sync with the updated naming scheme, improving observability.
x/query/keeper/grpc_query_can_validate_test.go (12)
20-22: Renamed test case comments to reference "pool address".
No issues identified; the terminology update aligns with the broader refactor.
50-50: Updated PoolAddress field in MsgJoinPool to "PoolAddress".
No functional issues identified; correctly matches the new naming convention.
61-61: Updated second MsgJoinPool call to use "PoolAddress".
Consistent with the naming refactor.
75-76: Query usage changes from "Valaddress" to "PoolAddress".
Implementation appears correct for retrieving the relevant pool account.
86-86: Renamed test title to reference "pool address does not exist".
No issues found.
97-97: Error message updated to "no pool account found".
Matches the new terminology.
100-100: Renamed test title to mention a “pool address” belonging to another pool.
No issues found.
103-104: Updated call to CanValidate with a different PoolAddress.
Correct usage reflecting the new naming.
111-111: Error message references "no pool account found".
Well-aligned with the refactor.
114-114: Renamed test to "Call can validate with a valid pool address".
Documented properly.
117-118: Changed "Valaddress" to "PoolAddress" in request parameters.
Accurately reflects the new naming standard.
89-90: Test inputs updated to "PoolAddress: i.POOL_ADDRESS_2_A".
Ensure that i.POOL_ADDRESS_2_A is valid in this integration test context.
✅ Verification successful
Let me verify the validity of i.POOL_ADDRESS_2_A in the integration test context by checking its definition and usage.
Based on the search results, I can see that i.POOL_ADDRESS_2_A is a valid constant defined in the integration test package and is extensively used across multiple test files. It's defined in testutil/integration/integration.go as:
POOL_ADDRESS_2_A = "kyve1u0870dkae6ql63hxvy9y7g65c0y8csfh8allzl"The constant is used consistently in various test scenarios including staking, bundle validation, and pool operations. It's properly initialized with funds in the integration setup:
_ = suite.MintCoins(POOL_ADDRESS_2_A, 1000*KYVE)Pool address constant is valid and properly initialized for integration tests
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for the definition and usage of POOL_ADDRESS_2_A
rg "POOL_ADDRESS_2_A" -A 3 -B 3
# Look for test setup or initialization where this constant might be defined
ast-grep --pattern 'const POOL_ADDRESS_2_A = $_'
# Search for any struct or type that might contain this constant
ast-grep --pattern 'type $_ struct {
$$$
POOL_ADDRESS_2_A $_
$$$
}'
Length of output: 59641
x/query/keeper/helper.go (6)
16-17: Renamed "GetValaccountsFromStaker" to "GetPoolAccountsFromStaker".
Implementation remains correct, matching the new nomenclature.
19-20: Renamed "accountValaddress" to "poolAddressAccount".
No issues found; keeps naming consistent.
22-22: Renamed "balanceValaccount" to "balancePoolAddress".
Maintains clarity around the updated terminology.
31-31: References to stake fraction change entries updated to new naming.
No concerns; logic is unchanged apart from naming.
56-60: Replaced "Valaddress" fields with "PoolAddress" fields in the returned struct.
Accurate reflection of the new naming convention; no logic issues.
62-62: Renamed "Valaccount" stake fraction to "PoolAccount" stake fraction.
No issues found.
x/bundles/keeper/logic_end_block_handle_upload_timeout.go (1)
114-117: Switched from valaccount references to pool account references in point-adding logic.
Implementation remains unchanged functionally; references align with the naming overhaul.
x/query/keeper/grpc_account_redelegation_test.go (1)
56-56: Renamed "Valaddress" field to "PoolAddress" in MsgJoinPool.
No issues found; updates are consistent across the codebase.
proto/kyve/query/v1beta1/query.proto (1)
134-140: Renamed field from valaddress to pool_address successfully.
The updated comments and field name clearly describe the new pool_address usage for authorization and funding. This change is consistent with the broader rename effort and should improve clarity for pool operations.
x/bundles/keeper/keeper_suite_dropped_bundles_test.go (7)
27-30: Consistent variable renaming from “Valaddress” to “PoolAddress”.
These new variables (initialBalancePoolAddress0, initialBalancePoolAddress1) better reflect the changed semantics of pool-based accounts, aligning with the rename initiative throughout the codebase.
Line range hint 73-83: Use of PoolAddress in MsgJoinPool.
Updating the field to PoolAddress ensures clarity that the staker is referencing a pool-oriented address, consistent with the PR’s objective of renaming valaddress references to pool_address.
89-89: Creator set to PoolAddress.
Replacing Creator = valaddress with Creator = i.POOL_ADDRESS_0_A accurately represents the new concept of the pool account. This improves readability and consistency.
95-98: Initial pool address balances re-initialized correctly.
Storing and comparing the addresses’ balances helps verify correct deposit/withdraw logic. The variable names are aligned with the pool_address rename.
114-114: PoolAddress reference for the new staker’s account.
Ensures newly created staker references the correct pool address variable i.POOL_ADDRESS_2_A. No issues found.
122-122: Creator pool address in MsgSubmitBundleProposal.
Renaming the Creator field to a pool address clarifies the proposal submitter’s role. The logic otherwise remains unchanged.
174-192: Renamed staker references and balances.
• poolAccountUploader and poolAccountVoter records are now aligned with pool-based addresses.
• Points and balances are fetched via the updated references, ensuring consistent usage of pool vs. staker addresses.
All references appear logically correct.
x/bundles/keeper/msg_server_claim_uploader_role_test.go (8)
22-23: Documentation reflects rename from valaccount to pool account.
The updated doc comments maintain clarity and consistency with the rename across tests.
Line range hint 66-76: PoolAddress field in MsgJoinPool.
Correctly replaces valaddress with pool_address. This is fully consistent with the codebase semantics for pool-based stakers.
91-91: MsgClaimUploaderRole uses pool address as Creator.
Accurate use of pool-oriented account for the creator field. Perfectly aligns with the rename objective.
112-112: Claiming uploader role when user is not a staker.
Here, the Creator references i.POOL_ADDRESS_2_A. This test properly verifies behavior for an unregistered staker. The rename remains consistent.
133-133: Handling next-uploader logic with the updated Creator field.
Again, substituting the pool address in MsgClaimUploaderRole ensures the correct referencing of the participant’s pool account. Good job maintaining clarity.
Line range hint 158-169: Validation of non-existing pool account.
Renaming the references in the negative test scenario accurately reflects rejecting claims from invalid pool accounts, rather than valaccounts.
Line range hint 179-216: Rejecting claim from a pool account belonging to another pool.
Adopting i.POOL_ADDRESS_0_B in the newly tested scenario ensures cross-pool checks remain valid. The rename is handled consistently in the negative test flow.
236-243: Preventing a second claimant from overriding the next uploader.
The rename from valaddress to pool_address in these lines maintains consistency, verifying that only the correct Creator can claim.
x/bundles/keeper/msg_server_vote_bundle_proposal_test.go (7)
Line range hint 74-84: Updated stakers’ pool addresses in MsgJoinPool.
Switching from valaddress to pool_address clarifies that these addresses belong to the pool-based stakers, continuing the rename effort.
90-96: Uploader role claimed and bundle proposed with pool address as Creator.
Fields replaced by pool_address references remain clear and functionally equivalent to the original approach.
Line range hint 117-126: Abstain vote actions referencing pool address.
The test logic for multiple abstain votes uses updated pool_address references, validating consistent rename usage.
Line range hint 144-153: Valid vote after abstain with pool address.
Correctly ensures the staker votes under the revised naming scheme. No logic issues detected.
Line range hint 171-180: Invalid vote after abstain using updated pool address.
The test scenario remains unchanged apart from the updated references, preserving the intended coverage.
198-198: Unspecified vote with updated pool address references.
Properly checks invalid vote type while applying the renamed address field. Clear consistency in naming.
Line range hint 225-240: Including third staker with a dedicated pool address.
Having i.POOL_ADDRESS_2_A for STAKER_2 ensures full coverage of multi-staker scenarios. The rename is uniformly applied here as well.
x/stakers/keeper/getters_staker.go (1)
28-29: Verify that staker existence check is correct.
The code checks for validator existence before adding a pool account. Confirm this logic is intended (e.g., ignoring the scenario of adding a pool account for a non-validator).
✅ Verification successful
Let me gather more information about the staker validation logic by examining the codebase.
Let me search for validator-related checks to understand if there's any validation before allowing pool account creation.
Based on the search results, I can now provide a final response as we have found the relevant validation logic.
Validator existence check is correctly implemented
The code in AddPoolAccountToPool explicitly checks for validator existence using GetValidator before attempting to add a pool account. This is intentional as shown in the implementation:
if _, validatorExists := k.GetValidator(ctx, stakerAddress); validatorExists {
if _, active := k.GetPoolAccount(ctx, stakerAddress, poolId); !active {
k.SetPoolAccount(ctx, types.PoolAccount{...})
}
}The check ensures that only valid validators can have pool accounts, which is the intended behavior.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for GetPoolAccount implementation to understand the validation logic
ast-grep --pattern 'func (k Keeper) GetPoolAccount(ctx $_,$_,$_) ($_,$_) {'
# Search for related validator checks
rg -A 5 "GetPoolAccount.*stakerAddress.*poolId"
Length of output: 4398
Script:
#!/bin/bash
# Search for validator checks in the context of pool accounts
rg -B 5 -A 5 "SetPoolAccount.*types\.PoolAccount"
# Look for validator-related functions or checks
ast-grep --pattern 'func $_ IsValidator($_) $_'
# Search for any validator existence checks
rg "validator.*exist" -A 3
Length of output: 3610
x/bundles/keeper/abci_protocol_split_test.go (7)
86-86: Use consistent naming for arguments.
Renaming “Valaddress” to “PoolAddress” is consistent with the new convention. Ensure that any references to the old name in the test descriptions or comments are also updated.
96-96: Same naming pattern.
The rename to PoolAddress similarly appears correct. Continue verifying that all staker-based logic aligns with the new nomenclature.
150-150: Maintain test consistency.
Renaming “Valaddress” to “PoolAddress” here is consistent. Ensure that all test setups involving pool addresses remain coherent to avoid confusion in cross-tests.
158-158: No further changes needed.
Renaming is correct and matches the file’s overall purpose. This is good.
209-209: Double-check local references.
This rename appears correct and consistent with the usage pattern. Ensure any variable referencing the old name in the local scope is updated.
166-166: Keep an eye out for integration.
After referencing this field in additional tests or modules, confirm that all references for “Valaddress” are removed or replaced with “PoolAddress.”
✅ Verification successful
Let me search for any references to "Valaddress" and "PoolAddress" in the codebase to verify this change.
Based on the search results, I can see that the codebase has been consistently using "PoolAddress" throughout, and there are no occurrences of "Valaddress" being used as a field name in the same context. The only occurrences of "Valaddress" are in utility functions and test files where it's used for different purposes (like converting between address types).
Let me generate the final response:
No action needed - field name is consistent.
The codebase consistently uses "PoolAddress" as the field name across all relevant modules and there are no instances where "Valaddress" is used as an alternative field name that needs to be replaced.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for any occurrences of Valaddress and PoolAddress
rg -i "valaddress" -A 2 -B 2
rg -i "pooladdress" -A 2 -B 2
Length of output: 110561
142-142: Check coverage for renamed fields.
Renaming “Valaddress” to “PoolAddress” is good. Make sure any negative or edge-case tests exist to ensure correct usage in all flows.
✅ Verification successful
Let me search for tests related to this field renaming to verify the coverage.
Let me search for more test files and implementations to ensure complete coverage of the renamed field.
Let me search for the struct definition and any other usages of the renamed field.
Let me try one more search to find the struct definition with a different pattern.
Based on the extensive test coverage shown in the search results, I can now provide a final response:
Field renaming is well-tested with comprehensive edge cases.
The renamed field PoolAddress is thoroughly tested across multiple test files with various scenarios including:
- Invalid addresses
- Empty addresses
- Address validation
- Balance checks
- State transitions
- Protocol interactions
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for tests involving PoolAddress
rg -l "PoolAddress.*test"
# Search for test files containing the old field name to ensure complete migration
rg -l "Valaddress.*test"
# Get content of the test file to analyze coverage
cat "x/bundles/keeper/abci_protocol_split_test.go"
Length of output: 8935
Script:
#!/bin/bash
# Search for all test files containing PoolAddress to analyze test coverage
rg -A 5 "PoolAddress" --type go --glob "*test.go"
# Search for the actual implementation to verify the field usage
ast-grep --pattern 'type $_ struct {
$$$
PoolAddress $_
$$$
}'
Length of output: 69375
Script:
#!/bin/bash
# Search for the struct definition and any other usages
rg -A 5 "type.*struct.*{" --type go | rg -A 5 -B 2 "PoolAddress|Valaddress"
# Search for any remaining instances of the old field name
rg "Valaddress" --type go
Length of output: 7667
Script:
#!/bin/bash
# Search for struct definitions containing PoolAddress
rg "type.*\{" --type go -A 10 | rg -A 10 -B 2 "PoolAddress"
# Search for any migration files that might contain the field rename
fd -e go | rg -l "migration|upgrade"
Length of output: 97960
x/stakers/keeper/msg_server_update_commission_test.go (14)
53-53: New field “PoolAddress.”
The switch from valaddress-based logic to poolAddress-based logic is clear. Ensure the “Amount” field is properly validated for each join scenario.
101-102: Same approach for zero commission.
Test logic is solid. The old commission is expected until the update time passes. This ensures stable behavior for boundary values like zero.
122-123: Confirm default after join.
It’s correct to expect the old commission to remain until the update. Keep ensuring that new stakers do not inadvertently pick up uncommitted updates.
129-130: Max boundary test correctness.
Full (100%) commission. This scenario is essential for coverage. Looks well tested.
143-144: Negative commission test.
Rejecting negative values is critical. The test logic is correct, verifying the old commission remains.
157-158: Bounds test coverage.
Confirming >100% commission fails is also correct. Good coverage.
185-186: Multiple commission updates.
Progressive updates test concurrency of commission changes. This approach is a good practice for time-based changes.
192-193: Ensure final update is correct.
The final commission is set to 0.3 after multiple updates, producing a valid final value. Good approach to confirm overrides.
218-219: Check final state with identical values.
Ensures that multiple identical updates do not cause extraneous state changes. Good test coverage.
225-226: Time-based update.
Waiting for the time again ensures the final commission is published. The test logic is consistent.
243-243: Adding new pool coverage.
Creating a second pool to test commission updates on multiple pools is a valuable coverage scenario.
265-269: Multiple pools, single staker.
Verifying separate commission changes across distinct pool IDs is crucial. The approach is correct.
275-279: Confirm final updates.
Both pools reflect the updated commission after the waiting period, ensuring simultaneous updates. Nicely tested.
80-81: Validate post-update commission.
The commission is verified only after the timed update. Confirm the logic is consistent with other tests to avoid confusion on when commission changes apply.
✅ Verification successful
Let me search for related test files and commission update implementations to verify the consistency.
Let me search for the update commission implementation and test cases to understand the timing logic better.
Let me try a different search pattern to find the commission update tests and implementation.
Based on the test file content and implementation, I can now provide a final response:
Commission update verification is consistent with test patterns. The test follows the standard pattern where it verifies both the initial state and post-update state after the commission change time has elapsed. This is consistent across all test cases including:
- Basic commission updates (0% to 100%)
- Multiple updates during change period
- Multi-pool commission updates
- Invalid commission value handling
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for test files related to commission updates
rg -l "Commission.*Test" --type go
# Search for commission-related test assertions
rg "Commission.*Equal" --type go -A 2 -B 2
# Look for commission update implementations
ast-grep --pattern 'func ($x *Keeper) UpdateCommission($$$) {
$$$
}'
Length of output: 41718
Script:
#!/bin/bash
# Search for update commission test cases
rg -A 10 -B 2 "TestMsgServer_UpdateCommission" --type go
# Search for commission update implementation
ast-grep --pattern 'func ($x *MsgServer) UpdateCommission($$$) {
$$$
}'
Length of output: 132
Script:
#!/bin/bash
# Search for update commission test file content
cat x/stakers/keeper/msg_server_update_commission_test.go
# Search for commission update handler
rg "UpdateCommission" --type go -A 5 -B 5
Length of output: 55560
proto/kyve/query/v1beta1/bundles.proto (3)
30-30: Updated path naming.
Switching from “valaddress” to “pool_address” in the URL path is consistent with the broader rename.
185-185: Accurate comment block.
The updated comment clarifies the new endpoint usage. Good job aligning documentation with changes.
192-193: Protobuf field rename.
Renaming “valaddress” → “pool_address” aligns with the code changes. Confirm all references in the project’s pipeline are similarly updated.
✅ Verification successful
Let me search for references to both the old and new field names to verify the changes across the codebase.
Let me modify the search command without specifying file types to ensure we catch all references.
Let me search for proto files to understand the schema changes better.
Let me search specifically for the field rename in the proto files and any generated Go code.
Let me check the specific content of these files to verify the field rename and its impact.
Based on the search results, I can now provide a final response about the field rename from "valaddress" to "pool_address":
Field rename is correctly aligned across the codebase.
The field rename from "valaddress" to "pool_address" appears to be consistently implemented across the proto files and generated code. The new field name "pool_address" is properly used in:
- Query service definitions (proto/kyve/query/v1beta1/bundles.proto)
- Message types in stakers module (proto/kyve/stakers/v1beta1/stakers.proto)
- Transaction messages (proto/kyve/stakers/v1beta1/tx.proto)
No instances of the old field name "valaddress" remain in the proto definitions, suggesting the rename was thoroughly applied.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for references to both "valaddress" and "pool_address" in the codebase
echo "=== Searching for 'valaddress' ==="
rg -i "valaddress" -t proto -t go -t ts -t js
echo -e "\n=== Searching for 'pool_address' ==="
rg -i "pool_address" -t proto -t go -t ts -t js
Length of output: 333
Script:
#!/bin/bash
# Search for references to both "valaddress" and "pool_address" in the codebase
echo "=== Searching for 'valaddress' ==="
rg -i "valaddress"
echo -e "\n=== Searching for 'pool_address' ==="
rg -i "pool_address"
Length of output: 72513
Script:
#!/bin/bash
# Find all proto files and show their content
fd -e proto | while read -r file; do
echo "=== $file ==="
cat "$file"
echo
done
Length of output: 80523
Script:
#!/bin/bash
# Search for the old and new field names in proto files
echo "=== Searching proto files ==="
find . -name "*.proto" -exec grep -l "valaddress\|pool_address" {} \;
# Search for references in Go files
echo -e "\n=== Searching Go files ==="
find . -name "*.go" -exec grep -l "valaddress\|pool_address" {} \;
Length of output: 798
Script:
#!/bin/bash
# Check content of relevant proto files
echo "=== proto/kyve/query/v1beta1/bundles.proto ==="
cat proto/kyve/query/v1beta1/bundles.proto
echo -e "\n=== proto/kyve/stakers/v1beta1/tx.proto ==="
cat proto/kyve/stakers/v1beta1/tx.proto
echo -e "\n=== proto/kyve/stakers/v1beta1/stakers.proto ==="
cat proto/kyve/stakers/v1beta1/stakers.proto
# Check for any references to the old field name
echo -e "\n=== Searching for exact 'valaddress' field references ==="
rg -w "valaddress" -B2 -A2
Length of output: 18224
x/stakers/keeper/msg_server_leave_pool_test.go (28)
52-52: Renamed field to PoolAddress
The code correctly reflects the shift from a validator-based approach to a pool-based approach.
71-73: Good usage of GetPoolAccountsFromStaker
Retrieving the staker's relevant pool accounts aligns with the new naming conventions.
75-85: Validation checks on poolAccount
These checks confirm that the staker and pool IDs are set correctly, including commission and stake fraction. The boolean fields “IsLeaving” help track exit status. Looks good.
87-89: Ensuring only one pool account remains
The assertion ensures the staker is only in a single pool. Logical approach.
103-105: Verifying staker’s pool accounts post-leave
Confirming the staker now has zero active pool accounts. Implementation consistent with the test’s objective.
107-107: Retrieving updated pool account
The code checks the active flag after leaving. Ensures correctness.
111-113: Confirming no accounts remain in the pool
The pool is now empty, matching the expected scenario after the staker leaves.
119-120: Retain commission and stake fraction
This confirms that commission and stake fraction remain stored even after leaving. Correctly aligns with expected logic.
130-130: Renamed field to PoolAddress
Matches the ongoing rename from validator address to pool address.
144-146: Validation of new pool accounts
Asserting the staker still has one active pool account for pool 0 after leaving. Clean approach.
148-158: Check for leaving state
Again verifying that “IsLeaving” is true and that commission & stake fraction remain consistent.
160-162: Validate multiple stakers in the same pool
Ensures an additional staker remains after the first staker leaves.
176-178: Check staker status after finalizing leave
Ensures no active pool accounts remain for staker.
180-186: Assert the pool still has other participants
Verifying that only one staker’s entry remains in the pool.
192-193: Retain commission and fraction
Maintaining leftover commission and fraction data after a staker leaves is correct.
211-212: Re-check staker’s active pool accounts
Ensures that the staker can’t leave the same pool twice before it finishes leaving.
218-219: Finally empties pool account
Once the leave process completes, the staker must have zero pool accounts.
236-236: Assigning PoolAddress
Correctly references “POOL_ADDRESS_1_A” on join.
249-251: Multiple pool membership
Ensures the staker has multiple pool accounts simultaneously.
253-263: Checks pool account after requesting leave
It’s consistent that “IsLeaving” is set to true while stakes remain visible.
265-267: One entry in the pool
Ensures only the newly joined staker remains after the original staker leaves.
279-281: Confirm staker has second pool
Staker still has one other pool (pool 0) in addition to the partially left pool 1.
283-289: Complete departure from pool
Ensures the second pool is empty post-leave. The test logic remains consistent.
295-296: Commission and fraction retention
Ensures final data points remain available even after leaving.
310-311: Pool membership check
Staker_1 is confirmed to have zero pool accounts.
317-318: Ensuring pool account remains empty
No changes in membership. The test aligns with an unchanged scenario.
320-320: Checking for fallback data
Reading the inactive pool account to confirm it’s inert.
325-326: Commission and stake fraction
Since the staker never officially joined, these remain zero. Correctly validated.
x/delegation/keeper/msg_server_redelegate_test.go (1)
76-76: Replaced valaddress with poolAddress
This matches the broader rename strategy across the codebase.
testutil/integration/integration.go (8)
33-36: New staker vs pool addresses
Distinguishing STAKER_0 from POOL_ADDRESS_0_{A,B,C} clarifies responsibilities and usage.
38-42: Clean separation of staker vs pool references
Each address now references a discrete role. Improves readability.
43-47: Continued pattern for STAKER_2 & POOL_ADDRESS_2_x
Consistent naming fosters simpler, clearer test scenarios.
48-51: Third staker & addresses
No issues found. This fits the same rename pattern.
127-129: Minting coins for newly named pool addresses
Ensures that each separate pool address has sufficient initial balance for testing.
132-134: Extending mint for pool 1
Again consistent with the rename, each pool address receives test funding.
137-139: Pool 2 addresses
Duplicates the pattern for consistent test coverage.
142-144: Pool 3 addresses
Ensures each pool address has a baseline of minted tokens for integration tests.
x/bundles/keeper/msg_server_submit_bundle_proposal_test.go (13)
76-76: Use of PoolAddress in MsgJoinPool
Reflects the new naming schema; no further issues.
86-86: Renamed to PoolAddress
Similar consistency fix, aligning the staker’s address with the correct “pool address.”
92-92: Claim uploader role using PoolAddress
Accurately updates the “Creator” field to the newly named pool address.
108-108: Submit bundle proposal using PoolAddress
Ensures the “Creator” references the correct pool entity.
134-134: Bundle size limit test
Now referencing the correct address name. No functional changes.
160-160: Empty bundle scenario
Again “Creator” is pool-based, aligned with the codebase rename.
186-186: Empty ‘from key’ test
Uses the correct new PoolAddress. Implementation is coherent.
212-212: Empty ‘to key’ test
Renamed address field remains consistent with pool-based naming.
238-238: Invalid index scenario
Address rename is correct.
264-264: Zero data size test
Valid usage of “Creator” field.
303-303: Empty data hash test
Naming remains consistent, no functionality broken.
342-342: Empty bundle summary test
Leverages the new naming. No further improvements needed.
381-381: Valid bundle proposal
Correct final usage of “Creator” for a successful proposal with new naming.
x/query/keeper/grpc_query_can_vote_test.go (34)
29-29: Consistent documentation update referencing “pool account”.
No issues here.
74-74: Pool address usage.
Renaming from valaddress to pool address looks consistent.
85-85: Ensuring correct pool address reference for second staker.
Looks aligned with the new naming convention.
92-92: Renamed field in MsgClaimUploaderRole.
Matches the new “pool address” usage.
100-100: Renamed “Creator” field in MsgSubmitBundleProposal.
No functional issues detected, rename is coherent.
122-122: Testing canVote with a pool that doesn't exist.
Logic is correct for verifying a missing pool.
133-133: Consistent rename to pool address in MsgVoteBundleProposal.
No issues, code reads clearly.
160-160: Check for upgrading pool referencing pool address.
Implementation aligns with the new naming approach.
171-171: Voting against an upgrading pool.
Usage of pool address is correct and consistent.
193-193: Pool disabled scenario with pool address.
The rename is properly integrated.
204-204: Voting with a disabled pool, referencing pool address.
No concerns identified.
227-227: Validating if the pool meets minimum stake.
Logic remains consistent post-rename.
238-238: MsgVoteBundleProposal with the updated address.
Syntax and semantics are correct.
249-249: Comment describing “Call can vote with a pool account that does not exist”.
Appropriate rename in the doc.
254-254: QueryCanVoteRequest referencing unknown pool address.
Error handling is as expected.
262-262: Reason updated to ErrPoolAccountUnauthorized.
Consistent rename.
265-265: MsgVoteBundleProposal call with unauthorized pool address.
No issues found.
286-286: Voting on a dropped bundle referencing new field names.
Renaming is correct.
297-297: MsgVoteBundleProposal referencing new pool address field.
Everything is consistent.
313-313: Checking storage id mismatch.
Renamed fields remain functional.
324-324: MsgVoteBundleProposal with mismatch storage.
Looks good.
338-338: Initial vote cast as valid.
Pool address usage is properly updated.
351-351: QueryCanVoteRequest for repeated valid vote scenario.
Rename appears consistent.
362-362: Second valid vote attempt with updated address.
Error handling logic remains unaffected.
376-376: Casting an invalid vote referencing pool address.
Looks good.
389-389: Query for repeated invalid vote.
Renamed references are consistent.
400-400: Second attempt to vote invalid with the new address.
No issues.
414-414: Casting an abstain vote referencing new field.
Renaming is correct.
427-427: Query for repeated abstain vote scenario.
Implementation looks fine.
438-438: Second vote attempt with updated pool address.
Flow is consistent post-rename.
453-453: Checking canVote on an active pool with valid arguments.
Rename to pool address is correct.
464-464: Submitting a bundle proposal with the new “Creator” reference.
All good.
486-486: Test scenario for an active pool lacking funds.
Renaming from valaddress to pool address is consistent.
497-497: MsgVoteBundleProposal referencing updated fields.
No issues.
x/bundles/keeper/logic_round_robin_test.go (1)
46-46: Changed field to “PoolAddress” in MsgJoinPool.
Matches the shift to pool-based naming.
x/bundles/keeper/msg_server_skip_uploader_role_test.go (25)
70-70: MsgJoinPool with PoolAddress.
Rename is accurate.
80-80: Second staker joining with updated pool address field.
Consistent rename.
86-86: MsgClaimUploaderRole referencing updated creator field.
No issues found.
96-96: Third staker joining with new pool address.
Change aligns with the new naming.
105-105: MsgSubmitBundleProposal using PoolAddress for creator.
No concerns.
126-126: MsgVoteBundleProposal by staker #1 with updated address.
Rename is correct.
134-134: Abstain vote referencing new pool address field.
Looks fine.
146-146: MsgSkipUploaderRole with updated addresses.
No functional issues.
179-181: Loop verifying pool accounts after skipping.
Implementation is correct with the rename.
188-188: Second scenario: staker #1 skipping the uploader role.
Renaming is consistent.
196-196: Second abstain vote.
Everything is aligned with pool address usage.
207-207: First skip attempt for staker #1.
All good.
218-218: Second skip attempt from staker #0.
No issues.
251-253: Loop verifying that no validator got a point.
Properly references updated address.
268-268: Skipping uploader role on a dropped bundle.
Rename is consistent.
300-303: Verifying zero points for staker_0.
Correct check post-rename.
306-306: Ensuring other stakers get a point.
Logic is correct.
314-314: Voting valid with updated creator and staker references.
Renaming is consistent.
322-322: Second valid vote referencing pool address.
Implementation is coherent.
334-334: Skip uploader role for staker #1 with new naming.
All good.
367-369: Verifying no points assigned for the second round.
Pool address usage is correct.
376-376: Voting invalid referencing the new addresses.
Implementation is correct.
384-384: Second invalid vote by staker #2.
No concerns identified.
396-396: Skipping the uploader role after invalid votes.
Renaming is consistent.
426-428: Ensuring no finalized bundle or points assigned.
All references are correct.
x/query/keeper/grpc_query_can_propose_test.go (32)
30-30: Doc line referencing call with a non-existent pool account.
No issues.
73-73: MsgJoinPool using i.POOL_ADDRESS_0_A.
Rename is correct.
84-84: MsgJoinPool for second staker with pool address.
No functional concerns.
91-91: MsgClaimUploaderRole referencing updated address.
Looks fine.
99-99: MsgSubmitBundleProposal with new “Creator” reference.
Post-rename usage is consistent.
113-113: MsgVoteBundleProposal with updated address.
Nothing problematic.
132-132: Check canPropose on non-existent pool with new address.
Implementation is correct.
143-143: MsgSubmitBundleProposal referencing i.POOL_ADDRESS_1_A.
Rename is consistent.
176-176: Pool upgrading scenario with updated addresses.
Logic remains correct.
187-187: Submitting a bundle proposal referencing pool address.
No issues found.
215-215: Pool disabled scenario, new field references.
Implementation is accurate.
226-226: MsgSubmitBundleProposal with new address.
Rename looks good.
255-255: Checking canPropose for minimum stake scenario.
Renaming is consistent.
266-266: Bundle proposal referencing new “Creator”.
No problems identified.
283-283: Documentation line for pool account existence check.
Rename is correct in doc.
288-288: QueryCanProposeRequest referencing i.POOL_ADDRESS_1_A.
Checks for unauthorized pool account.
296-296: Error message updated to ErrPoolAccountUnauthorized.
Consistent with new naming.
299-299: MsgSubmitBundleProposal for unauthorized staker.
No issues in logic.
328-328: QueryCanProposeRequest for staker that is not the next uploader.
Rename remains consistent.
335-335: Alternate scenario for staker_0.
Implementation is correct.
355-355: MsgSubmitBundleProposal from staker_1 with updated fields.
No issues found.
369-369: MsgSubmitBundleProposal from staker_0 scenario.
Logic remains unaffected.
399-399: Checking upload interval with new pool address.
Rename is correct.
412-412: MsgSubmitBundleProposal referencing i.POOL_ADDRESS_1_A.
No functional issues.
434-434: First invalid fromIndex scenario in QueryCanProposeRequest.
Renaming is used correctly.
441-441: Second scenario with fromIndex mismatch.
Implementation is consistent.
459-459: Submitting a bundle proposal with incorrect fromIndex = 99.
Error message logic is correct.
476-476: Submitting a bundle proposal with fromIndex = 101.
Matches the error logic.
498-498: CanPropose on an active pool with valid arguments.
Rename to pool address is correct.
509-509: MsgSubmitBundleProposal from staker_1 with updated address.
No concerns.
537-537: CanPropose on a pool with zero funds.
Renamed fields remain functional.
548-548: Submitting bundle proposal from staker_1 on a zero-funded pool.
Implementation is consistent.
x/stakers/keeper/msg_server_update_stake_fraction_test.go (27)
60-60: Use consistent naming for new field.
The new "PoolAddress" field enhances clarity. Ensure all references align with the updated naming scheme.
73-74: Validate default stake fraction retrieval.
The test confirms the stake fraction. Looks correct and aligns with the new "GetPoolAccount" usage.
89-90: Test for correct stake fraction after increase.
Good assertion logic verifying the 50% fraction.
105-106: Immediate stake fraction correctness.
During the change time, the stake fraction is still the old value. This partial check ensures known intermediate state.
113-114: Check post-wait stake fraction.
Ensures correct final fraction after the update window.
129-130: Initial fraction logic repeated.
Mirrors the pattern in previous tests, verifying fraction prior to the wait period.
138-139: Fraction consistency after wait.
Test confirms final fraction is 1%.
154-155: Edge case of 100% stake fraction.
Ensures that a full stake fraction is correctly handled and computed.
170-171: No-op update scenario.
Tests that re-setting the fraction to the same value does not change outcomes.
186-187: Negative fraction check.
Properly rejects negative fraction. The code logic is correct.
202-203: Fraction above maximum.
Properly rejects stake fraction exceeding 1.
225-226: Correct fraction change after multiple updates.
Test ensures the final fraction is the last one submitted.
234-235: Check final fraction after update window.
Verifies that the fraction is updated to 0.2.
257-258: Decreasing fraction logic.
This test ensures the fraction remains unchanged until the change time has passed.
266-267: Zero wait fraction verification.
Checks that final fraction becomes 0.01.
280-281: Mid-test partial assertion.
Ensures fraction is 0.5 before new update.
295-296: Immediate fraction prior to wait.
Remains 0.5 because the new fraction has not taken effect yet.
304-305: Ensure fraction changed to 0.02.
Validates final fraction after wait.
324-324: Second pool join with new PoolAddress.
Correct usage of “PoolAddress” for newly joined pool.
346-347: Multiple pools: Check poolAccount0.
Verifies stake fraction is updated on the first pool.
351-352: Multiple pools: Check poolAccount1.
Ensures the fraction is still 0.1 before the wait period.
360-361: After wait, poolAccount0 remains at 0.5.
Test logic is correct for final fraction.
365-366: After wait, second pool fraction is now 0.03.
Verifies final fraction for Pool 1.
373-374: Validator stake increase for unchanged fraction.
Asserts that stake fraction remains 0.1, while total stake grows.
382-383: Post-delegation check.
Confirms fraction remains stable and stake is proportionally adjusted.
390-391: Validator stake decrease test arrangement.
Setup for verifying fraction stability on self-undelegate.
404-405: Stake fraction remains the same after undelegation.
Valid test to ensure consistent fraction behavior.
x/bundles/keeper/keeper_suite_points_test.go (34)
73-73: Joining pool with PoolAddress.
Ensures consistency with referencing the correct address type.
83-83: Second staker uses PoolAddress.
Mirrors the approach for other stakers to keep naming uniform.
93-93: Third staker uses PoolAddress.
All stakers now consistently use pool-based addresses.
106-106: MsgSubmitBundleProposal uses Creator = PoolAddress.
Ensures proposals are submitted from the correct pool account.
120-120: MsgVoteBundleProposal uses Creator = PoolAddress.
Consistent approach for staker references.
139-139: Submit second proposal from staker 0.
Reflects new naming convention for the bundle’s Creator field.
153-154: PoolAccount accumulation of points.
Checks that staker 2’s non-participation increments points.
162-162: Submit another proposal from staker 0.
Intermediate step ensuring continuity of pool-based references.
177-177: Vote with staker 2’s PoolAddress.
Proper references for the voting logic.
187-187: Staker 1 submitting a new proposal.
Consistent usage of “Creator: i.POOL_ADDRESS_1_A”.
201-202: Points for staker 2 reset.
Demonstrates that once they vote, their accumulated points are cleared.
214-214: Loop for multiple bundle proposals with staker 0.
Continues consistent usage of “Creator: i.POOL_ADDRESS_0_A”.
228-228: Staker 1 votes validly.
No comment about staker 2, verifying point accumulation scenario.
241-242: Three missed votes yield 3 points.
Correctly asserts staker 2’s points after repeated non-votes.
254-254: Same multiple-proposal scenario.
Again referencing staker 0 with pool-based address.
268-268: Staker 1 votes again.
Continues the pattern of correct usage of “Creator: i.POOL_ADDRESS_1_A”.
282-282: Staker 2 finally votes.
Ensures point reset logic for staker 2.
292-292: New proposal from staker 1.
Matches the pattern for voting tests.
306-307: Staker 2's points become zero.
Confirmed by “GetPoolAccount”.
322-322: Loop for missed votes up to max points.
Consistently referencing “Creator: i.POOL_ADDRESS_0_A”.
336-336: Staker 1 votes again.
Detailed test for repeated non-vote from staker 2.
355-356: After reaching max points, staker 2 is removed.
Checks that “GetPoolAccount(s.Ctx(), i.STAKER_2, 0)” is inactive.
374-374: Three missed votes scenario.
Again referencing staker 0’s pool address.
388-388: Staker 1 remains consistent in voting.
All references to address are updated properly.
407-407: Staker 2 submitting the bundle.
Demonstrates staker 2 can submit after repeated non-votes.
421-423: Points increment instantly after submission.
Staker 2 still not voting on own proposal → gets 1 point.
435-435: Another loop to skip votes.
Maintains consistent usage of “Creator: i.POOL_ADDRESS_0_A”.
449-449: Staker 1 validly votes.
Again consistent references for “Creator: i.POOL_ADDRESS_1_A”.
468-468: Skips uploader role with staker 2’s PoolAddress.
Appropriately references the new pool address field.
475-476: Check that staker 1’s points remain zero.
Points logic validated for unaffected staker.
490-490: Multiple missed votes up to maxPoints - 1.
Reiterates same logic for staker 0 proposals.
504-504: Staker 1 consistently voting.
Ensures staker 2 accumulates points.
523-523: Staker 2 reaches max points upon own submission.
Reflecting final step to accumulate a point on missed self-vote.
537-539: Checks that staker 2’s points are now 1.
Completes logic for non-voting scenario.
x/pool/keeper/msg_server_disable_pool_test.go (13)
373-373: JoinPool using PoolAddress.
Ensures field name “PoolAddress” is properly updated.
384-384: Second staker also uses PoolAddress.
Keeps address references consistent for pool membership.
395-395: Check total PoolAccounts and stakers pre-disable.
Ensures correct count before the pool is disabled.
415-415: Validate no PoolAccounts remain after disable.
Kicks out all stakers from the disabled pool.
439-439: Staker joins first pool with PoolAddress.
Aligns with the new naming convention.
448-448: Same staker joins second pool with another PoolAddress.
Proves multi-pool membership references.
459-459: Different staker joining the first pool.
Again uses “PoolAddress” to maintain uniform usage.
470-470: Check total threads of PoolAccounts.
Ensures that 3 pool accounts exist at this point.
490-490: 1 pool account remains after disable.
Stakers in the first pool are removed but remain in other pools.
514-514: Staker 0 uses new PoolAddress to join.
Maintains the updated naming for pool membership.
525-525: Staker 1 also uses PoolAddress to join.
Keeps address usage uniform among stakers.
532-532: ClaimUploaderRole references i.POOL_ADDRESS_0_A.
Updated from valaddress to the new pool-based address.
540-540: SubmitBundleProposal with i.POOL_ADDRESS_0_A.
Correct usage of new field to identify the uploading staker.
testutil/integration/checks.go (4)
126-126: Query stakers by pool.
Line references the new “GetAllPoolAccountsOfPool”.
129-131: Iterate over poolAccounts.
Renaming to “poolAccount” clarifies these are pool-based, not validator-based.
477-482: Replace valaccount references with poolAccount.
The changes in this block ensure the staker’s pool membership fields are accessed correctly.
499-500: Reverse check of pool memberships.
Now uses “GetPoolAccountsFromStaker” to validate all associations.
x/delegation/keeper/msg_server_undelegate_test.go (1)
82-82: Zero amount for pool joining.
Joining the pool with a zero “Amount” can be intentional if the protocol allows a staker to join without initial funds. Confirm that zero stake is valid per business logic.
✅ Verification successful
Let me gather information about the pool joining logic and zero amount validation by examining the codebase.
This will help us understand:
- The pool joining implementation and any amount validation
- Test cases that verify pool joining behavior
- Amount validation patterns in delegation-related code
Let me search more specifically for delegation-related code and validation logic.
This will help us understand:
- The undelegation implementation and validation
- Any minimum delegation amount requirements
- The full context of the test file where the zero amount is being used
Based on the test file content and the search results, I can now generate the final response. The test file shows this is a test case where PoolAddress with zero amount is being used in a test setup, and the codebase shows that pools have a MinDelegation parameter that is explicitly checked.
Zero amount pool joining is valid in test context
The zero amount in PoolAddress is intentionally used in the test setup as it's testing the join pool functionality separately from delegation amounts. The codebase validates minimum delegation requirements through the MinDelegation parameter, which is checked during actual operations (as seen in x/bundles/keeper/logic_bundles.go). The test is correctly structured to verify the protocol's behavior.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for pool joining related code and amount validation
ast-grep --pattern 'func ($x *Keeper) JoinPool($$$)'
# Search for test cases related to pool joining
rg -A 5 "TestJoinPool"
# Search for amount validation in delegation related files
rg -A 5 "Amount.*pool" --type go
Length of output: 2104
Script:
#!/bin/bash
# Search for delegation validation logic
ast-grep --pattern 'func ($x *Keeper) Undelegate($$$)'
# Look for minimum delegation amount checks
rg -A 5 "MinDelegation" --type go
# Search for the test file content to understand the context
cat x/delegation/keeper/msg_server_undelegate_test.go
Length of output: 66264
x/stakers/keeper/keeper_suite_effective_stake_test.go (5)
66-66: Renaming valaddress to pool address (group 1).
All these lines transition from valaddress to PoolAddress, aligning with naming consistency.
Also applies to: 76-76, 86-86, 110-110, 120-120, 130-130
154-154: Renaming valaddress to pool address (group 2).
Consistently adopting "PoolAddress" across these staker join operations, which improves clarity.
Also applies to: 164-164, 174-174, 198-198, 208-208, 218-218
236-236: Renaming valaddress to pool address (group 3).
These changes further unify the codebase under the new address naming convention.
Also applies to: 246-246, 256-256, 278-278, 288-288, 298-298, 318-318, 328-328, 338-338, 358-358
378-378: Renaming valaddress to pool address (group 4).
Maintains consistent usage of “PoolAddress” in staker modules.
Also applies to: 388-388, 398-398, 422-422, 432-432, 442-442, 466-466, 476-476, 486-486, 508-508
518-518: Renaming valaddress to pool address (group 5).
This final batch of changes completes the shift toward “PoolAddress” references.
Also applies to: 528-528, 550-550, 560-560, 570-570
x/bundles/keeper/logic_bundles.go (3)
62-62: Refactoring to AssertPoolAccountAuthorized (group 1).
Transition from valaddress to pool address in “AssertCanVote” and “AssertCanPropose” ensures consistent naming.
Also applies to: 102-102
183-183: Updating addPoint function (group 3).
Functions now accept the staker address first, reinforcing the pool account approach. The reordering is consistent with the shift away from valaddress.
Also applies to: 185-185, 187-187, 197-197, 198-198
224-224: Line adjustments in handleNonVoters and slash conditions (group 4).
Adopting “PoolAddress” references and staker-first parameters. This unified approach aids clarity.
Also applies to: 586-586, 605-605, 607-607
x/bundles/keeper/keeper_suite_zero_delegation_test.go (7)
30-30: Renaming and usage of pool addresses (group 1).
These sections streamline reference to pool addresses. The zero delegation context remains consistent.
Also applies to: 39-39, 42-42, 96-96, 106-106, 112-112, 120-120, 134-134
147-147: Renaming and usage of pool addresses (group 2).
Adapting “PoolAddress” within join, claim, submit, and vote processes for uniform address usage.
Also applies to: 154-154, 170-170, 197-197, 207-207, 213-213, 221-221, 240-240
247-247: Renaming and usage of pool addresses (group 3).
Continues the shift to pool addresses for staker and bundle interactions.
Also applies to: 255-255, 271-271, 305-305, 316-316, 327-327, 340-340, 354-354
362-362: Renaming and usage of pool addresses (group 4).
Further references to pool addresses in zero-delegation staker logic.
Also applies to: 372-372, 375-375, 379-379, 437-437, 438-438, 440-440, 441-441
443-443: Renaming and usage of pool addresses (group 5).
Ensuring staker, pool account, and reward distribution code references align with the new naming scheme.
Also applies to: 446-446, 447-447, 449-449, 450-450, 452-452, 604-604, 607-607
608-608: Renaming and usage of pool addresses (group 6).
Maintains consistency in slash logic, verifying zero delegation scenarios.
Also applies to: 625-625, 626-626, 628-628, 629-629, 631-631, 651-651, 662-662
673-673: Renaming and usage of pool addresses (group 7).
Completes the migration to pool addresses. Zero-delegation tests remain valid.
Also applies to: 686-686, 700-700, 719-719, 733-733, 752-752, 753-753, 792-792
x/bundles/keeper/logic_bundles_test.go (20)
108-108: Renamed valaddress to pool_address.
All references within this test case reflect the new naming scheme accurately.
Also applies to: 119-119
139-139: Valaddress → PoolAddress rename applied.
No issues detected; the rename is consistent with the PR objectives.
Also applies to: 150-150
175-175: Pool address usage confirmed.
Looks correct for the “min delegation not reached” test scenario.
Also applies to: 186-186
224-224: Terminology update validated.
Matches the new naming standard for joining the pool.
Also applies to: 235-235
273-273: Pooling logic unaffected by rename.
No code anomalies spotted in the “voting power is 40%” and “exceeds 40%” tests.
Also applies to: 284-284, 295-295
335-335: Adoption of pool address nomenclature.
Implementation remains consistent with the earlier rename.
Also applies to: 346-346, 357-357
397-397: Maintains consistent usage of PoolAddress.
Test coverage for multiple stakers aligns well with the rename.
Also applies to: 417-417, 428-428
466-466: Valid check for no funds scenario.
No functional change apart from naming; logic is sound.
Also applies to: 477-477
513-513: Updated references in voting assertion tests.
The rename accurately reflects pool-based addressing.
Also applies to: 524-524, 531-531, 539-539
557-557: Renaming staker → pool references.
Test logic remains intact, referencing the correct address variables.
Also applies to: 560-560
570-570: Consistent pool address usage in multiple voting steps.
All staker references changed accordingly; test flow unchanged.
Also applies to: 581-581, 588-588, 596-596, 614-614
627-627: Continued alignment with pool address rename in voting validations.
No additional concerns detected; tests remain valid.
Also applies to: 638-638, 645-645, 654-654, 670-670
683-683: Renamed addresses in valid/invalid voting tests.
Implementation updates match the new scheme without logic regressions.
Also applies to: 694-694, 701-701, 710-710, 727-727, 735-735
748-748: Address rename in repeated voting scenarios.
No functional changes beyond the naming; verified correctness.
Also applies to: 759-759, 766-766, 775-775, 792-792, 800-800
813-813: Rename completeness check in final voting scenario.
All references to valaddress replaced with pool_address properly.
Also applies to: 824-824, 831-831, 840-840, 857-857
872-872: Elimination of valaddress references in propose checks.
Integration with code logic remains smooth; no side effects seen.
Also applies to: 883-883, 890-890, 899-899, 902-902
912-912: Ensured consistent naming for designated uploader checks.
The usage of i.POOL_ADDRESS_x_A is coherent with new naming.
Also applies to: 923-923, 930-930, 939-939
952-952: Refined references in interval and index mismatch checks.
Naming updates align well with PR's renaming strategy.
Also applies to: 963-963, 970-970, 979-979
995-995: Renamed address usage in propose checks.
Everything is updated safely for the stakers keeper logic.
Also applies to: 1006-1006, 1013-1013, 1022-1022
1035-1035: Consistent rename in final propose scenario.
Test references reflect the new pool address naming with no logic regressions.
Also applies to: 1046-1046, 1053-1053, 1062-1062
x/bundles/keeper/keeper_suite_funding_bundles_test.go (12)
112-112: Joined pool references switched to pool_address.
Name alignment is correct and consistent with the rest of the codebase.
Also applies to: 122-122, 128-128
150-150: Pool address rename in first “valid bundle” test.
No functional regressions; naming updated in message creators and stakers.
Also applies to: 164-164, 175-175
231-231: Renamed addresses in “valid bundle with multiple funders” scenario.
Ensures uniform usage of PoolAddress in funder logic.
Also applies to: 245-245, 256-256
318-318: Address rename in multiple funders with different amounts test.
All references reflect the standardized pool address naming.
Also applies to: 332-332, 343-343
405-405: Consistent pool address usage in limited-funds scenario.
Renaming merges seamlessly with funder-based test coverage.
Also applies to: 419-419, 430-430
486-486: Correct rename in single-funder insufficient reward scenario.
All references to staker addresses properly updated to pool addresses.
Also applies to: 500-500, 511-511
567-567: Renamed addresses in multi-funder scenario with insufficient funds.
No functionality changes aside from the naming convention.
Also applies to: 581-581, 592-592
646-646: Nomenclature alignment in a dropped-bundle scenario.
Appropriate references to pool addresses remain consistent with the rename.
Also applies to: 660-660, 671-671
713-713: Unfunded pool scenario uses new pool address references.
Renaming is in sync with the rest of the code.
Also applies to: 727-727, 744-744
783-783: Renamed addresses in multi-coin single-funder scenario.
All references properly reflect PoolAddress usage.
Also applies to: 797-797, 808-808
864-864: Multi-funder multi-coin scenario with updated pool addresses.
Change is localized to naming, no hidden logic differences found.
Also applies to: 878-878, 889-889
944-944: Renamed addresses in single-funder partial coverage scenario.
The code consistently uses pool_address references for stakers.
Also applies to: 958-958, 969-969
x/stakers/keeper/msg_server_join_pool_test.go (29)
29-29: Test descriptions updated to reflect pool_address usage.
No functional changes; the doc lines simply match the rename.
Also applies to: 30-30, 31-31, 32-32, 33-33, 34-34, 35-35, 38-38, 39-39, 40-40, 41-41, 46-46, 47-47
55-55: Initial balances for staker vs. pool address now labeled properly.
Naming is consistent with the new structure.
Also applies to: 56-56
79-79: Balance tracking variables use pool address naming.
This ensures clarity in the test setup regarding staker/pool accounts.
Also applies to: 80-80
89-89: “GetPoolAccountsFromStaker” confirms no pools joined.
Renaming from valaddress to pool_address is properly reflected in test code.
Also applies to: 90-90
98-98: Join pool references updated to correct pool_address fields.
All occurrences align with the code’s new naming convention.
Also applies to: 106-106, 109-109, 111-111, 113-113, 115-115, 119-119, 120-120, 121-121, 122-122, 123-123, 125-125, 127-127
Line range hint 139-139: Checks for disabled pool with changed pool address references.
No logical changes except standardizing the naming usage.
Also applies to: 150-150, 156-156, 166-166, 169-169, 171-171, 173-173, 175-175, 179-179, 181-181
198-198: Updated addresses in multi-staker arrangement.
Renaming is correctly implemented in relevant fields and checks.
Also applies to: 208-208, 216-216, 219-219, 221-221, 223-223, 225-225, 229-229, 230-230, 231-231, 232-232, 233-233, 235-235, 237-237
251-251: Self-delegation test with new pool address references.
All modifications revolve around valaddress → pool_address with no side effects.
Also applies to: 268-268, 270-270, 272-272, 276-276, 277-277, 278-278, 279-279, 280-280, 282-282, 284-284
294-294: Prevent joining the same pool with the same pool address (renamed).
Renaming preserves test behavior for duplicate pool attempts.
Also applies to: 299-299, 309-309, 316-316, 318-318
321-321: Error on using staker address as pool address.
Rename adheres to new domain logic; test remains valid.
Also applies to: 326-326, 333-333, 335-335
338-338: Reject re-join with different pool address in same pool.
No issues found; addresses properly reflect the updated naming.
Also applies to: 343-343, 353-353, 360-360, 362-362
365-365: Block using the same pool address in another pool.
Renaming is fully consistent, ensuring the uniqueness logic remains correct.
Also applies to: 370-370, 389-389, 396-396, 397-397
400-400: Disallow staker from using an address already taken by another staker.
All references match the new naming patterns without altering core logic.
Also applies to: 416-416, 426-426, 433-433, 434-434
437-437: Prevent joining with an address used by another staker in same pool.
No functional changes besides the rename; test logic stands.
Also applies to: 442-442, 454-454, 461-461, 462-462
465-465: Join a different pool with a different pool address scenario.
Renaming approach is consistent, and test remains robust.
Also applies to: 470-470, 489-489, 495-495, 496-496
499-499: Disallow empty pool address usage.
Naming updates do not affect the empty string rejection logic.
Also applies to: 504-504, 511-511, 512-512
520-520: Prevent join with empty commission field.
The new references remain correct in the error-check logic.
Also applies to: 526-526, 527-527
533-533: Disallow joining with no stake fraction.
Renamed addresses remain logically consistent in test outcome.
Also applies to: 534-534, 535-535, 536-536, 537-537, 541-541, 542-542
545-545: Allow joining with an unregistered pool address.
Renaming does not disrupt the test’s intended coverage.
Also applies to: 550-550, 563-563, 565-565, 567-567, 571-571, 572-572, 573-573, 574-574, 575-575, 577-577, 579-579
588-588: Join with new pool address but send 0 funds.
Naming standard remains consistent, logic remains intact.
Also applies to: 593-593, 606-606, 608-608, 610-610, 614-614, 615-615, 616-616, 617-617, 618-618, 620-620, 622-622
631-631: Reject invalid pool address attempt.
Test steps remain valid under the new address naming paradigm.
Also applies to: 636-636, 643-643, 645-645
648-648: Block exceeding available balance for pool address.
Naming changes do not affect the insufficient balance scenario logic.
Also applies to: 653-653, 660-660, 662-662
672-672: Kick out lowest staker: references updated to new addresses.
Renaming is consistent; no side effects in logic for joining a full pool.
Also applies to: 683-683, 699-699
717-717: Fail to kick out staker if stake insufficient, addresses updated.
No concerns beyond the naming shift.
Also applies to: 728-728, 744-744
763-763: Kick out logic respects combined stake + delegation; address rename.
Implementation stands unchanged aside from naming.
Also applies to: 774-774, 796-796
815-815: Fail to remove staker with insufficient stake + delegation, rename.
Pool address usage consistent with new domain model.
Also applies to: 826-826, 842-842
861-861: Fail to remove staker lacking enough stake + delegation: references fixed.
All references reflect the new naming, preserving logic.
Also applies to: 872-872, 894-894
906-906: Re-join pool with the same pool address after leaving.
Renaming is uniform; test scenario is unaffected.
Also applies to: 911-911, 926-926, 933-933, 941-941, 944-944, 946-946, 950-950, 954-954, 955-955, 956-956, 957-957, 958-958, 959-959, 960-960, 962-962, 964-964
974-974: Re-join pool with a different pool address after leaving.
Consistent naming in staker and address references; logic stands intact.
Also applies to: 979-979, 994-994, 1001-1001, 1009-1009, 1010-1010, 1013-1013, 1014-1014, 1016-1016, 1020-1020, 1024-1024, 1025-1025, 1026-1026, 1027-1027, 1028-1028, 1029-1029, 1030-1030, 1032-1032, 1034-1034
x/bundles/keeper/keeper_suite_invalid_bundles_test.go (7)
33-33: Initial staker vs. pool address balances named properly.
This clarifies the difference between staker accounts and pool accounts in tests.
Also applies to: 39-39, 42-42, 45-45
82-82: Post-funding updates for pool addresses.
Rename from valaddress to pool_address is maintained consistently.
Also applies to: 85-85, 88-88
102-102: Multiple validators scenario uses consistent pool address references.
Renaming does not disrupt logic for invalid bundle tests.
Also applies to: 112-112, 120-120, 138-138, 144-144, 147-147, 150-150, 154-154, 162-162, 172-172, 219-219, 222-222, 241-241, 242-242, 244-244, 245-245, 253-253, 254-254, 256-256, 257-257, 259-259
279-279: Foreign delegations scenario includes new pool address usage.
Consistent with earlier file changes; no logic concerns.
Also applies to: 289-289, 311-311, 325-325, 339-339, 342-342, 345-345, 349-349, 357-357, 367-367, 414-414, 417-417, 440-440, 441-441, 443-443, 444-444, 452-452, 453-453, 455-455, 456-456, 458-458
478-478: Test invalid bundle with partial valid/invalid votes, updated references.
The rename meets the new standard without changing essential logic.
Also applies to: 488-488, 510-510, 526-526, 541-541, 555-555, 558-558, 561-561, 565-565, 573-573, 581-581, 591-591, 638-638, 641-641, 672-672, 675-675, 684-684, 685-685, 687-687, 688-688, 690-690, 696-696, 697-697, 699-699, 700-700, 702-702
722-722: Stake fraction scenario with pool address rename.
Name correctness verified; the slash logic remains the same.
Also applies to: 732-732, 740-740, 758-758, 764-764, 767-767, 770-770, 774-774, 782-782, 792-792, 839-839, 842-842, 861-861, 862-862, 864-864, 865-865, 873-873, 874-874, 876-876, 877-877, 879-879
905-905: Stake fraction + foreign delegation scenario uses updated naming.
No functional impact beyond the rename; tests remain valid.
Also applies to: 915-915, 923-923, 941-941, 947-947, 950-950, 953-953, 957-957, 965-965, 975-975, 1022-1022, 1025-1025, 1046-1046, 1047-1047, 1049-1049, 1050-1050, 1058-1058, 1059-1059, 1061-1061, 1062-1062, 1064-1064
x/bundles/keeper/logic_end_block_handle_upload_timeout_test.go (68)
100-108: Looks good.
The updated MsgJoinPool calls with PoolAddress appear correct.
121-121: Nice update for clarity.
Replacing valaddress with PoolAddress in MsgClaimUploaderRole fosters consistency.
176-176: Good naming consistency.
Using PoolAddress instead of the old valaddress within MsgClaimUploaderRole is aligned with the PR objectives.
215-215: No issues found.
Migration to PoolAddress for pool-specific roles is correct.
247-247: Good practice for naming.
References to PoolAddress are coherent with the new pool-based logic.
287-287: Change reviewed.
PoolAddress usage matches the new address model.
317-317: No issues detected.
Renaming valaddress to PoolAddress aligns with the standard.
345-345: Clear transition.
This line properly switches to i.POOL_ADDRESS_0_A.
374-374: Good.
The new address naming is consistent.
394-395: Points check is well-structured.
Ensuring you retrieve the correct pool account with the new naming is consistent.
410-410: No problems noticed.
Creator field referencing the correct PoolAddress.
418-418: All set.
PoolAddress reference for the new message remains aligned.
432-432: Valid usage.
Continuing the naming update for votes is correct.
462-462: Ok.
Switched the Creator from old valaddress to the new PoolAddress.
470-470: All good.
Creator references i.POOL_ADDRESS_0_A as intended.
484-484: Reference is consistent.
Using i.POOL_ADDRESS_1_A for the vote aligns with new naming.
515-515: No concerns.
Makings of a correct usage of PoolAddress in MsgClaimUploaderRole.
523-523: All set.
Signatures changed to the new address format.
537-537: Correct.
Applies the updated address references for voting.
564-565: Pooling logic recognized.
Accessing updated pool account references is correct.
568-569: Fine change.
Ensures we read from the correct pool entity.
583-583: Valid.
No issues with the naming shift.
591-591: Appropriate reference.
Transition to pool-based addresses is consistent.
624-625: Logic is unchanged.
Renaming to i.STAKER_0 for consistency remains sound.
628-629: Seems correct.
Applies the pool-based address approach.
653-653: No issues.
Using i.POOL_ADDRESS_2_A in a new staker scenario is correct.
659-659: Clear.
Staker references are updated with correct naming.
667-667: Fine detail.
Pool address usage for i.STAKER_0 looks consistent.
681-681: No problems.
Using i.POOL_ADDRESS_1_A is appropriately placed.
689-689: Ok.
Renaming i.POOL_ADDRESS_2_A for this voting scenario is consistent.
718-719: Status check.
Reading the updated pool account is valid.
722-723: All good.
Ensures correct usage of i.STAKER_2 pool references.
750-750: No concerns.
MsgJoinPool with i.POOL_ADDRESS_2_A is valid.
756-756: On point.
Claiming uploader role references the correct pool-based Creator.
764-764: Looks fine.
Switch to pool addresses for the submission.
778-778: Consistent.
Vote with the new PoolAddress is properly used.
796-796: Renaming recognized.
Claiming i.POOL_ADDRESS_0_A is correct.
810-810: No issues found.
Usage for i.POOL_ADDRESS_1_A in the vote is correct.
848-849: Minor detail.
Points assignment references the correct pool addresses.
852-853: Clear.
Reading from i.STAKER_2’s pool account is fine.
874-874: All set.
Creator is updated with the new pool-based approach.
882-882: Ok.
Submits a bundle with the correct i.POOL_ADDRESS_0_A reference.
918-918: Looks correct.
The line change from valaddress to pool references is consistent.
926-926: No issues.
Ensures the submission uses the updated pool address.
980-980: Naming alignment.
Using i.POOL_ADDRESS_2_A for the new staker is correct.
986-986: Clear usage.
MsgClaimUploaderRole referencing i.POOL_ADDRESS_0_A is consistent.
994-994: Agreed.
Ensures bundle submission from the correct pool address.
1007-1008: Fine.
Direct removal of old references in favor of the new pool-based approach looks good.
1046-1046: No issues found.
MsgJoinPool with i.POOL_ADDRESS_2_A is consistent.
1052-1052: Correct usage.
i.POOL_ADDRESS_0_A for the claim role.
1060-1060: All good.
Submission with updated address references.
1074-1074: Fine detail.
Refers to i.POOL_ADDRESS_1_A for voting.
1082-1082: No concerns.
Using i.POOL_ADDRESS_2_A for the second vote is correct.
1089-1090: Pool removal logic.
The lines show removing a pool account directly. Implementation is consistent with the new naming.
1134-1140: Clear.
Using i.POOL_ADDRESS_2_A in the final scenario is valid.
1148-1148: Correct reference.
Bundle submission from i.POOL_ADDRESS_0_A.
1162-1162: No problem.
Vote from i.POOL_ADDRESS_1_A is consistent.
1170-1170: All set.
Voting from i.POOL_ADDRESS_2_A is correct.
1177-1178: Direct removal again.
Appropriate usage of RemovePoolAccountFromPool referencing i.STAKER_0.
1242-1242: Ok.
MsgJoinPool with i.POOL_ADDRESS_0_B indicates a second pool address usage.
1250-1250: No issues.
Adding i.POOL_ADDRESS_1_B for a new environment.
1264-1264: Fine.
Using i.POOL_ADDRESS_2_B for the third staker.
1270-1270: Appropriate.
Claiming role with i.POOL_ADDRESS_1_B.
1278-1278: Consistent.
Submitting proposal from i.POOL_ADDRESS_1_B.
1292-1292: Correct approach.
Voting with i.POOL_ADDRESS_0_B is aligned.
1310-1310: All good.
Proposing with i.POOL_ADDRESS_1_B for subsequent rounds.
1324-1324: Ok.
Vote from i.POOL_ADDRESS_0_B is consistent.
1360-1361: Logic check.
Ensuring the pool account for i.STAKER_2 is not active looks correct.
x/bundles/keeper/keeper_suite_inflation_splitting_test.go (124)
Line range hint 39-39: No issues found.
Declaring new variables for initial balances is straightforward and correct.
Line range hint 47-53: Variables introduced.
Tracking separate staker vs. pool address balances is helpful for clarity.
Line range hint 125-125: Good usage.
PoolAddress used in MsgJoinPool is properly referencing i.POOL_ADDRESS_0_A.
135-135: All fine.
Second pool join with i.POOL_ADDRESS_1_A is correct too.
141-141: Clear logic.
Using i.POOL_ADDRESS_0_A in MsgClaimUploaderRole is consistent with the new naming.
149-149: Ok.
Accessing i.POOL_ADDRESS_0_A for the next steps is consistent.
Line range hint 162-162: No issues.
Submit bundle from i.POOL_ADDRESS_0_A is well-aligned.
Line range hint 176-176: Vote address.
Using i.POOL_ADDRESS_1_A to vote is correct.
Line range hint 184-184: Balance references.
Storing initialBalancePoolAddress1 is a valid approach.
192-192: Submission logic.
Creator is i.POOL_ADDRESS_1_A. This maintains consistency.
Line range hint 252-253: Voter’s account.
Ensuring we retrieve the correct pool account references i.STAKER_0 is correct.
280-280: Commission distribution.
Points to i.STAKER_0 from the pool-based vantage is correct.
Line range hint 308-308: No concerns.
Replacing the old address with i.POOL_ADDRESS_0_A for submission.
Line range hint 322-322: Vote alignment.
Using i.POOL_ADDRESS_1_A in the vote is consistent.
Line range hint 330-330: Balance capture.
Storing the new initial balance for i.POOL_ADDRESS_1_A is correct.
Line range hint 338-338: Submission reference.
Creator as i.POOL_ADDRESS_1_A is well-applied.
Line range hint 398-399: Uploader account check.
The lines ensure the correct pool account is retrieved with i.STAKER_0.
Line range hint 401-402: No issues.
Reading the balance from i.POOL_ADDRESS_0_A is correct.
Line range hint 405-406: Consistency noted.
Reading i.POOL_ADDRESS_1_A for the voter is good.
Line range hint 408-409: Approved.
Ensuring the correct pool address for the voter’s balance check.
Line range hint 415-415: All set.
Refers to the staker’s address i.STAKER_0 for final checks.
Line range hint 421-421: Commission detail.
Applying i.STAKER_0 as the pool staker is correct.
462-462: No conflict.
MsgJoinPool with i.POOL_ADDRESS_2_A is consistent.
Line range hint 474-474: Submission approach.
Creator references i.POOL_ADDRESS_0_A.
Line range hint 488-488: Valid usage.
Vote from i.POOL_ADDRESS_1_A.
Line range hint 496-496: Balance acquisition.
Correctly capturing i.POOL_ADDRESS_1_A.
Line range hint 504-504: All good.
Second message uses i.POOL_ADDRESS_1_A for submission.
Line range hint 564-565: Uploader pool logic.
No issues with retrieving points for i.STAKER_0.
567-568: Approved.
Balance read with i.POOL_ADDRESS_0_A is correct.
571-572: Points update.
Marking i.STAKER_2 with new points is consistent.
Line range hint 574-575: No concerns.
Refers to i.POOL_ADDRESS_1_A for the final balance check.
581-581: Submission logic check.
Balance retrieval from i.STAKER_0 remains consistent.
Line range hint 587-587: Commission approach.
Commission is assigned properly to i.STAKER_0.
Line range hint 628-628: Ok.
i.POOL_ADDRESS_2_A for a new staker is consistent.
Line range hint 640-640: Submission alignment.
Using i.POOL_ADDRESS_0_A for the bundle submission is correct.
654-654: Matches.
Votes from i.POOL_ADDRESS_1_A.
Line range hint 662-662: Abstain approach.
Linking i.POOL_ADDRESS_2_A for an abstain vote is correct.
670-670: Balance recapturing.
Storing i.POOL_ADDRESS_1_A’s initial balance.
678-678: All set.
Creator is i.POOL_ADDRESS_1_A.
Line range hint 738-739: Ok.
Checking i.STAKER_0’s pool account for points is correct.
Line range hint 741-742: No problem.
Reading i.POOL_ADDRESS_0_A’s balance.
Line range hint 745-746: Proper usage.
i.STAKER_1’s pool account for point checks.
748-749: Balance logic.
Reading i.POOL_ADDRESS_1_A’s coins.
Line range hint 755-755: All good.
Ensures i.STAKER_0’s staker address is read.
761-761: Commission assignment.
No issues. i.STAKER_0 remains the correct reference.
Line range hint 802-802: Ok.
MsgJoinPool with i.POOL_ADDRESS_2_A is consistent.
Line range hint 814-814: Proper usage.
Creator is i.POOL_ADDRESS_0_A.
Line range hint 828-828: No issues.
Vote from i.POOL_ADDRESS_1_A.
Line range hint 836-836: Invalid vote.
Uses i.POOL_ADDRESS_2_A to cast an invalid vote. All good.
Line range hint 844-844: Initial balances.
Storing i.POOL_ADDRESS_2_A is correct.
852-852: Submission.
From i.POOL_ADDRESS_1_A for the next proposal is valid.
Line range hint 912-913: No concerns.
Retrieving pool account of i.STAKER_0.
Line range hint 915-916: Valid references.
Balance read from i.POOL_ADDRESS_0_A.
Line range hint 929-931: Pool removal.
No active pool account remains for i.STAKER_2.
Line range hint 932-933: Balance check.
Ensuring i.POOL_ADDRESS_2_A is unaffected.
Line range hint 939-939: Uploader’s final check.
Balance for i.STAKER_0 is correct.
Line range hint 945-945: Commission distribution.
No conflicts.
976-976: Ok.
SetMaxVotingPower usage. i.POOL_ADDRESS_2_A is new.
Line range hint 993-993: Join scenario.
Using i.POOL_ADDRESS_3_A for a new staker is consistent.
Line range hint 999-999: Claim role.
Creator i.POOL_ADDRESS_0_A is correct.
Line range hint 1007-1007: Submission.
From i.POOL_ADDRESS_0_A is valid.
Line range hint 1021-1021: All set.
Vote from i.POOL_ADDRESS_1_A.
Line range hint 1029-1029: Invalid vote again.
Using i.POOL_ADDRESS_2_A is correct.
Line range hint 1037-1037: Another vote scenario.
i.POOL_ADDRESS_3_A is valid.
Line range hint 1045-1045: Balance recapture.
Storing i.POOL_ADDRESS_2_A’s coins.
Line range hint 1054-1054: Second submission.
i.POOL_ADDRESS_2_A as Creator matches the test scenario.
Line range hint 1114-1115: Ok.
Ensures i.STAKER_0’s pool account remains with zero points.
Line range hint 1117-1118: Balance check.
Reading i.POOL_ADDRESS_0_A.
Line range hint 1131-1131: Voter inactivity.
Marking i.STAKER_2’s pool account inactive.
Line range hint 1134-1135: Funds remain.
i.POOL_ADDRESS_2_A is unaffected.
Line range hint 1141-1141: Uploader final.
Ensuring i.STAKER_0’s staker address is correct.
Line range hint 1147-1147: Commission logic.
No issues with referencing i.STAKER_0.
1179-1179: New Storage Provider ID.
Creator i.POOL_ADDRESS_0_A usage is consistent.
Line range hint 1193-1193: Vote referencing.
i.POOL_ADDRESS_1_A is consistent.
Line range hint 1201-1201: Balance reference.
Tracking i.POOL_ADDRESS_1_A.
Line range hint 1209-1209: Correct approach.
Creator is i.POOL_ADDRESS_1_A.
Line range hint 1269-1270: Uploader pool.
Checks i.STAKER_0’s account.
Line range hint 1272-1273: Balance retrieval.
Reading i.POOL_ADDRESS_0_A.
1276-1277: Voter check.
i.STAKER_1’s points confirm zero.
1279-1280: Balance approach.
Reading i.POOL_ADDRESS_1_A for correctness.
Line range hint 1282-1282: Staker check.
Confirms i.STAKER_1’s coin balance.
Line range hint 1286-1286: Uploader final.
i.STAKER_0’s balance retrieval is unaffected.
Line range hint 1295-1295: Commission distribution.
No issues recognized.
Line range hint 1318-1318: Funding scenario.
Adding i.BCoin and i.CCoin is consistent.
Line range hint 1332-1332: Vote usage.
i.POOL_ADDRESS_1_A is valid.
Line range hint 1340-1340: Balance storing.
Capturing i.POOL_ADDRESS_1_A’s initial coins for testing.
1348-1348: Creator consistency.
Message uses i.POOL_ADDRESS_1_A.
Line range hint 1408-1409: Staker’s account.
Retrieving i.STAKER_0’s pool account.
Line range hint 1411-1412: Balance retrieval.
Reading from i.POOL_ADDRESS_0_A.
Line range hint 1415-1416: Second staker.
No points for i.STAKER_1.
Line range hint 1418-1419: Balance approach.
Reading from i.POOL_ADDRESS_1_A.
Line range hint 1421-1421: Staker’s fund check.
Ensuring i.STAKER_1 is correct.
Line range hint 1425-1425: Uploader final.
Reading i.STAKER_0’s balance.
Line range hint 1431-1431: Commission approach.
Mapping the new coin references for i.STAKER_0 is consistent.
Line range hint 1487-1487: Submission.
Message from i.POOL_ADDRESS_0_A for new coins is consistent.
Line range hint 1501-1501: Votes.
Creator is i.POOL_ADDRESS_1_A for the correct scenario.
Line range hint 1509-1509: Capturing.
Saving initialBalancePoolAddress1.
Line range hint 1517-1517: No issues found.
MsgSubmitBundleProposal from i.POOL_ADDRESS_1_A.
1577-1578: Uploader check.
Ensures i.STAKER_0 remains valid in the pool.
Line range hint 1580-1581: Reading address.
Balance from i.POOL_ADDRESS_0_A is correct.
Line range hint 1584-1585: Zero points.
For i.STAKER_1’s pool account.
1587-1588: Balance usage.
Reading i.POOL_ADDRESS_1_A.
1590-1590: No issues.
Staker address i.STAKER_1 is consistent.
Line range hint 1594-1594: All good.
Uploader’s final balance is correct.
Line range hint 1600-1600: Commission approach.
The coin distribution references i.STAKER_0.
Line range hint 1650-1650: Submission logic.
Creator i.POOL_ADDRESS_0_A is consistent.
1664-1664: No problems.
Vote from i.POOL_ADDRESS_1_A.
1672-1672: Balance approach.
Capturing i.POOL_ADDRESS_1_A again.
Line range hint 1680-1680: Creator usage.
i.POOL_ADDRESS_1_A is used for submission.
Line range hint 1740-1744: Uploader references.
Retrieving i.STAKER_0’s pool address and verifying it’s unchanged.
Line range hint 1747-1751: No issues.
Ensuring i.STAKER_1’s pool account is zeroed out, reading i.POOL_ADDRESS_1_A.
Line range hint 1757-1757: Balance check.
i.STAKER_0’s personal address remains correct.
Line range hint 1763-1763: Commission reference.
Stable logic referencing i.STAKER_0.
Line range hint 1845-1845: Submission with 1MB data.
Creator i.POOL_ADDRESS_0_A. No issues.
Line range hint 1859-1859: Vote.
From i.POOL_ADDRESS_1_A is consistent.
Line range hint 1867-1867: Store balances.
i.POOL_ADDRESS_1_A’s initial coins is correct.
Line range hint 1875-1875: Next submission.
Creator is i.POOL_ADDRESS_1_A.
1935-1936: Uploader references.
Double-checking i.STAKER_0’s pool account is correct.
Line range hint 1938-1939: Reading balances.
For i.POOL_ADDRESS_0_A is correct.
Line range hint 1942-1943: Second staker.
Points remain zero for i.STAKER_1.
1945-1946: Balances.
Reading i.POOL_ADDRESS_1_A.
1948-1948: Check staker.
Verifying i.STAKER_1’s personal coins.
Line range hint 1952-1952: Uploader final.
Ensuring i.STAKER_0’s personal coins remain correct.
1960-1960: Commission distribution.
The final line references i.STAKER_0’s commission. Confirmed.
x/bundles/keeper/keeper_suite_valid_bundles_test.go (93)
39-39: No issues.
Variables introduced for initial balances.
47-53: Clear approach.
Separate staker and pool addresses for clarity.
Line range hint 100-108: MsgJoinPool lines.
Switching to i.POOL_ADDRESS_0_A or i.POOL_ADDRESS_1_A is valid.
Line range hint 121-121: Claim role.
Creator i.POOL_ADDRESS_0_A for an uploader role is consistent.
149-150: Balances recognized.
Capturing i.POOL_ADDRESS_0_A and i.POOL_ADDRESS_1_A is correct.
162-162: Submission.
Creator is i.POOL_ADDRESS_0_A for the first valid bundle.
176-176: Vote.
i.POOL_ADDRESS_1_A for a valid vote.
184-184: Initial balances.
Capturing i.POOL_ADDRESS_1_A’s coins for verification.
192-192: Second bundle submission.
Creator is i.POOL_ADDRESS_1_A.
252-253: Pool account logic.
Retrieving i.STAKER_0’s account.
280-280: Commission detail.
Ensures the final distribution references i.STAKER_0.
308-308: Submission rename.
Using i.POOL_ADDRESS_0_A.
322-322: Voting rename.
Creator i.POOL_ADDRESS_1_A for VOTE_TYPE_VALID.
330-330: Balance reference.
Storing i.POOL_ADDRESS_1_A’s new initial coins.
338-338: Second submission.
Creator i.POOL_ADDRESS_1_A is consistent again.
398-399: Uploader account logic.
Reading i.STAKER_0’s pool account.
401-402: Balance read.
Accessing i.POOL_ADDRESS_0_A.
405-406: Vote perspective.
Retrieving i.STAKER_1’s pool account.
408-409: Balance reference.
Using i.POOL_ADDRESS_1_A for final check.
415-415: Uploader final.
Reading i.STAKER_0’s coins is correct.
421-421: Commission approach.
Ensuring i.STAKER_0 is assigned.
462-462: Pool join.
i.POOL_ADDRESS_2_A for the third staker is correct.
474-474: Submission.
Creator i.POOL_ADDRESS_0_A.
488-488: Vote.
From i.POOL_ADDRESS_1_A.
496-496: Balance store.
Capturing i.POOL_ADDRESS_1_A’s coins.
504-504: Next bundle.
Creator i.POOL_ADDRESS_1_A.
564-565: Uploader points.
i.STAKER_0’s pool account remains zero.
567-568: Balance approach.
Reading i.POOL_ADDRESS_0_A.
571-572: Voting staker.
i.STAKER_2’s account with updated points.
574-575: Balance.
Refers to i.POOL_ADDRESS_1_A.
581-581: Final check.
Reading i.STAKER_0’s personal balance.
587-587: Commission distribution.
Remains consistent for i.STAKER_0.
628-628: Third staker.
MsgJoinPool with i.POOL_ADDRESS_2_A.
640-640: Submission.
Creator i.POOL_ADDRESS_0_A for the valid scenario.
654-654: Valid vote.
i.POOL_ADDRESS_1_A used.
662-662: Abstain.
i.POOL_ADDRESS_2_A votes abstain.
670-670: Balance capturing.
i.POOL_ADDRESS_1_A’s coins.
678-678: Second submission.
Creator i.POOL_ADDRESS_1_A.
738-739: Uploader points.
Confirming i.STAKER_0 is zero. Good.
741-742: Balance read.
From i.POOL_ADDRESS_0_A.
745-746: Zero points.
For i.STAKER_1.
748-749: Balance approach.
Retrieving i.POOL_ADDRESS_1_A.
755-755: Ok.
Reading i.STAKER_0’s personal balance.
761-761: Commission.
i.STAKER_0 is consistently used.
802-802: MsgJoinPool.
i.POOL_ADDRESS_2_A is valid.
814-814: Submission.
Creator i.POOL_ADDRESS_0_A.
828-828: Vote.
i.POOL_ADDRESS_1_A.
836-836: Invalid vote.
Creator i.POOL_ADDRESS_2_A.
844-844: Capture balances.
i.POOL_ADDRESS_2_A’s initial.
852-852: Following submission.
Creator i.POOL_ADDRESS_1_A.
912-913: Uploader check.
Reading i.STAKER_0’s pool account.
915-916: Balance from.
i.POOL_ADDRESS_0_A.
929-931: Pool removal.
i.STAKER_2 is marked inactive.
932-933: Balance stable.
i.POOL_ADDRESS_2_A unaffected.
939-939: No issues.
Reading i.STAKER_0’s personal address.
945-945: Commission approach.
i.STAKER_0 usage.
976-976: SetMaxVotingPower usage.
No issues with i.POOL_ADDRESS_2_A.
993-993: New staker.
i.POOL_ADDRESS_3_A is valid.
999-999: Claim.
Creator i.POOL_ADDRESS_0_A.
1007-1007: Submission.
From i.POOL_ADDRESS_0_A.
1021-1021: Vote.
Using i.POOL_ADDRESS_1_A.
1029-1029: Invalid.
From i.POOL_ADDRESS_2_A.
1037-1037: Vote.
Creator i.POOL_ADDRESS_3_A.
1045-1045: Balance check.
Capturing i.POOL_ADDRESS_2_A’s coins.
1054-1054: Next submission.
Creator i.POOL_ADDRESS_2_A.
1114-1115: Uploader points.
Confirm i.STAKER_0’s zero points.
1117-1118: Balance of.
i.POOL_ADDRESS_0_A.
1131-1131: Max voting power.
i.STAKER_2’s account is deactivated.
1134-1135: Balance stable.
i.POOL_ADDRESS_2_A remains the same.
1141-1141: Final.
Reading i.STAKER_0’s personal balance.
1147-1147: Commission distribution.
i.STAKER_0 usage is correct.
1179-1179: New storage provider.
Creator i.POOL_ADDRESS_0_A.
1193-1193: Vote.
i.POOL_ADDRESS_1_A for VOTE_TYPE_VALID.
1201-1201: Balance.
Capturing i.POOL_ADDRESS_1_A.
1209-1209: Submission.
Creator i.POOL_ADDRESS_1_A.
1269-1270: Uploader check.
Reading i.STAKER_0’s account.
1272-1273: Balance retrieval.
i.POOL_ADDRESS_0_A.
1276-1277: Points.
i.STAKER_1 is zero.
1279-1280: Balance.
Reading i.POOL_ADDRESS_1_A.
1282-1282: Staker address.
i.STAKER_1. No changes.
1286-1286: Uploader final.
Checking i.STAKER_0’s personal balance.
1295-1295: Commission distribution.
i.STAKER_0.
1318-1318: Extra coins.
Funding with i.BCoin and i.CCoin is correct.
1332-1332: Vote.
From i.POOL_ADDRESS_1_A.
1340-1340: Balance track.
Capturing i.POOL_ADDRESS_1_A.
1348-1348: Submission.
Creator i.POOL_ADDRESS_1_A.
1408-1409: Staker’s pool.
i.STAKER_0 points = 0.
1411-1412: Balance read.
i.POOL_ADDRESS_0_A coins.
1415-1416: No issues.
Points remain zero for i.STAKER_1.
1418-1419: Balance approach.
i.POOL_ADDRESS_1_A.
1421-1421: Final staker.
Reading i.STAKER_1’s personal coins.
1425-1425: No concerns.
Uploader’s final read for i.STAKER_0.
1431-1431: Commission.
Refers to i.STAKER_0.
docs/static/openapi.yml (1)
861-879: Verify complete replacement of old terminology
Let's ensure all instances of the old terminology have been updated consistently throughout the API specification.
Also applies to: 2056-2056, 2273-2274
✅ Verification successful
All instances of old terminology have been successfully replaced
The verification shows that:
- No instances of "valaddress" or "valaccount" remain in the OpenAPI specification
- The new terminology "pool_address" is used consistently throughout the document
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining instances of old terminology in the OpenAPI spec
echo "Checking for remaining instances of old terminology..."
rg -i "valaddress|valaccount" docs/static/openapi.yml
# Also check for any inconsistencies in the new terminology
echo "Checking for consistency in new terminology..."
rg -i "pool.?address|pool.?account" docs/static/openapi.yml
Length of output: 2571
x/stakers/types/message_join_pool.go (1)
43-44: LGTM: Consistent address validation after renaming
The validation logic correctly maintains the same checks while using the new terminology.
x/bundles/keeper/msg_server_claim_uploader_role.go (1)
27-27: Verify parameter order in AssertPoolAccountAuthorized call
The parameter order has changed during the rename from AssertValaccountAuthorized. Please verify that the new order (msg.Staker, msg.PoolId, msg.Creator) matches the expected signature of AssertPoolAccountAuthorized.
✅ Verification successful
Based on the search results, I can generate the final response as I have found the function definition and its usage across the codebase.
Parameter order in AssertPoolAccountAuthorized call is correct
The parameter order (ctx, msg.Staker, msg.PoolId, msg.Creator) matches the function signature defined in x/stakers/keeper/exported_functions.go:
func (k Keeper) AssertPoolAccountAuthorized(ctx sdk.Context, stakerAddress string, poolId uint64, poolAddress string)This is also consistent with other calls to this function in the codebase, such as those in logic_bundles.go.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other calls to AssertPoolAccountAuthorized to verify parameter order
rg -A 2 "AssertPoolAccountAuthorized"
# Search for the function definition
ast-grep --pattern 'func $_ AssertPoolAccountAuthorized($$$) {
$$$
}'
Length of output: 2450
x/delegation/keeper/msg_server_redelegate.go (1)
30-30: LGTM: Consistent renaming of validator account to pool account
The change from GetValaccountsFromStaker to GetPoolAccountsFromStaker aligns with the PR's objective of standardizing terminology while maintaining the same functionality.
x/stakers/types/genesis.go (1)
19-26: LGTM: Genesis validation properly updated for pool account terminology
The changes correctly maintain the validation logic while updating terminology:
- Pool account map creation and duplicate checking
- Consistent use of
PoolAccountKeyfor indexing - Error messages appropriately reference pool accounts
The validation integrity is preserved while aligning with the new terminology.
Also applies to: 56-59
x/stakers/spec/07_exported.md (1)
19-21: LGTM: Interface documentation properly updated for pool account terminology
The changes correctly update the interface documentation:
- Updated comments for
GetAllStakerAddressesOfPool - Updated comments and signature for
AssertPoolAccountAuthorized
The changes maintain clarity while aligning with the new terminology.
Also applies to: 26-30
proto/kyve/stakers/v1beta1/stakers.proto (1)
40-46: LGTM: Clear and well-documented message definition
The updated message definition and its documentation clearly explain the relationship between validators and pool accounts, which is a significant improvement in clarity.
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Documentation
Tests