lthn/docs
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update multi-assets-custody-guide.md

Browse source
This commit is contained in:
cryptozoidberg 2025-06-11 15:32:10 +04:00 • committed by GitHub
parent fafc60e540
commit be1ef8b3b8
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/build/exchange-guidelines/multi-assets-custody-guide.md vendored
View file

@ -33,7 +33,7 @@ Thus, the RPC API in Zano is divided into two parts - the DAEMON RPC API and the
Zano is a platform where anyone can deploy their own asset, which will have the same privacy features as Zano itself. Such assets are called **Confidential Assets**. Support for Confidential Assets is reflected in the API documentation and in this manual. Each asset has an identifier (**asset_id**), and only this asset_id identify this specific asset. All other attributes of the asset may match similar attributes of other assets
## Custom transaction generation process and TSS
Some exchanges/custody services have their own frameworks for working with crypto, which implyes custom(manual) building for transactions. This typically works pretty good for non-privacy blockchains, such as Ethereum or Bitcoin with regular ECDSA, but this might be extremely challanging with Zano. As as privacy coin, Zano transaction has quite sophisticated set of proofs and signatures, that is used to secure it. As far as we aware, there is no other implementations of complete process of generating Zano transaction and it's proofs, implemented in languages other than reference implementation in C++ that is used in the wallet codebase. If, for some reason, you still want to implement manual process of creating Zano transaction, please be advised to read this materrials that would help you to understand the math behind this proofs:
Some exchanges and custody services use their own frameworks for working with cryptocurrencies, which require manually constructing transactions. This approach generally works well for non-privacy blockchains such as Ethereum or Bitcoin with regular ECDSA signatures, but it can be extremely challenging with Zano. As a privacy coin, a Zano transaction includes a sophisticated set of proofs and signatures that secure it. As far as we are aware, there are no complete implementations of the Zano transaction-generation process and its proofs in languages other than the C++ reference implementation used in the official wallet codebase. If, for any reason, you still want to implement a manual process for creating Zano transactions, please review the following materials to understand the mathematics behind these proofs:
* Original CryptoNote protocol description(basic concepts of ring signatures and ephemeral keys) https://github.com/hyle-team/docs/blob/master/arch/cryptonote_wp_v2.0.pdf
* Zano original whitepaper(describes the way payload encrypted in tx) https://github.com/hyle-team/docs/blob/master/zano/Zano_WP_latest.pdf