An open letter on strategy and execution

ShapeShift DAO Community Lounge
1
  1. Dear DAO Community -

    Let me start by saying I am encouraged by the recent community led efforts that have taken place as the broad market has declined. Resource constraints are always a great impetus for a business to prioritize and focus. I believe that the DAO will emerge stronger and more focused as a result. While I have seen lots of discussion about budget changes, in this letter I want to present some ideas that may alter our thinking and therefore execution in the DAO. While these ideas have been formulating from well before the selloff, the recent market events do create an even greater opportunity for us to refine and adapt the DAOs execution. These are my own opinions as a FOX holder and active DAO member, they have nothing to do with my role at the Fox Foundation.

    A good place to start this conversation is around two polarizing examples, please understand it is meant to highlight extremes and neither side is reality. If our vision is to become the interface to the decentralized universe, we can discuss two execution strategies to realize this vision. The first would be to build in parallel the minimum feature set that would fulfill the interface needs of all users (of all wallets, environments, blockchains, etc). Along the way we wouldn’t really be able to measure much, because we don’t expect anyone to come to the platform until we have reached that minimum feature set. Our development is slow as we optimize for all users on all platforms on all blockchains.

    A second approach would be to segment the potential audience of our platform, similar to a user persona. From there we would identify the minimum viable feature set that we would expect to be sufficient to attract that user segment to the platform. This segment only uses a subset of all the possible chains, wallets, environments and protocols needed in the previous example. We are able to move quickly as a business as we are laser focused on all decisions to optimize the experience of this segment. Once we have shipped this smaller feature set, we then measure, inspect and adapt our hypothesis and broader vision. We have gotten critical feedback about our vision sooner and spent less resources, enabling us to fail or succeed much faster.

    To me, our current approach to realizing the product vision is closer to the first example than the second. While we have sparse data about our users, when that data is examined, the response is often, well we don’t expect users of X until we have A, B, and C integrated. I would advocate to change this approach and do the following:

    Identify a subset of users and the minimum feature set we believe they need to be attracted to the platform. Focus all of our efforts on realizing this feature set, move quickly on business decisions that enable this audience.

  2. Make an informed hypothesis on measurable results. For example, when we achieve the minimum feature set we expect X KPI to grow to Y
  3. Once we have measured the outcome, determine if our hypothesis was correct, adapt and execute the next experiment.

I want to make it clear that I am not questioning the vision, in fact I don’t have an opinion on the vision. I want the data to inform that opinion, and it is too sparse at the moment to do that. It is also early, we have not made a concerted effort to migrate users from beta and until that happens it will be hard to draw many conclusions.

Below is some of the data we do have that is directly attached to app.shapeshift.com. The only conclusion I can draw is that we need to expedite the process by which we get measurable data to inform our product decisions and our assumptions.

All data as of 5/17

Gem Integration

  • $76,413.68 in March (April data is not available)

  • 162 total transactions (DAO rev share is 28.5 bps or $217 for the month of march)
  • Gem - Google Sheets

Foxy

  • 131 FOXy holders (unique addresses, some addresses may hold multiple users funds like RARI for example)

  • 45 MM staked FOX (12% of circulating supply)
  • Dune

Yearn Integration

Requests to app.shapeshift.com over last 30 days

  • Please note that a user != request. Each visit to the application will generate many requests, but this data can be useful in drawing order of magnitude type comparisons (for example, less than 1% of requests on either application are generated from mobile IOS devices).

    58,740 requests

  • 2,760 of these came from mobile devices
  • 70 IOS
  • 2570 Android

Requests to beta.shapeshift.com over last 30 days

  • 33.25M requests

  • 582K of these from mobile
  • 231k of thes from iOS
  • 327k of these from android

With love and much respect for the Shapeshift DAO community -

0xean

2

58,740 requests

Going to the site and connecting my wallet was around ~175 requests made (for me, YMMV). That’s roughly 470 users that have connected their wallets in the past month (likely much less considering most visits will do more than just pair wallet)

Engineering might disagree with me heavily on this, and I may be completely wrong about everything so please feel free to correct me… but the platform is becoming way too bloated already. Everything is being over-complicated by trying to implement the native wallet, and the in-house hdwallet library.

Maybe I’m missing something because all the features haven’t been built out yet, but I have yet to see a feature that truly requires all this complication.

