the vanishing account / built for Thru Alphanet
Thru Alphanet / account compression

Nothing disappears.
It goes Thru.

An account can leave active validator storage entirely, keep nothing but a single hash on-chain, and still be proven and restored - bit for bit.

Walk the full lifecycle below: create state, compress it off the ledger, verify it still exists with a Merkle proof, then decompress it back. The proof check runs real SHA-256 in your browser, so you do not have to trust this page.

View source
active state36 bytes
state root computing...
36 bytes of live state one 32-byte commitment the whole network agrees on.
00
the idea

State that validators no longer have to store.

Every validator on Thru keeps the current state of active accounts so it can check the next transaction. State only grows, and storing all of it forever is the expensive part of running a chain.

Compression breaks that link. A compressed account is archived off the active ledger - validators drop its data and keep only its commitment inside one global Merkle tree. The root of that tree is the single value the whole network agrees on. To touch the account again, you decompress it by handing back its data together with a proof that it was compressed in exactly that state.

The account did not vanish. Its truth moved into a hash. Everything below is that idea, made touchable.

01
lifecycle

Create, mutate, compress, prove, restore.

Step through a single account as it moves in and out of active state. The panel on the left is its live state and updates at every step.

Create the account

You connect the embedded Thru wallet, approve with a passkey, and the program creates a permanent account with a creation proof. The signer, the fee payer and the managed account can all be different keys - the wallet handles that separation for you.

Give it something to say, then create it.

syscall: tsys_account_create() + TN_STATE_PROOF_TYPE_CREATION
What is real here: the syscalls, the three proof types, the leaf and node hash construction, and the browser verifier are Thru's actual account-compression model. This page runs an interactive model of the lifecycle so you can see it end to end - it does not broadcast to Alphanet. The on-chain version is the C program and scripts in the repo, which you deploy and prove against the live network yourself.
02
under the hood

One account exercises the whole developer stack.

Building this touches nearly every layer Thru ships, which is the point - it is a working read of the platform, not a faucet tap.

ThruVM

The program is plain C compiled to RISC-V. No chain-specific language, close to the metal, aimed at high-compute and high-write workloads.

State model

Permanent and ephemeral accounts, sequence, flags, and creation, existing and updating state proofs.

Wallet

Embedded wallet with passkey approval and a separate signing context, so signer and fee payer need not be the managed account.

ABI and explorer

A published ABI with instruction, account and event roots lets the explorer decode every capsule transaction on sight.