# Sending Transaction

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

1. Creating a `Transaction` by providing a simple `TransactionRequest`.
2. Signing the created `Transaction`.
3. Proving the signed `Transaction` to get the shielded transaction (`ZTransaction`).
4. 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

```solidity
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.

### Sending Transaction

```solidity
function transact(ZTransaction memory ztx) external;
```

But before passing the TypeScript object `ZTransaction` to `transact` you have to convert it to input suitable for the contract. Doing so is as simple as calling `ztx.toSolidityInput()`.