memoscan

0x3aa0…29e6

All memos sent from and to 0x3aa0…29e6.
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#24,718,463·0x5eb79587…09eded
# ERC20 Emergency Upgrade: Add Fund Recovery to ERC20 Bridge This proposal upgrades one of the ERC20 bridge contracts to include emergency fund recovery features following the shutdown of the Kroma L2 chain (the other ERC20 bridge upgrade is failing in simulation and will be handled separately). New Implementation Addresses (1) [https://etherscan.io/address/0xDc021260744c6A8c0a86D0374042916ace040fAd](https://etherscan.io/address/0xDc021260744c6A8c0a86D0374042916ace040fAd) Key Features Added 1\. \*\*Emergency Shutdown Mode\*\*: Allows authorized parties to activate emergency state 2\. \*\*Direct Emergency Withdrawal\*\*: Bypasses L2 validation for fund recovery Authorization and Withdrawal Model \- TallyDAO approves the implementation upgrade \- Emergency Multisig (same wallet that controls ChainAdmin for ZKcandy Mainnet) will handle the steps of activating Emergency Shutdown and then executing the EmergencyWithdrawal function, sending all ETH to the Emergency Multisig \- Funds will be transferred into a Snapshot-based Withdrawal Smart Contract on Ethereum and a UI for that will be available for users to claim from Execution Plan 1\. \*\*Upgrade\*\*: Upgrade proxy implementation via vote 2\. \*\*Activation\*\*: Multisig activates emergency shutdown 3\. \*\*Recovery\*\*: Execute emergency withdrawal to multisig 4\. \*\*Distribution\*\*: Implement snapshot-based withdrawal system on Ethereum
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#23,325,986·0xb6d40621…d120cd
# Reduce Quorum to 2 signers **This proposal reduces the necessary quorum to 2 signers.**  **Rationale:** (1) We have been informed that one of the current signers is leaving and most others probably don't want to need to sign anything going forward.  (2) Likely there won't be any more proposals needed anyway, but in case something is needed in the future, this proposal reduces the necessary quorum to 2 signers. 
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#23,323,986·0x0c65f879…9a7edf
# ERC20 Emergency Upgrade: Add Fund Recovery to ERC20 Bridge ## Summary This proposal upgrades one of the ERC20 bridge contracts to include emergency fund recovery features following the shutdown of the Kroma L2 chain (the other ERC20 bridge upgrade is failing in simulation and will be handled separately). ## New Implementation Addresses (1) [https://etherscan.io/address/0x6abf2c41e4606bb2b4237ee5794d272c21593f4a](https://etherscan.io/address/0x6abf2c41e4606bb2b4237ee5794d272c21593f4a) ## Key Features Added 1\. \*\*Emergency Shutdown Mode\*\*: Allows authorized parties to activate emergency state 2\. \*\*Direct Emergency Withdrawal\*\*: Bypasses L2 validation for fund recovery ## Authorization and Withdrawal Model \- TallyDAO approves the implementation upgrade \- Emergency Multisig (same wallet that controls ChainAdmin for ZKcandy Mainnet) will handle the steps of activating Emergency Shutdown and then executing the EmergencyWithdrawal function, sending all ETH to the Emergency Multisig \- Funds will be transferred into a Snapshot-based Withdrawal Smart Contract on Ethereum and a UI for that will be available for users to claim from ## Execution Plan 1\. \*\*Upgrade\*\*: Upgrade proxy implementation via vote 2\. \*\*Activation\*\*: Multisig activates emergency shutdown 3\. \*\*Recovery\*\*: Execute emergency withdrawal to multisig 4\. \*\*Distribution\*\*: Implement snapshot-based withdrawal system on Ethereum
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#23,000,291·0x51dede5f…14ad28
# Emergency Upgrade: Add Fund Recovery to KromaPortal ## Summary   This proposal upgrades the KromaPortal contract to include emergency fund recovery features following the shutdown of the Kroma L2 chain.      ## New Implementation Address  [https://etherscan.io/address/0x929937A7A065B35F983147349cC312920660c691](https://etherscan.io/address/0x929937A7A065B35F983147349cC312920660c691)      ## Key Features Added   1\. \*\*Emergency Shutdown Mode\*\*: Allows authorized parties to activate emergency state   2\. \*\*Direct Emergency Withdrawal\*\*: Bypasses L2 validation for fund recovery      ## Authorization and Withdrawal Model   \- TallyDAO approves the implementation upgrade   \- Emergency Multisig (same wallet that controls ChainAdmin for ZKcandy Mainnet) will handle the steps of activating Emergency Shutdown and then executing the EmergencyWithdrawal function, sending all ETH to the Emergency Multisig \- Funds will be bridged to ZKcandy and transferred into a Snapshot-based Withdrawal Smart Contract and a UI for that will be available for users to claim from     ## Execution Plan   1\. \*\*Upgrade\*\*: Upgrade proxy implementation via vote 2\. \*\*Activation\*\*: Multisig activates emergency shutdown   3\. \*\*Recovery\*\*: Execute emergency withdrawal to multisig   4\. \*\*Distribution\*\*: Implement snapshot-based withdrawal system on ZKcandy Mainnet         ## Community Benefit   This upgrade is essential for protecting user funds following the L2 chain shutdown, providing a secure and transparent path to fund recovery.  
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#22,114,585·0x4d0e6c52…21237a
# Replacement of Security Council EOA for Wemix Foundation In the previous proposal, the **EOA address of Wemix Foundation** was changed. However, at the request of Wemix Foundation, it is now being **replaced with another address**. See the previous proposal: [https://www.tally.xyz/gov/kroma-security-council-l1/proposal/111958584110631001628230229008816068426656704641631938464874456535496323166842](https://www.tally.xyz/gov/kroma-security-council-l1/proposal/111958584110631001628230229008816068426656704641631938464874456535496323166842) Address Changes: `0xECe4AAf6A41aa81A164363Ec6C420510617Fc998` -> `0x70cd6f41651123edbaf78cab205d36d2d3bbaef8` -> `0xD417Ff17bf3cFD7260a4De20C6864090aA0503cC`
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#22,064,935·0x65a0253d…fec452
# Replacement of Security Council EOA for Wemix Foundation This proposal involves updating the externally owned address (EOA) associated with Wemix Foundation to ensure enhanced security and seamless operations.
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#21,778,782·0x77d136c1…cd55aa
# Kroma's Migration to MPT and zkVM This proposal upgrades Kroma’s protocol to use MPT for its state management and zkVM for its proof system. Changes: * zkEVM to zkVM proving in challenge * Submission & challenge restriction for the first output after MPT transition * Modify proveWithdrawal to use MPT instead of ZKTrie post-MPT transition
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#21,112,082·0xa5bcbcaa…26e89f
# Update ValidatorRewardScalar to 0 and Update Node Guardians’ EOA This proposal seeks to set the ValidatorRewardScalar to 0 and update the Externally Owned Address (EOA) of Node Guardians. Following the recent upgrade to the Kroma Validator System V2, which transitioned rewards from ETH to KRO tokens, the ValidatorRewardScalar is now obsolete and will be set to 0. Additionally, this proposal will update the Node Guardians’ EOA to enhance security and support seamless operations.
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#21,063,017·0xae4102b8…2fd63a
# Adding New Member to the Kroma Security Council: Hexlant We propose integrating Hexlant into the Kroma Security Council by allowing its validator node to serve as a Guardian node. This strategic addition will adjust the Protocol Governance Quorum to require an 8 out of 10 consensus, up from the current 7 out of 9. 
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#21,011,448·0x736ab0c5…ccefb5
# Smart Contract Upgrade to Support KRO-based Validator System This proposal seeks to upgrade the existing Kroma validator system to a KRO-based validator system. This upgrade includes the deployment of new smart contracts that will introduce new staking mechanisms and validator reward structures. For more details about the new validator system, please refer to the[ specification](https://specs.kroma.network/protocol/validator-v2/overview.html). Upon the successful approval and execution of this proposal, the related contracts will be upgraded on the mainnet, and validators will be required to update their nodes to [Kroma’s v2.0.0](https://github.com/kroma-network/kroma/releases/tag/v2.0.0).
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#20,876,939·0x9158819d…2ac644
# Replacement of Security Council EOA for Xangle This proposal involves updating the externally owned address (EOA) associated with Xangle to ensure enhanced security and seamless operations.
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#20,210,087·0x14592887…c18fbe
# Security Council Membership Removal: B-Harvest This proposal seeks the removal of B-Harvest from the Kroma Security Council following their decision to exit. Upon approval, B-Harvest's SBT will be burned and B-Harvest will shut down its guardian node subsequently.
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#20,116,567·0x4342bcfe…9c10b5
# Smart Contract Upgrade to Support Ecotone Fee Calculation in ZKVerifier This upgrade proposal aims to upgrade the ZKVerifier Smart Contract to support the latest fee structure introduced by Ecotone. The recent changes in the Ecotone fee mechanism require updates to the ZKVerifier, which requires to modify the prover and verifier to support Ecotone's updated fee structure. Also, adjustments have been made in the L1 Cost part, and the specific cost changes can be reviewed here: <https://specs.optimism.io/protocol/exec-engine.html#ecotone-l1-cost-fee-changes-eip-4844-da>. You can find the contract to be upgraded here: <https://etherscan.io/address/0x4cd05ab629055a449617a28e3466660403ea7126>
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#19,708,884·0xca9e54f6…af6dcb
# [Rollback of Fee Scalar due to Upgrade Delay] 1. Rollback of Fee Scalars Due to an unexpected error in v1.4.1 causing a delay in the upgrade, we are rolling back the Fee Scalar accordingly. The previous Fee Scalar settings will be restored.
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#19,680,392·0xacaef413…c861aa
# [Smart Contract Upgrade and Fee Scalar Changes for v1.4.1] ### 1. Support for the Colosseum's Cancun block fault-proof system With the Ecotone upgrade, three fields are added to the block header, characteristic of the Cancun block: BlobGasUsed, ExcessBlobGas, and ParentBeaconRoot. Therefore, this upgrade to the Colosseum contract includes support for the Cancun block fault-proof system. ### 2. Change Fee Scalars for Ecotone Following the activation of the Ecotone upgrade, blob-carrying transactions are utilized to post batch data to L1. Consequently, adjustments have been made to the L1 fee structure, including the setting of the L1 fee scalar and L1 blob fee scalar. For more detailed information, please refer the specs. specs: <https://specs.optimism.io/protocol/exec-engine.html#ecotone-l1-cost-fee-changes-eip-4844-da>
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#19,566,665·0x80b28005…cfec5d
# [Smart Contract upgrades for v1.3.4] ### 1. Addition of withdrawTo in ValidatorPool Previously, validators could only withdraw funds to themselves. Now, with the withdrawTo function, they can withdraw directly to a specified address. Implementation contract address: `0x8EDc4cCa2aF96f5D5141d55333043a65c3f59Ec4` ### 2. Change in block header hash function for Colosseum With the Shanghai upgrade on the Kroma mainnet, a withdrawalsRoot field has been added to the block header. Accordingly, the hash function for obtaining the block header in Colosseum has been modified. Implemenatation contract address: `0x311b4A33b6dC4e080eE0d98caAaf8dF86C833066`
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#19,275,090·0x0cb77ec7…f53506
# Enhancing Kroma Security Council with New Member & Governance Efficiency ### 1. Inclusion of Animoca Brands into the Security Council We propose to integrate Animoca Brands into the Kroma Security Council by allowing their validator node to serve as a Guardian node. This strategic addition will not only bolster our council's capabilities but also adjust the Protocol Governance Quorum to require an 8 out of 10 consensus, up from the current 7 out of 9. This change reflects our commitment to a more robust and inclusive decision-making framework. ### 2. Optimizing Protocol Governance Through Timelock Adjustment Given that Kroma is currently in Stage 0 of its Layer 2 development, with no mandatory exit period for upgrades decided by the Security Council, we suggest removing the 7-day execution timelock delay. This change aims to make Kroma more nimble in addressing security vulnerabilities and integrating community insights, ensuring our platform remains dynamic and secure.
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#18,868,735·0x24402eb7…e93e43
# [Resubmission] Adjustment of Protocol Governance Quorum ## **\[Update Contract Parameter on Ethereum(L1)]** **1. Amendment of Protocol Governance Quorum** Recently, L2beat announced that the security council's quorum requirement for stage 1 is now set at a minimum of 75%. In accordance with this, we propose adjusting Kroma's quorum from its current setting of 51% to a value exceeding 75%. This adjustment will significantly increase the difficulty of pushing protocol upgrades or overriding checkpoint outputs, contributing to a more robust proof system for Kroma. ref: [**https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52**](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52)
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#18,776,142·0x2153c03c…9103be
# Adjustment of Protocol Governance Quorum ## **\[Update Contract Parameter on Ethereum(L1)]** **1. Amendment of Protocol Governance Quorum** Recently, L2beat announced that the security council's quorum requirement for stage 1 is now set at a minimum of 75%. In accordance with this, we propose adjusting Kroma's quorum from its current setting of 51% to a value exceeding 75%. This adjustment will significantly increase the difficulty of pushing protocol upgrades or overriding checkpoint outputs, contributing to a more robust proof system for Kroma. ref: [**https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52**](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52)
0x3aa00bb9…29e6sent to0xb3c415c2…a537·#18,383,330·0x9473ad55…ba30e4
# Kroma L1 Smart Contract Upgrades ## [Smart Contract Upgrades on Ethereum(L1)] ### 1. Timelock Period Decrease: - Currently, the timelock period for Kroma's L1 smart contract upgrade is set at 30 days. - We initially aimed for Stage 2 with the mainnet launch but have decided to prioritize Stage 1. - Therefore, we are decreasing the timelock period from 30 days to 7 days for Stage 1, enabling faster upgrades and improvements. ### 2. Removal of Emergency Upgrade Contract: - In the event of a critical issue requiring immediate action, we had implemented an emergency upgrade contract. - With the timelock period reduced to 7 days, this emergency method is no longer necessary. - Consequently, we are removing the emergency upgrade contract for a more streamlined process. ### 3. Validator Reward Scalar Adjustment: - Initially, we set the Validator Reward Scalar to 1 to provide validators with the entire L2 fee. - However, recent data shows that L2 fees account for over 80% of the total fee, contrary to our initial findings. - To better distribute rewards, we are decreasing the Validator Reward Scalar to 0.5, with the remaining half directed to the ProtocolVault. ### 4. Next Validator Selection Logic Enhancement: - We've made enhancements to our validator selection logic. For detailed information, please refer to the following GitHub PRs: [PR #206](https://github.com/kroma-network/kroma/pull/206) and [PR #209](https://github.com/kroma-network/kroma/pull/209). ### 5. Change in Multisig Wallet Management: - Currently, the Security Council's multisig wallet is managed through a whitelist. - We are transitioning to a more secure approach based on Soul Bound Tokens (SBTs) for wallet management.