List view
## Breaking changes - A very important change of behavior is that once a wallet is locked, it should be as secure as possible within 7 days unless the majority of its guardians collude. (currently, the lock will be automatically removed after 1 day) - We remove the `onlyHaveEnoughGuardians` modifier; make sure `requireMajority` checks the number of active guardians is > 0 - The first two guardians still don't have to wait a pending period - If a function `doSomething` has a version that supports multi-sig authorization, I name it `doSomethingWA` where *WA* means *WithApproval*. I also make sure these two functions are next to each other. If a function only supports multisig, *WA* will be dropped from the function name - Add default impl for `bindableMethods` in BaseModule - Allow owner to lock his own wallet (regardless of the current lock status) - Disable automatic unlock after 1 day. Do not track who locked the wallet. - Lock and unlock does not check the previous status and will always succeed. - Change the max number of guardians from 20 to 10, change guardian waiting period from 1 day to 7 days - Disable unlock by one single guardian and only allow unlock with a majority (owner signature required) - Event `WalletLock` now includes which guardian locked a wallet and which module unlocked a wallet. - Allow wallet owner to specify the inheritance waiting period (2 months to 10 years) - Remove `cancelGuardianAddition` and `cancelGuardianRemoval`. These will be part of the `removeGuardian` and `addGuardian` behavior - Rename event 'WalletLock' to 'WalletLocked' - Add `lockWA` that doesn't use a nonce - Daily quota is by default disabled and can be set to non-zero to enable quota checking/update. - Last touch timestamp will not be checked/updated if no inheritor is set.
Due by November 5, 2020•2/2 issues closedIncluding finalized AMM contract and fixes for all known issues. This version will be used for the first 3.6 production launch.
Due by October 30, 2020•7/7 issues closedThis will be our next major version to deploy on Ethereum mainnet to replace Loopring 3.1.
Due by September 15, 2020•46/46 issues closedA very minor change: we do not burn LRC directly in Loopring. The burn will only happen in FeeVault.
Due by January 1, 2020•2/2 issues closed- Due by December 31, 2019•11/11 issues closed
Previously known as Loopring 4.0
Due by December 30, 2020•11/11 issues closedThis release will include the following: all known bug fixes; all improvements based on security auditing feedback and GitCoin bug bounty program; LRC burning using UniSwap; more unit tests for UniversalRegistry, ProtocolFeeVault, ProtocolRegistry, and UserStakingPool.
Due by November 30, 2019•16/16 issues closed- Due by December 30, 2019•1/1 issues closed
This release will include the following: 1) all improvements based on security auditing feedback, if not included in Loopring_3.0beta4 (Brecht); 2) a design to support Exchange Modules. 3) more unit tests for UniversalRegistry, ProtocolFeeVault, ProtocolRegistry, and UserStakingPool (Steve) Most work shall be started as of now without waiting for the security audit report. DAO is still not a priority.
Due by November 1, 2019•6/6 issues closedThis release will include various performance optimizations including a new Merkle tree hashing algorithm, a new quadtree, and support for transparent proxy-based upgradability. This release will be the baseline for third party security auditing
Due by August 15, 2019•29/29 issues closedThis release will include a new fee model, many bug fixes, and some performance optimizations.
Due by June 30, 2019•17/17 issues closed- Due by April 15, 2019•6/6 issues closed