A PCASH account is the durable control point for authorization. Its canonical AccountState commits its identity, installed rules, kind, revision, and receive-key state; a wallet proves that a selected rule approved the exact action without revealing the account, rule, funding composition, or private action meaning.
For youRead this when you want to understand keys, policies, account recovery, or revocation.
Before you startIt helps to know that a payment consumes private inputs and publishes nullifiers.
An Ethereum address creates one user account. That account does not expose a public PCASH balance. Its canonical AccountState commits the address, a private nullifier-key hierarchy, the installed rule-set commitment, account kind, revision, and optional encrypted-delivery key state. accountStateCommitment hashes that complete state under ACCOUNT_STATE_COMMITMENT_DOMAIN; the Account State Tree authenticates those commitments under accountStateRoot. Notes separately commit their owner, while a credit contribution opens the address's public accrual and private debit checkpoint. Spending works only when the proof joins the selected value sources to the authenticated account state.
Account creation is the one bootstrap exception. The Ethereum key signs the revision-1 creation directly; after that transaction lands, the creating key has no standing unless an installed application grants it. PCASH has no separate reset authority. Recovery must already be an installed application capable of authorizing an account update, or the account has no recovery path.
The account is the durable control point
Every real input note opens to one ownerId. A credit-bearing action binds the same user address to the credit leaf, checkpoint, and credit nullifier. The selected AccountState supplies that address and its nullifierKeyCommitment; the kernel combines them into a stable authorizationAccountId and requires every private contribution on the direct path to belong to it.
That identity stays stable when the account's policy set, receive key, or revision changes. It is also distinct from the signing key inside an application: an account can delegate authority or rotate signers without redirecting change to the delegate.
View the source behind this explanationcircuits/libraries/protocol/src/account.nr:19
An account commits an exact program, not a capability label
One policy entry commits three application-owned facts: the canonical hash of an exact 163-field Mega verification key, a configuration commitment, and a blinder. The kernel privately receives the key, recomputes its hash, proves the selected entry belongs to the account's depth-8 rule set, and links that application's result.
There is no protocol flag for “can pay,” “can recover,” or “is an admin.” Those meanings live in the application. A narrow payment rule must reconstruct the payment action it accepts; a deliberately broad rule may approve more. Either choice affects only the account that installed it. The fixed kernel continues to enforce note membership, credit sufficiency and checkpoint continuity, nullifiers, value conservation, asset rules, and the authenticated account.
- Application identity
- Exact Mega VK hash
- Rule-set capacity
- 256 private entries
- Protocol capability bits
- None
- Each action family
- One fixed wire shape
View the source behind this explanationcircuits/stacks/private_value/direct_kernel/src/main.nr:236
Five private fields are the whole interface
- configurationCommitmentwhich private rule configuration
- actionCommitmentthe complete action being approved
- recentPcashBlockHashauthenticated recent context
- authorizationAccountIdthe stable account being authorized
- pcashChainIdthe network replay boundary
private CHONK databus
The actionCommitment is the center of the interface. It binds the complete action supplied by the kernel: a private-value transaction under any private funding composition, a role-separated fee action, or an account update. Distinct action domains keep approval for one role from becoming authority for another.
The configurationCommitment belongs entirely to the application. It can represent a signer, threshold, passkey, recovery condition, or any other private configuration. The recent block hash gives the application authenticated state or Ethereum context; the account ID says whose authority is being exercised; the chain ID prevents cross-network replay.
All five values stay on CHONK's private databus. Consensus learns that the folded proof is valid, not which policy ran, which configuration it opened, or what secret satisfied it.
View the source behind this explanationcircuits/stacks/private_value/direct_kernel/src/main.nr:326
Revocation is a new account state, with a bounded overlap
Old proofs age out with their named block, even if their transaction deadline is later.
A user account update replaces the complete policy-set commitment and optionally keeps, clears, or replaces the receive key. The update proof takes the current policy set, revision, and key material as witnesses, authorizes the exact old-to-new transition with a rule from that set, increments the revision once, and binds a deadline. It opens no state root: the node recomputes the expected action commitment from the account's committed row, so a proof built against a stale or invented current state simply does not match the row and fails.
Revocation is intentionally not retroactive across every recent proof anchor. An action may still prove against a canonical block from before the update while that block remains inside the one-hour recent-block window. Once those anchors age out—or disappear in an Ethereum reorg—the old set can no longer authorize new actions, and a transaction that still names such a block is included as a failure. A transaction deadline does not extend that window.
Removing one slot is not enough when the same policy was installed more than once. The new commitment must exclude every index containing the revoked rule.