ALLOCATED PRIORITY: New Wallet

[JackALaing (Jack Laing)]

POP Objective

PNF has been working with the Raid Guild team on developing Wrapped POKT (wPOKT), a tokenized representation of POKT on the Ethereum blockchain. Raid Guild is also developing the wPOKT bridge app, which will rely on browser injection functionality for a safe bridging user experience. Currently, the only POKT wallet with this functionality is SendWallet (an open-source browser extension wallet funded by PEP-37). It is important for the wPOKT bridge to have more than one wallet option to remove single points of failure that could interrupt bridging for users.

This Pocket Open Priority (POP) invites community builders to create and maintain a new wallet.

---

POP Specifications

Requirements (Must Have):

• Compatible with existing POKT keyfiles and private keys (and functionality to import)
• Ability to create a new POKT wallet
• Ability to export both POKT keyfiles and private keys created by the wallet
• Ability to transfer POKT to another address
• Integration with the wPOKT bridge app, enabling the wallet to sign bridging transactions, using the browser injection method described here (to minimize the integration work required by the Raid Guild team)
• Support for POKT testnet, so we can test the wallet integrated with the bridge testnet app
• Availability to fix bugs and ensure uptime
• Open-source

Things we are agnostic to (Not Essential to Have):

• Ability to stake, unstake, and unjail nodes in a non-custodial fashion. This can currently be done via the official wallet webapp, so as long as you support exporting there will be an option for users.
• Ability to hold wPOKT. wPOKT will be supported by existing ERC20 wallets such as MetaMask. This POP specifically focuses on the need for another POKT wallet.

Nice to Haves:

• Commitment to integrate Ledger – note: the official wallet webapp is open source and has this integration
• Commitment to continue developing with future UX/design updates (e.g. saving recipient addresses)

References:

• Official Wallet Webapp (GitHub)
• SendWallet Browser Extension (GitHub)
• SendWallet Browser Injection (GitHub)

---

POP Funding & Application Details

• Open: Now
• Price: TBC - based on submissions. Preference will be granted to submissions that are priced in POKT.
• Funding: This submission will be funded from the Era Allocation as outlined in PEP-60 ERA Budget.
• Submission Deadline: Close of day 11th August
• Decision Provided: Close of day 15th August

Submission details requested:

• Full scope of work, including technical specification
• Estimated timeline
• Breakdown of expected fees and payments
• Team working on it

Key factors being considered in choice of winning bid:

• Estimated timeline - will the wallet be ready for wPOKT testing (early September)?
• UI/UX details
• Price

Submissions should be posted as replies to this thread with Submission in the first line. Submissions can be edited at any point up until the deadline.

[whyclosedsource]

imo low prio due two options available already:

• https://wallet.pokt.network/ which should be built out to support bridging
• the mentioned SendWallet

else I would suggest integrating with existing wallets, eg stackwallet is opensource & others. Why another app to install. Also wpokt can be stored in MM & co.

[Jinx (Chris Jenkins)]

The default wallet doesn’t support browser actions and EVM, and can’t reasonably work with wPOKT. The community deserves to have options for wallets that work with wPOKT, so this POP is important.

[Jinx (Chris Jenkins)]

Also, SendWallet has done a helluva job bringing this functionality to the community, but given that their wallet is GPL-3, there are pretty significant limitations to how the community can use the code they’ve created. If “Build in the open” is actually a value we share, we need to have a viable option that can be remixed and forked by the community at large at will.

I’m happy to see this POP created, as it demonstrates a commitment by the foundation to that value.

[shane]

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:

• React
• Mocha
• Turbo
• PocketJS
• Web3
• BIP-32
• BIP-39

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.

[iannn (Ian)]

Submission

Though I am late to submit, there was only a single submission and so I’m going to add my thoughts as well as throw my hat in the ring to offer a variety of options:

• I’m no expert but it appears to me that GPL3 more closely aligns with the DNA of Pocket:

  • Copyleft protection preventing closed source wallets fosters development around the trustless principle of web3, the open principle of the pocket dna
  • GPLv3 ensures that if you distribute a device with GPL software, hardware manufacturers can’t prevent modifications to locked down hardware using GPL code ( Tivoization protection).
  • All future modifications to the codebase benefit anyone who has contributed
  • GPL is a strong statement in favor of software freedom, that software should exist to empower its users, not limit them.

• Why do POPs need to have binary outcomes, only 1 winner? I think for each of the previous POPs our ecosystem would have benefited from having >1 entities providing the same service with different minds and different stacks.

