# PCASH: Ethereum-Native Private Money # Abstract Using Ethereum today publishes your financial life: who paid whom, how much, and how those payments connect over time. Conventional finance does not publish everyday payments by default. PCASH is private money for Ethereum. Every PCASH node computes the PCASH ledger from Ethereum's own history, so there is no operator, sequencer, or upgrade key, and no smart contract holds anyone's funds. Each payment carries a zero-knowledge proof: the network checks that the payment is valid without learning the sender, the recipient, the amount, or anyone's balance. PCASH exists only in private form. There is no public version to deposit or withdraw, so no user's privacy depends on how much capital other users keep inside a pool. PCASH starts at zero. New PCASH, up to a cap of one billion, is issued for successful payments and asset transactions, to whoever publishes each one or to a destination it names. Accounts choose their own spending rules, contracts with permanent rules make escrow and custodian-free trading with ETH possible, and anyone can create a private fixed-supply asset. # Part I — Why PCASH ## Ethereum as the Base Layer Ethereum is the strongest foundation available for open, neutral, internet-native money. It has deep economic security, resists censorship, lets anyone participate, and keeps a widely replicated history. It suits public financial activity well and private payments poorly. A salary paid on-chain can reveal compensation to landlords, counterparties, and data brokers. A rent payment can link an address to a home. A purchase can connect identity, balance, and shopping history in a way no bank would publish. Privacy is part of what makes money censorship-resistant and safe to use. It is not a feature at the edge of Ethereum's mission. Ethereum needs a standard form of private money, and PCASH is designed to be it. ## Problems with Existing Approaches ### The Smart-Contract Dilemma Most private money on Ethereum so far has been a smart contract. Tornado Cash and Railgun are the best-known examples. A contract has to choose between being immutable and being upgradeable, and both choices cost something. An immutable contract, like Tornado Cash, cannot fix a bug or replace aging cryptography. The only way forward is a new contract, and moving to it forces users out of the old anonymity set, which damages the privacy the system exists to provide. An upgradeable contract, like Railgun, can fix bugs and adopt new cryptography. But whoever controls upgrades controls the system, so its security rests on a governance process or a small group of keyholders. Either the system can change only through a disruptive migration, or someone holds the power to change it. ### The Public–Private Asset Problem A shielded pool built into Ethereum itself would avoid the contract dilemma. It would still have a second problem: its privacy would come from public ETH that users deposit and leave inside. Every user's privacy would then depend on other users keeping their money shielded. Each withdrawal shrinks the anonymity set for everyone who remains, and a smaller set gives the remaining users less reason to stay. The pool has to keep persuading people not to leave. In effect, it rents its anonymity set from the capital inside it. Zcash shows the limit. Even on a network built for privacy, only a minority of the supply is shielded. When privacy is optional, the private set grows only as large as the amount of money people are willing to keep there. ## What Is PCASH? PCASH is a separate blockchain whose state is computed from Ethereum's history. It has no consensus mechanism, validators, or sequencer of its own. Ethereum orders PCASH transactions and makes their data available, and every PCASH node applies the same rules to that history and arrives at the same state. Because PCASH is defined by rules for reading Ethereum rather than by a smart contract, it has no contract administrator and no upgrade key. Its rules change only when people choose to run new software, the way Ethereum's own rules change. PCASH is private-only. Value is held in private notes. The network never learns who owns a note, and it learns a note's amount only for the payouts that fees and issuance create. There is no public PCASH token, no public PCASH balance, and no way to redeem PCASH for ETH through the protocol. That is deliberate. A redeemable public form would bring back the pool boundary, and with it the dependence of every user's privacy on capital staying on the private side. PCASH still connects to the rest of Ethereum economically. People can sell PCASH to each other for ETH through escrow contracts that release the PCASH only to a buyer who proves payment. No bridge operator or custodian is involved, and the price is whatever buyer and seller agree on. Two choices let the anonymity set grow without renting capital. Joining takes one Ethereum transaction to register an account, and no deposit. And because balances are private, an empty account looks the same as a full one, so the set of accounts each user hides among does not shrink when people spend or sell. New PCASH comes only from issuance. Successful payments and asset transactions earn newly issued PCASH for whoever publishes them or for a destination they name, up to a total of one billion, with no premine, no allocation to early addresses, and no sale. # Part II — How PCASH Works ## A Private Blockchain Derived from Ethereum Every PCASH block is computed from one Ethereum block. PCASH block N comes from Ethereum block `anchor + N`, where the anchor is the Ethereum block chosen at launch. No one proposes or signs PCASH blocks. Any correct node given the same Ethereum history computes the same PCASH blocks.
Each Ethereum block produces one PCASH block: select the PCASH postings, run their transactions in order, and commit the result.
**Publishing.** PCASH transactions reach Ethereum inside ordinary Ethereum transactions sent to a designated inbox address. The inbox is not a smart contract. It is an address that marks an Ethereum transaction as carrying PCASH data. Each such transaction carries one batch of PCASH transactions, either in its calldata or in blobs, Ethereum's cheaper data format. Anyone can collect PCASH transactions into a batch and post it; whoever does is called a relayer or poster. There is no sequencer and no permission to post. Every PCASH transaction names the PCASH network it belongs to, so a transaction prepared for one PCASH network means nothing on another. **Ordering.** Transactions run in Ethereum's order: by Ethereum block, then by position within the block, then by position within the batch. Each transaction sees the state left by every successful transaction before it. If two transactions try to spend the same note, the first one to pass every check succeeds and the other fails.
Transactions run in Ethereum order. The first spend of a note succeeds; a later spend of the same note fails.
**Every outcome is recorded.** Each PCASH transaction gets a committed outcome: success, or one specific failure such as "already spent" or "proof rejected". A failed transaction changes no state, but its exact bytes and outcome stay in PCASH history. A wallet or explorer can therefore explain a failure later without returning to Ethereum blob data, which Ethereum keeps only for a limited time. Bytes that are not a transaction for this network, such as truncated data, an unknown transaction type, or a transaction for another PCASH network, are skipped. One case is different. If a node cannot obtain data it needs, such as a blob that should be available, it stops and waits rather than guessing. Treating "I could not check" as "this failed" could lead nodes to different states. **No contract and no stored state.** PCASH does not keep its state in an Ethereum contract. The current state is whatever the rules produce from Ethereum history since the anchor. Ethereum does not need to know that PCASH exists. **Reorganizations.** When Ethereum reorganizes, the PCASH blocks computed from the abandoned Ethereum blocks disappear with them. A node goes back to the last block the old and new histories share and recomputes forward along the new history. The result is exactly the state a fresh node would compute from scratch.
When Ethereum replaces blocks, a node restores the state at the common ancestor and recomputes the replacement blocks.
## Notes, Nullifiers, and Accounts PCASH keeps value in **notes**. A note is a discrete piece of value, like a banknote: it has an owner, an asset (PCASH itself or a custom asset), and an amount. A payment consumes notes and creates new ones, the way paying with a large bill produces a payment and change. The ledger never stores a note in the clear. It stores a **commitment** to the note: a cryptographic fingerprint that fixes the owner, asset, and amount without revealing them. The information that matches the fingerprint is the note's **opening**. Only someone who holds the opening knows what the note contains. Every new commitment is appended to one ever-growing list of notes, the output tree.
A note is committed in layers: its owner and a secret, then its asset and amount, then its position in the output tree.
A note must be spendable only once, but the network must not learn which note was spent. PCASH solves this with a **nullifier**, a one-time spend marker computed from the note and its owner's secret key. Every valid spend of the same note produces the same nullifier. Nodes keep the set of every nullifier ever used, and a transaction that presents a nullifier already in the set fails. The nullifier cannot be linked to the note's commitment without the owner's secrets, so observers learn that some note was spent, not which one.
The note's commitment stays in the output tree. Spending it adds its nullifier to the spent set, so it cannot be spent again.
An **account** is the control point for spending. Each account has an address and commits the rules that decide what may be spent from it. It can also publish a receive key so that others can send it encrypted notes. Creating an account is a public registration: it reveals that the address joined PCASH, but it reveals no balance and commits no money. Once created, an account stays registered permanently. Receiving PCASH needs no account. Spending existing notes does. This is the main difference from a shielded pool. Joining costs one Ethereum transaction and no capital, and because balances are private, an account holding nothing looks the same as an account holding a lot. The anonymity set is every account that has ever registered, and it does not shrink when people spend or sell. There are two kinds of accounts: * A **user account** belongs to an Ethereum address. The Ethereum key for that address creates it, because no other rules exist yet. From then on, the account's installed rules decide who can spend and who can change the rules. The owner can move from Ethereum-key authorization to a passkey, a multisig, a recovery condition, or another method without moving any funds. * A **contract account** has no key, and no one can change it. Its rules are fixed when it is created, and its address is derived from them and its other fixed contents. Contract accounts hold funds under permanent conditions, which is what makes escrow and similar arrangements trustworthy. ## A Payment, Step by Step Here is one ordinary payment. The numbers are illustrative.
Alice's wallet prepares and proves the payment, anyone can publish it, nodes check it, and Bob's wallet recovers his note.
Alice owns a private note worth 5 PCASH. She wants to pay Bob 3 PCASH and offer a 0.01 PCASH fee to whoever publishes the transaction. Her wallet spends the 5 PCASH note and creates two new notes: 3 PCASH for Bob and 1.99 PCASH of change for Alice. ```text 5 PCASH spent = 3 to Bob + 1.99 change to Alice + 0.01 fee ``` **Fixed shapes hide the details.** Every payment uses one of two public sizes, called profiles. The small profile, S, has four input positions and five output positions. The large profile, L, has thirty-two of each. Positions that carry no value are filled with padding that looks the same as real inputs and outputs from the outside. Alice's payment uses S: one real input and three padding inputs, two real outputs (Bob's note and her change) and three padding outputs. An observer sees four nullifiers and five new note commitments and cannot tell which ones are real. Only the choice of profile is visible.
In the S profile, all four input positions and all five output positions are always filled. Padding hides which ones carry value.
**One proof covers authorization and the ledger.** Alice's wallet produces a single zero-knowledge proof that shows two things. First, the ledger rules hold: the input note exists and is Alice's, its nullifier is computed correctly, the new notes are built correctly, and value balances. Second, one of the rules installed on Alice's account approved this exact transaction, for example with a signature from her Ethereum key. Neither half is enough alone. An approving signature cannot create value or spend someone else's note, and a balanced transaction cannot spend Alice's note without her approval.
A payment must pass Alice's own account rule and the fixed ledger rules, both inside one proof.
**Publishing.** Alice, or any relayer, posts the transaction to the inbox. The public part is the proof, the four nullifiers, the five new note commitments, an encrypted data field for each output, the 0.01 PCASH fee, a reference to a recent PCASH block that the proof was built against, and the time window in which the transaction is valid. Alice, Bob, the amounts, which positions are real, and which of Alice's rules approved the payment all stay private. **Checking.** Nodes check the transaction in Ethereum order. The referenced block must be canonical and recent, the time window must include the current block's time, the nullifiers must be new, there must be room in the output tree, and the proof must verify. If every check passes, the nullifiers join the spent set and the five commitments join the output tree. Ethereum verifies nothing about PCASH; PCASH nodes do. **Receiving.** Each output carries a fixed-size encrypted data field. Bob's wallet tries to decrypt every new output with his receive key. When one opens, the wallet rebuilds the note and checks it against the commitment on the ledger. Alice recovers her change the same way. Bob needed no account to receive the note: he can give his receive key to a sender directly, and an account only publishes one for anyone to look up. He needs an account before he can spend the note.
What the network sees, and what stays private, in Alice's payment.
## Relaying, Fees, and Where Issuance Goes A transaction has to get onto Ethereum, and someone has to pay the Ethereum gas to put it there. Successful payments can also earn newly issued PCASH (see the next section), so each transaction says both how it pays its publisher and where its issuance goes. There are three ways to do this: * **Open fee.** The transaction offers a public PCASH fee to whoever publishes it successfully. Any relayer can pick it up. Any issuance goes to the same publisher. * **Selected relayer.** The wallet agrees on a private fee with one relayer and pays it as an ordinary encrypted note to that relayer, as one of the transaction's outputs. The public fee is zero. The relayer's quote also names a one-time destination for any issuance, which the proof fixes, so the relayer receives the issuance as well as its fee. * **Self-publishing.** The wallet publishes the transaction itself, paying Ethereum gas but no PCASH fee, and names its own destination for any issuance. Publishing from your own Ethereum address publicly links that address to the transaction.
An open fee pays the publisher publicly, a selected relayer's fee is a private note, and issuance follows its own destination.
A transaction may offer a public fee or name an issuance destination, but not both. A named destination is fixed by the proof, so copying the transaction into someone else's batch cannot redirect its issuance. Without a named destination, the fee and any issuance go to whoever publishes the transaction successfully first, and anyone can copy it into their own batch to try. This includes a transaction that offers no fee and names no destination. A publisher is identified by a commitment in the batch, not by the Ethereum address that sent the batch. Fees move existing PCASH. They never create new PCASH, and issuance cannot fund a fee. Publishing costs Ethereum gas whether the transaction succeeds or fails, and a failed transaction pays no PCASH fee and earns no issuance. After all of a block's transactions have run, the node pays publishers and issuance destinations with new notes called system payouts. Their amounts are public; their owners are hidden behind commitments. Everything a block owes the same publisher is combined into one payout, which records its fee and issuance parts separately. ## Native Issuance PCASH starts with no holdings at all. There is no premine, no allocation to early addresses, and no sale. New PCASH enters circulation only as issuance for successful qualifying transactions, and total issuance can never exceed one billion PCASH.
Gross issuance starts at zero and can never exceed one billion PCASH.
**What qualifies.** Every successful payment qualifies, including a payment of zero PCASH, and so does every successful private-asset transaction. Registering an account, updating one, creating a contract, and failed transactions do not qualify. Qualification counts successful transactions, not people or useful commerce. One account can make many qualifying transactions, and the rules make no attempt to tell real activity from payments to oneself. **How much.** Every qualifying transaction in a block earns the same amount: the smallest of three limits. 1. The **offer**, a per-transaction amount that changes over time as described below. 2. An equal share of the **block allowance**, which is three times the current baseline. 3. An equal share of the **remaining supply**. For example, with an offer of 100 PCASH and an allowance of 300 PCASH: | Qualifying transactions in the block | Each earns | Total issued | |---|---|---| | 0 | — | 0 PCASH | | 1 | 100 PCASH | 100 PCASH | | 3 | 100 PCASH | 300 PCASH | | 6 | 50 PCASH | 300 PCASH | The count covers the whole block, so spreading transactions across more batches earns nothing extra. Allowance that a block leaves unused is gone; it does not carry over to the next block. Remainders from the division stay unissued. **Why the offer changes.** The offer has two parts. The **baseline** declines as supply is issued. It follows a curve that would issue the whole supply in about a year if one qualifying transaction happened every twelve seconds. That year only sets the curve's scale: issuance has no deadline and can continue indefinitely if activity is sparse. The baseline starts near 761 PCASH per transaction and falls to half that once three quarters of the supply has been issued. It does not fall just because time passes. The **controller** compares elapsed time with progress along that curve. When issuance is behind the reference pace, the offer rises: every two days behind doubles it, up to four times the baseline. When issuance is ahead, the offer falls. The controller remembers at most four days of being behind, so a long quiet period does not build up an unlimited catch-up. At launch, the offer is provisionally set to start at one-sixteenth of the baseline.
The baseline falls with issued supply, the controller scales it by how far issuance is behind or ahead, and each block's allowance is shared equally.
Because a block's allowance is three times the baseline, even a transaction alone in its block earns at most three times the baseline, whatever the offer. The protocol specification gives the exact arithmetic and rounding. **Starting with nothing.** A newcomer needs no PCASH to earn some. A payment of zero PCASH that spends no notes and pays no fee is still a qualifying transaction. Because it spends nothing, the protocol does not even require a registered account for it. The newcomer names their own issuance destination, publishes the transaction, and, if it succeeds while the block pays issuance, receives a new PCASH note. Spending that note later requires a registered account, as spending always does. A successful transaction can also earn zero, for example when many transactions share the block allowance and the equal share rounds down. ## Authorization Every spend must satisfy two independent sets of rules. The ledger rules are fixed by the protocol and the same for everyone: notes must exist and belong to the spender, nullifiers must be correct, and value must balance. The authorization rules are chosen by each account and decide whether a particular action is approved. An account's authorization rules are small zero-knowledge programs. A user account calls them policies; a contract account calls them functions. An account commits to a set of up to 256 of them. Each rule is identified by the exact fingerprint of its circuit's verification key, together with a committed configuration. For a signature rule, the configuration might name the signing address and say what the signature must cover. Anyone can write a new rule. A badly designed rule can endanger the account that installs it, but it cannot weaken the ledger rules or affect any other account.
An account commits a set of rules. The selected rule decides whether to approve, and the protocol still enforces every ledger rule.
When an account spends, its wallet picks one installed rule and proves, inside the transaction's proof, that the rule approved the exact action. The rule receives a commitment to the complete action, so it can tie its approval to that one transaction: a signature rule that signs the commitment cannot have its approval reused for another. A rule may also approve more broadly, by design. Observers learn that some valid rule approved the transaction. They do not learn which account acted, which rule was used, or what secret satisfied it. **Secrets are separate from authority.** The key material that identifies an account's notes and computes their nullifiers is separate from the authority to spend them. A hardware wallet, for example, can hold an Ethereum key and sign a typed description of a payment. The signature leaves the device and goes into the proof; the key never does. Wallet software can build the transaction and its proof without ever being able to spend the user's money on its own. **Changing the rules.** A user account's rules are replaced by an account update, which must itself be approved by one of the account's current rules. The account's address and note keys stay the same, so no funds move. To remove a rule, the owner replaces the rule set with one that leaves it out. Removal is not instant: a proof may be built against any canonical PCASH block from the past hour, so for up to an hour a transaction can still be proven against the old rule set.
An update replaces the whole committed rule set. Proofs against older blocks stop working once those blocks are more than an hour old.
## Immutable Authorization Some arrangements need more than one person's approval. A user account can install a two-of-three rule for both spending and changing the rules. If it installs no weaker rule for changes, no single signer can replace the threshold. The signers acting together can still change the rules. That is right for key rotation and recovery, but it means the custody arrangement is not permanent. When the rules themselves must be permanent, PCASH uses a contract account. A contract account has no key and can never be updated. Its address is derived from its fixed contents, including its functions. Creating it publishes each function's circuit fingerprint and configuration commitment, so anyone who obtains a function's code and configuration can check them against the registered contract. Once PCASH is sent to a contract, it can move only when one of those original functions approves. Not even the contract's creators can change the terms, which is what makes escrow, vesting, and sales credible.
A contract account is published once with fixed functions. Each later call spends contract-owned notes under one of them.
A contract is not a program that every node runs. There is no PCASH virtual machine and no contract storage. A contract holds notes, and its functions are the only conditions under which those notes can move. Calling a function means proving, privately, that the function approved the action. A multi-step application, such as an escrow, is a sequence of such transactions, each consuming the contract's current notes and creating new ones. A contract's creator decides whether to publish the contract's note key along with it. With the key published, anyone who also knows a note's opening can spend it, but only when one of the contract's functions approves. This is how publicly callable contracts work. A contract cannot spend anything before it exists, so a user account pays for its creation: it approves the publication and pays the fee from its own notes. ## Programmable Conditions Rules do not have to decide from signatures alone. They can also depend on facts about Ethereum or about PCASH's own history. **Selling PCASH for ETH without a custodian.** A seller locks PCASH in a contract account with two functions. One releases the PCASH to a buyer who proves an ETH payment to the seller. The other returns it to the seller after a deadline. The buyer inspects the escrow, pays the seller in ETH through an Ethereum payment contract that records each payment as an event, then proves that event against PCASH's record of Ethereum history and claims the notes. The buyer is protected by the escrow's permanent release rule. The seller has either already received the ETH or reclaims the PCASH when the deadline passes. The exchange is custodian-free but not atomic. The seller receives the ETH the moment the buyer pays, so the buyer must claim before the deadline. A buyer who pays and misses the deadline can lose the payment while the seller reclaims the notes. No operator holds either side's funds, and there is no bridge that redeems PCASH for ETH. **How rules see Ethereum.** Every PCASH block commits a record of every Ethereum block since the anchor, including a tree of that Ethereum block's event logs. A rule can prove privately that a specific Ethereum event happened, such as a payment contract recording a certain amount paid to a certain address, and decide what it means. A plain ETH transfer emits no event; a rule that relies on one must prove the transaction itself. Other facts reachable from an Ethereum block hash, such as receipts, storage values, and transactions, can be proven by the rule itself. The same approach supports time conditions, oracle events, and conditions on earlier PCASH state.
A rule opens one Ethereum event beneath a recent PCASH block and interprets it.
**The other direction.** When activity on Ethereum depends on PCASH state, usually nothing is needed on Ethereum beyond an ordinary transaction. A participant checks PCASH state and then acts on Ethereum, while the protections are enforced on the PCASH side. In the escrow above, the buyer pays in ETH only after checking that the escrow exists and will release to them. Each party's protection lives on the chain that holds the other party's obligation. An Ethereum contract that must act on PCASH facts by itself could, in principle, verify a proof that a PCASH state follows from Ethereum history under the PCASH rules. No such prover exists today, and no such contract would be privileged or canonical. **Limits.** PCASH programmability is limited on purpose. Rules decide whether a proposed transfer is authorized. They cannot create PCASH, create units of an existing asset, spend a note without its owner's rule, spend a note twice, or change the fixed transaction shapes. ## Private Assets The same machinery supports private assets other than PCASH, and anyone with a registered account can create one. Every note names its asset with an asset ID: zero means PCASH, and any other value names one instance of the standard fixed-supply asset. The asset ID stays inside the proof, so the network does not see which asset moved. There is no registry and no administrator assigning IDs. An asset's ID is computed from its fixed definition: a random salt, a commitment to its metadata, its total supply, and a commitment to a secret that authorizes its issuance. Changing any of these gives a different asset. Wallets and catalogs decide which names to show for which IDs.
An asset's ID is a commitment to its fixed definition.
**Issued once.** An asset's whole supply is created in one transaction. The issuer proves knowledge of the issuance secret, one of the issuer's account rules approves the transaction, and the transaction consumes a one-time marker derived from that secret. Every attempt to issue the same asset produces the same marker, so only the first can succeed. There is no later minting. **Then only moved or burned.** After issuance, asset notes are spent like PCASH notes. Each transaction balances the asset and PCASH separately: asset in equals asset out plus any voluntary burn, and PCASH in equals PCASH out plus the fee. Asset value cannot turn into PCASH, and PCASH cannot turn into the asset.
An asset is defined, issued once, and afterwards only moved or burned.
The standard asset has no freeze, pause, clawback, blacklist, transfer tax, or later mint. More controlled distribution uses contract custody instead: the issuer can issue the whole supply to a contract account whose functions release it on a schedule, against payment, or under other conditions. Those conditions apply while the contract holds the notes and end when the notes leave it. A transaction can move at most one asset besides PCASH, and all of its inputs must belong to one account. There is one exception: a user account may pay the PCASH fee for a contract account's asset transaction, and contribute nothing else. Arrangements with more parties use contracts and a sequence of transactions. Fees are always paid in PCASH, and a transaction with no fee is valid. ## One Recent Block Anchors Every Proof A proof has to show facts about PCASH state: that a note exists in the output tree, or that an account has a particular rule installed. It does this against one recent PCASH block, named by its hash. The block hash commits the block's state root. The state root commits the output tree, the account tree, the spent-nullifier set, and the issuance totals. The block hash also commits the record of Ethereum history and of earlier PCASH blocks.
A PCASH block hash commits the current state and two histories: Ethereum's and PCASH's own.
The transaction publishes only the block hash. Which parts of the state the proof opened beneath it, which Ethereum event, or which earlier block, stays private. Nodes accept the transaction only while the named block is part of the canonical chain and less than an hour old. If an Ethereum reorganization removes that block, transactions naming it fail until they are proven again against a newer block. A wallet can prove the same approved action again against a newer block without asking for a new approval, unless the rule's approval depended on the specific block. ## Delivery and Recovery To spend a note, its owner needs the note's opening: its amount, its owner, and its secret. PCASH does not dictate how an opening reaches the recipient, but it gives every output a fixed-size data field for delivery. A user account can publish a receive key, and a sender encrypts the opening to that key. The encrypted data contains no recipient identifier. Wallets try to decrypt every new output and check any opening they recover against the ledger. Payment codes, keys exchanged in advance, and delivery outside PCASH also work. System payouts carry no encrypted data, so their owners find them another way. The reference wallet derives each payout's owner commitment from a secret seed and public context. After a restore, it finds its payouts by recomputing candidate commitments and matching them against the node's payout records, with no saved list of past transactions.
The reference wallet restores its payouts from its seed and the node's public payout records.
Receive keys are ML-KEM-768 keys, a post-quantum encryption scheme, so the encryption itself resists a future quantum computer. Whether old encrypted data stays confidential also depends on where the receive key came from. A receive key derived from an Ethereum signature can be reproduced by anyone who later breaks that Ethereum key, and with it every note sent to that key can be read. Long-term confidentiality against quantum computers needs a receive key that is not derived from an elliptic-curve key. ## Protocol Evolution Each version of PCASH is immutable. It has no upgrade key, no governance contract, and no other way for anyone to change its rules. PCASH can still evolve the way Ethereum does, through people adopting new software. A new version can begin applying new rules from a chosen Ethereum timestamp and carry the existing state forward. This allows bugs to be fixed and aging cryptography to be replaced without giving anyone control over the current version. Such a change is a hard fork, not something the existing protocol performs. Users and node operators decide whether to adopt it, and each proposal must specify and justify its own activation point, rules, and treatment of existing state. ## What You Trust The design minimizes trusted parties by making as much as possible a function of public Ethereum history and publicly checkable proofs. **Users rely on:** * Ethereum's consensus and canonical history * access to the Ethereum data PCASH transactions were posted in, including blob data, which Ethereum nodes discard after about 18 days * the soundness of the zero-knowledge proof system and its universal setup parameters * the correctness of the circuits, verification keys, and parameters * the correctness of the software that computes PCASH state from that history **Users do not rely on:** * a sequencer or privileged batch poster * a multisig administrator or upgrade key * a bridge operator or custodian * other users keeping their money in a shielded pool * any particular Ethereum contract being the canonical PCASH contract # Part III — Privacy and Security ## Privacy Properties For every private-value transaction, the proof hides the sender, the recipient, the amounts, balances, which notes were spent, which rule approved it, whether it moved PCASH or another asset, and how it relates to other transactions. Some things are public: * that an account registered, its address, and its initial rule-set commitment and receive key; * when an account updates its rules or receive key, its address and its new rule-set commitment and receive key; * a contract's complete definition, when it is created; * that a transaction happened, when, which profile (S or L) it used, the recent block it names, its time window, and its outcome; * its public fee, if any, and its issuance destination commitment; * each batch's publisher commitment, which links batches that reuse it; * each system payout's amount, its split between fee and issuance, and its owner commitment; * total issuance, and the issuance and fees of each block. Public details can still reveal information. An Ethereum address that publishes its own transaction is linked to it. A rarely used asset has a small anonymity set, and fee choices, timing, and application behavior can distinguish transactions. The baseline anonymity set for a transfer is every account that has registered. Registration is public and permanent but reveals no balance, so an account holding nothing looks the same as one holding a lot. Because registration needs no deposit, and spending or selling removes no account, the set grows with adoption rather than with the amount of capital users keep locked up. ## Security Assumptions and Failure Modes PCASH's security rests on its zero-knowledge proof system (CHONK proofs over the BN254 curve), on the universal setup parameters that system depends on, and on the correctness of the circuits, verification keys, parameters, and node software that enforce ownership, authorization, conservation, and issuance. **Counterfeiting cannot be detected after the fact.** A system with both a public and a shielded form of the same asset can compare the two to check the shielded supply. PCASH has no public form. Total issuance is known, but the amount held in unspent private notes is not, so a flaw that let someone create counterfeit notes would leave them indistinguishable from real ones. The protocol does not promise to identify such notes. A later version of PCASH that stops trusting the current proof system, and still wants to count as the same money, must declare a monetary trust reset. Holders then claim their PCASH by proving each claim from the historical record, under the rules in force when that history was written, without relying on the old proofs. The new version may accept only notes that existed unspent at an earlier block it still trusts, which excludes everything received after that block, and it may leave unavailable any value held under rules it cannot re-check. In total, it may carry forward no more PCASH than the one-billion issuance cap. In the worst case, counterfeit claims crowd out honest holders, but the total carried forward stays bounded. Custom-asset notes are not carried forward under their old IDs. Anyone may create a new asset and a contract that hands it out against claims on the old notes, and users and markets decide which new asset, if any, continues the old one. The protocol specification defines the exact criterion. **Quantum computers.** The current proof system and ordinary signature-based rules are not post-quantum. The ML-KEM-768 receive keys protect only the confidentiality of note delivery, and only when the receive key is not derived from an elliptic-curve key. **Losing keys.** A user account's Ethereum key is needed only to create it. After that, only the account's installed rules can authorize its transactions or replace its rules, and nothing can override them. If the owner can no longer satisfy any installed rule, the rules can never change and the account's notes are stranded, so a recovery method has to be installed in advance. Using a rule also means keeping what it needs: its configuration secrets, including the blinding value that hides it. One secret can never be replaced, even while the rules can: the account's root note key, fixed at creation. Anyone who can no longer reconstruct it can no longer spend the account's notes, and that value is stranded permanently. The receive key's secret is needed to read notes sent to the account. How these secrets are generated and kept is a wallet choice outside the protocol. Deriving them from a signature by the account's Ethereum key needs no separate backup but ties them to that key: losing the key loses them, even after the account has moved its authorization to other methods. Secrets generated independently of the key must be backed up on their own. # Conclusion PCASH makes privacy a property of money rather than a place where money is temporarily kept. It is not a shielded form of ETH and not a private IOU redeemable for a public asset. It is a separate, private-only money whose state is computed from Ethereum's history, and which trades with public assets without a bridge. That answers both problems that motivate it. There is no contract administrator to trust, and no pool of deposited capital that other users must keep locked up for privacy to hold. Each version is immutable, and successors are adopted socially, as Ethereum's are. Registration without a deposit grows the anonymity set with adoption. Issuance distributes PCASH for successful payments and asset transactions, with no allocation or sale. Zero-knowledge proofs hide participants, amounts, assets, and relationships. Fixed-supply assets extend the same privacy beyond PCASH, and programmable rules support ordinary wallets, multisig, escrow, controlled distribution, and trading with ETH, all without a custodian, an operator, or a separate consensus mechanism. Ethereum's history determines the chain. Zero-knowledge proofs determine what may move within it. No withdrawal boundary limits the private system to the capital people are willing to keep shielded.