Fees and remaining balance

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

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.

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 for valid bundle shapes and Contract events for settlement evidence.

Overview

Private balance

Amounts and exits

Fees and remaining balance

Value equations

Worked example

Why a fee change needs a fresh proof

After settlement

​Value equations

​Worked example

​Why a fee change needs a fresh proof

​After settlement

Value equations

Worked example

Why a fee change needs a fresh proof

After settlement