From a end users’ perspective, platform features and usability would matter astronomically more than a true BIP32 implementation. Especially since most users would realistically be injecting their wallets anyways. When I imagine the “DeFi universe” assets like Bitcoin, Litecoin, Doge, etc., do not even pop up in my mind. EVMs, Cosmos, hell, even Solana and Tron are what come into mind.

It feels like we are trying to re-invent the wheel instead of innovating.

Am I alone in thinking that DeFi has evolved to a point where we don’t really need a true native hdwallet implementation? Cross chain, multi chain, < insert buzz word > chain features are not off the table by deciding to go with the injection route. Maybe I’m being too naive in thinking and am failing to see the true added benefits in the future by going this route. Someone please convince me otherwise, I am simply stating what I think I know from observing from an awkward not too far yet not too close distance from the development progress.

Again, this is coming from a genuine care and concern of ShapeShift. Engineering team, please don’t hate me. Call me out on all the inaccurate ideas and viewpoints I may be holding instead. Every day I’m amazed at the level of your talents, but I feel it could be better allocated. Tell me if I’m wrong <3

3

no offense taken.

Let me answer in two parts - with respect to hdwallet and requests.

w.r.t hdwallet

The hdwallet abstraction is important. It provides a unified interface for interacting with any wallet, with adapters on both the chain side, and the wallet side. e.g. the same code signs an ETH tx with the native wallet or with tally cash. Chain adapters broadcasts the transaction for native, tally broadcasts it’s own txs.

Without this abstraction - we’d have custom code littered across the client, and chain adapters, deal with the specific wallets and their own interfaces.

Regarding the native wallet - I agree this needs to be heavily scrutinized, in the context of the user personas we want to target and optimize for. It’s a massive security and maintenance liability and we don’t have any good data to suggest people are using it, breadth (number of users) or depth (balance) wise. If it were purely up to me we’d ditch it in favor of the defacto standard wallet support for each chain respectively.

Agree that LTC/DOGE are dinosaur/meme coins from a previous cycle, and can’t really be monetized. Again IMO, we should expand upon the wallet migration UX and just say ‘cool here’s your mnemonic take your assets to a wallet that supports them’.

w.r.t request count

Without seeing more granularity in ’s data - I believe it’s counts of requests to CloudFlare.

If this is the case, the assumption of 1 user connecting a wallet being equal to 175 requests is off by at least an order of magnitude, most likely two orders of magnitude. With a native wallet I’m seeing 17 requests to the shapeshift.com TLD, including static assets, requests to unchained and websockets, with MetaMask I’m seeing 3 requests - one for the page itself, one for the account from unchained, and one for a websocket for Ethereum.

4

More broadly, replying to the OP, and thank you for the thoughtful post .

I’m in full agreement, and think we need to collectively define hypotheses that can be tightly scoped, executed, measured, and iterated upon, with the number one goal of increasing users and monetizing them ASAP.

Referring to my other comments on Discord in text and governance chats regarding product market fit (PMF), our current strategy is predicated on a large assumption about the interface play and integrations, but from the limited data we do have, it suggests it’s not working, perhaps not yet, but given the runway and macro conditions I don’t believe we have time to execute an experiment that’s likely as long as the runway.

I know people have mentioned feature-fatigue and noted that nothing we have tried for years has worked, but this is a sunk cost fallacy.

If anything, we need to experiment more and iterate faster now more than ever. This will come at the cost of tech debt and I’m ok with this, and yes I lead engineering. A perfectly abstracted and engineered product with no users is akin to shuffling the deck chairs on the Titanic.

If people aren’t ok with the idea that we need to move fast and probably break things in order to find better PMF ASAP then perhaps this DAO is not the right environment to be contributing to.

I’m looking forward to suggestions of specific ideas we can define, implement, measure, and iterate on quickly. I think the yieldy concept is one of the most promising so far.

5

discourse-post-upload20231125-65354-m88hlg.png 0xdef1cafe:

ters on both the chain side, and the wallet side. e.g. the same code signs an ETH tx with the native wallet or with tally cash. Chain adapters broadcasts the transaction for native, tally broadcasts it’s own txs.

Without this abstraction - we’d have custom code littered across the client, and chain adapters, deal with the

Appreciate the response!

