For the time being 16, but we need to perform benchmarks and testing internally to decide on the final size.
James W:
I tried the testnet app some time ago and it took roughly 3 min or so to calculate the „deposit“ proof in the GUI. I noticed it was single threaded though, is that on purpose / limited by the browser interface?
Neo:
Yeah it’s kinda limited by the browser because browsers are single threaded by design.
James W:
16 sounds reasonable.
Neo:
Yeah it does, but we need data to confirm it.
James W:
And rolling up 16 tx should take, let‘s say 1h?
Neo:
No not really, it should take like 10/15 mins. The publishers are meant to be running on heavy resource machines, not web browsers.
James W:
Could be tricky in terms of UX. If users walk away and miss the metamask pop up for confirming the tx for example. Would it be possible to show a loading bar in % completed?
Neo:
It doesn’t really matter because the proof will be saved in your browser and you can submit on chain whenever you want. If you miss the metamask pop up you can just submit again in seconds.
James W:
Well if you know you know. I can understand and appreciate the strategy to reduce gas fees for a zk tx to a minimum level, and maybe come down to or even beat a token ERC-20 swap tx on uni. However it looks like users will have to compromise significantly on the UX side:
2-10(?) min of local proving time (consider users on mobile devices)
15 min rollup time
vault stored locally and not on chain
and I‘m not sure if a potential „average“ protocol user is a) expecting and b) willing to accept those drawbacks.
Imho I rather would pay a higher tx gas fee, knowing that my zk tx is reliably pushed and stored on-chain.
The improvements of v2 (zkXFT, arbitrary amounts, no fixed ETH deposit) w/o all the above compromises are speaking for themselves alone.
Neo:
The ability to store utxos on chain is gonna be there, users will have the ability to opt out of it. And really there’s always a compromise with everything. Monero’s UX is very similar to ours though you can look at their marketcap.
James W:
Will the on-chain vault look the same as the current testnet? Or do I have to dig out single deposit notes?
Neo:
The notes are just data and can be represented in any way or form. What do you mean by dig out?
James W:
So the current testnet shows the zkXFT balance for the connected wallet. Which is great btw 👌 Will the on-chain note storage look similar to this? Or will it be like zkXFT deposit A - 2000zkXFT left zkXFT deposit B - 20zkXFT left and so on. You know what I mean?
Neo:
Yeah it’s gonna be one thing. That’s the point of the v2
James W:
Awesome.
Neo:
The process you can imagine is very similar to how any btc wallet works, anyone in crypto is very familiar with that process. And we are working on a refined UX strategy that focuses on using already common methods in the ecosystem.
Mugi:
The end goal here is to have something that just feels self explanatory compared to our v1 release. The goal is to have a user experience that doesn’t need a tutorial or explanation, not to say that we won’t have any tutorials for v2.
James W:
I probably would not second „anyone in crypto knows this“😁 but I understand your point and how the UTXO protocol works👍
Neo:
What do you mean really with this? To buy xft you need ethereum. Our entire target community is ethereum users, they pretty much understand how to use metamask and send ether or erc20 tokens.
James W:
Yeah right but probably not that the zk tech in v2 is UTXO based
Neo:
The zk tech and the UTXO are backend. The point of UI/UX for users to not have to deal with that.
February 6th
UniswapV3’s Swap Router will be used to give users the option to swap withdrawn XFT for Ether to fund the new address. To prevent abuse of this feature, the team is exploring a burn percentage that will lead to a net reduction in XFT supply. The community was surveyed in a poll on X to determine their preferred percentage.
This leads us to the following poll question: In your opinion, what would be an optimal burn percentage for those opting to use the swap router functionality? Comment below with specific percentages.
In relation to the above, the community and devs had the following conversation:
L
01:50
Blobbybobman
when it comes to @nXoFoTb post. what pros and cons does the team see in their assessment of the burn percentage?
SV
07:17
S V
might be 2 dumb qns but:
07:18
1) who pays the gas for the univ3 swap of XFT into eth (and is it swapped in the receiving wallet or before it is sent to the receiving wallet - in which case where is the swap happening
07:18
2) what is the “abuse” of this feature that is being referred to - ie without this burn what could a bad actor do
07:18
in general would help if team dumbed it down for laymen lol
J
09:10
James
09:14
will the XFT / ETH swap on protocol side be done in batch mode?(=combine several withdraw transactions to ETH in an atomic uni swap tx). meaning that users would be able to save some gas fees vs. doing it own their own in the fresh wallet.
if so, probably a 5% fee is justifiable.
J
09:29
James
would there be a limit to the amount of ETH that‘s withdrawable?
It ultimately becomes a question of cost-benefit to the user. Does the reduced XFT mint and higher withdrawal fee (due to higher gas used to swap) justify using the feature? Of course we cannot answer this until the protocol is live, but this poll is a way to gather user opinions beforehand.
This feature will be a part of the publish function, and the gas will be paid by the publisher. Gas will be recompensated in the form of XFT minted upon withdrawal to the publisher. In the mempool, publishers can create a fee market by choosing or not choosing to roll up transactions that satisfy their fee demands. And users can likewise decide which publisher to use based on publisher fee rates.
One potential scenario would be a price fluctuation in XFT leading to publishers not being sufficiently recompensated in fees to justify publishing batches.
This is possible, but may not be worthwhile. An immediate downside for the withdrawals included earlier in the batch is that it would lead to a smaller ETH return because the later transactions would lead to a lower average XFT price. Calculating out exact prices is also possible, but will lead to higher gas usage and thus a higher withdrawal fee for the publisher.
I don‘t get it. Is the publisher fee paid in XFT or in $ (in XFT)? From your comment it‘s rather the first option, but that would be quite volatile and not very straight forward to determine?
It would be the former, and while it is subject to price volatility it is not necessarily difficult to calculate. Gas usage can be estimated depending on the operations performed in a withdrawal, and XFT price in Wei can be fetched from Uniswap, or even from an oracle that does TWAP such as the one used for v1. Chainlink also provides a gas price oracle so all the necessary components are available to calculate a publisher's fee in XFT. Publishers can use their own calculations if they find that it is more competitive to do so as well, since all the necessary values are available publicly on-chain.
agree on the calculation part. I also assume that the UX will give a smart estimate / proposal where the user just needs to approve.
However there‘s still the volatility aspect. I am thinking about a scenario where there‘s significant XFT price movement between tx queuing event (where publisher fee will be determined, right?) and actual publishing time. So the publisher fee - if paid in nominal XFT - could be significantly less/more worth at publishing time. Or what do I get wrong?
With the current implementation, it could be solved by having queued transactions overpay the publisher fee and issuing a refund of the remainder, or by the publisher waiting for a time with lower gas prices. We have a new implementation in mind that would address the queue/publish lag, but it is still in development so I don't want to discuss it just yet.
For example, if a user withdraws 100XFT and uses the swap router feature, with a 5% burn, the user will receive 95XFT which will then be swapped for WETH.
wouldn’t it be possible to open a small ETH side pot and pay them in ETH right away?
n
22:34
n00b
This would only work if all transactions were done in the contract queue. Private transfers and withdraws cannot send ETH because they will be sent to the publisher via mempool, not the on-chain queue.
