Since July 2026 Platform has a shielded pool. Credits go in as Orchard notes, and from then on the amount, who sent it and who holds it are hidden. What stays public is the pool's total, its note count and its anchors. This page reads the public part, on both networks.

Two pools

Balance, notes, anchors and protocol come from the chain through the SDK. The transition counts come from pshenmic's index. In minus out on the index runs a touch above the chain's balance: the fee of a pool-paid move is carved out of the notes and never shows up as an out.

In and out, week by week

into the pool out of the pool
MoveTypeCountAmount

The pool and the price

The chain knows what the pool holds. It has no idea what a DASH is worth, so the price here comes from an exchange, one close a day, and is lined up with the index's daily buckets. Both lines have climbed since July, which is the trap: two rising lines always correlate. The arithmetic below asks the narrower question that can actually answer something: on a day when more went into the pool than came out, did the price move with it?

pool balance DASH price
Correlationrp

What a price move does to the pool

The day-to-day figure above finds nothing once volume is out, and that is an artefact of the bucket: one day holds both a rise and the selling into it, so the two directions cancel before they are counted. Every transition is stored here with the block it landed in and the price at that block, so the same question can be asked per hour and with the two directions kept apart. Below: after an hour that moved the price, how much DASH went into the pool and how much left over the next six hours, against the same six hours measured from hours picked at random.

After an hour that movedtimesinoutin : outp

Where the price stood when credits moved

Every transition sorted into a five-dollar band by the price at its block, counted the same way as the table above. Read it as a description, not a trigger: over ten weeks DASH visits a level once, so a band and a date are the same fact here. It takes a price that comes back to tell them apart, and the file keeps growing.

The six moves

Every shielded transition carries an Orchard bundle: at least two actions, each a spend paired with an output; an anchor into the note commitment tree; one Halo 2 proof; and a binding signature. What differs between the six is which side, if any, is transparent.

Public

  • the pool's total balance
  • how many notes it holds, and each note's 216 encrypted bytes
  • the anchors: roots of the commitment tree, kept for 1,000 blocks
  • every nullifier once spent, so a note cannot be spent twice
  • on the way in and out: the transparent side, its amount and its address

Hidden

  • who a note belongs to
  • what it holds
  • which note a spend consumes: a nullifier does not point back
  • the 36-byte memo, encrypted to the receiver
  • a shielded transfer as a whole: no identity, address or amount in it

Is this a shielded address?

A shielded address starts with dash1z on mainnet and tdash1z on testnet: 43 bytes, an 11-byte diversifier and a 32-byte key, behind a type byte and a bech32m checksum. The check runs in this page and looks nothing up. There is nothing to look up: an address never appears on chain. A note is encrypted to it, and only the viewing key finds it back.

An identity straight out of the pool

Using it today

The pool is written to from Rust. These ship it:

Not here, yet. The JavaScript SDK reads the pool and nothing more: creating a shielded transition needs the Orchard prover, and putting Halo 2 into the WASM bundle adds ten megabytes and a proving design of its own, so the SDK team left it out on purpose (dashpay/platform#3235). Every number on this page is a read. The explorer has the same reads with proofs on, and a nullifier check.