I’m still having a hard time understanding the benefits of being able to interact on both sides of the chain if there isn’t any cross-chain functionality (yet). Without any routers/nodes/channels/validators/etc deployed on both sides of the chains to facilitate cross chain communications, am I correct in assuming that we’ll ultimately be relying on third party protocols, like Thorchain for swaps and NXTP for bridging?

6

It’s about a single interface to represent a wallet, such that calls from the client are transparent as to what chain you’re dealing with, what wallet actually signs it, and what you get back. Pass params, get result, hdwallet abstracts away the details, chain adapters broadcasts, same deal.

Yes we’re ultimately relying on third party protocols, but this is why a common abstracted interface that supports multiple chains and wallets backing it is important, so when we add EVM chains the client doesn’t become a giant ball of spaghetti figuring out what it needs to construct and pass to the wallet, how to parse the return, how to broadcast the tx etc.

More broadly we’re following/setting industry specs with respect to CAIPs and working with the xchain.js team to see if they can integrate with us/we can integrate with them, including how hdwallet and chain adapters can be merged, such that hdwallet is not just an “offline” wallet so to speak, relying on chain adapters to talk to the chains.

The future is cross chain, and if you want to challenge our vision or support for that I’m all ears, but if we’re supporting cross chain, a wallet abstraction is a necessity in some form or another.

Sorry, pretty technical for a governance forum, but I wanted to shed more light on this for you.

7

Hahah don’t get me wrong, I think it’s fcking awesome what you guys are doing. And I think we should have launched our own bridge a long time ago. I guess it’s so rare to see a true bip32 implementation outside of simple wallets, it’s hard to envision for the 99% what a DeFi platform would look like with a wallet that can interact with both EVM and non-EVMs seemlessly. Last annoying question - can already popular libraries like ethers/web3.js be used in tandem, even if in a somewhat isolated environment from the ‘main’ platform? That’d be very powerful, imo, considering the pool of devs that are solely used to building out new and often times very creatives or game-changing DeFi projects on these libraries.

8

Yes - web3 is already a dependency and we already use it in the client for things like fetching rebase history, about to use it for others like APY from Uniswap pools for the FOX asset page, The Graph for other EVM market data etc. We try and hide/wrap it up behind services where we can.

web package.json

9

My personal take on the ShapeShift app usage is that its just simply not accessible to me as a relatively “small crypto baller”. I think a couple people I have talked to have the same thoughts in that we are building this awesome app on Mainnet but like… we can’t generally afford to use it so we go elsewhere to access DeFi opportunities on other chains (like Elk finance that supports xDAI which is conveniently the chain we all get paid on). side idea: if we did an ELK finance integration that would be absolutely amazing IMO as there is a lot of $ flowing through there and diverse DeFi opportunities that I think a lot of our current contributors take advantage of.

I think we would see a SIGNIFICANT increase in use if we supported more (secure/vetted) chains that appeal to people who can’t necessarily afford mainnet costs. Shoot, just supporting the Gnosis chain would be huge and I would happily use ShapeShift. I want to use this app we are building and literally just am financially blocked from considering it as a smart move just because of cost inhibitors as there are simply cheaper options/more suited options for my financial status out there.

10

Since def1 so kindly responded to my questions and concerns, I’ll take some load off and take this one.

If we had taken aimed for EVMs first instead of Cosmos, I’m pretty sure EVMs (including Gnosis) would have been implemented already, or close to being finished. From what I saw for Cosmos, it seems that each chain on Cosmos need to be individually implemented. I think engineering is working on changing that so one abstraction layer for a network could support the majority of chains on it - at least definitely for EVMs. Eng can correct me on that.

https://global.discourse-cdn.com/standard10/uploads/foxcookieco/optimized/1X/e21df1aeb626a7f172a6d4de36fa821a901c48f0_2_690x426.png

But If this notion timetable is accurate, we should be seeing some a lot more EVM activity shortly 1f64f

11

discourse-post-upload20231125-65354-m88hlg.png 0xdef1cafe:

Regarding the native wallet - I agree this needs to be heavily scrutinized, in the context of the user personas we want to target and optimize for. It’s a massive security and maintenance liability and we don’t have any good data to suggest people are using it, breadth (number of users) or depth (balance) wise. If it were purely up to me we’d ditch it in favor of the defacto standard wallet support for each chain respectively.

