It depends. If projects can migrate smart contracts/code from other chains without much overhead and use their existing tooling as well, then yes. Could work the reverse way as well, projects starting on VSC and then being able to migrate to another chain/their own chain later on.
Think of it like building with Lego versus custom blocks. With Lego (like EVM), you can rebuild, reuse parts, or plug into other sets easily. There's a whole ecosystem around it.
But with custom blocks (a custom framework), you're stuck. It might work well in one place, but if yo want to move or expand, you'll probably have to rebuild everything from scratch because nothing else is compatible.
So, ultimately, it’s about flexibility and not being locked in.
That said, there's one thing that makes me wonder:
No, VSC uses the native Hive tokens for all transactions on the network. We plan to launch a token once the project is self sustainable via a fair launch.
Technologies can always be replaced or added under the same cryptocurrency. Meaning, Hive could add native EVM support to its codebase or spin up a separate EVM chain, running under the same cryptocurrency, HIVE. But having an L2 which is supposed to be an extension, then having its own cryptocurrency, where does that leave HIVE?
I'm sure it's all in good faith, it's simply important that the value flows back to HIVE.
Totally agree with you. One way value is flowing back to Hive, which also subsequently pays Hive back for development costs, is our LPs use HBD. What that means is every trading pair locks up some HBD on one side of the pair. As trading occurs a small fee is taken and given to the liquidity providers and system reserve, causing deflation on HBD, ultimately routing back to increase the Hive price. In addition, consensus staking requires locking up Hive. Both of these routes will not be changing anytime soon, even with a long term token in a few years from now.
Our strategy is to build a sustainable network without a token first, then worry about the rest later.