Contracts 0.8 upgrade, subgraph to 0.14, devnet and testnet only for now #1941
Conversation
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. 💤 Files selected but had no reviewable changes (5)
You can disable this status message by setting the WalkthroughThis PR introduces a comprehensive upgrade process for the Kleros smart contracts. It adds new deployment scripts (e.g., upgrade-all.ts) that dynamically retrieve contract names, prompt user confirmation, and invoke specialized initializer functions. Several Solidity contracts have new initializer methods (initialize2/initialize3) to support staged upgrades. In addition, obsolete simulation scripts are removed, deployment artifacts (ABI, JSON files) are updated with new metadata and addresses, and the Hardhat config is modified to include a storage layout comparison task. The subgraph configuration and some UI components are updated for improved robustness. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UpgradeScript
participant Deployer
User->>UpgradeScript: Run upgrade-all.ts
UpgradeScript->>User: Log deployer address, chain ID, contract names
loop For each contract to upgrade
UpgradeScript->>User: Prompt confirmation to upgrade contract?
alt User confirms
UpgradeScript->>Deployer: Call deployUpgradable with initializer and args
Deployer-->>UpgradeScript: Return success or error message
else User cancels
UpgradeScript-->>User: Skip upgrade for current contract
end
end
UpgradeScript->>User: Log completion of upgrade process
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🪧 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 (
|
jaybuidl
force-pushed
the
chore/contracts-0.8-upgrade
branch
from
f57de75 to
f793d6a
Compare
✅ Deploy Preview for kleros-v2-testnet-devtools ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for kleros-v2-testnet ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for kleros-v2-neo ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for kleros-v2-university ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
contracts/deploy/upgrade-all.ts (1)
1-61: 🛠️ Refactor suggestionNew batch upgrade functionality.
This new script introduces the ability to upgrade multiple contracts in a batch, with user confirmation for each upgrade. The implementation includes proper error handling and user interaction.
The actual deployment logic is commented out (lines 35-40), which prevents the function from performing the actual upgrades. Uncomment and implement this section to make the script functional.
- // await deployUpgradable(deployments, contractName, { - // newImplementation: contractName, - // initializer, - // from: deployer, - // args, // Warning: do not reinitialize existing state variables, only the new ones - // }); + await deployUpgradable(deployments, contractName, { + newImplementation: contractName, + initializer, + from: deployer, + args, // Warning: do not reinitialize existing state variables, only the new ones + });
🧹 Nitpick comments (2)
contracts/scripts/utils/contracts.ts (1)
126-146: Added network-specific contract retrieval functions.The new functions
getContractsFromNetworkandgetContractNamesFromNetworkprovide a convenient way to retrieve contracts based on the network name. However, they only handle specific networks ("arbitrumSepoliaDevnet", "arbitrumSepolia", and "arbitrum"), throwing an error for any other network.Consider adding support for local development networks or additional testnets to improve the developer experience. This could be done by adding a default case that returns BASE contracts for unknown networks, or by extending the network mapping.
export const getContractNamesFromNetwork = async (hre: HardhatRuntimeEnvironment) => { const { network } = hre; if (network.name === "arbitrumSepoliaDevnet" || network.name === "arbitrumSepolia") { return getContractNames(Cores.BASE); } else if (network.name === "arbitrum") { return getContractNames(Cores.NEO); + } else if (network.name === "hardhat" || network.name === "localhost") { + // For local development environments + return getContractNames(Cores.BASE); } else { throw new Error("Invalid network"); } };contracts/deploy/upgrade-all.ts (1)
21-45: Robust upgrade function with user confirmation.The
upgradefunction properly prompts for user confirmation before proceeding with each contract upgrade, which is a good safety measure. However, it doesn't provide feedback on the upgrade status or handle partial upgrade scenarios.Consider adding status reporting and the ability to continue with remaining upgrades if one fails:
const upgrade = async (contractName: string, initializer: string, args: any[]) => { try { print.highlight(`💣 Upgrading ${bold(contractName)}`); const { confirm } = await prompt.ask({ type: "confirm", name: "confirm", message: "Are you sure you want to proceed?", }); if (!confirm) { console.log("Operation cancelled by user."); return; } print.info(`Upgrading ${contractName}...`); await deployUpgradable(deployments, contractName, { newImplementation: contractName, initializer, from: deployer, args, // Warning: do not reinitialize existing state variables, only the new ones }); + print.success(`✅ Successfully upgraded ${contractName}`); + return true; } catch (err) { console.error(err); - throw err; + print.error(`❌ Failed to upgrade ${contractName}: ${err.message}`); + return false; } };Then update the main function to handle partial failures:
- await upgrade(disputeKitClassic, "initializer2", []); - await upgrade(disputeTemplateRegistry, "initialize2", []); - await upgrade(evidence, "initialize2", []); - await upgrade(core, "initialize3", []); - await upgrade(policyRegistry, "initialize2", []); - await upgrade(sortition, "initialize3", []); + const results = await Promise.all([ + upgrade(disputeKitClassic, "initializer2", []), + upgrade(disputeTemplateRegistry, "initialize2", []), + upgrade(evidence, "initialize2", []), + upgrade(core, "initialize3", []), + upgrade(policyRegistry, "initialize2", []), + upgrade(sortition, "initialize3", []) + ]); + + const failedUpgrades = [ + disputeKitClassic, + disputeTemplateRegistry, + evidence, + core, + policyRegistry, + sortition + ].filter((_, index) => !results[index]); + + if (failedUpgrades.length > 0) { + print.error(`Failed upgrades: ${failedUpgrades.join(', ')}`); + } else { + print.success('All contracts upgraded successfully'); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
contracts/deploy/upgrade-all.ts(1 hunks)contracts/deploy/upgrade-dispute-kit-v0.8.0.ts(2 hunks)contracts/deploy/upgrade-kleros-core-v0.8.0.ts(2 hunks)contracts/deploy/upgrade-sortition-module-v0.8.0.ts(2 hunks)contracts/hardhat.config.ts(0 hunks)contracts/scripts/simulations/README.md(0 hunks)contracts/scripts/simulations/tasks.ts(0 hunks)contracts/scripts/simulations/utils.ts(0 hunks)contracts/scripts/utils/contracts.ts(4 hunks)contracts/src/arbitration/DisputeTemplateRegistry.sol(1 hunks)contracts/src/arbitration/KlerosCore.sol(1 hunks)contracts/src/arbitration/KlerosCoreNeo.sol(1 hunks)contracts/src/arbitration/PolicyRegistry.sol(1 hunks)contracts/src/arbitration/devtools/KlerosCoreRuler.sol(1 hunks)contracts/src/arbitration/dispute-kits/DisputeKitClassic.sol(1 hunks)contracts/src/arbitration/evidence/EvidenceModule.sol(1 hunks)
💤 Files with no reviewable changes (4)
- contracts/hardhat.config.ts
- contracts/scripts/simulations/README.md
- contracts/scripts/simulations/tasks.ts
- contracts/scripts/simulations/utils.ts
🧰 Additional context used
🧬 Code Definitions (4)
contracts/deploy/upgrade-kleros-core-v0.8.0.ts (1)
contracts/scripts/utils/contracts.ts (1)
getContractNamesFromNetwork(137-146)
contracts/deploy/upgrade-sortition-module-v0.8.0.ts (1)
contracts/scripts/utils/contracts.ts (1)
getContractNamesFromNetwork(137-146)
contracts/deploy/upgrade-dispute-kit-v0.8.0.ts (1)
contracts/scripts/utils/contracts.ts (1)
getContractNamesFromNetwork(137-146)
contracts/deploy/upgrade-all.ts (1)
contracts/scripts/utils/contracts.ts (1)
getContractNamesFromNetwork(137-146)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Redirect rules - kleros-v2-testnet-devtools
- GitHub Check: Header rules - kleros-v2-testnet-devtools
- GitHub Check: Pages changed - kleros-v2-testnet-devtools
- GitHub Check: contracts-testing
🔇 Additional comments (17)
contracts/src/arbitration/evidence/EvidenceModule.sol (1)
44-46: Added empty initializer for future upgrades.The
initialize2function uses thereinitializer(2)modifier to set up a new initialization point for future contract upgrades. This empty function (NOP - No Operation) follows the standard pattern for upgradeable contracts, allowing future versions to include implementation changes without modifying the existing initialization logic.contracts/src/arbitration/KlerosCore.sol (1)
59-61: Added version 3 initializer to support contract upgrades.The
initialize3function with thereinitializer(3)modifier provides a new initialization point for the next contract upgrade. This follows UUPS upgrade patterns and allows for seamless contract upgrades while maintaining state. The function currently contains no operations (NOP), which is appropriate for this stage.contracts/src/arbitration/KlerosCoreNeo.sol (1)
70-72: Added initialize3 function for future contract upgrades.The
initialize3function acts as a checkpoint for the next contract upgrade, properly using thereinitializer(3)modifier. This follows the same pattern used in KlerosCore, maintaining consistency across the system. The empty implementation (NOP) is appropriate as this is setting up the upgrade path without changing functionality.contracts/src/arbitration/dispute-kits/DisputeKitClassic.sol (1)
32-34: Added initialize2 function to support the upgrade path.The
initialize2function withreinitializer(2)provides a proper upgrade path for this contract. This follows the same pattern used in other contracts within this PR, maintaining consistency throughout the codebase. The empty implementation is appropriate at this stage.contracts/src/arbitration/DisputeTemplateRegistry.sol (1)
47-49: Looks good - Added reinitializer for contract upgrade.The addition of the empty
initialize2()function with thereinitializer(2)modifier is an appropriate pattern for upgradeable contracts using the UUPS pattern. This allows the contract to be properly upgraded without requiring any new state initialization.contracts/src/arbitration/devtools/KlerosCoreRuler.sol (1)
213-215: Looks good - Added consistent reinitializer for upgrades.The new
initialize2()function with thereinitializer(2)modifier follows the same pattern as in other contracts. This ensures a consistent upgrade approach across the system.contracts/src/arbitration/PolicyRegistry.sol (1)
54-56: Looks good - Added reinitializer for contract upgrade.The implementation of
initialize2()with thereinitializer(2)modifier maintains consistency with the upgrade pattern used in other contracts. This empty function (NOP) allows for proper contract upgradeability without needing to initialize new state.contracts/deploy/upgrade-sortition-module-v0.8.0.ts (2)
5-5: Looks good - Added import for dynamic contract name resolution.Adding the import for
getContractNamesFromNetworksupports the shift toward dynamic contract name resolution based on network context.
16-20: Looks good - Improved deployment flexibility with dynamic contract names.Replacing the hardcoded contract name with a dynamic lookup through
getContractNamesFromNetwork(hre)improves the deployment script's flexibility and maintainability. The deployment can now adapt to different networks without code changes. The upgrade to useinitialize3as the initializer aligns with the broader upgrade strategy.contracts/deploy/upgrade-kleros-core-v0.8.0.ts (2)
5-5: Import statement added for dynamic contract name retrieval.The addition of
getContractNamesFromNetworkimport supports the shift from hardcoded contract names to dynamic retrieval based on network, enhancing deployment flexibility.
16-20:❓ Verification inconclusive
Improved contract name retrieval with dynamic network detection.
The changes effectively replace hardcoded contract names with dynamic retrieval based on the current network environment. The upgrade to
initialize3indicates a new initialization function in the contract to support the v0.8.0 upgrade.
🏁 Script executed:
#!/bin/bash # Check if KlerosCore contract contains an initialize3 function ast-grep --pattern $'contract KlerosCore { $$$ function initialize3() $_ { $$$ } $$$ }'Length of output: 100
Action Required: Manual Verification Needed for
initialize3Initializer FunctionThe deployment script in
contracts/deploy/upgrade-kleros-core-v0.8.0.tsnow uses dynamic contract name retrieval and refers to the new initializer"initialize3"to support the v0.8.0 upgrade. However, our initial automated search did not yield any evidence that the KlerosCore contract includes ainitialize3function. Please manually verify that the KlerosCore contract (or its upgrade implementation) contains the newinitialize3initializer to ensure consistency and prevent deployment issues.
- Location to check: The Solidity contract for KlerosCore (likely under a
contracts/directory, e.g.,contracts/KlerosCore.sol) should define afunction initialize3(...) { … }.- Deployment Script Affected:
contracts/deploy/upgrade-kleros-core-v0.8.0.ts(lines 16-20).Once manual verification confirms the presence and correct implementation of
initialize3, please update this review comment accordingly.contracts/deploy/upgrade-dispute-kit-v0.8.0.ts (2)
5-5: Import statement added for dynamic contract name retrieval.This import enables the script to dynamically determine contract names based on the network environment, consistent with the approach in other upgrade scripts.
16-20:❓ Verification inconclusive
Enhanced deployment with network-aware contract name resolution.
The implementation now uses dynamic contract name retrieval and updates the initializer to
initialize2. This approach makes the deployment more flexible across different environments and aligns with the PR objective of supporting new initialization functions.
🏁 Script executed:
#!/bin/bash # Check if DisputeKitClassic contract contains an initialize2 function ast-grep --pattern $'contract DisputeKitClassic { $$$ function initialize2() $_ { $$$ } $$$ }'Length of output: 107
Manual Verification Needed: Confirm
initialize2Function ExistsThe deployment update now dynamically retrieves the contract name and sets the initializer to
"initialize2", aiming for a more flexible, environment-aware deployment approach. However, our initial automated search for aninitialize2function in theDisputeKitClassiccontract produced no output. To ensure the upgrade behaves as intended, please manually verify that theinitialize2initializer is indeed defined within theDisputeKitClassiccontract (for example, incontracts/DisputeKitClassic.sol).
- Confirm that
DisputeKitClassicincludes a properly definedinitialize2function.- Ensure this change aligns with the PR’s intent to support new initialization functionalities.
contracts/scripts/utils/contracts.ts (3)
19-19: Added EvidenceModule import.Added import for EvidenceModule to support the additional functionality in getContractNames and getContracts functions.
30-66: Centralized contract name mapping.The new
getContractNamesfunction effectively centralizes the mapping between core types (BASE, NEO, UNIVERSITY) and their respective contract names. This refactoring improves maintainability by providing a single source of truth for contract names.
76-108: Refactored contract retrieval to use centralized naming.Modified
getContractsto use the newgetContractNamesfunction, making the code more DRY and maintainable. This approach ensures consistent contract naming across the codebase.contracts/deploy/upgrade-all.ts (1)
47-52:❓ Verification inconclusive
Contract upgrade sequence.
The sequence of contract upgrades is well-defined with appropriate initializer functions for each contract. This matches the PR objective of adding new initialization functions.
🏁 Script executed:
#!/bin/bash # Verify if the initializer functions exist in the contracts echo "Checking if initialize2 exists in DisputeKitClassic..." ast-grep --pattern $'function initialize2' | grep -i disputekitclassic echo "Checking if initialize2 exists in DisputeTemplateRegistry..." ast-grep --pattern $'function initialize2' | grep -i disputetemplateregistry echo "Checking if initialize2 exists in EvidenceModule..." ast-grep --pattern $'function initialize2' | grep -i evidencemodule echo "Checking if initialize3 exists in KlerosCore..." ast-grep --pattern $'function initialize3' | grep -i kleroscore echo "Checking if initialize2 exists in PolicyRegistry..." ast-grep --pattern $'function initialize2' | grep -i policyregistry echo "Checking if initialize3 exists in SortitionModule..." ast-grep --pattern $'function initialize3' | grep -i sortitionmoduleLength of output: 1118
Action: Please Verify Contract Initializer Function Names Manually
The upgrade sequence appears to use the correct new initializer functions as intended by the PR. However, the automated verification did not produce any output. In particular, note that the DisputeKitClassic upgrade call uses
"initializer2", yet the script searched for"initialize2". Additionally, no initializer functions were detected in the other modules.
- Ensure that DisputeKitClassic actually implements a function named
initializer2(and notinitialize2).- Verify that DisputeTemplateRegistry, EvidenceModule, and PolicyRegistry define a function named
initialize2.- Confirm that KlerosCore and SortitionModule define a function named
initialize3.Please perform a manual inspection of the contract files to confirm that these functions exist with the correct names.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (9)
contracts/deployments/arbitrumSepolia/EvidenceModule.json (1)
131-137: Add New Initialization Functioninitialize2
A new function is introduced with no inputs and no outputs, and it is marked as nonpayable. This function supports the new upgrade initialization process as per the PR objectives.contracts/deployments/arbitrumSepolia/DisputeTemplateRegistry.json (1)
150-156: Add Newinitialize2Function in ABI
The addition of theinitialize2function (with no inputs and nonpayable state) reflects the upgrade’s requirement to use a parameterless initializer. Please ensure that the corresponding contract implementation correctly supports this function and that deployment scripts are updated accordingly.contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Implementation.json (1)
240-244: Detail Update in Devdoc forInvalidImplementationError
The devdoc entry for theInvalidImplementation(address)error now includes a detailed message ("Theimplementationis not UUPS-compliant"). This clarification is useful for debugging upgrade failures. Confirm that the contract implementation enforces UUPS compatibility as described, and that this message is reflected in error handling.contracts/deployments/arbitrumSepolia/DisputeTemplateRegistry_Implementation.json (1)
147-153: Add no-opinitialize2function.This new initializer with no parameters currently performs no state changes. If this is intended as a placeholder for future changes, it looks fine, but consider clarifying its purpose or providing inline documentation.
contracts/deploy/upgrade-all.ts (1)
10-48: Upgrade flow logic is clear.The
deployUpgradeAllfunction orchestrates upgrades for multiple contracts. The inclusion of user confirmation withprompt.askis a good safety check. Error handling withtry/catchis also well-structured. Make sure to avoid re-initializing already-existing storage variables in each initializer.contracts/deployments/arbitrumSepolia/SortitionModule.json (1)
554-560: Addedinitialize3function.As with other multi-initializer patterns, ensure that this function only sets new state variables to avoid overwriting existing initialization. Consider documenting what is initialized here.
contracts/deployments/arbitrumSepolia/KlerosCore.json (1)
163-167: New Error “StakingZeroWhenNoStake” Added
A new error definition has been introduced to signal cases when a staking operation results in zero stake despite expectations. Please verify that this error is properly referenced in the staking logic and that its message (via its naming) clearly communicates the condition.contracts/deployments/arbitrumSepoliaDevnet/PolicyRegistry_Implementation.json (1)
355-362: State Variable Metadata forversion.
The devdoc now includes a state variable entry forversionwith details on its return value. Although the contract definesversionas a public constant, including this in the storage layout metadata aids clarity.contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassic.json (1)
667-676: Clarify New Parameters in getDegreeOfCoherence
Two additional uint256 parameters have been added with empty names. To improve clarity for both developers and downstream tooling, please consider providing descriptive names or adding inline documentation that explains their purpose.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro (Legacy)
📒 Files selected for processing (23)
contracts/README.md(2 hunks)contracts/deploy/upgrade-all.ts(1 hunks)contracts/deploy/upgrade-dispute-kit-v0.8.0.ts(2 hunks)contracts/deploy/upgrade-kleros-core-v0.8.0.ts(2 hunks)contracts/deploy/upgrade-sortition-module-v0.8.0.ts(2 hunks)contracts/deployments/arbitrumSepolia/DisputeKitClassic.json(4 hunks)contracts/deployments/arbitrumSepolia/DisputeTemplateRegistry.json(3 hunks)contracts/deployments/arbitrumSepolia/DisputeTemplateRegistry_Implementation.json(8 hunks)contracts/deployments/arbitrumSepolia/EvidenceModule.json(3 hunks)contracts/deployments/arbitrumSepolia/EvidenceModule_Implementation.json(7 hunks)contracts/deployments/arbitrumSepolia/KlerosCore.json(5 hunks)contracts/deployments/arbitrumSepolia/PolicyRegistry.json(3 hunks)contracts/deployments/arbitrumSepolia/PolicyRegistry_Implementation.json(8 hunks)contracts/deployments/arbitrumSepolia/SortitionModule.json(6 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassic.json(5 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry.json(3 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Implementation.json(8 hunks)contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule.json(3 hunks)contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Implementation.json(9 hunks)contracts/deployments/arbitrumSepoliaDevnet/KlerosCore.json(16 hunks)contracts/deployments/arbitrumSepoliaDevnet/PolicyRegistry.json(3 hunks)contracts/deployments/arbitrumSepoliaDevnet/PolicyRegistry_Implementation.json(8 hunks)contracts/deployments/arbitrumSepoliaDevnet/SortitionModule.json(9 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- contracts/deploy/upgrade-dispute-kit-v0.8.0.ts
- contracts/deploy/upgrade-kleros-core-v0.8.0.ts
- contracts/deploy/upgrade-sortition-module-v0.8.0.ts
🧰 Additional context used
🧬 Code Definitions (1)
contracts/deploy/upgrade-all.ts (1)
contracts/scripts/utils/contracts.ts (1)
getContractNamesFromNetwork(137-146)
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: Redirect rules - kleros-v2-testnet-devtools
- GitHub Check: Header rules - kleros-v2-testnet-devtools
- GitHub Check: Pages changed - kleros-v2-testnet-devtools
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
🔇 Additional comments (104)
contracts/deployments/arbitrumSepoliaDevnet/KlerosCore.json (14)
82-86: Added Error: GuardianOrGovernorOnly
A new error has been introduced to enforce that only a guardian or governor may execute certain functions. Please verify that the corresponding contract logic correctly triggers this error when unauthorized calls are attempted.
144-167: New Staking Error Definitions Added
Several new error types have been defined to capture specific staking rule violations:
• StakingInTooManyCourts
• StakingLessThanCourtMinStake
• StakingNotPossibeInThisCourt
• StakingTransferFailed
• StakingZeroWhenNoStake
These additions will help ensure robust validation of staking operations. Please confirm that the staking logic in the contracts uses these errors appropriately.
194-198: Added Error: UnstakingTransferFailed
This new error will provide clearer feedback if unstaking token transfers fail. Ensure that the unstaking mechanism calls this error in failure cases.
214-218: Added Error: WhenNotPausedOnly
The addition of this error enforces that specific functions can only be executed when the contract is not paused. Double-check that functions relying on the operational state trigger this error when necessary.
219-223: Added Error: WhenPausedOnly
This error ensures that certain operations are only available when the contract is paused. Please verify that all related functions correctly use this mechanism for improved state control.
964-976: New Function: changeGuardian
A new function has been added to update the guardian address, which is important for flexible access control. Make sure that only authorized entities can call this function and that adequate checks are implemented within the contract logic.
1651-1657: New Initialization Function: initialize3
The upgrade introduces aninitialize3function (with no inputs) to replace or complement the previous initialization method. This simplifies the initialization phase of the proxy. Please verify that all deployment scripts have been updated to call this new function and that no obsolete initialization logic remains.
1727-1746: Pause Functionality Introduced: pause & paused
New functionspause(nonpayable) and the view functionpausedhave been added to enable emergency stop capabilities. Confirm that these functions integrate correctly with the rest of the contract’s logic and that any functions requiring a non-paused state use the appropriate error handling (such asWhenNotPausedOnly).
1832-1838: New Function: unpause
Theunpausefunction has been introduced to restore normal operations after a pause. Verify that it includes the necessary access control and that state transitions occur as expected.
1857-1869: Added Version Function
A newversionfunction returning a string has been added. This is useful for deployment verification and in future debugging scenarios. Ensure that the returned version string is updated whenever contract upgrades occur.
1968-1971: Updated Execute Block for Initialization
The execution configuration now specifies"methodName": "initialize3"with an empty arguments array. This change aligns with the new initialization process. Please verify that deployment routines are updated accordingly.
1972-1972: Updated Implementation Address
The"implementation"field has been updated to"0xF5609e6F10fd25aCb4ddAF14874aD4BaF1956827". Be sure that this address is correct and reflects the intended new logic for upgrades.
1963-1965: New Deployment Metadata Fields
New fields"numDeployments","solcInputHash", and"metadata"have been added to provide enhanced tracking and reproducibility of the deployment process. These additions are important for maintaining accurate deployment histories and should be consistently updated for future releases.
1966-1967: Updated Bytecode Fields
The"bytecode"and"deployedBytecode"fields have been updated. Since these are auto-generated by the compiler following the changes made in the contract, please ensure that integration tests confirm that no unintended behavioral changes were introduced.contracts/deployments/arbitrumSepolia/EvidenceModule.json (2)
187-199: Add New Version Functionversion
The ABI now includes a view function namedversionthat returns a string. This function provides a built-in mechanism for version tracking of the contract. Ensure that the underlying implementation returns the expected version format.
250-252: Update Deployment Metadata
The deployment metadata has been updated:
• The"numDeployments"field now reflects the new deployment count (2).
• The"solcInputHash"has been updated accordingly.
• The"execute"section now calls the newinitialize2function.
These updates ensure that the deployment scripts align with the new initialization process.contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry.json (3)
150-156: Add New Initialization Functioninitialize2
A new no-argument, nonpayable functioninitialize2has been added. This function is now available in the contract’s ABI and is part of the upgrade path. Verify that all corresponding contract source code and deployment scripts use this new function.
231-242: Add New Version Functionversion
The ABI now includes a new view functionversionthat returns a string. This addition is consistent with similar changes in other contracts and improves version management.
293-294: Update Deployment Parameters
The deployment metadata has been updated with:
•"numDeployments": 3(indicating an increased deployment count)
• An updated"solcInputHash"value
These changes reflect that the contract was recompiled with updated settings. Please ensure that any associated migration scripts or tests are updated accordingly.contracts/deployments/arbitrumSepolia/DisputeKitClassic.json (4)
838-844: Introduceinitialize2in DisputeKitClassic
A new no-argument functioninitialize2is added to support the upgrade mechanism. Ensure that the contract source code now routes upgrade calls through this function.
887-899: Add FunctionsingleDrawPerJuror
The ABI now includes a new view functionsingleDrawPerJurorwhich returns a boolean. This signal is likely used to indicate a specific draw mode per juror. It is important to verify that this new function matches the behavior defined in the Solidity implementation and that appropriate tests exist for this functionality.
919-930: Add New Version Functionversion
The contract now provides a view functionversionthat returns a string. This enhancement will help in tracking the deployed contract version and should be verified alongside the deployment scripts.
1015-1017: Update Deployment Metadata
Deployment parameters are updated:
•"numDeployments"is set to 2
• The"solcInputHash"has been refreshed
These changes reflect the upgrade and must be consistent with the new initialization logic in the deployment scripts.contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule.json (2)
131-137: Add New Initialization Functioninitialize2
The devnet version of EvidenceModule now includes the newinitialize2function (nonpayable, no arguments) to support the updated initialization process. Please confirm that the new function’s behavior is as intended in your underlying Solidity implementation.
255-258: Execute Updated Initialization
The"execute"section now callsinitialize2with an empty argument array. This update is consistent with the new ABI changes and deployment strategy.contracts/deployments/arbitrumSepolia/PolicyRegistry.json (3)
144-150: Introduceinitialize2to PolicyRegistry
A newinitialize2function (nonpayable, no inputs or outputs) is now part of the PolicyRegistry ABI. This addition is part of ensuring a standardized upgrade mechanism across all contracts.
225-236: Add New Version Functionversionin PolicyRegistry
The contract’s ABI now contains aversionfunction that returns a string. This provides a built-in approach for version tracking. Make sure that the contract’s implementation returns an appropriate version string.
287-289: Update Deployment Details
The deployment metadata now reflects updated values:
•"numDeployments"has been increased to 2
• The"solcInputHash"has been updated
Ensuring consistency across deployment scripts and source code is key for smooth upgrades.contracts/deployments/arbitrumSepolia/DisputeTemplateRegistry.json (4)
230-242: Introduce NewversionFunction in ABI
The newversionfunction provides a view returning a string, which is useful for confirming the contract’s version at runtime. Verify that the string returned by the implementation matches expectations and that it is consistent with other versioning conventions in the system.
293-295: Update Deployment Metadata:numDeploymentsandsolcInputHash
The change from a single deployment tonumDeployments: 2and the accompanying update tosolcInputHashindicate that the compilation inputs or configuration have been revised. Please double-check that these new values correctly reflect the upgraded contract’s state and that downstream deployment scripts interpret them as intended.
299-300: Update Execution Block to Callinitialize2
The deployment’sexecutesection now specifies theinitialize2method with an emptyargslist. This aligns with the new initializer signature. Ensure that this change has been propagated to all relevant deployment scripts and that post-deployment initialization behaves as expected.
302-302: Updated Implementation Address
Theimplementationfield now points to a new address (0xf97791DA66e0A8Ff8Ee4908872CfCAcc641829Ec). Please verify that this address corresponds to the correct deployed implementation and that all references to the implementation in deployment and upgrade scripts are adjusted accordingly.contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Implementation.json (7)
2-2: Updated Contract Address
The contract’s"address"field has been updated to0x6C255c01E6547f6C9ed98E7f3d9BB3eF9a347C52. Confirm that this new address is intentional and that any external references to the EvidenceModule implementation are revised accordingly.
128-134: Add Newinitialize2Function in ABI
Similar to the other deployment file, the ABI now includes aninitialize2function with no inputs and nonpayable state mutability. Ensure that the smart contract’s logic (using a reinitializer) properly handles this new function and that it is used consistently across different environments (e.g., mainnet vs. devnet).
184-196: Introduce NewversionFunction in ABI
A new view functionversionhas been added, which returns a string. This provides a mechanism for the contract to report its version at runtime. Verify that the string value returned in the implementation is consistent with the upgrade version (e.g., "0.8.0") and that documentation and deployment scripts reflect this change.
198-207: Update Transaction Metadata in Deployment Receipt
The deployment receipt metadata—including thetransactionHash,contractAddress,gasUsed, andblockHash—has been updated. These changes are expected with a redeployment. Please ensure that any automated monitoring or off-chain indexing systems that depend on these values are aware of the update.
228-230: Update Deployment Metadata:numDeploymentsandsolcInputHash
The change to"numDeployments": 2along with the updated"solcInputHash"confirms modifications in the contract’s compilation settings or source code. Verify that these updated values align with the current contract artifacts and that upgrade procedures account for multiple deployments if applicable.
231-232: Review Updated Bytecode Values
The"bytecode"and"deployedBytecode"fields have been updated as part of this upgrade. This is expected; however, make sure that these new bytecode values have been thoroughly tested and that the upgrade does not introduce any unintended behavioral changes.
336-342: Review Storage Layout Update
The storage layout section now shows an updated entry (e.g., the"astId": 21480for thegovernorvariable). Verify that no unintended storage reordering has occurred during the upgrade and that the changes are backward-compatible with previous deployments.contracts/deployments/arbitrumSepolia/DisputeTemplateRegistry_Implementation.json (4)
2-2: Confirm new contract address.A new deployment address was introduced: "0xf97791DA66e0A8Ff8Ee4908872CfCAcc641829Ec". Please verify that this address is correct and matches the intended target environment.
226-236: Addedversionfunction for implementation info.Great addition for clarity. This function helps keep track of which version is deployed. Validate that this matches your official release/versioning scheme.
241-275: Deployment state updated (transaction data, bytecode, etc.).All these updates (transaction hash, contract address, block number, gas used, bytecode, etc.) appear to be normal byproducts of a redeployment. Ensure they match the expected environment and that no references to the old addresses remain in your code or scripts.
284-288: Added doc details forInvalidImplementation(address).Documenting the error case for non-UUPS-compliant implementations improves maintainability and clarity.
contracts/deploy/upgrade-all.ts (3)
1-9: Imports and setup look consistent.These imports (Hardhat, prompt utilities, custom deploy functions, etc.) are appropriate. No issues found.
50-56: Sequential upgrades to various contracts.Invoking
initialize2orinitialize3for each contract is consistent with the new upgrade pattern. Confirm that the chosen initializer name correctly matches the contract’s new initialization version to avoid re-initialization conflicts.
58-61: Deployment skip condition.Skipping networks based on
isSkippedand chain configuration is a straightforward approach. No concerns here, but ensure the correct chain IDs are included inHomeChains.contracts/deployments/arbitrumSepolia/SortitionModule.json (5)
102-102: Changed event name toStakeDelayedAlreadyTransferredDeposited.Renaming an event can break external listeners that rely on the old name. Confirm that dependent services or subgraphs are updated to use the new event name.
200-206: New_amountAllCourtsparameter inStakeSetevent.This extra parameter can provide valuable context for staked amounts across all courts. Ensure downstream consumers are aware of this extended event signature.
224-236: AddedchangeGovernorfunction.Introducing a dedicated governance function can simplify role changes. Verify that only authorized calls can execute this method to prevent governance hijacking.
961-972: Added aversionpublic view function.This function clarifies which version of the contract is in use. This is key when verifying deployments across networks.
1023-1027: Deployment metadata updated (numDeployments, bytecode, etc.).All updated deployment metadata is consistent with the introduction of a new initializer. Verify that references throughout your codebase align with the new deployment data.
contracts/deployments/arbitrumSepolia/EvidenceModule_Implementation.json (5)
2-2: Contract Address Updated
The contract address has been updated from the old value to"0xC4e64e6E949936a18269937FC1e18cb11E3db14D". Please ensure that all dependent systems and scripts are referencing this new address.
128-134: New Initialization Functioninitialize2Added
A new nonpayable functioninitialize2has been introduced. This aligns with the upgrade pattern for multi-phase initializations. Verify that its invocation is coordinated with the upgrade process and that no legacy reliance on the old initializer remains.
184-196: New Version FunctionversionAdded
The addition of the view functionversionto return a string version identifier helps ensure version tracking for the deployed implementation. Confirm that the returned version string is consistent with documentation and other contracts in the upgrade process.
198-230: Deployment Metadata Updated
Deployment metadata such as thetransactionHash,gasUsed, and thenumDeploymentsvalue (now updated to 2) have been refreshed. These changes demonstrate a new deployment instance and updated gas metrics. Please verify that these metadata values correctly reflect the latest deployment outcomes and are in sync with the deployment scripts.
240-244: Enhanced Error Message forInvalidImplementation
The error object forInvalidImplementationhas been enhanced with a detailed message indicating that the implementation is not UUPS-compliant. This extra detail should aid in debugging upgrade failures. Ensure that consumers of this error can correctly parse and react to the more descriptive message.contracts/deployments/arbitrumSepoliaDevnet/PolicyRegistry.json (4)
144-150: New Initialization Functioninitialize2Added
A new initializerinitialize2(nonpayable with no inputs/outputs) has been added. This update is consistent with the new initialization approach across the contracts. Confirm that deployment scripts or upgrade routines call this function appropriately.
224-236: New Version FunctionversionAdded
The new view functionversionreturns a version string for the contract. This will be useful for tracking the deployed implementation version. Ensure that the value returned here matches the intended versioning standard applied within the upgrade framework.
293-295: Updated Execute Configuration
Theexecutesection has been updated to call the newinitialize2function with an empty arguments list. This change should be reflected in the deployment automation. Verify that this adjustment triggers the expected initialization behavior during deployment.
287-289: Deployment Metadata Adjustments
Metadata fields such asnumDeployments(now set to 2) and thesolcInputHashhave been updated, reflecting the latest compilation and deployment status. Please double-check that these changes are in line with the overall upgrade and deployment process.contracts/deployments/arbitrumSepolia/KlerosCore.json (4)
289-294: Refined Court ID Type in Events
The_courtIDparameter in the relevant event (e.g. in the “NewPeriod” event) now usesuint96instead of the wider type. This change improves storage efficiency. Ensure that any dependent off-chain systems or event listeners are updated to expect auint96value.
1651-1657: New Initialization Function “initialize3” Introduced
A new functioninitialize3(with no arguments and marked nonpayable) has been added to support the upgraded initialization process. Please double-check that all deployment scripts and upgrade workflows now call this new function instead of the legacy initializer, and that the change is propagated throughout the system.
1858-1869: Addition of “version” Function
A new view functionversionis provided to return a string representing the contract version. This is useful for on-chain versioning and external integrations. Please confirm that the returned version value matches the intended contract version and that client tools querying this information are updated accordingly.
1963-1965: Updated Deployment Metadata
The deployment details have been revised—numDeploymentsis now 2 and thesolcInputHashas well as metadata fields have been updated. Make sure these changes are in sync with the latest implementation and that any integration or testing scripts consuming this metadata are correspondingly updated.contracts/deployments/arbitrumSepolia/PolicyRegistry_Implementation.json (5)
2-2: Updated Contract Address
The contract address has been updated to"0x7CC8E0787e381aE159C4d3e137f20f9203313D41". Confirm that all references (deployment scripts, front-end integrations, etc.) are now pointing to the new address.
221-233: Addition of “version” Function
A new view functionversionreturning a string is now available. This function will help clients and tools to retrieve the implementation version. Ensure that the version string returned is consistent with the contract’s upgrade history and that downstream tools that rely on this information are updated accordingly.
235-243: Updated Deployment Receipt Details
The receipt section reflects updates in the transaction hash, contract address, transaction index (now 3), and gas usage. Please confirm that these updated details are aligned with the new deployment process and that any monitoring or documentation tools are updated to reflect this change.
265-267: Updated Deployment Metadata and State Variables
The metadata now indicatesnumDeploymentsas 2 and includes a newsolcInputHashalong with a detailed metadata section (including aversionstate variable description). Verify that these metadata changes correctly reflect the current implementation and that any automated tooling or deployment verifications can process these new details.
141-147:❓ Verification inconclusive
New Initialization Function “initialize2” Added
The ABI now includes a new functioninitialize2(nonpayable with no inputs or outputs) that supplements the deployment initialization process. Please verify that its purpose is documented in accompanying code or deployment guides and that other components relying on initialization have been updated to call it where appropriate.
Below is a shell script that searches for references to the new
initialize2function across the repository—including in potential documentation (such as README.md and any docs folder). This will help verify whether its purpose is documented and whether other components that rely on initialization have been updated accordingly.Please run this script to gather the verification details. Once you have the results, you can confirm if the addition of
initialize2is properly documented and integrated in related components.
🏁 Script executed:
#!/bin/bash # Search for all occurrences of "initialize2" in the repository echo "Searching for references to 'initialize2' across the repository..." rg -n "initialize2" . # Check for documentation in README.md echo "Searching for references to 'initialize2' in README.md..." rg -n "initialize2" README.md || echo "No references found in README.md." # Optionally check within a docs folder if it exists if [ -d "docs" ]; then echo "Searching for references to 'initialize2' in the docs/ directory..." rg -n "initialize2" docs/ || echo "No references found in the docs directory." else echo "Docs folder not found." fiLength of output: 93867
Action Required: Verify Updated Documentation for
initialize2FunctionThe ABI now includes the new no-op reinitializer function
initialize2, which is visible not only in the current file (contracts/deployments/arbitrumSepolia/PolicyRegistry_Implementation.json, lines 141–147) but also across similar deployment artifacts and contract source files (e.g., inPolicyRegistry.sol,EvidenceModule.sol, andDisputeTemplateRegistry.sol). This appears to be an intentional version bump for initialization upgrades.However, our initial search did not reveal corresponding references in README.md or a dedicated docs folder. Please confirm that:
- The purpose of
initialize2is clearly documented in your deployment guides or code comments.- All dependent components have been updated accordingly to invoke this new initialization function where needed.
contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Implementation.json (4)
2-2: Contract Address Update.
The contract address has been updated to0x03D29FE2bDd759613B92C190e2991036b2939Ff1as expected according to the PR objectives. Please double-check that all deployment scripts reference this new address.
227-238: Addition ofversionFunction.
A new view functionversionreturning a string (the implementation version) has been added. This aligns with the coordinated update across similar contracts and improves upgrade tracking.
241-247: Updated Deployment Transaction Details.
Transaction details includingtransactionHash,transactionIndex,gasUsed, and block identifiers have been updated. Ensure that these values are consistent with the latest deployment and that further deployment scripts or monitoring systems are updated accordingly.
271-274: Increase in Number of Deployments and Metadata Updates.
The number of deployments has increased to 3, and thesolcInputHashhas been updated. Additionally, the metadata now includes enhanced descriptions for functions and errors (e.g. the detailed explanation forInvalidImplementation). This improves clarity on function behavior and error handling.contracts/deployments/arbitrumSepoliaDevnet/PolicyRegistry_Implementation.json (6)
2-2: Contract Address Update.
The contract address has been updated to0xda6Da4CCb1EA9aD670A1380De84c5dD4aef87adf. Confirm that deployment scripts and front-end integrations now target the new address.
141-147: Addition ofinitialize2Function.
The newinitialize2function (nonpayable, no inputs/outputs) has been added. This update is consistent with similar changes in other contracts and improves the initialization upgrade process.
221-233: Addition ofversionFunction.
A new view functionversionreturning a string has been introduced. This addition helps in identifying the version of the implementation at runtime and is a welcome enhancement for contract management.
235-243: Updated Deployment Transaction Details.
Changes to transaction metadata (transaction hash, index, gas used, block hash, and block number) have been updated. These values should match the new deployment on the network. Please verify that off-chain tooling uses these updated values.
265-267: Deployment Count and Compilation Metadata.
ThenumDeploymentsfield now reflects 2 deployments, and thesolcInputHashhas been updated. This metadata update appears to be in line with the changes introduced in the PR.
278-282: Enhanced Error Documentation in Devdoc.
TheInvalidImplementation(address)error now includes the description "Theimplementationis not UUPS-compliant". This detailed error message will help during troubleshooting in upgrade scenarios.contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassic.json (5)
838-844: New initialize2 Function Added
The newinitialize2function (with no inputs or outputs) has been added to support the upgrade. Please verify that its internal initialization logic correctly sets up the contract state and that all deployment scripts have been updated to invokeinitialize2instead of the legacyinitialize.
887-895: Addition of singleDrawPerJuror Function
The new functionsingleDrawPerJuror, which returns a boolean and is marked as view, appears to fulfill its designed role. Please ensure that its implementation logic meets the new business requirement and that any off‐chain integrations are aware of this updated interface.
919-930: Inclusion of version Function
The newly addedversionfunction returns a string and is appropriately marked as view. Confirm that the returned version string is consistently maintained across upgrades to help track deployment milestones.
1015-1017: Deployment Metadata Update
The updates tonumDeployments,solcInputHash, and themetadatasection reflect a new compilation state and additional deployments. Please make sure these values accurately represent the deployed contract's state and that any documentation referencing versioning is in sync with these changes.
1021-1024: Execute Section Consistency Check
Theexecuteobject now specifiesinitialize2as the method to call, and theimplementationaddress has been updated. Verify that the deployment scripts correctly trigger this new initializer and that the implementation update is accurate relative to the upgraded contract.contracts/deployments/arbitrumSepoliaDevnet/SortitionModule.json (8)
101-104: Renamed Event for Stake Delayed Transfer
The event has been renamed toStakeDelayedAlreadyTransferredDeposited. Ensure that off‐chain services (e.g., indexers or event listeners) are updated to monitor this new event name so that no critical event data is missed.
200-206: New Parameter Added to StakeSet Event
TheStakeSetevent now includes an extra parameter_amountAllCourts. Please confirm that this value is correctly populated during event emissions and that any consumers of the event update their parsing logic accordingly.
225-235: Addition of changeGovernor Function
A newchangeGovernorfunction has been introduced. Please verify that appropriate access control mechanisms are enforced in the underlying contract logic to ensure that only authorized accounts can change the governor address.
554-560: New initialize3 Function Introduced
Theinitialize3initializer is added to support the upgrade process. Ensure that its execution sets up the new state correctly and that it does not conflict with any previous initializers.
961-972: Addition of version Function in SortitionModule
Theversionfunction is now available to return the current contract version as a string. Confirm that this function's return value is maintained consistently across upgrades, aiding in tracking contract revisions.
1023-1025: Updated Deployment Artifact Metadata
The artifact now reflects an increasednumDeploymentsand updatedsolcInputHashalong with revised metadata. Ensure that these updates are in line with the actual deployment changes and that documentation or scripts consuming these artifacts are adjusted accordingly.
1029-1031: Execute Section for initialize3
The execute section now callsinitialize3(with no arguments), which corresponds to this contract’s new initialization process. Please verify that the associated deployment workflows correctly trigger this function to set up the contract state post-upgrade.
1032-1033: Implementation Address Update
The implementation address has been updated to0x45129beB9B84BFb07bA885085C1D60437494a93f. Please confirm that this address correctly points to the upgraded contract and is consistent with your deployment records.contracts/README.md (12)
38-38: Updated DisputeKitClassic Implementation Reference
The README now reflects the updated implementation address for DisputeKitClassic (0xCd4B2aD853027DbF7629003242CD609BDdaA89E1). Please ensure that this change is consistent with the deployment artifacts and that all relevant documentation is updated.
40-40: Updated DisputeTemplateRegistry Implementation
The implementation address for DisputeTemplateRegistry has been updated. Confirm that the new address (0xf97791DA66e0A8Ff8Ee4908872CfCAcc641829Ec) aligns with the deployed contract version.
41-41: Updated EvidenceModule Implementation Reference
The EvidenceModule now points to the new implementation address (0xC4e64e6E949936a18269937FC1e18cb11E3db14D). Please verify that this reflects the latest upgrade.
42-42: Updated KlerosCoreNeo Implementation
The updated implementation address for KlerosCoreNeo (0x3Dc15eb9673b7228c69aBcF056d4c4044325fdf7) is now documented. Ensure that this address is correct and that any dependencies on this contract are updated.
46-46: Updated PolicyRegistry Reference
The PolicyRegistry section now includes the new implementation address (0x7CC8E0787e381aE159C4d3e137f20f9203313D41). This update should be verified against your deployment data.
48-48: Updated SortitionModule Implementation
The SortitionModule implementation address is now updated to0xAe750D6Fa39b1044d4081CB0bfecF886d176Be5b. Please double-check that this new reference is accurate and consistent throughout your documentation.
80-80: Updated DisputeKitClassic in Devnet Section
Within the Devnet section, the DisputeKitClassic proxy now points to an updated implementation (0xCb9621470b3081f7164445bd8522F8A6c5Bfe3fa). Verify that this address is in line with your latest devnet deployments.
87-87: Updated Devnet DisputeTemplateRegistry Implementation
The implementation for DisputeTemplateRegistry on Devnet has been updated (new address:0x03D29FE2bDd759613B92C190e2991036b2939Ff1). Please ensure this is correct and that any devnet scripts reference the new address.
88-88: Revised EvidenceModule for Devnet
The Devnet EvidenceModule now uses the new implementation address (0x6C255c01E6547f6C9ed98E7f3d9BB3eF9a347C52). Confirm that this change is reflected across your support documentation.
89-89: Updated KlerosCore on Devnet
The KlerosCore entry for Devnet has been updated to the new implementation (0xF5609e6F10fd25aCb4ddAF14874aD4BaF1956827). Verify that all related references in deployment scripts and tests are accordingly updated.
97-97: Updated Devnet PolicyRegistry Implementation
The new implementation address for PolicyRegistry in the Devnet section (0xda6Da4CCb1EA9aD670A1380De84c5dD4aef87adf) is now documented. Please check that this matches the upgraded contract address.
99-99: Updated Devnet SortitionModule Reference
The SortitionModule in the Devnet section now points to the new implementation (0x45129beB9B84BFb07bA885085C1D60437494a93f). Confirm that this update is consistent with your artifact files.
contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Implementation.json
Show resolved
Hide resolved
jaybuidl
changed the title
fix(subgraph): subgraph-event-fix
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro (Legacy)
📒 Files selected for processing (5)
subgraph/core/src/SortitionModule.ts(2 hunks)subgraph/core/subgraph.yaml(5 hunks)subgraph/core/temp-abis/KlerosCore.json(1 hunks)subgraph/core/temp-abis/SortitionModule.json(1 hunks)subgraph/temp-older-events-addition.txt(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- subgraph/core/subgraph.yaml
🧰 Additional context used
🧬 Code Graph Analysis (1)
subgraph/core/src/SortitionModule.ts (1)
subgraph/core/src/entities/JurorTokensPerCourt.ts (1)
updateJurorDelayedStake(99-113)
⏰ Context from checks skipped due to timeout of 90000ms (15)
- GitHub Check: Redirect rules - kleros-v2-university
- GitHub Check: Header rules - kleros-v2-university
- GitHub Check: Pages changed - kleros-v2-university
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-neo
- GitHub Check: Header rules - kleros-v2-neo
- GitHub Check: Pages changed - kleros-v2-neo
- GitHub Check: SonarCloud
- GitHub Check: contracts-testing
- GitHub Check: Analyze (javascript)
🔇 Additional comments (12)
subgraph/core/src/SortitionModule.ts (2)
3-3: Added import for backward compatibility.The import statement has been added for the
StakeDelayedAlreadyTransferredtype to support handling of the old event name.
15-18: Good temporary solution for handling renamed event.This function handles the old event name
StakeDelayedAlreadyTransferredwhich has been renamed toStakeDelayedAlreadyTransferredDepositedin the new contract version. The implementation correctly forwards the parameters to the existing handler function and is well-documented as a temporary fix.This approach ensures backward compatibility during the transition period, allowing the subgraph to process events from both old and new contract versions without data loss.
subgraph/temp-older-events-addition.txt (3)
1-62: KlerosCore CourtCreated event type change documented.This section properly documents the structure of the
CourtCreatedevent in KlerosCore, showing the change of_courtIDto use typeuint256. This documentation is essential for understanding the ABI changes and implementing proper handlers.
67-91: StakeSet event definition with parameters is well-documented.The JSON definition for the
StakeSetevent in SortitionModule is clearly documented with the appropriate parameter types and indexing information.
96-120: Old StakeDelayedAlreadyTransferred event structure preserved.This section preserves the structure of the old
StakeDelayedAlreadyTransferredevent that's being renamed toStakeDelayedAlreadyTransferredDepositedin the new contract version. Maintaining this documentation ensures proper handling of events from older contract versions.subgraph/core/temp-abis/KlerosCore.json (3)
1713-1717: New initialize3 function added for contract upgradeability.The addition of
initialize3enhances the contract's upgradeability, allowing for governance changes as mentioned in the PR objectives. This function is correctly called during deployment as seen in the execution metadata.
165-167: New error type added for stake validation.The
StakingZeroWhenNoStakeerror has been added, which appears to be a validation check for when a user tries to set their stake to zero when they don't already have a stake.
2033-2033: Implementation address updated.The contract implementation address has been updated to
0xF5609e6F10fd25aCb4ddAF14874aD4BaF1956827, which is part of the contract upgrade process described in the PR.subgraph/core/temp-abis/SortitionModule.json (4)
102-128: Both old and new event names maintained for compatibility.The ABI includes both the new event name
StakeDelayedAlreadyTransferredDeposited(lines 102-104) and the old event nameStakeDelayedAlreadyTransferred(lines 127-129). This ensures compatibility with both old and new contract versions, matching the approach taken in the event handler code.
604-609: New initialize3 function added for contract upgradeability.Similar to KlerosCore, the addition of
initialize3enhances the contract's upgradeability, aligning with the PR objectives to enhance governance functions.
1082-1082: Implementation address updated.The contract implementation address has been updated to
0x45129beB9B84BFb07bA885085C1D60437494a93fas part of the contract upgrade process.
206-260:❓ Verification inconclusive
Duplicate StakeSet events with different parameter sets.
There are two definitions of the
StakeSetevent with different parameter lists:
- First definition (lines 206-235): Includes parameters
_address,_courtID,_amount, and the new_amountAllCourts- Second definition (lines 237-260): Only includes
_address,_courtID, and_amountThis duplication is intended to support backward compatibility but could lead to confusion in event processing. Ensure the subgraph handlers account for both event signatures.
🏁 Script executed:
#!/bin/bash # Check how the StakeSet event is emitted in the contract implementation rg -A 2 "emit StakeSet"Length of output: 65910
Action Required: Verify Dual Handling of StakeSet Events in Subgraph Mapping
The ABI defines two separate
StakeSetevents with different parameters—a 4-parameter version (with_address,_courtID,_amount, and_amountAllCourts) and a legacy 3-parameter version (dropping_amountAllCourts). Our search shows the live contract (in SortitionModuleUniversity.sol) emits the 4-parameter event:
emit StakeSet(_account, _courtID, _newStake, juror.stakedPnk);Since the duplicate 3-parameter event exists solely for backward compatibility, please verify that your subgraph event handlers are correctly set up to capture and process both signatures.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
contracts/scripts/compareStorageLayout.ts (2)
21-45: Effective but potentially inefficient build info search.The code searches for build info by iterating through all build info paths and parsing each file. This approach works but might be inefficient with many build files.
Consider using the Hardhat API more directly if possible:
// Alternative approach (if available in your Hardhat version) const artifact = await hre.artifacts.readArtifact(contract); const buildInfo = await hre.artifacts.getBuildInfo(`${artifact.sourceName}:${contract}`); if (!buildInfo) { throw new Error(`Could not find build info for contract ${contract}`); } const contractData = buildInfo.output.contracts[artifact.sourceName][contract]; const updatedLayout = contractData.storageLayout;
47-55: Consider making validation options configurable.The validation options are hardcoded, which limits flexibility. Consider allowing these to be customized through task parameters.
+ .addFlag("allowCustomTypes", "Allow custom types in storage upgrade") + .addFlag("allowRenames", "Allow storage variable renames") + .addFlag("skipStorageCheck", "Skip storage layout check") + .addFlag("allowLinkedLibraries", "Allow linked libraries in the contract") .setAction(async ({ deployedArtifact, contract, + allowCustomTypes, + allowRenames, + skipStorageCheck, + allowLinkedLibraries }, hre: HardhatRuntimeEnvironment) => { // ... const validationOptions: Required<ValidationOptions> = { - unsafeAllowCustomTypes: true, + unsafeAllowCustomTypes: allowCustomTypes || false, - unsafeAllowRenames: false, + unsafeAllowRenames: allowRenames || false, unsafeAllow: [], - unsafeSkipStorageCheck: false, + unsafeSkipStorageCheck: skipStorageCheck || false, - unsafeAllowLinkedLibraries: false, + unsafeAllowLinkedLibraries: allowLinkedLibraries || false, kind: "uups", };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro (Legacy)
📒 Files selected for processing (2)
contracts/hardhat.config.ts(1 hunks)contracts/scripts/compareStorageLayout.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- contracts/hardhat.config.ts
⏰ Context from checks skipped due to timeout of 90000ms (15)
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-neo
- GitHub Check: Header rules - kleros-v2-neo
- GitHub Check: Pages changed - kleros-v2-neo
- GitHub Check: Redirect rules - kleros-v2-testnet-devtools
- GitHub Check: Header rules - kleros-v2-testnet-devtools
- GitHub Check: Pages changed - kleros-v2-testnet-devtools
- GitHub Check: Analyze (javascript)
- GitHub Check: contracts-testing
- GitHub Check: SonarCloud
🔇 Additional comments (3)
contracts/scripts/compareStorageLayout.ts (3)
1-9: Good imports for a Hardhat task script.The imports are appropriate for handling file operations, path manipulation, console output, and OpenZeppelin's storage layout comparison utilities.
10-13: Well-structured task definition with clear parameters.The task name and description are clear, and the parameters are appropriately defined with one required parameter ("contract") and one optional parameter ("deployedArtifact").
56-74: Good error handling and reporting for storage layout incompatibilities.The code properly handles the comparison results, providing clear success or error messages. The error handling block (try/catch) ensures that any exceptions are properly reported to the user.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
contracts/deploy/upgrade-all.ts (1)
27-31: Consider enhancing the confirmation message.The confirmation prompt could be more specific about which contract is being upgraded. This would be especially helpful when upgrading multiple contracts in sequence.
- message: "Are you sure you want to proceed?", + message: `Are you sure you want to proceed with upgrading ${contractName}?`,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro (Legacy)
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (6)
contracts/deploy/upgrade-all.ts(1 hunks)contracts/deploy/upgrade-dispute-kit-v0.8.0.ts(2 hunks)contracts/deploy/upgrade-kleros-core-v0.8.0.ts(2 hunks)contracts/deploy/upgrade-sortition-module-v0.8.0.ts(2 hunks)contracts/package.json(3 hunks)contracts/scripts/compareStorageLayout.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- contracts/deploy/upgrade-sortition-module-v0.8.0.ts
- contracts/package.json
- contracts/scripts/compareStorageLayout.ts
🧰 Additional context used
🧬 Code Graph Analysis (2)
contracts/deploy/upgrade-kleros-core-v0.8.0.ts (2)
contracts/scripts/utils/contracts.ts (1)
getContractNamesFromNetwork(137-146)contracts/deploy/utils/deployUpgradable.ts (1)
deployUpgradable(37-89)
contracts/deploy/upgrade-all.ts (2)
contracts/scripts/utils/contracts.ts (1)
getContractNamesFromNetwork(137-146)contracts/deploy/utils/deployUpgradable.ts (1)
deployUpgradable(37-89)
⏰ Context from checks skipped due to timeout of 90000ms (15)
- GitHub Check: Redirect rules - kleros-v2-neo
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-university
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-neo
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-university
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-neo
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-university
- GitHub Check: SonarCloud
- GitHub Check: contracts-testing
- GitHub Check: Analyze (javascript)
🔇 Additional comments (11)
contracts/deploy/upgrade-dispute-kit-v0.8.0.ts (3)
5-7: Good addition of utilities for improved UX.The imports for dynamic contract name retrieval and interactive prompting enhance the upgrade experience significantly by making the script adaptable to different networks and adding user interaction.
19-33: Great addition of validation and user confirmation.The implementation of storage layout validation and user confirmation before proceeding with the upgrade significantly improves safety. This helps prevent unintended consequences during critical contract upgrades.
34-36: Note the initializer change from "initialize" to "initialize2".The script now uses the new "initialize2" function instead of "initialize". This aligns with the PR objective of enhancing governance functionalities through new initializer functions.
contracts/deploy/upgrade-kleros-core-v0.8.0.ts (3)
5-7: Good addition of utilities for improved UX.The imports for dynamic contract name retrieval and interactive prompting enhance the upgrade experience significantly by making the script adaptable to different networks and adding user interaction.
19-33: Great addition of validation and user confirmation.The implementation of storage layout validation and user confirmation before proceeding with the upgrade significantly improves safety. This helps prevent unintended consequences during critical contract upgrades.
34-36: Note the initializer change from "initialize" to "initialize3".The script now uses the new "initialize3" function instead of the previous initializer. This aligns with the PR objective of enhancing governance functionalities through new initializer functions. Note that this is "initialize3" whereas the dispute kit uses "initialize2" - this suggests KlerosCore has gone through more upgrade iterations.
contracts/deploy/upgrade-all.ts (5)
1-9: Good structure and imports for the new upgrade utility.The new file properly imports all necessary dependencies for handling contract deployments and upgrades. The use of the gluegun library for interactive CLI and the utility functions from other modules is appropriate.
18-20: Effective use of dynamic contract name retrieval.The script properly extracts contract names dynamically using the
getContractNamesFromNetworkfunction. This aligns with the PR's goal of making the deployment scripts more flexible and network-aware.
21-51: Well-structured upgrade function with proper validation and error handling.The
upgradefunction encapsulates all the necessary steps for upgrading a contract:
- Validation of storage layout
- User confirmation
- Actual deployment
- Verification on Etherscan
This approach provides consistency across all contract upgrades and includes proper error handling.
53-58: Consistent approach to upgrading multiple contracts.The script properly applies the upgrade function to multiple contracts with their respective initializers:
- Most contracts use "initialize2"
- Core and sortition use "initialize3"
This is consistent with the PR's objective of enhancing governance functionalities through new initializer functions.
61-64: Appropriate tags and skip conditions.The deployment tags and skip conditions are properly set to ensure the script runs only on appropriate networks, consistent with the other upgrade scripts.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Implementation.json (1)
147-153: Addition ofinitialize2Function (Duplicate Review).
As in other files, the newinitialize2initializer is added here to standardize post-upgrade procedures.
🧹 Nitpick comments (2)
contracts/deployments/arbitrumSepoliaDevnet/KlerosCore.json (1)
153-157: Potential Typographical Issue in Error Name: StakingNotPossibeInThisCourt.
The error name"StakingNotPossibeInThisCourt"appears to contain a probable typo (“Possibe” vs. “Possible”). Please double-check the naming convention. If this is unintentional, consider correcting it to"StakingNotPossibleInThisCourt".contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Implementation.json (1)
184-195: AddversionFunction to ABI
A new view functionversionreturning a string has been added. Confirm that the returned version string (which should reflect the intended version, e.g. "0.8.0") is consistent with the contract’s documentation and on-chain constants.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro (Legacy)
📒 Files selected for processing (15)
contracts/README.md(2 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassic.json(6 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassicNeo.json(0 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassicNeo_Proxy.json(0 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassic_Proxy.json(2 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeResolver.json(6 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeResolverNeo.json(0 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeResolverRuler.json(0 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry.json(4 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Implementation.json(8 hunks)contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Proxy.json(2 hunks)contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule.json(4 hunks)contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Implementation.json(9 hunks)contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Proxy.json(2 hunks)contracts/deployments/arbitrumSepoliaDevnet/KlerosCore.json(18 hunks)
💤 Files with no reviewable changes (4)
- contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassicNeo_Proxy.json
- contracts/deployments/arbitrumSepoliaDevnet/DisputeResolverNeo.json
- contracts/deployments/arbitrumSepoliaDevnet/DisputeResolverRuler.json
- contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassicNeo.json
🚧 Files skipped from review as they are similar to previous changes (1)
- contracts/README.md
⏰ Context from checks skipped due to timeout of 90000ms (7)
- GitHub Check: Redirect rules - kleros-v2-university
- GitHub Check: Header rules - kleros-v2-university
- GitHub Check: Pages changed - kleros-v2-university
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: contracts-testing
🔇 Additional comments (72)
contracts/deployments/arbitrumSepoliaDevnet/KlerosCore.json (17)
2-2: Updated Contract Address.
The contract’s address has been updated to"0x4838e31E0ea315232c431598110FE677cAF2D6E6". Please verify that this is the intended deployment address and that it is consistent with your deployment scripts and network configuration.
82-86: New Error Definition: GuardianOrGovernorOnly.
A new error"GuardianOrGovernorOnly"has been added. Ensure that this error is correctly integrated in the contract’s authorization logic and that corresponding tests are updated to capture this failure condition when unauthorized addresses attempt sensitive actions.
144-147: New Error Definition: StakingInTooManyCourts.
The error"StakingInTooManyCourts"has been introduced to likely guard against excessive staking across multiple courts. Confirm that the contract logic properly checks for this condition and that documentation/tests reflect its intended usage.
148-152: New Error Definition: StakingLessThanCourtMinStake.
The addition of the"StakingLessThanCourtMinStake"error indicates a new validation to ensure staked amounts meet a court’s minimum requirement. Please verify that the usage of this error is aligned with contract invariants and that adequate test cases cover this scenario.
158-162: New Error Definition: StakingTransferFailed.
The error"StakingTransferFailed"has been added. Verify that its triggering condition is robustly coded and that failing transfers are properly handled elsewhere in the contracts, including in any retry or recovery logic if applicable.
214-223: New Error Definitions: WhenNotPausedOnly and WhenPausedOnly.
Two pause-related errors have been introduced. Ensure that the pause/unpause logic in the contract uses these errors appropriately to restrict function calls when the contract is paused or active.
964-976: New Function: changeGuardian.
A new functionchangeGuardianhas been added (lines 964–976). Confirm that this function implements the necessary access control (e.g., only callable by a governor or equivalent authority) and that related tests and documentation are updated accordingly.
1652-1657: Added Initializer: initialize3.
The new, parameterless initializerinitialize3is introduced to replace the older initialization routine. Make sure that deployment scripts and upgrade procedures now referenceinitialize3and that all initialization data is correctly transferred to the new function.
1728-1733: New Function: pause.
The addition of thepausefunction introduces pause functionality for emergency stops. Please confirm that appropriate access control is enforced and that tests cover scenarios where pause should and should not be allowed.
1734-1746: New Function: paused.
A new view functionpausedhas been added to query the pause state of the contract. Verify that it returns accurate status in all cases and that it is used by off-chain monitoring or other contract logic as intended.
1833-1838: New Function: unpause.
Theunpausefunction allows resuming operations after a pause. Confirm that proper access restrictions are in place and that this function restores all functionalities without side effects.
1858-1869: New Function: version.
The newly addedversionfunction returns a string representing the contract version. Ensure that the version string accurately reflects the current upgrade (e.g.,"0.8.0") and is integrated into any user interfaces or administrative tooling.
1891-1897: Deployment Receipt Updates.
The receipt section now includes updated values such as thecontractAddress,transactionIndex, andgasUsed. While these details are auto-generated, please double-check that they match expected outcomes based on your deployment environment.
1963-1963: Updated Implementation Address.
The"implementation"field has been updated to"0xb6839061C3aD03c208EFd697409453bf9900cAb2". Verify that this new implementation address is correct and that it reflects the latest contract upgrade.
1964-1965: Metadata and Compiler Settings Update.
ThesolcInputHash,metadata, and associated fields have been updated to reflect the new compiler version (0.8.24) and optimizer settings. Please verify that these auto‑generated values are consistent with the intended contract configuration and that nothing critical was omitted during the upgrade.
1967-1968: Bytecode Updates.
Both thebytecodeanddeployedBytecodefields have new values. Although these are generated by the compiler, a verification that the new bytecode corresponds to the updated contract logic (including new errors and functions) is recommended.
1968-1991:❓ Verification inconclusive
Initialization Method Discrepancy.
The"execute"section calls the method"initialize"with several arguments, yet the ABI now includes a newinitialize3function (which appears parameterless). This discrepancy might mean that the deployment process is still targeting the old initializer. Please confirm whether the deployment should now callinitialize3rather thaninitializeand update the deployment configuration accordingly.
Heads-up: Verify Initialization Method Alignment
The deployment configuration incontracts/deployments/arbitrumSepoliaDevnet/KlerosCore.jsonstill calls the"initialize"method with several arguments, while the updated ABI now includes a new, parameterless"initialize3"function. This mismatch may indicate that the deployment is targeting an outdated initializer.
- Please confirm whether the deployment should now invoke
"initialize3"instead of"initialize".- Update the deployment configuration accordingly if
"initialize3"is indeed the intended initializer.contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Implementation.json (10)
2-2: Update Contract Address
The contract address has been updated to"0xf9f41910696DadF83a7B0b3e856a175D6aEEC8e8". Please ensure that all dependent modules and off-chain references are updated accordingly.
202-207: Update Deployment Receipt Details
Within the"receipt"block, fields such as"contractAddress","transactionIndex","gasUsed","blockHash", and"transactionHash"have been updated. Please double-check that these new values accurately reflect the deployment on the correct network.
210-219: Refresh Log Entry Details
The log entry in the receipt (covering transaction index, block number, transaction hash, contract address, log index, and block hash) has updated values. Ensure these details match the expected deployment log on-chain.
229-229: UpdatesolcInputHash
The"solcInputHash"has been updated to"c66a072bc17d18807b6e81f338ff0fab". Verify that this hash correctly corresponds to the new compilation input and reflects any relevant compiler changes.
230-230: Update Metadata for New Compilation
The metadata section now reflects updated compiler settings (e.g. version"0.8.24+commit.e11b9ed9") and associated configuration. Please confirm that these metadata values are in sync with your current build environment.
232-232: New Deployed Bytecode
The"deployedBytecode"has been updated. Make sure that this bytecode corresponds exactly to the newly deployed contract version and that no unintended modifications are present.
240-244: ClarifyInvalidImplementationError Documentation
The documentation for theInvalidImplementation(address)error now explicitly states that the implementation is not UUPS‑compliant. This added clarity is useful—just verify that all references to UUPS upgradeability are consistent across contracts.
265-267: Refine Evidence Parameter Documentation
The_evidenceparameter documentation now specifies that the evidence is provided as a stringified object (including fields likename,description, andfileURI), rather than an IPFS path. This clarification should help users correctly format their submissions.
310-316: Update State Variable Documentation forversion
The state variable documentation now confirms thatversionreturns a version string. Ensure that this documentation accurately mirrors the behavior of the corresponding function in the contract logic.
336-342: Verify Storage Layout Consistency
The storage layout for thegovernorvariable (stored at slot"0") has been highlighted. Confirm that this layout is consistent with the design of your upgradeable contract to avoid any storage collision issues.contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry.json (5)
2-2: Update of the Contract Address.
The address has been updated to"0x45f0662ec4aA4164b187c1bd39D35D0E3168787a", which looks intentional as part of this upgrade.
150-156: Addition ofinitialize2Function.
A new no-argument, nonpayable initializer (initialize2) has been introduced. This aligns with the upgrade objectives for a standardized, parameter‐free reinitialization step. Please verify that all dependent systems (including deployment scripts) call this new initializer where intended.
230-242: Addition ofversionFunction.
The new view functionversionreturning a string is added to provide runtime version identification. This is consistent with the overall versioning improvements.
264-269: Updated Deployment Receipt Details.
Several fields within the receipt (such ascontractAddress,transactionIndex,gasUsed, andblockHash) have been updated to reflect the new deployment transaction. Please double-check that these new values (especially gas usage) have been validated against the network’s behavior.
287-292: Updated Constructor Arguments and Deployment Metadata.
Theargsnow include the new implementation address"0x0406ea6E28fAb9A23BF0d6f0f23f4352383A8592", and both thenumDeploymentsandsolcInputHashhave been updated. These changes are in line with the upgrade; however, please ensure that dependent tooling (such as subgraph queries) is compatible with the new values.contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule.json (6)
2-2: Update of the Contract Address.
The address has been updated to"0x990f44d19a5F46889801B31bf58e0536fBECf27C", which should now match the new deployment.
131-137: Addition ofinitialize2Function.
The newinitialize2function with no inputs and no outputs is added to support the upgraded initialization flow. This change is consistent with similar contracts in this PR.
187-199: Addition ofversionFunction.
The addedversionfunction returns a version string for the contract and is beneficial for transparency and debugging.
217-224: Updated Deployment Metadata in the Receipt.
Key receipt fields (such ascontractAddress,transactionIndex,gasUsed, andblockHash) have been revised—noticeably with a substantial reduction in gas used. Please confirm that these changes have been thoroughly tested in the new environment (devnet/testnet).
247-249: Updated Constructor Arguments.
The arguments now include"0xf9f41910696DadF83a7B0b3e856a175D6aEEC8e8"as the first arg. Ensure this value is intentional and that every downstream component correctly uses the updated parameters.
291-296: Updated Deployment Metadata and Compiler Hash.
ThenumDeployments,solcInputHash, andmetadatafields have been updated. This is consistent with a new compilation run using Solidity 0.8.24.contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Implementation.json (3)
2-2: Update of the Contract Address.
The implementation address has been updated to"0x0406ea6E28fAb9A23BF0d6f0f23f4352383A8592". This change should now reflect the new contract version.
227-239: Addition ofversionFunction.
The newly introducedversionfunction (view, returns string) aligns with the overall versioning strategy of the contracts.
241-246: Updated Receipt and Transaction Details.
The transaction hash, receipt details (includingcontractAddress,transactionIndex, andgasUsed), and associated metadata have been updated. Please verify these against your deployment records for consistency.contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassic.json (6)
2-2: Contract Address Update.
The address has been updated to"0x2246821E1313A93e2F8CdF7a3422d078f560b457", which is expected after the upgrade.
838-844: Addition ofinitialize2Function.
A new initializer (initialize2) is now available. Ensure that calls from external scripts (and proxy deployments) have been adjusted to use this new method.
887-896: Addition ofsingleDrawPerJurorFunction.
The new view functionsingleDrawPerJuror, which returns a boolean, has been added. This appears intended for governance rules regarding juror draws. Confirm that both the interface and internal logic have been integrated with dependent modules.
919-930: Addition ofversionFunction.
This function now provides runtime versioning information. Its addition is consistent with similar changes across the system.
667-677: Signature Change ingetDegreeOfCoherence.
The function’s input parameter list now includes additional (unnamed)uint256parameters. Please ensure that the updated signature is intentional and that all callers of this function have been updated to match the new input structure.
1011-1017: Updated Deployment Metadata.
The deployment-related fields (such astransactionHash,args,numDeployments, andsolcInputHash) have been updated. Verify that these new values are correct and that any off-chain indexers (e.g., subgraphs) are adjusted accordingly.contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Proxy.json (5)
2-2: Contract Address Update.
The proxy contract address has been updated to"0x990f44d19a5F46889801B31bf58e0536fBECf27C", which matches the new deployment expectations for the EvidenceModule.
29-32: Updated Receipt Fields – Contract Address.
The receipt now shows the updatedcontractAddress(line 33) along with other changes (e.g.transactionIndex). Please verify that these numbers align with your network deployment.
35-39: Updated Gas and Block Details.
ThegasUsed,logsBloom, andblockHashfields have been significantly revised. The lower gas usage (175367) should be confirmed to be expected after these changes.
58-61: Updated Constructor Arguments.
The arguments now include"0xf9f41910696DadF83a7B0b3e856a175D6aEEC8e8"and a new data payload. Ensure these values are correctly set for the intended initialization of the proxy contract.
63-64: Updated Compilation and Metadata Fields.
ThesolcInputHashand the embedded metadata have been updated to reflect the new compilation state (using Solidity 0.8.24+commit.e11b9ed9). This is in line with the overall upgrade; please check that any dependent tooling expects this change.contracts/deployments/arbitrumSepoliaDevnet/DisputeTemplateRegistry_Proxy.json (7)
2-2: Updated Contract AddressThe contract address has been updated to
"0x45f0662ec4aA4164b187c1bd39D35D0E3168787a". Please verify that this address is the correct deployment target for the devnet environment.
29-29: Updated Transaction HashThe transaction hash is now
"0x5beebc57cd875a210eeda1dc1056a22c5410bf6b6cb5232034c35b4813dacc4b". Confirm that downstream integrations and indexing services reflect this new transaction.
33-38: Receipt Metadata UpdateWithin the receipt, key fields have been updated:
"contractAddress"now matches the new address."transactionIndex"is updated to4."gasUsed"is reduced to"175413"."blockHash"is updated.Ensure these changes are intentional (e.g. reflecting optimized deployment parameters) and consistent across deployments.
41-50: Updated Log DetailsThe logs now show updated values:
"transactionIndex": 4"blockNumber": 141215321"logIndex": 11"blockHash"is updated accordingly.Please verify that these log details correctly capture the new transaction context.
53-54: Block and Cumulative Gas UpdateThe overall
"blockNumber"(141215321) and"cumulativeGasUsed"("449841") have been revised. Double-check that these metrics match expected network conditions for efficiency improvements.
59-59: Modified Deployment ArgumentsThe first argument now is
"0x0406ea6E28fAb9A23BF0d6f0f23f4352383A8592". Confirm that this parameter update aligns with the new governance or configuration model.
63-64: Metadata and Compiler Version UpdateBoth
"solcInputHash"and"metadata"now reflect the use of Solidity compiler version0.8.24+commit.e11b9ed9. Ensure that all deployed artifacts and downstream tooling are updated to work with this new compiler version.contracts/deployments/arbitrumSepoliaDevnet/DisputeKitClassic_Proxy.json (7)
2-2: Updated Contract AddressThe contract address is updated to
"0x2246821E1313A93e2F8CdF7a3422d078f560b457". Please confirm that this address is correct for the intended deployment environment.
29-29: Updated Transaction HashThe updated transaction hash is
"0xf5b19a72c51e016b4baa80e54c9e35ad9ff413f2a2f3a0d3460807ac2e1fef71". It is important to validate that all transaction references and logs have been synchronized with this new value.
33-38: Receipt Details RevisionIn the receipt, note that:
"contractAddress"now reflects the new address."transactionIndex"is now3."gasUsed"is"178371".- The
"logsBloom"and"blockHash"fields have been updated.Verify that these receipt changes accurately capture the new deployment’s execution and gas characteristics.
41-50: Log Section UpdateThe log details now show:
"transactionIndex": 3"blockNumber": 141215195"logIndex": 0"blockHash"updated accordingly.Ensure these changes are consistent with the overall deployment and facilitate correct event indexing.
53-54: Updated Block and Cumulative Gas MetricsThe deployment record now lists
"blockNumber": 141215195and"cumulativeGasUsed": "271619". Please verify that these values align with expected network performance improvements.
59-61: Deployment Arguments UpdatedThe first argument in
"args"is now"0xc51Ac08b07832Cf9b51Ff9E9dd3E85a3D205ff24"and the second argument has changed accordingly. Confirm that these parameter updates match the revised configuration for the system.
63-64: Compiler Input and Metadata UpdateThe
"solcInputHash"and"metadata"now indicate a compiler version upgrade to0.8.24+commit.e11b9ed9. Ensure that this is fully compatible with the current contract logic and tooling.contracts/deployments/arbitrumSepoliaDevnet/DisputeResolver.json (6)
2-2: Updated Contract AddressThe contract address is updated to
"0x524C5541f440204E0B4577334c439277018F971f". Please confirm that this change is reflected consistently in all related modules and deployment scripts.
296-304: Receipt and Transaction Details RevisionKey updates include:
"transactionHash"updated to"0x71a94b840ca3bf1901e76986788f114d9ed205b39f35c7867280ad8b68ecf63b".- In the
"receipt","contractAddress"now matches the new address,"transactionIndex"is4,"gasUsed"is"899678", and both"blockHash"and"blockNumber"(141215329) are updated.These modifications should be checked against the deployment logs to confirm that they are correct.
311-314: Updated Deployment ArgumentsThe
"args"array now contains:
- First argument:
"0x4838e31E0ea315232c431598110FE677cAF2D6E6"- Second argument:
"0x45f0662ec4aA4164b187c1bd39D35D0E3168787a"Verify that these arguments correctly represent the updated addresses required by subsequent contract logic.
316-317: Compiler Input and Metadata RevisionThe
"solcInputHash"and metadata have been updated to reflect solidity compiler version0.8.24+commit.e11b9ed9. This change should be verified for compatibility with all contract functionalities.
318-319: Bytecode and Deployed Bytecode UpdateThe
"bytecode"and"deployedBytecode"fields have been updated. Although these are autogenerated during compilation, it is important to ensure that the resulting bytecode corresponds to the expected contract logic.
397-436:❓ Verification inconclusive
Storage Layout Improvements
Several storage layout entries have updated
"astId"values and type definitions:
- Changes for storage variables such as
"governor","arbitrator","templateRegistry","disputes", and"arbitratorDisputeIDToLocalID"now include new identifiers.- Types for contracts (e.g.
"t_contract(IArbitratorV2)22692"and"t_contract(IDisputeTemplateRegistry)22863") and the array of dispute structures have been updated.These changes likely reflect modifications in the underlying contract schema (possibly due to the addition of new initializer functions like
initialize2andversion). Confirm that the new storage layout is fully backward compatible or that appropriate migration measures are in place.
🏁 Script executed:
#!/bin/bash # Search for references to 'initialize2' in the DisputeResolver contract source file echo "Searching for 'initialize2' occurrences in src/arbitration/arbitrables/DisputeResolver.sol:" rg "function initialize2" -n "src/arbitration/arbitrables/DisputeResolver.sol" # Search for references to 'version' in the DisputeResolver contract source file echo -e "\nSearching for 'version' occurrences in src/arbitration/arbitrables/DisputeResolver.sol:" rg "function version" -n "src/arbitration/arbitrables/DisputeResolver.sol"Length of output: 725
Attention: Verify Storage Layout Compatibility
The updated storage layout in
contracts/deployments/arbitrumSepoliaDevnet/DisputeResolver.jsonnow reflects new"astId"values and type definitions for storage variables (e.g.,"governor","arbitrator","templateRegistry","disputes", and"arbitratorDisputeIDToLocalID"), which appears to indicate modifications in the underlying contract schema—potentially involving changes like the addition of new initializers (initialize2andversion). However, our search did not locate the correspondingDisputeResolver.solfile at the expected path (src/arbitration/arbitrables/DisputeResolver.sol), making it difficult to directly verify these changes.Action Items:
- Confirm File Location: Verify that the correct contract file is present (and whether its path has changed) to ensure that the JSON deployment file references the intended implementation.
- Review Backward Compatibility: Ensure that any schema changes (reflected by updated astId values and type annotations) are fully backward compatible or have appropriate migration measures in place.
Please manually review the contract implementation to validate these storage layout modifications.
contracts/deployments/arbitrumSepoliaDevnet/EvidenceModule_Implementation.json
Show resolved
Hide resolved
fix: court name
|
Code Climate has analyzed commit 2f2dbba and detected 19 issues on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
|
PR-Codex overview
This PR focuses on significant updates and improvements to the Kleros arbitration system, including contract upgrades, initialization functions, and adjustments to the subgraph configurations.
Detailed summary
initialize2andinitialize3functions to several contracts for governance.StakePanelcomponent to handle optional court names.package.jsonandyarn.lockfor various libraries.Summary by CodeRabbit
New Features
Chores