I feel that this deserves it’s own post/focus/proposal, and I am 100% behind it. I find native wallet to be anachronistic and out of scope to our current goals and aims of being the abstraction layer hub of web3.

If the numbers are suggesting there is a negligible amount of users in the native wallet ecosystem, and it is clear we will not be dedicating the resources to vaulting and keeping it as the top non-custodial software wallet, I would be in favor of driving a discussion to best handle sunsetting discussions.

I am also in favor of giving all users their mnemonic, loading up a help desk article with wallets that support all previously supported chains, and burning native down.

I don’t want to drive this conversation away from a lot of the serious points about PMF and current statistics we can define of our user base brought by and . There’s a lot more needed than simply cleaning up and clearing out native wallet in favor of the current software options we integrate or are about to, but I think it would be an important start.

I hope we can look at the best ways to also migrate those users at beta to app seamlessly in the near future, but even with full feature parity and a complete transfer of those users I feel we are lacking the features and desires currently sought after in the ecosystem.

discourse-post-upload20231125-65354-m88hlg.png 0xdef1cafe:

If anything, we need to experiment more and iterate faster now more than ever. This will come at the cost of tech debt and I’m ok with this, and yes I lead engineering. A perfectly abstracted and engineered product with no users is akin to shuffling the deck chairs on the Titanic.

If people aren’t ok with the idea that we need to move fast and probably break things in order to find better PMF ASAP then perhaps this DAO is not the right environment to be contributing to.

Let’s forever remain agile and keep DAOing it faster.

12

I think this is a great conversation to have, thank you for starting it 0xean.

For starters, I think we want to better define and reduce to practice goals. If our immediate goals are monetization, then yes, we’ll want to drive toward features where we have revenue sharing, but beyond the features we need some serious effort toward bringing people in to actually use our implementations. We can build great revenue sharing features, but if no one is using them, we won’t get monetization.

Looking at the numbers, we still have relatively large user base on the legacy platform. Gaining parity with the old stuff would allow us to force legacy users into the new app. It would also allow us to tear down legacy infrastructure. Though the tear down itself may not be monetizing the new app, it will be removing existing liabilities of the legacy infrastructure. In that sense, I think achieving parity is an important and urgent goal, and could see a more assured ROI as compared to experimental new features to attract users. Even if the return there is the removal of liability to the existing legacy infrastructure.

My personal views, which may be ignorant of some of the constraints of runway and operation costs, are a bit more long term in the crypto space. I would like us to be a resilient, decentralized, fully featured wallet. I would like to see ShapeShift as a lifeboat in a time of a future centralized crypto reckoning. I fully expect centralized institutions to be attacked and perhaps shut down by the political means. With what we have, we can be the safe haven where crypto users can escape crackdowns on crypto usage. I think with this vision, the market will understand the value of the Fox token in the shorter term. In this vision, there could be a long period where we don’t have a lot of users, then one day, when shit hits the crypto fan, we all the sudden see a massive influx of people looking secure their wealth away from the greedy hands of political actors. If and when that time comes, we’ll want to be a Noah’s ark, able to accommodate every crypto user into our system, every wallet that we can. We cannot know which coins the market will choose down the line. We cannot know which networks will fail (think LUNA). In this sense I disagree that the legacy UTXO coins should be brushed off. They may not have the shiny bells and whistles of some of the newer networks like cosmos, but they also have more time tested resiliency. The original vision of cryptocurrency was to replace fiat currency with a market based, non-controlled currency that cannot be cheated by the whims of the politically well connected. To even the playing field for all within the global economy’s most important asset, money. I would like to do whatever I can to fulfill that vision. DeFi I believe builds off of that original vision in expanding from just currency into a fully fledged market and is very important in fulfilling that vision.

I do understand that my hopes for ShapeShift may not be fully considering some of the real world, short term necessities like monetization and to that end I am fully on board in addressing the short term needs. That said, I do believe that the market will understand the value of Fox when it starts to see us as that safe haven for when all else fails.

13

Good point . With small amounts of investment, you can stake Cosmos on our platform. Cheap transaction costs on a blockchain that has been around the block (pun intended). You can buy ATOM on coinbase, send it to your SS wallet, and then stake. Earn 15%. You’ll spend less than $0.10 in transactions costs.

