coderabbitai[bot]
commented
2 months ago Walkthrough
The changes involve significant modifications across multiple contracts, focusing on stricter compilation rules, token supply management, nonce tracking, and enhanced error handling. The foundry.toml file now mandates that compilation fails if warnings are present. The DeployExocoreGatewayOnly contract has been updated to include the exocoreProxyAdmin address in its serialization process. The SetupScript contract has shifted to directly referencing token supplies instead of TVL limits, and new mappings for nonces have been introduced in the ExocoreDeployer contract. Additionally, error handling has been improved across various contracts.
Changes
| Files | Change Summary |
|---|---|
foundry.toml |
Added deny_warnings = true to enforce stricter compilation rules, ensuring compilation fails if warnings are present. |
script/10_DeployExocoreGatewayOnly.s.sol |
Updated serialization to include exocoreProxyAdmin address in the DeployExocoreGatewayOnly contract. |
script/3_Setup.s.sol |
Modified token supply handling by replacing TVL limits with total supply metrics and adjusting the logic for populating the tvlLimits array. |
test/foundry/ExocoreDeployer.t.sol |
Introduced new mappings for outboundNonces and inboundNonces, and updated logic for managing whitelisted tokens and TVL limits based on token supply. |
script/deployedExocoreGatewayOnly.json |
Added exocoreProxyAdmin field to the JSON configuration with the corresponding address. |
src/core/Bootstrap.sol |
Enhanced token whitelisting by adding TVL limits as parameters in the initialize and addWhitelistTokens functions, along with new error checks for array lengths. |
src/core/ClientGatewayLzReceiver.sol |
Updated payload decoding to include tvlLimit and adjusted logic for managing token limits in requests. |
src/core/ExocoreGateway.sol |
Reordered parameters in addWhitelistToken and removed tvlLimit from updateWhitelistToken, allowing zero values for inactive tokens. |
src/interfaces/IExocoreGateway.sol |
Updated addWhitelistToken and updateWhitelistToken function signatures to reflect changes in parameter handling. |
src/libraries/Errors.sol |
Introduced new error types for improved error handling related to token management and removed outdated error types. |
src/storage/BootstrapStorage.sol |
Added tvlLimit parameter to _deployVault function for vault initialization and a new function to count whitelisted tokens. |
src/storage/ClientChainGatewayStorage.sol |
Introduced a constant for the length of add whitelist token requests and removed the previous constant for token address length. |
src/storage/ExocoreGatewayStorage.sol |
Added constants defining lengths for associate and dissociate operator requests. |
src/storage/GatewayStorage.sol |
Introduced MessageExecuted event and InvalidRequestLength error for better message processing and error handling. |
test/foundry/unit/ClientChainGateway.t.sol |
Modified message construction for adding tokens to whitelist, incorporating dynamic values based on token state. |
test/foundry/unit/ExocoreGateway.t.sol |
Updated function signatures and error messages to align with new token management logic, reflecting changes in handling total supply. |
test/mocks/AssetsMock.sol |
Removed tvlLimit from registerToken and updateToken functions for streamlined usage. |
test/mocks/ExocoreGatewayMock.sol |
Adjusted constructor and updateWhitelistToken function to allow zero tvlLimit for inactive tokens, reflecting a shift in validation logic. |
Possibly related PRs
- #23: Involves registering whitelist tokens to Exocore, which relates to token management.
- #39: Refactors
addWhitelistTokensto require more token information, aligning with improvements in token handling. - #54: Introduces a centralized
_handleResponsefunction, enhancing response handling relevant to token management. - #61: Adds functions for associating and dissociating operators, relevant to governance and management practices.
- #66: Establishes precompiles as the single source of truth for registered items, enhancing code quality.
- #86: Adds
oracleInfoto token registration, improving token management functionality. - #90: Ensures
markBootstrappedfunction does not fail, improving code quality. - #92: Addresses centralization risks with multisig wallets and a timelock contract, enhancing governance.
🐰 In a garden lush and bright,
I hop and dance with pure delight.
New limits set for tokens fair,
A world of numbers, fresh and rare.
With every hop, I celebrate,
For changes made, oh, how great! 🥕
Recent review details
**Configuration used: CodeRabbit UI** **Review profile: CHILL**Commits
Files that changed from the base of the PR and between 83e96a5e1bea2f334207b68be3f6ef58780ab7af and a3b5c7ca1b4b5ff1248f6057187ee2ccae9fe334.Files selected for processing (15)
* script/3_Setup.s.sol (2 hunks) * src/core/Bootstrap.sol (7 hunks) * src/core/ClientGatewayLzReceiver.sol (3 hunks) * src/core/ExocoreGateway.sol (3 hunks) * src/interfaces/IExocoreGateway.sol (1 hunks) * src/libraries/Errors.sol (3 hunks) * src/storage/BootstrapStorage.sol (3 hunks) * src/storage/ClientChainGatewayStorage.sol (1 hunks) * src/storage/ExocoreGatewayStorage.sol (2 hunks) * src/storage/GatewayStorage.sol (3 hunks) * test/foundry/ExocoreDeployer.t.sol (7 hunks) * test/foundry/unit/ClientChainGateway.t.sol (1 hunks) * test/foundry/unit/ExocoreGateway.t.sol (6 hunks) * test/mocks/AssetsMock.sol (1 hunks) * test/mocks/ExocoreGatewayMock.sol (4 hunks)Files skipped from review due to trivial changes (3)
* src/storage/ExocoreGatewayStorage.sol * test/foundry/ExocoreDeployer.t.sol * test/mocks/AssetsMock.solFiles skipped from review as they are similar to previous changes (5)
* src/core/Bootstrap.sol * src/core/ClientGatewayLzReceiver.sol * src/libraries/Errors.sol * src/storage/ClientChainGatewayStorage.sol * test/foundry/unit/ClientChainGateway.t.solAdditional comments not posted (17)
src/interfaces/IExocoreGateway.sol (2)
`51-51`: **LGTM, but update the documentation and the client code.** The changes to the `addWhitelistToken` function are approved: - Moving the `tvlLimit` parameter to the end of the parameter list improves the readability and maintainability of the code. - Updating the `tvlLimit` parameter description improves the clarity of the code. - Changing the `tvlLimit` parameter type from `uint256` to `uint128` is justified by the comment that explains that it can fit 1 trillion tokens with 18 decimals, which is sufficient for most use cases. It also improves the compatibility with Solana. However, please make sure to update the documentation and the client code to reflect these changes, as they are breaking changes. Also applies to: 54-55, 62-63 --- `68-68`: **LGTM, but update the documentation and the client code.** The changes to the `updateWhitelistToken` function are approved: - Removing the `tvlLimit` parameter simplifies the function's signature and emphasizes the necessity of the token's existence in the whitelist before any updates can be made. - The function's documentation has been updated to reflect these changes, enhancing clarity regarding the roles of the parameters. However, please make sure to update the documentation and the client code to reflect these changes, as they are breaking changes. Also applies to: 71-71src/storage/GatewayStorage.sol (3)
`43-46`: **LGTM!** The newly added `MessageExecuted` event provides useful visibility into message processing and execution. The event parameters `act` and `nonce` are appropriate for tracking and debugging purposes. --- `61-65`: **LGTM!** The newly added `InvalidRequestLength` error enhances error management by providing the expected and actual lengths of requests. This helps in identifying and fixing issues related to invalid request lengths. --- `106-114`: **LGTM!** The newly added `_validatePayloadLength` function is a useful addition that allows the contract to enforce stricter checks on incoming data. It correctly validates the payload length against the expected length and reverts with the `InvalidRequestLength` error if there is a mismatch. This helps in ensuring data integrity and preventing unexpected behavior.script/3_Setup.s.sol (3)
`100-100`: **LGTM!** The type change from `uint256` to `uint128` for the `tvlLimits` array is approved. It reduces storage size while still allowing sufficiently large values for token value limits. --- `108-108`: **LGTM!** Setting the first element of `tvlLimits` to `restakeToken.totalSupply() / 5` is approved. This aligns with the phased approach and ensures the limit stays proportional to the token's total supply. --- `116-116`: **LGTM!** Setting the second element of `tvlLimits` to 0 for native restaking is approved. This effectively removes any limit on native restaking, aligning with the intended behavior.test/mocks/ExocoreGatewayMock.sol (2)
`175-187`: **LGTM!** The changes to the constructor function are approved: - The change in the parameter order for `tvlLimit` does not affect the functionality. - Allowing a zero value for `tvlLimit` for inactive tokens is a valid change. - The comment regarding the allowance of a TVL limit of zero for inactive tokens provides clarity. --- `207-216`: **LGTM!** The changes to the `updateWhitelistToken` function are approved: - The removal of the `tvlLimit` parameter is consistent with the shift from a TVL-centric approach to one that prioritizes total supply. - The requirement that `metaData` must not be empty reinforces the new logic.src/storage/BootstrapStorage.sol (2)
Line range hint `355-373`: **LGTM!** The changes to the `_deployVault` function are approved. The addition of the `tvlLimit` parameter and its usage in vault initialization enhances the functionality by allowing a TVL limit to be set for each vault during deployment. --- `378-380`: **LGTM!** The addition of the `_getWhitelistedTokensCount` function is approved. Although the function seems redundant, as mentioned in the comments, it provides a shared implementation for getting the count of whitelisted tokens, which can be used by both the Bootstrap and ClientChainGateway contracts.src/core/ExocoreGateway.sol (2)
`207-207`: **Breaking change: TVL limit can no longer be updated. Update all callers.** The `tvlLimit` parameter has been removed from the function signature and the internal logic, which is a breaking change. Ensure all callers of this function are updated to match the new signature. The TVL limit can no longer be updated through this function. It must be updated separately on the client chain. To verify that all callers have been updated, run: Also applies to: 215-216Verification successful
--- **Verification successful: Callers of `updateWhitelistToken` have been updated.** The `tvlLimit` parameter has been removed from the function signature, and all callers in the codebase have been updated to match this change. The function is now called with the updated signature, confirming that the breaking change has been addressed.--- `177-178`: **Breaking change: Update all callers. Consider including `tvlLimit` in `registerToken`.** The function signature has been updated to move the `tvlLimit` parameter to the end, which is a breaking change. Ensure all callers of this function are updated to match the new signature. Setting a `tvlLimit` of zero is now permitted to add an inactive token that can be activated later by updating the TVL limit on the client chain. Consider including the `tvlLimit` in the call to `ASSETS_CONTRACT.registerToken` for consistency, instead of passing it separately in the interchain message. To verify that all callers have been updated, run: Also applies to: 185-186, 199-199Scripts executed
The following scripts were executed for the analysis: Script: ```shell #!/bin/bash # Description: Verify all callers of `updateWhitelistToken` have been updated to match the new function signature. # Test: Search for calls to the function. Expect: Only occurrences of the new signature without `tvlLimit`. rg --type solidity -A 5 $'ExocoreGateway\(.*\)\.updateWhitelistToken\(' ``` Length of output: 105 --- Script: ```shell #!/bin/bash # Find all Solidity files and search for calls to `updateWhitelistToken`. fd --extension sol --exec rg 'updateWhitelistToken\(' ``` Length of output: 872test/foundry/unit/ExocoreGateway.t.sol (3)
`529-529`: **LGTM!** The update to the `MESSAGE_LENGTH` constant to include an additional `uint128` parameter for the total supply limit is correct and aligns with the changes made to the `addWhitelistToken` function. --- `545-545`: **LGTM!** The addition of the `uint256` parameter initialized to `0` in the `addWhitelistToken` function calls across various test cases is correct. This parameter likely represents the total supply limit for the token. Also applies to: 554-554, 562-562, 570-570, 578-578, 586-587 --- `613-613`: **LGTM!** The changes in the `UpdateWhitelistTokens` contract, including the update to the `MESSAGE_LENGTH` constant, the addition of the `uint256` parameter in the `addWhitelistToken` function calls, and the removal of the `tvlLimit` field from the `TokenDetails` struct, are consistent with the modifications made in the `AddWhitelistTokens` contract and align with the terminology change to use total supply instead. Also applies to: 618-618, 626-627, 642-642, 649-649, 655-655, 661-661, 668-668
MaxMustermann2
feat(tvl-limit): impose tvl limit on client chain
The TVL limit is imposed on the client chain, which also imposes the fact that nobody can deposit more than the total supply of the tokens.
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests