Decentralized Authority (DA), consisting of @shane and @AmishBatman, in collaboration with @Jinx, is happy to submit a proposal to be considered to build the next generation of the POKT Wallet.
Background
Many in the POKT ecosystem are aware of who we are and the work we’ve done, but I’ll highlight the relevant experience that pertains to POKT and web3 wallets.
Wallet Experience
DA’s team has been a lead dev on a number of wallets, spanning across Bitcoin, Ethereum, and POKT. @AmishBatman was the primary dev on a desktop multi-wallet for the Blocknet ecosystem called XLite. It supported dozens of chains and integrated with Blocknet’s DEX and interchain API.
He also created a fork of MetaMask that natively integrated with Blocknet’s interchain products and services. Though it was never released by Blocknet, it was an opportunity to work directly on MetaMask’s code.
POKT wise, he has already built a fully functioning, downloadable POKT desktop wallet for PNI. This initiative was sunset by PNI to focus on other products, but it was fully functioning, built to spec, and was ready for QAing. Most of the features listed here were included in the desktop wallet, so recreating them in an extension wallet would be no issue.
POKT Experience
Decentralized Authority is very familiar with POKT’s code, ecosystem, culture, values, and have been long time contributors. Please review our Github to see all the POKT related products and tools we have developed over the past 3 years. Notable open source projects:
- Node Launcher (a deployment engine for POKT validators utilizing Docker and TypeScript APIs)
- Community Chains (Geo distributed load balancers connecting POKT nodes to chain nodes providers)
- POKTLint (A multi-chain, global latency tester for POKT Servicers)
- Other POKT related tools pertaining to address analysis, Servicer stress testing, QoS checker, etc.
Technical Spec
This wallet would be a new codebase, designed specifically for POKT, and will not be a fork of an existing extension wallet. SendWallet provided POKT with an extension wallet that was largely Taho Wallet code, so a second extension wallet with a different code base would eliminate the risk of a single point of failure.
We would build this wallet primarily in TypeScript and are considering the following libraries:
Features
Our design is focused on expandability. Having a new codebase allows us to build from the ground up with the POKT ecosystem in mind. The features in this wallet include ones that will be ready at launch (Launch Features), and ones that would be ready to add in the future (Addon Features). Since the wallet’s design is meant to expand, adding features in the future will be a significantly streamlined process.
Prototype GUI (not production GUI and subject to change).
Launch Features
- Create, import, and export POKT wallets via keyfile and private keys
- BIP-39 compatible: Mnemonic seed phrase
- BIP-32 compatible: Single seed phrase, endless wallet addresses
- Standard Wallet functionality: Send POKT, Receive POKT, view past TX, POKTScan quicklinks
- Recipient Address Book
- Stake, unstake, and unjail nodes (custodial and non-custodial)
- wPOKT Bridge App Integration using browser injection
- Testnet Support
- Open-source with Apache v2 License
Follow-up Features
- EVM Support (hold wPOKT from Ethereum, in the same wallet with all the Standard Wallet Functionality described above)
Addon Features (possible features that could be added with additional funding)
- Ledger Integration
- WalletConnect Integration: for use with most modern dApps, including DEXes like Uniswap.
- V1 Integration: POKT will need a v1 wallet, and this would provide a ready extension framework for v1.
- IBC integration: v1 ready to integrate with the Cosmos Ecosystem.
- Hosting Provider Extensions: where providers could connect to an API to integrate their staking services directly into the wallet itself.
- V1 Staking Extensions: where developers can stake for relays, or stake to gateways. Similar to Hosting Provider Extensions, gateways could use an API to integrate their services directly into the wallet.
- Desktop and mobile ports: this extension wallet could be ported to other forms and devices through our technology stack and design. Each port would require additional work, but multi-device is possible, similar to Keplr.
Differentiation from SendWallet
Codebase
As mentioned above, this wallet will not copy the work of Taho Wallet. This means that POKT would be better secured by having multiple codebases as part of our ecosystem.
Taho Wallet currently only supports EVMs, and while that is a positive for wPOKT, a new codebase focused on POKT specific needs could be easier for adding v1 needs, like IBC.
License
SendWallet is licensed under GPL-3, which is required since Taho Wallet is GPL-3. GPL-3 has limitations where the code inside of that work can only be used inside of other GPL-3 works. This means that other extension wallets like Trust Wallet, Coinbase Wallet, Rabby Wallet etc. could not use SendWallet code for their own POKT integrations in the future. Most of crypto uses MIT or Apache licenses, as they are unrestricted and can be freely used anywhere. GPL-3 is much too constrictive for wide adoption and use.
A new wallet with an Apache V2 licensed codebase would mean that any other wallets or product could create POKT integrations by using the new wallet’s code. This would be a great value add to the POKT ecosystem as it would allow more code sharing across significantly more projects.
Multi-service
SendWallet only allows users to use SendNodes for staking. It would be beneficial for POKT to have a wallet that is open to expanding to more services. Our desire would be to provide an expandable design to allow anyone to integrate their services, giving users many options when joining the POKT ecosystem.
By having a codebase that is focused on expansion for any POKT service, plus an Apache v2 license so the code is open for any service to use, the whole ecosystem would be able to reach new POKT users in an equal fashion.
While Decentralized Authority’s products have been mostly focused on independent node running, we have always been neutral in never promoting or favoring one POKT service over another. This wallet would be “pro” anyone reputable that offers POKT services.
Budget
The estimated budget: $48,000 and would take 3 to 4 months to complete (though we expected an MVP version to be released sooner). All funds would go toward development and design time.
We believe there is fair reasoning that this budget could come from multiple ERA initiatives, including wPOKT, v1 and possibly gateway-verse, as POKT needs an expandable wallet for the future. We are also open to using DAO proposals for partial or future funding.