ATOM is a gateway into the full IBC supported suite of blockchains, which are pretty awesome. And to start, it’s as simple as staking ATOM.

14

I think it’s vital that we get more data and make more data-driven decisions. I appreciate you putting out some of the data that we do have . Can’t wait for Pendo integration to get more of it. Will be so useful when that data starts flowing in.

Stating hypothesis for proposed work - how we think it will change our metrics, and then measuring against that once the work is complete, that will be a great day when we are doing that.

15

Totally! I am really happy and super impressed with the timely/flexible Cosmos work that has been done and am really looking forward to exploring similar features more as they are built out. I was just was giving my personal experience for context for how I have used the app.

16

Thank you . While I do agree that we will have way more data once Pendo is lit up, I want to challenge us as a DAO to not wait for that and will give a specific example of how we can start.

In the coming week(s), we will be kicking off an email campaign to make the first concerted effort to drive users from beta to app. Getting the app to close-to-parity has been the primary focus of the DAO’s work-streams and we have made some assumptions about the user conversion rate we might expect to see once we begin this campaign.

Without any additional engineering work, we can test our assumptions. Using the metrics posted above on requests may not be perfect but if we are correct about the migration, we should see a significant reduction in requests to beta and a related increase of requests to app. Request numbers are not the perfect KPI, but it’s what he have today. I believe it would be prudent for us to quantify ahead of time what “significant” is and what the outcomes we expect are so that we can reflect without the bias of already knowing it.

This data may help us to select the next set of features we prioritize and how much more investment we may make into the remaining minor feature disparity between the platforms. It might even inform how quickly we redirect all users and sunset the beta application entirely. Conversely, It also could show us that we missed some critical piece of functionality that users still require if they were to migrate.

Based on recent conversations it is clear there isn’t alignment in taking this approach. I believe it is time that we as a DAO start to get laser focused on the measure-able growth of the users on the application. We desperately need feedback from the market on what we are building to guide the next round of investments we make.

17

discourse-post-upload20231125-65354-zsozg2.png 0xean:

This data may help us to select the next set of features we prioritize and how much more investment we may make into the remaining minor feature disparity between the platforms. It might even inform how quickly we redirect all users and sunset the beta application entirely. Conversely, It also could show us that we missed some critical piece of functionality that users still require if they were to migrate.

This user migration data I believe is critical to us understanding if our previous goals of complete feature parity are still in alignment and strongly desired by our user base. In my opinion, we do not have the time to ignore prime chances for us to measure our works impact and respond in an agile fashion. Perhaps the numbers provided at the beginning could be further refined into measurables like wallets connected and features engaged with?

My understanding is that we have lots of available metrics at beta still active we can use to measure the migration and could probably define further insights and goals with far less development cycles than it would be to finish the parity feature set as it currently sits on the roadmap.

If we can pour the development cycles into idle finance and potentially shelf it last minute due to product market fit or lack of TVL, I believe we should absolutely look at any and all items on the roadmap with the same level of scrutiny to continuously provide the product we’d like to see in the market, not the one we hoped we’d see 6-8 months ago. Crypto is too fast to not be reflective and accountable to our processes as they happen live.

I believe there is absolutely data we’d discover that would and should change our roadmap. To not take the small amount of time to set rudimentary insights and metrics i.e. goals and objectives in such a big part of the work we set out to do over 8 months ago seems akin to discussions seen in this forum around workstreams and KPIs.

I haven’t read that anyone here is communicating we are only successful if a specific number or percentage of users migrate. I do think there is a clear request to start to measure an epic event such as the migration with the best tools available, and read and react to the information we gather. After the conversation that was had yesterday, I reread and do not see any accusations of Product flying blindly here. I do however feel that this is a golden opportunity for agile accountability that is more than fair and appropriate to measure and react to, and is potentially being squandered due to some form of pride, ego, or a ‘stay the course’ and ‘if you build it, they will come’ mantra that I do not believe has the metrics behind it for me to continue to blindly support. We have the ability to start to measure information, our youth or the rudimentary nature of the current measurements should not deter us from still striving for and iterating on our ability to measure and respond appropriately.

18

I believe that:

Native wallet support (sunset this please)

Ledger wallet support

Trezor wallet support

Any chain supported in beta that is not in app currently

