📤Sending Transaction

The flow from crafting transactions to sending transactions is simple using the SDK. The process is divided into four steps:

Creating a Transaction by providing a simple TransactionRequest.
Signing the created Transaction.
Proving the signed Transaction to get the shielded transaction (ZTransaction).
Sending the proved transaction.

Creating Transaction

Signing Transaction

To authorize the created Transaction i.e tx Above, it needs to be signed by the owner. This is as simple as:

Proving Transaction

Now, we need to prove this signed transaction to include the ZK proof in it & hide all the sensitive fields. This, too, is as simple as:

ZTransaction

struct ZTransaction {
    ZTransactionType txType;
    uint16 revokerId;
    uint256 addressTreeRoot;
    uint256 commitmentTreeRoot;
    uint256 feeData;
    uint248[] pubAssets;
    uint256[] nullifiers;
    uint256[] commitments;
    bytes proof;
    bytes[] noteMemos;
    bytes assetMemo;
    bytes complianceMemo;
    bytes targetData;
    bytes refundData;
}

txType: Type of transaction- DEPOSIT, TRANSFER, WITHDRAW, CONVERT

revokerId: ID of revoker used for this transaction. This will enable the selected revoker to decrypt these transaction details, but only once the deanonymisation request has been approved by the guardian network.

addressTreeRoot: Recent Merkle root of address tree.

commitmentTreeRoot Recent Merkle root of the commitment tree.

feeData Packed fee data (20-byte paymaster address + 12-byte fee value)

pubAssets An array of encoded bytes (3 bytes assetId + 28 bytes asset value) for publicly spent assets. If the shielded transaction is coming through the bundler, the fee asset in which the bundler fee is paid to the paymaster, is the first element in this array.

nullifiers Revealed nullifiers of input/spent notes.

commitments New commitments of output notes to be inserted in the commitment merkle tree. This merkle tree holding all note commitments is used to create a proof of inclusion by a user attempting to spend a note on the Veilnyx protocol.

proof Abi encoded ZK proof used to prove the validity of the transaction along with obscuring sensitive transaction details, thus enforcing privacy!

noteMemos Memos for output notes. This is list of encrypted notes' fields for each note and can be decrypted by the owner of the notes.

assetMemo This is empty for non-TRANSFER transactions. For TRANSFER transactions,

this is encrypted assets using sender's key that were transferred to receiver. These can only be decrypted by the sender.

complianceMemo Encrypted compliance data that was created using the compliance encryption key.

targetData Target address (first 20-bytes) for withdraw/adapter concatenated with any required payload.

refundData Refund address (first 32-byte) for public deposit to shielded account concatenated with refund memo.