> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nullark.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Fees and remaining balance

See how Nullark calculates a withdrawal fee and why an unspent sibling stays available without creating private change.

The deposit template creates every child note up front. A withdrawal spends one child, sends its net value publicly, and leaves any sibling untouched.

## Value equations

```text
parent deposit = child 0 + child 1
gross withdrawal = selected child amount
fee = floor(gross withdrawal * feeBps / 10,000)
recipient amount = gross withdrawal - fee
```

No value is split during withdrawal, and the pool inserts no new commitment.

## Worked example

A `1 ETH` bundle can contain two `0.5 ETH` children. With a fee of `33` bps, withdrawing one child produces:

| Term | Value |
| --- | ---: |
| Gross child amount | `0.5 ETH` |
| Fee | `0.00165 ETH` |
| Recipient gets | `0.49835 ETH` |
| Unspent sibling | `0.5 ETH` |

The sibling was committed during the original deposit. It needs no new recovery payload or tree leaf after the first withdrawal.

## Why a fee change needs a fresh proof

The fee is a public proof input. The client reads it before proving and again after proving. If the live rate changes, the prepared statement is stale.

> **Warning:**
> Discard the stale proof and prepare the withdrawal again. Do not loosen the user's maximum fee or minimum received amount to force submission.

## After settlement

Match the successful `Withdrawal` event against the selected child nullifier, destination, gross amount, fee, net amount, and encrypted payload. Then mark only that child spent. Any sibling remains in the restored bundle inventory.

See [Fixed denominations](/concepts/fixed-denominations.md) for valid bundle shapes and [Contract events](/reference/events.md) for settlement evidence.