are all in need of more measurable metrics before being considered a must have or requirement for a GO for sunsetting Beta from an Operational Perspective, and should be potentially shelved for higher priority work, and measurements that define the demand for these features.

19

Love seeing this important discussion happening in the community and generally agree that we need more data to be testing our hypothesis and then iterating and responding to that data on a regular basis. Without that, will be impossible to ever know if we are heading the right direction or not.

On the discussion around native wallet, I think there is still quite a big opportunity there we are potentially giving up if we entirely sunset it (there are a lot of users, especially on mobile, who have a native wallet at this point) and giving up the ability to “control our own destiny” with the native wallet should not be taken lightly. That being said there are some good arguments for sunsetting is as well if we can come up with other options for users to interact with the platform and shed the maintenance weight of doing that ourselves, though it may limit our options in other ways since we won’t control the roadmap of other wallets. Ultimately I am somewhat neutral on this and look forward to seeing the analysis and discussion on this play out for what the community thinks is best for the DAO.

To respond to some specific points/thoughts made in the discussion so far:

discourse-post-upload20231125-65354-sr9of9.png theoboldfrazier:

My personal views, which may be ignorant of some of the constraints of runway and operation costs, are a bit more long term in the crypto space. I would like us to be a resilient, decentralized, fully featured wallet. I would like to see ShapeShift as a lifeboat in a time of a future centralized crypto reckoning. I fully expect centralized institutions to be attacked and perhaps shut down by the political means. With what we have, we can be the safe haven where crypto users can escape crackdowns on crypto usage.

I think this is a great point about making sure we always build for where the puck is going. Some of the value of what ShapeShift builds may not be readily apparent until some terrible things happen on a macro level, that said we also cannot lose the focus on more immediate PMF and revenue if we want to survive long enough to provide those things the world will need.

discourse-post-upload20231125-65354-zsozg2.png 0xean:

In the coming week(s), we will be kicking off an email campaign to make the first concerted effort to drive users from beta to app. Getting the app to close-to-parity has been the primary focus of the DAO’s work-streams and we have made some assumptions about the user conversion rate we might expect to see once we begin this campaign

this will be a great effort to explore our ability to start migrating users away from beta to the new stuff, though it will remain difficult to get them over and/or measure to the degree many of them are on mobile still and we don’t have a solution on that side yet for those users.

discourse-post-upload20231125-65354-zsozg2.png 0xean:

This data may help us to select the next set of features we prioritize and how much more investment we may make into the remaining minor feature disparity between the platforms. It might even inform how quickly we redirect all users and sunset the beta application entirely. Conversely, It also could show us that we missed some critical piece of functionality that users still require if they were to migrate.

Love the spirit of this, we should always be constantly re-evaluating our assumptions and pushing to use our limited resources where they bring the DAO the most value. What this means may change every few months or even every few weeks, let us not stay static in our assumptions and ways of pushing the DAO forward.

discourse-post-upload20231125-65354-zsozg2.png Tyler:

If we can pour the development cycles into idle finance and potentially shelf it last minute due to product market fit or lack of TVL, I believe we should absolutely look at any and all items on the roadmap with the same level of scrutiny to continuously provide the product we’d like to see in the market, not the one we hoped we’d see 6-8 months ago. Crypto is too fast to not be reflective and accountable to our processes as they happen live.

Totally agree with this, we should always be re-evaluating the roadmap on the fly, staying agile, and adjust as the environment around us changes as well. The DAO should be nothing if not adaptive to stay relevant in the crypto space. Sometimes that adapaption will be uncomfortable but that is no reason for us to not continue to adapt and pivot towards PMF as necessary.

discourse-post-upload20231125-65354-zsozg2.png Tyler:

I believe that:

Native wallet support (sunset this please)

Ledger wallet support

Trezor wallet support

Any chain supported in beta that is not in app currently

These are good assumptions to try to validate/evaluate with further data. I think ledger/trezor is less important to the degree we have other ways for users to plug in those hardware wallets (such as through metamask, xdefi, keplr etc), then we don’t need to support the native plugging in of those wallets necessarily, though we should not under-estimate the need to support those larger HW users bases in some fashion for the growth and TVL we want to see. Metamask snaps in particular would seem to be a great fit here on many levels if we can move quickly on that and lean in on it for our needs.

20

First, I want to say that overall I agree with the sentiment in the letter and appreciate everyone’s perspectives and relentless efforts to ensure ShapeShift DAO succeeds. In a world with infinite things to build, it’s essential that we are thoughtful about everything we prioritize across the DAO, including formulating hypotheses, setting goals, and measuring results.

I do think it’s important to recognize that we are not a new startup building a new product. Over the past 12 months, we’ve been in a transition period to decentralize ShapeShift and rebuild our existing offering as an open-source, community-owned app architected for full decentralization. Along the way, we’ve prioritized a limited set of features outside of this rebuild, but never without thought, and never with the hypothesis that we would see signs of product market fit before the transition is complete or with the limited set of features we’ve added thus far.

While replacing the legacy ShapeShift with the new versions has taken longer than hoped, my understanding is that we are almost there. The remaining list of functionality that we’re considering a requirement for “parity” is short: support for THORChain trading (in progress), replacing the mobile app with app.shapeshift.com (part 1 of 2 complete), and support for the following UTXO and Cosmos chains that as I understand, the heavy lifting for abstractions that streamline supporting these chains is almost complete: Binance, THORChain, Litecoin, Doge, Digibyte, Dash, Bitcoin Cash

Whether the decision to rebuild ShapeShift was the right one could be debated, but at this point, we are so close to being able to sunset beta and redirect all users to app.shapeshift.com, and while we will absolutely track the results of the migration, I am not sure what data we could possibly get prior to this redirect that could influence us to change course. We’ve already agreed that we can defer Trezor, Ledger, and Ripple support, and I’m glad that the conversations around whether or not to continue prioritizing/maintaining Native wallet are in progress.

I love the idea of determining strategic milestones where we actually expect

  1. to start seeing signs of product-market fit, and I think we’re finally getting there. My recommendation is that we focus on completing the migration, track the results of how many users migrate and how they behave in the new app, but not have the hypothesis that we will suddenly see signs of product market fit until we’ve completed some of the following milestones. I do expect each of these milestones to result in user and revenue growth and don’t see any reason why we can’t complete these within the next quarter. If anyone thinks any of these are unattainable in the next 3 months, would love to hear why:

    Support for more EVMs. I thought we would have this sooner and think this is one of the main reasons that we’ve lost users over the past year. Fortunately, we’ve done a lot of the heavy lifting, and as soon as we can add support for more EVMs, we can enable on/off ramping, trading, and yield generating opportunities with minimal additional effort. I would expect to see at least 10% MoM increase in fiat on/off ramps, trade volumes, and deposits into single-sided staking protocols that we support at the time (particularly if we can support them on cheaper networks like Idle on Polygon)

  2. Osmosis trading + support for at least the top 5 Cosmos zones. This is one I’m really excited about because staking is already one of our strongest revenue drivers, and there are few if any apps that enable you to do as much as we will on both Ethereum and Cosmos (buy, sell, send, receive, trade, and earn yield). The fact that this is all open-source, free, and community-owned I think are compelling differentiators that will resonate with the target markets, particularly the idea that by using these services through ShapeShift, it doesn’t cost you any extra as a user, but will generate revenues for the DAO that fund the ongoing development of public goods and also benefit FOX holders. I would expect to see at least 10% MoM growth in assets staked to ShapeShift validators as well as at least 20% MoM growth in trade volumes from this release. I would expect similar growth once we support the ability to LP and bond on Osmosis.
  3. MetaMask BTC Snap support (or even better, multi-chain snap with at least support for Cosmos zones) + THORChain. This is one that I think we can expect 100% if not 1000% MoM growth in total users/revenues. I think it’s worth re-prioritizing whatever we need to to ensure that we at minimum have BTC snap support and BTC/ETH&ERC20 trading on THORChain in time for MetaMask’s release, doing whatever we can to get them to promote us, and doing max promotion on our end.

Always open to other ideas for milestones to aim for and goals to set. To be clear, I do not expect any product market fit until we have completed these milestones, but I do expect that we will begin to see compounding signs of product market fit as we complete the above milestones which I am hopeful are within close reach. Also very excited to finally get Pendo integrated in app.shapeshift.com so we can better understand current app.shapeshift.com metrics, but don’t think we need to wait for that to experiment with various methods of acquiring users and driving KPIs.