Update Low-TVL cToken Implementations
01Summary
This proposal upgrades the cToken implementation for 5 low-TVL assets to Solidity 0.8.10, removing SafeMath library calls in favor of native checked math and replacing custom error codes with reverts and custom errors. No core logic changes are intended, and the upgrade has been audited by ChainSecurity and OpenZeppelin.
- Type
- contract upgrade
Key changes
- Upgrade Solidity version from prior version to 0.8.10(medium)
- Remove SafeMath and CarefulMath library dependencies, leveraging Solidity 0.8's native checked arithmetic(medium)
- Replace custom error code return values with reverts and custom errors for improved error handling(medium)
- All existing unit and scenario tests expected to pass with changes only in error code cases(low)
Notable concerns
- Changes affect error handling behavior in failure cases, requiring careful testing of edge cases
- This is a patch for low-TVL cTokens with future upgrades planned for other cTokens pending successful execution
Generated by Kvorum
02Description
Update Low-TVL cToken Implementations
Summary
This proposal is a patch developed by Equilibria which updates the cToken implementation contract for 5 low TVL assets to a more recent Solidity version (0.8.10) and removes error codes in favor of reverts with custom errors. No other core logic changes are intended. The new implementation has been deployed to 0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376.
Changelog
These changes implement the following:
- Upgrade the Solidity version of the cToken and related contracts to 0.8.10 - all contracts in the repo were changed to 0.8.10 but only the cTokens will be upgraded as part of upcoming governance proposals. This is due to the complexity of having multiple Solidity versions in the same repo.
- Remove the usage of SafeMath and CarefulMath in favor of Solidity 0.8’s checked math - Solidity will now automatically revert when math errors occur (overflows, division by zero, etc)
- Remove the custom errorCode return values in favor of reverts and custom errors - this allows for a more structured way to deal with errors rather than enum or string comparisons.
It is important to note that the goal is to have no behavior changes in the happy path case, and to only move away from errorCodes and to revert in the failure case (both math errors and checks). All existing unit and scenario tests should pass with only changes to the error code cases.
More cTokens will be upgraded in a future proposal if this one passes and causes no issues.
Development
The code changes can be viewed here: Pull Request #152.
Audits of these changes were completed by ChainSecurity and OpenZeppelin and all issues were either fixed or out of scope for this change. For further discussion, please view the Community Forum thread.
03Mismatch analysis
The proposal describes upgrading the implementation of 5 low-TVL cToken contracts to a single new implementation deployed at 0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376. The decoded calldata contains exactly 5 actions, each calling _setImplementation(address,bool,bytes) on a distinct cToken proxy address, all pointing to that exact same implementation address (0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376), with allowResign=true and empty init data — a standard, non-suspicious pattern for this type of upgrade. The count (5) matches the description's claim of '5 low TVL assets', and the implementation address matches precisely (case differences are irrelevant since Ethereum addresses are case-insensitive). No additional transfers, role grants, or other side effects are present in the calldata beyond the implementation swaps, consistent with the description's claim of 'no other core logic changes'. I cannot independently verify that the 5 target addresses correspond to the specific named low-TVL assets Equilibria intends (the description doesn't list them individually), but this is a reasonable summarization gap rather than a discrepancy — the number and nature of actions line up. Overall the description accurately and completely represents the on-chain actions.
Generated by Kvorum
04Actions
- Target
- 0x0411…925d
- Value
- 0 wei
- Function
- _setImplementation(address,bool,bytes)
- Arguments
{ "0": "0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376", "1": true, "2": "0x" }- Calldata
- Target
- 0x4b01…c9d7
- Value
- 0 wei
- Function
- _setImplementation(address,bool,bytes)
- Arguments
{ "0": "0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376", "1": true, "2": "0x" }- Calldata
- Target
- 0x80a2…3946
- Value
- 0 wei
- Function
- _setImplementation(address,bool,bytes)
- Arguments
{ "0": "0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376", "1": true, "2": "0x" }- Calldata
- Target
- 0xe65c…d06c
- Value
- 0 wei
- Function
- _setImplementation(address,bool,bytes)
- Arguments
{ "0": "0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376", "1": true, "2": "0x" }- Calldata
- Target
- 0x7713…3f67
- Value
- 0 wei
- Function
- _setImplementation(address,bool,bytes)
- Arguments
{ "0": "0x3363BAe2Fc44dA742Df13CD3ee94b6bB868ea376", "1": true, "2": "0x" }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| EA0xea6c…3bf7 | For | 306K | 53.12% | — | 5y ago |
| A60xa6e8…eef6 | For | 75K | 13.02% | — | 5y ago |
| 8D0x8d07…a265 | For | 70K | 12.15% | — | 5y ago |
| 7A0x7ae1…e585 | For | 50K | 8.68% | — | 5y ago |
| 070x0703…961b | For | 50K | 8.68% | — | 5y ago |
| 2B0x2b38…bf33 | For | 20.1K | 3.49% | — | 5y ago |
| DAdakeshi.eth0xe3c9…6b21 | For | 5K | 0.87% | — | 5y ago |
| 840x84e3…5a95 | For | 11.5 | 0.00% | — | 5y ago |
| 450x4504…3424 | For | 4.2 | 0.00% | — | 5y ago |
| BA0xba8a…c1c5 | For | 0.1 | 0.00% | — | 5y ago |
| AC0xacad…e428 | For | 0.1 | 0.00% | — | 5y ago |
| 570x5767…feae | For | 0.1 | 0.00% | — | 5y ago |
| 7A0x7a67…8c0e | For | 0 | 0.00% | — | 5y ago |
| FB0xfb55…1600 | For | 0 | 0.00% | — | 5y ago |
| B80xb80a…dc0c | For | 0 | 0.00% | — | 5y ago |
07Forum
No forum thread is confidently linked to this proposal.