@james_katz @elijahhampton @Edicksonjga and especially @Juanky are the folks to thank!
![]()
![]()
![]()
It was a pleasure to help in the launch of this first version.
Need some help getting this to run. I’ve tried both the appimage and .deb files with similar results.
System info:
We had some problems with linux Mint but we thought these problems are not general… But were wrong. Thanks for testing & we are working on this for the next release that it will be soon… Sorry about that.
Ideas on how to implement zip-317 to Zingolib
I’m pretty sure Zingo Labs guys are already working hard to make Zingo! zip-317 compliant, but here are my ideas on how to do it in a way that needs very little changes to the current code. unfortunately I know jack about Rust, or I would implement it myself.
Even though I can’t code in Rust, I can follow the overall logic of it, so I have a basic understanding of Zingolib architecture, here is my idea on how zip-317 could be implemented:
First of all, in commands.rs add new command called GetConventionalFee this command will be called by Zingo-PC using zingolib_execute through native.node neon binding. GetConventionalFee will accept a tos json object containing recipients and amounts to send. This function will call GetNotesAndFee function described below.
In wallet.rs move all note selection logic from send_to_address_inner to a new function called GetNotesAndFee.
Function GetNotesAndFee will receive a list of recipients and amounts, calculate the target_amount and return orchard_notes, sapling_notes, utxos, target_amount, selected_value and zip317_fee. The zip-317 fee can be easy calculated since we know the inputs (selected notes) and outputs (recipients).
In commands.rs edit SendCommand to accept orchard_notes, sapling_notes, utxos, target_amount, selected_value and zip317_fee as extra arguments and call lightclient.do_send function with those arguments, e.g. lightclient.do_send(tos, orchard_notes, sapling_notes, utxos, target_amount, selected_value, zip317_fee).
In lightclient.rs edit do_send function to accept previously mentioned arguments. Now the function do_send will call wallet.send_transaction with these extra arguments.
Again in wallet.rs edit send_transaction and send_transaction_inner to accept all these extra arguments. send_transaction_inner will construct the transaction using the selected notes, amounts and fee received as arguments.
Putting it all together:
- User wants to send new transaction and fill up To and Amount on Send screen of Zingo-PC.
- Users click Send Button. Zingo-PC will call
zingolib_execute("GetConventionalFee", tos)– Heretosis the recipients and amounts to send. GetConventionalFeewill callwallet.GetNotesAndFeeand will receive the selected notes, target amount, selected value and zip-317 fee.- Zingo-PC will display a modal displaying the zip-317 fee and will ask for confirmation.
- When user confirms the send, Zingo-PC will call
zingolib_execute("send", tos, orchard_notes, sapling_notes, utxos, target_amount, selected_value, zip317_fee) - Command
SendCommandwill calllightclient.do_sendwith received arguments. - Lightclient
do_sendwill callwallet.send_transactionwith received arguments. - Wallet
send_transaction_innerwill build the transaction with received selected notes and fee.
I don’t know if I expressed myself cleary, or if it makes any sense … but in my mind it makes sense.
This is the key function. Fees depend on the inputs and outputs, therefore there is a cyclic relationship. Throw in multi receivers uas and it becomes fairly complex.
Any plans on a new release with a release build? People seem interested and they will have a very negative impression of the performance…
We are working now in a new & better sync process, I think we will release both apps with the new sync feature ASAP. Thanks. And we need to resolve the linux problems as well…
I just uploaded a new binaries for linux, can you, please try again the same process with the new binary??? I would really appreciate it. Thanks.
That’s good news, thank you so much.
We created a new pre-release version v1.0.1 including our new zingolib feature using shardtree to sync, we are already testing it so we consider this experimental…
I’ve just opened Zingo PC 1.0.1 and it’s showing me a much higher balance
, all in the Sapling pool. I also have the account on Ywallet and it’s showing the correct balance (i.e. I don’t think anyone sent me a lot of ZECs by accident
). I’ll try rescanning
Yes, I noticed the same, it seems like the old promotions from sapling to orchard have no effect now. This is a Bug in the new sync feature affecting to the balance. Well, this version is experimental, Thanks for testing and maybe it’s better to use the stable version 1.0.0, it’s up to you…
Yep, I understand, just making sure it got reported, glad you’re working on it. Thanks!
Hello @zancas! Has anyone besides me tried to sync zingo PC with an initial phrase over 4 years old? My result on macOS is that the entire balance of incoming transactions was summed up by the total cumulative amount and it ends up displaying incorrectly as a large number. In reality there are hundreds of times less funds in the balance.
That’s very interesting, have you attempted a rescan? Ywallet is also available on Mac OS as another option to attempt if you dont have any luck with zingo
Thank you! I’ve only done one scan. Actually there is no problem, I use in parallel all possible platforms from one seed-phrase, more for testing purposes. Because I have to make recommendations myself in Russian-speaking communities and it would be strange if I was lost with that. It’s more of a feedback.
Thanks @artkor we’ll look into this!
Which version are you using? There is a bug in 1.0.1 which is experimental, I had a similar issue as reported above.


