milestones

start date

end date

mainnet launch with 10^2 = 100 users, each with $100 assets

mainnet launch with 10^3 = 1000 users, each with $100 assets

mainnet launch with 10^4 = 10,000 users, each with $1000 assets

mainnet launch with 10^5 = 100,000 users, each with $1000 assets

✅Make the client resilient to brute-force attacks

✅Implement a new method that imposes a difficulty parameter on operation execution

☑️Replace EOTP hash function with a stronger candidate, Argon2

Document and analyze this method and the choice of the hash function

✅Offer Double OTP as a composable authentication method for enhanced security

✅Make a one-time recovery EOTP residing on the client that is time-independent

✅Ensure a commit is confirmed on blockchain, before revealing an operation (transfer or recovery).

✅display the total number and the total asset of 1wallet generated (waiting for Jenya to deliver API endpoint)

✅command line interface (for slowmist audit, hackathon spec, client security focus)

✅Add a button and a screen on wallet display page, that allow the user to set recovery address, if it is currently empty #7

Substantially reduce client bundle size

dune analytics on the total number of 1wallet addresses

dune analytics on the total assets of 1wallet addresses

Add buttons and a screen on wallet display page, that allow the user to increase or decrease the wallet's spending limit

If the user does not use any composable authentication method (i.e. has not set double OTP)

If the user has already set a composable authentication method, require the user to use the composable authentication method (double OTP) to adjust the limit

✅simple IP-based rate-limiting

use relayer to sign for predefined transactions (nft purchase on da vinci, telegram tips)

https://eips.ethereum.org/EIPS/eip-1207

NFT transfer should happen on the NFT contract itself, so no signature is needed. The buying and selling of NFT is another matter. Selling may require signature. Need to find out exactly how it is verified right now, and how trading of NFT is done on Da Vinci.

s: buy/sell nft is similar to other tx signing, which can be done later. for m3, let's support hrc20/hrc721 token transfers to/from 1wallets

use relayer to sign for staking transactions

Signature is verified against the signer's address. Stakes will be taken from signer's address. So we can't have the wallet contract to stake but have the relayer to sign.

s: relayer for off-chain staking or delegation is similar to staking derivatives or staking pool. schedule a call with rj on a minimal setup even in a trusted pool settings?

Account abstraction: gasless wallet creation

near's account model

Client-side transaction signing

Transaction authorization without forwarder

✅Compute stateless incoming request fingerprints using the hash of concatenations of geo-IP, user-agent, HTTP ACCEPT header, and wallet root hash.

✅Impose rate-limits for requests based on fingerprints. Requests exceeding rate limits per fingerprint will be responded with error-429 (Too Many Requests), subject to a delay that is doubled per consecutive error-429 resposnes, starting from 1 second.

Wallet creation: 1 per minute per fingerprint, and 30 per minute globally

Implement response prioritization: if a request is capped by global rate limit, it will be placed in a priority queue instead of responded with error-429 error. A counter will be kept for the number of requests in the queue per geo-IP, user-agent, and fingerprint. When an item is placed in queue, its priority will be set to -1 multiply by the sum of the counter values for its corresponding geo-IP, user-agent, and fingerprint. The server periodically (at a small interval) picks the request with the highest priority to serve. Any request staying for more than 10 seconds is automatically removed.

Commit: 30 per minute per fingerprint

Reveal (of any kind): 30 per minute per fingerprint

Others: 6 per minute per fingerprint

✅ Implement response prioritization: when an incoming requests exceeds the rate limit, it will be placed in a priority queue for the type of the request. The request with the smallest The priority is determined as the following: the sum of number of requests from each of the following

✅Implement the patch to prevent the attack described above

✅Implement the new recovery mechanism (Part I §3, Part II §3)

Implement the daily spending limit mechanism (Part II §4)

✅Implement activation of double OTP (Part I §2(a)(ii))

✅Wrap up reviews for two outstanding pull requests:

✅Ivan's review on ONEWallet contract #3

✅Slowmist code review on the "command line" version (li to cooridinate)

✅Dimitris' review/audit on security

✅Adriana's review/audit on security

✅Automatically trigger recovery process when the recovery address sends 0.1 ONE to the wallet

✅support HRC21 (native and bridged asset)

✅support HRC721 (NFT asset)

gifting "one launch" (binance.us launch video by robin) to the first million 1wallet users

https://davinci.gallery/edit/0x541e2e5c7161c24c82371b252b20f790ccbea9f8

✅NFT asset display gallery

crazy.one names for wallet address

Integrate with Harmony staking

https://github.com/polymorpher/one-wallet/issues/9

https://github.com/harmony-one/onewallet/blob/master/src/popup/pages/API/SignTransaction.vue#L263

Implement encrypted connection and session management, per WalletConnect spec

Implement user interface for parsing a WalletConnect QR code (via copy-paste) and parsing the underlying wc:... connection string.

The introduction of the new methods for client security in Part I

New algorithms, hash functions, benchmark, and security strengths in practice

Yubikey or other generic, tamper-proof private-key based signing device.

Alternatives considered during the design of the new methods for client security

The user experience considerations and flow design in Part II

The smart contract and protocol updates in Part IV

Feedback from Ivan @ivan-homoliak-sutd