Skip to main content

Shield

Shielding moves tokens from your public balance into the pool. It is the entrance: everything private starts here.

Shielding needs no zero-knowledge proof. You are depositing tokens you already hold publicly, so there is nothing to hide yet and nothing to prove — the runtime simply moves the balance and records a commitment.

What happens​

  1. You choose an amount and an asset. The tokens leave your public balance.
  2. Your wallet creates a note — the amount, the asset, your owner key, and a random blinding factor — and hashes it into a commitment.
  3. The commitment is appended to the active Merkle tree, and the encrypted note travels with the transaction so your wallet can find it again.

From this point the note is private. Nothing that happens to it later reveals what it holds.

What this reveals​

Shielding is a public action. Anyone reading the chain sees:

VisibleHidden
That your account depositedWhere those funds go next
The amount depositedWhich later note is this one
The assetThe blinding factor
A commitment (an opaque hash)Every future movement

This is the honest trade at the entrance. The deposit is visible; the link between this deposit and any later transfer or withdrawal is not.

Timing is the thing that leaks

Shielding 1,000 ORB and unshielding 1,000 ORB minutes later links the two by amount and timing, whatever the cryptography does. Let value rest in the pool, and prefer amounts that are not distinctive.

Batching​

shield_batch deposits up to 20 notes in a single extrinsic, each with its own asset, amount, commitment and memo. It emits one Shielded event per operation and fails atomically — if any single deposit is invalid, the whole batch reverts.

This is useful for splitting a balance into several denominations at once, which is also good privacy hygiene: a set of round-numbered notes blends into the crowd better than one distinctive amount.