The first 2 are definitely not representative. Those addresses are in very active use and have a Storj balance. You can forget about those. Your binance deposit address will only have a Storj balance if you have already transferred Storj to it that same day. Which… at that point you clearly don’t care about transaction costs.
I can’t explain the difference for the other 2. All I can say that my transactions of Storj to binance have always cost me 51,496 gas. Maybe someone else knows what the difference is.
@hoarder: Is this actually what you pay for your own transactions or are you just looking at random transactions on the blockchain? I would like to know where the difference comes from.
I think I’ve figured it out. It’s cheaper if you transfer your entire token balance, bringing it to 0. I’ve always transferred just part of my balance. I did some testing and see that metamask suggests different gas limits in those two scenarios. So I’m pretty sure that explains it. That’s good info to have I guess. So, transferring part of your balance 2.3% more expensive, transferring all of it, 44% more expensive.
So I guess you get lowest gas if you transfer the whole balance to address with token balance, 36k if you transfer whole balance to an address with no token balance or you transfer a part of your balance to an address with existing balance, and 51k if you transfer a part of your balance to address that has no token balance.
What happened to the idea to enable SNO‘s to trigger a payout manually (L1)?
I remember that many people here in the forum already mentioned that they would only trigger the payout every few months, so STORJ could save a lot of fees with this easy to implement feature.
Of course the minimum payout threshold should also be applied there.
Currently my payout wallet is my Binance.US exchange deposit address so I can go straight to selling the coins. It doesn’t look like Binance.US supports ZKsync for this unless I just don’t know where to find that info.
I don’t know how you guys pick the time to send the payouts, but I’d think a lot could be saved by just setting a limit on what you’re willing to pay on fees. example if the average gwei for transactions over the last month was 100 that would be the absolute upper limit of what you should pay and just wait for it to come down otherwise. I don’t think there is anyone out there using this as their primary means of income who would be destroyed by waiting a couple days or a week for more reasonable gas fees on ETH. I would probably choose the 30% point of fees over the past month and just look for the market to hit that to make the payouts. In the example of 100 average that would be 2 x 100 x 30% = 60 gwei.
I think loosening the payout schedule and just working it around the fees would be something worth floating out there and see if there are any operators that object. I find it fairly unlikely that we’ll see much push back on that.
When the crypto market tanked a couple of days ago, wouldn’t that have been the right time to do some transactions? Current Gas price is showing prices as low as 44 Gwei.
That brings me to the question, why Storj Labs is sticking to such a strict payout regime in an environment that fluctuates dramatically.
One of my ideas would be an implementation that tries to send out outstanding balances every single day. So this would mean to let’s say finalize balances during the first week of a month, and after that check Gas prices every day and send out all balances that meet the minimum on that specific day. Or better check twice a day or three times a day.
What I don’t understand is that payout has to be completed around the 15th, throwing literally half a month away of chances, where the Gas price could fall, like it just did which would have seemed (and still seems) to be a great chance to settle some outstanding balances. @jtolio
There’s one key problem with the whole transactions piece: the payout deadline. They always aim for the first 2 weeks (might be 15 days, but I seem to recall 2 weeks) for payouts (and they had people complaining about the variance and delays even with 2 weeks for crying out loud). Because the amounts are calculated right before the payout, that creates a gradient that is very likely not optimal for paying out people. Hence why it’s easier to either hold onto the earnings until they exceed the required threshold OR payout via L2. Say they pay out on the 8th of the month for those with high enough balances for payout as an example. Now let’s say the token price at that time is 1.52USD. On the 18th, the gas price drastically drops allowing STORJ to pay out more people. But on the 18th, the price is 1.84USD so those paid on the 18th get less tokens. Ultimately, it’s the same USD payout amount, but unfortunately, the number of tokens is what quite a few people focus on rather than the overall value. Not to mention that you’d be forcing Storj to do that calculation over and over to see if the 25% threshold got hit for anyone else. Not exactly a productive solution in all honesty especially with how quickly the gas price can rise or fall.
How is that relevant for Storj Labs. They always claim to pay USD value in tokens. So Storj value does not matter to them and should not matter to the recipients.
You would be correct in that assessment. It shouldn’t matter. But it does to some people unfortunately. The primary problem is the unreasonable expectation for Storj to check to see if held earnings due to transactions fees can be paid out later in the month and then have to recalculate the new payouts in tokens. If they want 2 weeks to do the once a month calculation and payout those who qualify, it’s not reasonable to expect them to process that on a dime when the gas price gets low.
For the same reason as for remained 100500 other blockchains: we have no plans to switch blockchain.
If they can offer a good solution as zkSync, will accept STORJ tokens and there is enough operators who would subscribe to the option - then it could be possible.
? You wouldn’t need to switch, Polygon supports ERC20 tokens, you just need to set them up. Sure, to get back on Ethereum requires bridge but HODLers could weigh up and make their own decision if you offered incentive.
It would be nice, if you can do that. We have no devs to deal with other blockchains instead of implementing features for the customers.
Please understand, the blockchains and tokens are the last things which would be in our list. Our main product is offering object storage, not blockchain-related functionality.
Even zkSync support was implemented when fees on Ethereum become a real problem. However, all needed functions was implemented by Matter Labs. We just send to their API a list of addresses and deposit tokens to disperse.
If Poligon is able to do similar - it could be added as a supported method for payouts.
We do not want to spend time on implementing functions in other blockchains - it’s out of our scope and goals.
Add my $0.02 after one of my tokens jumped from Ethereum mainnet to Polygon…
I highly recommend Polygon. The network uses the same Ethereum address… so no changes need to be made in Storj Operator configuration. Just change to polygon network in Metamask and many tokens are available for trade on numerous DeFi platforms… including wBTC and ETH.
After using Polygon for awhile… I can’t wait until the Ethereum 2.0 PoS merge supposedly coming in Q2 2022…
Is there an API of the bridge between ETH and Polygon?
We would not like to spent time on implementing functions for blockchains rather functions for our decentralized cloud storage.
If there is an API to help to distribute tokens as it happen with zkSync, this method could be added as a wallet function.
I had some Axion tokens which jumped for Ethereum mainnet to Polygon. I would imagine the Axion team might give hints on modifying the token contract. They paused the Ethereum based token and air dropped Polygon tokens to each holder address along with about $0.10 in MATIC.
Disclaimer: This post is not investment advice. I’m not advocating Axion… or their token…
Using the wallet as a bridge assumes that we need to implement all functions/scripts to send tokens on foreign blockchain. We have no plans to implement functions for blockchains.
There should be similar API, as zkSync do. In simple:
deposit/import tokens preferable via API
provide a list of addresses with amount to the API
call the send function
all the hassle with transfer fees, guaranteed sent without double spent must be handled by that API
The Polygon is look like an ETH fork (I did not dive into details of implementation), so everything should be implemented with the same or greater involvement as on ETH. We doesn’t have a capacity to implement such a functional.
But we can use a ready one if it exist.
In zkSync the cost of every transaction has two components:
Off-chain part (storage + prover costs) : the cost of the state storage and the SNARK (zero-knowledge proof) generation. This part depends on the use of hardware resources and is therefore invariable. Our benchmarks give estimates of ~0.001 USD per transfer.
On-chain part (gas costs) : for every zkSync block, the validator must pay Ethereum gas to verify the SNARK, plus additionally ~0.4k gas per transaction to publish the state ∆. The on-chain part is a variable that depends on the current gas price in the Ethereum network. However, this part is orders of magnitude cheaper than the cost of normal ETH/ERC20 transfers.
So, zkSync seems to fulfill your requirements closer than Polygon. The STORJ tokens remain on Ethereum mainnet.
It’s a shame that Ethereum 2.0 has taken so long… looking forward to The Merge.