I would like to see a proposal to fund development of additional wallet support, maybe the best place to start is to support all onboard.js wallets (or at least a good subset of them) in the platform. What would be a good amount of FOX to incentivize this? This could be taken on by current ShapeShift developers in their off hours even ahead of full open-sourcing of the code.
How about a bounty of 35k FOX, would that be enough to have this get done relatively quickly? Open for thoughts/discussion on this topic.
+1 for onboard.js support, we’ve got a great relationship with the Blocknative team and have discussed not only supporting all the wallets on EVM networks, but have also discussed the possibility of them upgrading onboard.js to support all of the chains supported by the wallets.
This is hands down one of the biggest features missing from ShapeShift today evidenced by all of the valid complaints today from metamask users.
The challenge isn’t just in implementing onboard.js unfortunately. Because wallets like metamask don’t support xpubs, and as a multi-chain hardware wallet interface, our system was initially built to support xpubs, we need to do some work to support accounts in addition to xpubs.
That said, I fully agree we should make this upgrade asap. Once the upgrade to our backend is complete, I think 35K FOX would be a generous bounty to implement onboard.js in the platform and would support that proposal.
Because ShapeShift isn’t dissolving tomorrow and still employs a large team of engineers, perhaps the backend architecture is something that could be completed by the ShapeShift team while they work on open-sourcing efforts (at no expense to the DAO). Just a thought. Generally I support investing ShapeShift’s engineering resources exclusively on open sourcing these systems asap so we can get to the point where anyone can make these changes.
+1 for onboard.js support. ShapeShift historically has had a great relationship with the Blocknative team and have discussed not only supporting all the wallets on EVM networks, but have also discussed the possibility of them upgrading onboard.js to support all of the chains supported by the wallets.
This is hands down one of the biggest features missing from ShapeShift today evidenced by all of the valid complaints today from metamask users.
The challenge isn’t just in implementing onboard.js unfortunately. Because wallets like metamask don’t support xpubs, and as a multi-chain hardware wallet interface, our system was initially built to support xpubs, we need to do some work to support accounts in addition to xpubs.
That said, I fully agree we should make this upgrade asap. Once the upgrade to our backend is complete, I think 35K FOX would be a generous bounty to implement onboard.js in the platform and would support that proposal.
Because ShapeShift isn’t dissolving tomorrow and still employs a large team of engineers, perhaps the backend architecture is something that could be completed by the ShapeShift team while they work on open-sourcing efforts (at no expense to the DAO). Just a thought. Generally I support investing ShapeShift’s engineering resources exclusively on open sourcing these systems asap so we can get to the point where anyone can make these changes.
Yes I am generally aligned in terms of during normal working hours engineers should be focused just on open sourcing so the community can get involved ASAP. That being said my idea here is a bounty to incentivize work during their non-normal hours (outside of work) to see this get delivered even ahead of that. I think it would be worth it, if 35k FOX is too much maybe we reduce to something like 20k FOX to see it happen in the short term?
Glad to be discussing potential cool new features here. - How would reducing the amount of FOX for the work make it more likely to happen in less time? Maybe I misunderstood what you were saying?
Wearing my engineer hat, removing the the ETH xpub dependency seems like it fits in as a prerequisite to this. It’s really tech debt that has to be paid down to enable the feature, and perhaps that should be tracked separately. Conceptually, I think that part fits more within the realm of what SS US engineers should be doing to open-source everything, while the addition of onboard.js and/or other wallets seems more like something to handle via the DAO.
This is a good consideration. Where the work to support account-based coins by account is allocated. I will discuss with the team. Thanks for bringing it up.