PCASH applications are private circuits folded around fixed protocol kernels. A contract is an immutable, keyless account that commits callable applications—not bytecode executed by every node.
For youRead this when you want to build rules, contracts, escrows, claims, or Ethereum-grounded applications.
Before you startYou should know that accounts install exact authorization applications.
An application answers a narrow question: does this private witness authorize this exact action for this authenticated account? It can check a signature, threshold, secret, schedule, prior PCASH state, or an Ethereum fact. Then the protocol kernel independently proves note ownership or credit sufficiency, conservation, nullifiers, output construction, and every account join.
This split is the safety boundary. Application authors can define new conditions without getting a hook into consensus code. A permissive application weakens only the account that committed its exact key; it does not weaken the ledger.
CHONK hides variety behind one verifier
The proving stack has four jobs. The selected application evaluates private policy. A protocol kernel authenticates its exact Mega verification-key hash and enforces the transaction relation. A family finalizer accepts only pinned kernel identities. A wire circuit exposes the transaction type's ordered public inputs.
Consensus verifies the compressed result against one pinned wire key. It does not receive the application key, configuration, selected account entry, internal action fields, or application witnesses. Adding a more elaborate condition changes the prover's work, not the public transaction shape.
- Application interface
- 5 private fields
- Consensus artifact
- 1 compressed proof
- Node-executed app code
- 0
- Public app identity
- Hidden
View the source behind this explanationcircuits/stacks/private_value/wire/src/main.nr:4
A contract is an immutable account with functions
- Nullifier-key material
- Optional receive key
- Ordered function entries
A contract account has no signing key and cannot be updated. Its address derives from its nullifier-key commitment, complete function-set commitment, receive-key state, and nullifier-root publication mode. Creation publishes that identity once in Ethereum data availability.
Each function is the same object a user account calls a policy: an exact application-key hash plus a configuration commitment, stored at a selector. Calling a function means proving its entry under the contract account and folding the application into a protocol kernel. The selector, application key, and call condition remain private in the final proof.
There is no PCASH virtual machine, public method call, mutable storage dictionary, or contract admin. A contract holds private notes. Its committed functions define the only conditions under which those notes can move. A marketplace, escrow, or distribution flow is therefore a sequence of authenticated note transitions, not a shared program stepping through public storage.
View the source behind this explanationcircuits/libraries/protocol/src/account.nr:78
State lives in notes and accounts, not inside a VM
Suppose an escrow contract owns an asset note. One committed function may let a buyer claim it after proving payment; another may let the seller reclaim it after a deadline. Either successful action consumes the current note and creates successor notes. The next action starts from those new notes.
That construction makes transition authority explicit. Nothing silently mutates between calls, and nodes never execute arbitrary application bytecode. If an application needs an instance to be distinct, its committed configuration or nullifier-key material must make that identity distinct from the start.
Applications can prove one Ethereum event
Every PCASH header commits an accumulator of canonical Ethereum block facts. Each Ethereum leaf binds the block identity, timestamp, normalized-log root, and log count. An application opens one block beneath a recent PCASH header, then one depth-64 normalized log beneath that block.
The log has a fixed shape: emitter, ordered topics, and data. The application interprets those fields—for example, requiring a particular contract, event signature, recipient, and amount. Unrelated receipt structure and unrelated logs change the Merkle path, not the application circuit's input shape.
This is grounding, not an oracle. PCASH authenticates that the event appeared in canonical Ethereum history. The application remains responsible for deciding what the event proves and binding it to the exact PCASH action.