Why Polygon support was removed?

For a while there was an impression that support for payments on Polygon was added then removed. Why ?
Polygon works pretty well and is already and is well established and have support from several Wallets.

zkSync Era is still newer and may have some particularities that may not be desired to be used by many. Swapping from it to Ethereum network isn’t the same as using any DeX or swap platforms available.

Why choose zkSync Era only and not Polygon ?

Reference :point_down:

Now you may be tempted to suggest some other payment method so please read this FAQ

5 Likes

Hello

I have read both thread previously but it doesn’t explain why Polygon was dropped and could not continue in paralell with zkSync

There was very little demand for using it by SNOs during the time when we did offer it as payment option. Maintaining alternate payment options is extra work for Storj, the polygon usage did not justify the extra effort.

2 Likes

Perhaps then Polygon should replace zkSync-Era as it is much more popular and easier to swap tokens and do bridging

2 Likes

yep, this only confirm your believe. Out of

and

If you promote one over the other it will be more traction in the beginning. Wasn’t zkSync payments available before Polygon ?

1 Like

Why we need to promote the (foreign) Polygon, if we accept zkSync Era both for payouts and payment methods?
Especially when there was only 35 adopters from thousands?
zkSync was available before a Polygon, yes.

1 Like

@Alexey that’s not what I meant.
What I said is that at that point zkSync has been the Storj Management preference so it is natural that people see and use it.

Plus at the point Polygon had that number number o payments it wasn’t as popular as it is today, and despite Storj preference for zkSync, Polygon is nowadays more widely adopted and preffered, and that means easier for both node payouts and customers.

2 Likes

As far as I understand (and I’m in no way an expert on this) between the two, zksync is clearly superior choice.

  • zksync is, well, Zero Knowledge, and inherits erherium security. To compromise it you have to also compromise etherium
  • polygon operates on its own blockchain with their own set of validators. Transactions are validated on this side chain and then proof is submitted to etherium. Risk of compromise of enough validations that can lead to fraud is much higher than that on etherium.

The only benefit of polygon was cost, and, like with storj, race to the bottom on price is rarely a good thing in the long run.

1 Like

No, it is not that clear. It is may be just your understanding.
zkSync may be a good solution, but it is not near known and used it is Polygon now a days. Due that it has a broader number of users, DeX with liquidity pools to swap tokens, over USD 2B+ TVL. zkSync Era although promising higher transaction rate and other features is still growing with a USD 450M+ TVL and les transactions per day than Polygon.

The fact that Polygon operates its own blockchain isn’t any worse for the context here. What matters at the end is that it has a high transaction rate capacity and transfer fees are cheap. Putting that risk or compromise to Polygon is the same as if you are crossing the road and be smashed by a car, so just a very hypothetical as in any other blockchain.

The initial discussion was why Polygon was dropped and also why zkSync was the preferred one by Storj Management. Was there any benefit to the corporation or partnership agreed at the time or was it just an evalutation between the both at the time that ended up to zkSync as preferred ?

Correct. I feel zksync is a better engineered, cleaner solution, that does not introduce unnecessary complications.

It was pointed out above, that most storage node operators agree with me in preferring zksync, regardless of reasoning: Support for polygon was added, did not receive any traction, and was subsequently dropped. That’s the sufficient reason.

Why zksync was chosen in the beginning — polygon did not exist when decision was made. See Alexeys comment above.

So does zksync. And transaction rate is entirely irrelevant for storj usecase

Liquidity is a problem, yes, but that’s because there is no incentive to use zksync today. As long as storj is paying gas — why should SNO jump through hoops with any L2 solution?

I myself started with zksync and then switched back to L1.

1 Like