Aaron Li
Yuriy M
Giv ParvanehCurrent 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
Updates
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
Checklist
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
