Meta-Proposing a KeepKey Workstream

I love KeepKey, but as a hardware product it doesn’t fit very well into the typical engineering workflow. There are lots of things I’d like to propose the DAO fund which are KK related, and I’d love to see a specific home for them – especially given that getting a feature into the official KK firmware release is, for the foreseeable future, an inherently centralized process.

I see KeepKey firmware development as important to ShapeShift in the long term. Beyond its literal use in the hardware wallet of the same name, its very presence as a separate implementation (and set of tests) makes the rest of our code better for having to support it. Trezor and Ledger are great, but having KeepKey lets us innovate at our own pace. Also, there are a variety of interesting security reasons that it might be a great idea to compile it to WASM and use the same firmware directly on the web as a type of software wallet.

I’d like to propose that someone propose a proposal for a KeepKey Workstream.

4 Likes

I agree that KeepKey - especially as a core wallet product of ours, deserves a dedicated space and team. Additionally we are managing KeepKey retail and tech support within Customer Support. If there was a specific KeepKey workstream, I’d be interested to see if retail will still need to be supported.

Customer support would then have a dedicated team to reach out to regarding troubleshooting, updates, etc. Would you want to have dedicated tech support for this workstream? Is that in your vision here? Or would that still ideally be flowing through our traditional/general support path?

1 Like

Just a thought, as a product could this fit into that workstream and tasks be distributed though bounties and special projects? If the foundation of other teams are in place, product, support, engineering, operations, and security. Establishing dedicated milestones and or roadmap (I can imagine central shapeshift has already) these tasks can be delegated effectively.