Full Security & Recovery for 1Wallet Updates

Full Security & Recovery for 1Wallet Updates

Next Date
November 30, 2021
Aaron LiYuriy MGiv Parvaneh
Live on Mainnet
Release Date

Current Progress

  • Working on a large upgrade (v15)
    • New security mechanisms
      • Spend limit adjustment
      • Restore wallet without scanning QR code seed (need exported file)
        • Exported file can be backed up on cloud
      • Wallet address is now predictable
      • Wallet contract integrity can now be verified
      • Wallet address will be stored on Authenticator
    • Apple built-in authenticator will be supported (auto fill-in code)
    • Auto sync wallet across devices
    • Integration with Simplex fiat gateway is on the way
      • Apple Pay will come for free
  • ETA
    • New security mechanisms: Dec 3
    • Apple built-in authenticator: Dec 6
    • Sync across devices: Dec 10
    • Sync exported file on cloud: Dec 10

What's next

Dec 1

We plan to make 1wallet address unchanged when the user's wallet is upgraded. We saw many complaints regarding issues and complications in upgrades. They could be avoided if upgrade simply does not give the user a new address and migrate their assets.

We initially designed this upgrade mechanism to strengthen wallet security, as we noted that the common proxy-based upgrade implementations used by other wallet may not be secure enough: attackers who temporarily gain control on the client side may "upgrade" the wallet to an implementation under their control, thereby circumventing all security measures in the wallet's smart contract. The core weakness of the proxy-based implementation is that wallet's code is no longer immutable, and it poses too much risk if the user is allowed to instantly change the code (by pointing it to another contract address, as per standard in proxy-based implementations).

Under the principle that the user should be given the minimal permission possible over the contract to complete the intended operation, our initial upgrade mechanism disallows any mutation to the code. Instead, upgrades are achieved by securely deploying a new contract, securely migrating all assets over, and make the old address forward assets to the new address automatically. Inevitably, this process creates a new address (for the new contract, which hosts new version of the code). The user's old wallet address remains usable for all purposes as it shares requires exactly the same authentication used by the new wallet address, and assets are automatically transferred to new address whenever the old wallet address receives something.

Although the above mechanism is sound in theory, in practice the migration process is imperfect. Many users complained about "loss of funds", where in fact the assets are left over in the old wallet instead of being migrated. Mechanisms are implemented to manually reclaim these assets, but the user experience is apparently suboptimal.

Moreover, the old wallet cannot automatically transfer ERC-20 tokens if it receives some of those after the upgrade. Moreover, some non-standard NFTs fail to implement functions that notify the receiver, causing the NFT to be stuck in the old wallet address instead of being forwarded to the new address.

Another issue is we designed this mechanism with an understanding that the use of domain names should rapidly take over the use of standard addresses. The 20-byte long address is comparable to IP addresses in the traditional Internet. IP addresses are dynamically and infrequently reassigned, but domain names and personal identities (e.g. Google Login) are not. However, the reality is that the crypto infrastructure is far from ready to do away with the concept of address. Users are still expected to provide their hexadecimal or one1... addresses in almost every app, and it is often impossible to change that address in those apps, once the address is linked and established with the app.

Accordingly, it is apparent that the change-of-address issues substantially affect the users' trust and experience. To make 1wallet a wallet for everyone, we must fix this. To do that, we will combine the best parts of both the existing upgrade implementation and the proxy-based pattern:

  • 1wallets without user-set recovery address will require 6-consecutive authenticator codes to initiate and approve the upgrade (implemented in Nov 24 milestone)
  • 1wallets with user-set recovery address can initiate the upgrade with only a single authenticator code, but they must send 0.1 ONE from their recovery address to approve the upgrade.
  • The wallet implementation will employ a proxy-based pattern, such that the logical code is pointing to another contract its address may change for each upgrade. However, until an upgrade is approved, no change would take effect.

Nov 24

We will focus on two things:

  • Using iOS built-in authenticator (and auto-completion) for wallet setup and operations
    • Since the built-in authenticator does not expose seed, this implies we will add a new mechanism for restoring wallet.
    • We tentatively decide to use consecutive authenticator codes to achieve this purpose. After the user correctly provides six successive authenticator codes, we will let the user set up a new authenticator code (via either iOS built-in authenticator or Google Authenticator)
  • Make 1wallet address "pre-computable" (predictable, deterministic), so that the address is stored internal to authenticator. The users do not need to remember their 1wallet address when they restore their wallet. The onboarding process will also be substantially faster. See for more details


Nov 7

We made it possible to renew an expiring wallet, add new authenticator code to a wallet, and buy fiat securely directly from 1wallet. We also made a large number of improvements concerning asset safety during upgrade and recovery. For more information, see the two links below

Oct 24

We made it easy for other apps to securely integrate with 1wallet, and made Harmony Safe (based on Gnosis Safe) the first example. Find out more at

Oct 10

We made authenticator code valid for longer, and made it easier for people to retrieve assets failed to automatically transfer during an upgrade. For more details, see


Below is a checklist of tasks we previously compiled (in Oct 2021) which we intend to implement over time. Some of them overlap with the milestones stated above. From Nov 2021, we post weekly milestones instead to provide more visibility for 1wallet development

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)
Purchase NFT from daVinci via 1wallet (completed)
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
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