Store client information on IPFS using revised Scrambled Memory Layout method, as documented in Client Security
Store 1wallet address on Google Authenticator entry
Wallet creation factory via smart contract
Produce predictable, deterministic 1wallet address, given its seed and version
New wallet creation flow and UI updates
Yubikey support as an option to provide hardware based security and recovery mechanism
Enable users to gradually adjust spending limits when composable security is enabled, such as when two OTPs are used or when recovery address is set.
UI components and frontend infrastructure
Implementations to support various settings
When double OTP is used
When recovery address is used
When Yubikey is used
When more than one of the above is used
When none is used
Detailed analysis of the choice of hash functions used in Client Security
Substantially improve 1wallet loading speed by reducing client bundle size
Produce global usage statistics using Dune analytics (including total asset, number of wallets, and others)
Staking ONE via 1wallet (without using pools)
Pay transaction costs (gas) using 1wallet instead of using relayer (via Account Abstraction)
Perform mutable transactions directly from client instead of using relayer (depending on Account Abstraction)
Support WalletConnect in browser (Explained in detail here under Section VI)
Session management and encryption per WalletConnect spec
UI implementation, QR code, and connection URI support
Main wiki and protocol specification update
Algorithms in Client security
Double OTP
Controlled Randomness
(Revised) Scrambled Memory Layout
Alternatives considered
Hash functions for client security
Benchmark
Analysis of security strengths in practice
Alternatives considered
Yubikey or other generic, tamper-proof private-key based signing device.
The user experience considerations and flow design in Part II
The smart contract and protocol updates in Part IV
Incorporating feedback from @ivan-homoliak-sutd (June 2021) for main wiki