• I hesitated to bid on this POP because I’m uncertain about the liability of single handedly building/owning/maintaining a wallet as an individual/undercapitlized entity and what the real risks are in doing so. No one has discussed this out loud and I even tried reaching out to some of the other wallet providers/builders in this ecosystem (we have a few that are sidelined) to help understand this and got crickets basically.

• Because of the above, and my own ptsd, I worry about this being a trap.

• Despite the above, I am interested in contributing wallet code, I do have some experience with wallet sdks/managing keys:

  • Bulk staking integrated into cryptonode.tools (forked version of nodies stakepokt app);
  • Have started work on adding bulk staking to the main pokt wallet;
  • Built in validator automations for eth and harmony in DA’s node launcher
  • Manage my own fleet via pocketjs 2.1.1 with automated restakes and topoffs in nestjs with full logging

I believe I have the capabilities to build out the requested features, and since the dao would like a faster timeline for wPokt bridging, I can dedicate my time to forking sendwallet (keeping the same license) and make my best effort to integrate wPokt bridging for testnet within 4 weeks. I would commit to cooperating with PNF and Raidguild for testing and preparation for mainnet integration as well, however long that takes for it to be deemed safe by others with more expertise than I have. I would also commit to the Nice to Haves, however long that takes as well.

That the first bullet of the agnostic list is not a priority for the dao somewhat baffles me. Leaving increased friction for users who wish to maintain self custody of their funds and stake to nc providers is kind of antithetical to the pocket dna if you ask me, and so I plan to add features for bulk staking/unstaking into the main pokt wallet regardless of whether I’m paid for this or not, and would also include those features as well into an extension wallet if chosen to do so.

I would be happy to see others building wallets and to have their worth to do so, but I’d be thrilled myself to accept the challenge of the needed and wanted features of the extension wallet for 500k pokt, and to have some carrot to share in the celebration of a future successful pokt turnaround.

[shane]

FYI, the Chrome Store will only accept extensions that follow’s Chrome’s Manifest V3, and will NOT accept submissions that are Manifest V2.

Currently SendWallet is Manifest V2 (similar story with Taho), so a fork of SendWallet would not be accepted into the Chrome Store without first making it Manifest V3 compatible. SendWallet is considered a legacy submission to the Chrome Store, which is why you can still find it there, but any new extensions have to be Manifest V3.

A new wallet would need to be Manifest V3 from the start (which we became familiar with due to prototyping). Just thought this would be helpful context for the community.

Google plans to remove all Manifest V2 extensions from the Chrome Store in January.

[iannn (Ian)]

I appreciate the additional context, a little bit of extra work but that doesn’t seem like a major hurdle to me. The POP neither requires nor specifies any submissions to be accepted into any third party app marketplaces, however, I would commit to making the update to eventually get listed in the chrome store. To be clear though, my priority would to have a wallet for testing wpokt quickly, and it wouldn’t bother me at all if sendwallet were able to integrate the wpokt features I built before I updated the manifest and get my version accepted into the chrome store.

[JackALaing (Jack Laing)]

Thanks everyone for the submissions and the extra insights/context. There are more considerations to this decision than we anticipated so we’re going to take another 48h to reflect and then we’ll get back with next steps.

[JackALaing (Jack Laing)]

After some reflection and discussion with both applicants, we have decided to award the POP to DA (@shane). Since our priority with this POP is an MVP wallet that integrates with the wPOKT bridge, the DA team has agreed to reduce the number of launch features and to accordingly reduce the cost to $20k.

The features they will ship as part of this $20k cost are:

• BIP-39 compatible: Mnemonic seed phrase
• BIP-32 compatible: Single seed phrase, endless wallet addresses
• Create, import, and export POKT wallets via keyfile and private keys
• Standard Wallet functionality: Send POKT, Receive POKT, view past TX, POKTScan quicklinks
• wPOKT Bridge App Integration using browser injection
• Testnet Support
• Open-source with Apache v2 License

[ArtSabintsev (Arthur Sabintsev)]

hey folks, adding my 2 cents here as I’m catching up, but the ecosystem must maintain an integration with Ledger on at least one wallet that’s recognized by PNF, the DAO, or the ecosystem at large. I saw it mentioned in Shane’s proposal, but not in the follow up posted earlier today by Jack.

Until then, the web wallet must still be maintained as it’s the only Ledger access point at this point in time.

[whyclosedsource]

would appreciate a version for Add-ons for Firefox (en-US) as well

[shane]

Mozilla is in the process of adapting Manifest v3 to FF. Once they do, then this wallet should be immediately portable to FF.