Update erc-8289.md

Cyimon · web-flow · commit 685314e174cf · 2026-06-16T11:02:13.000+08:00
diff --git a/ERCS/erc-8289.md b/ERCS/erc-8289.md
@@ -12,7 +12,7 @@ created: 2026-06-16
 
 ## Abstract
 
-This document defines [ERC-8289](./eip-8289.md), a **private-by-default fungible token** for the EVM: the privacy version of [ERC-20](./eip-20.md). Under the hood it uses the Orchard shielded-pool model from the Zcash Protocol Specification (https://zips.z.cash/protocol/protocol.pdf). It keeps the [ERC-20](./eip-20.md) full method surface, but several methods are **private** (holder-only, off-chain) rather than public on-chain reads, and `transfer` / `approve` / `transferFrom` all appear on-chain as the same `transfer` operation. See [Interface Overview](#interface-overview).
+This document defines [ERC-8289](./eip-8289.md), a **private-by-default fungible token** for the EVM: the privacy version of [ERC-20](./eip-20.md). Under the hood it uses the Orchard shielded-pool model from the Zcash Protocol Specification. It keeps the [ERC-20](./eip-20.md) full method surface, but several methods are **private** (holder-only, off-chain) rather than public on-chain reads, and `transfer` / `approve` / `transferFrom` all appear on-chain as the same `transfer` operation. See [Interface Overview](#interface-overview).
 
 ## Motivation
 
@@ -28,7 +28,7 @@ The key words **MUST**, **MUST NOT**, **SHOULD**, **MAY** are interpreted per RF
 
 ### Underlying Protocol
 
-Value is held in shielded notes, not account balances. The note format, nullifiers, commitment tree, note encryption, and action/bundle structure follow the **Orchard shielded pool** in the Zcash Protocol Specification (https://zips.z.cash/protocol/protocol.pdf), adapted here as a per-asset EVM contract verified with Groth16. Field-level formats not repeated below are normative in the [Reference Implementation](#reference-implementation).
+Value is held in shielded notes, not account balances. The note format, nullifiers, commitment tree, note encryption, and action/bundle structure follow the **Orchard shielded pool** in the Zcash Protocol Specification, adapted here as a per-asset EVM contract verified with Groth16. Field-level formats not repeated below are normative in the [Reference Implementation](#reference-implementation).
 
 ### Interface Overview
 
@@ -38,9 +38,9 @@ This section lists **all interfaces** in one place and marks whether each corres
 |---|---|---|---|---|
 | `name()` / `symbol()` / `decimals()` | yes | on-chain | public | Identical to [ERC-20](./eip-20.md) |
 | `totalSupply()` | yes | on-chain | public | Public counter (`mint` − `burn`) |
-| `balanceOf(addr)` | yes | off-chain | **private** | Scan Orchard notes (Zcash Protocol Specification, https://zips.z.cash/protocol/protocol.pdf) with viewing key; holder-only |
+| `balanceOf(addr)` | yes | off-chain | **private** | Scan Orchard notes (Zcash Protocol Specification) with viewing key; holder-only |
 | `transfer(PrivacyCall)` | yes | on-chain | private (parties + amount) | Orchard action bundle |
-| `approve(spender, N)` | yes | off-chain | private (relationship hidden) | ZIP-32 subaccount (https://zips.z.cash/zip-0032); fund + deliver key; on-chain submits as `transfer(PrivacyCall)` |
+| `approve(spender, N)` | yes | off-chain | private (relationship hidden) | ZIP-32 subaccount; fund + deliver key; on-chain submits as `transfer(PrivacyCall)` |
 | `allowance(owner, spender)` | yes | off-chain | **private** | Scan subaccount remaining balance |
 | `transferFrom(from, to, amount)` | yes | off-chain | private (relationship hidden) | Spender spends subaccount; on-chain submits as `transfer(PrivacyCall)` |
 | `mint(amount, PrivacyCall)` | extension | on-chain | amount public; recipient private | Issuer-only; Orchard action + `totalSupply` increase |
@@ -129,7 +129,7 @@ Conformance:
 
 ### Call Format
 
-Every value-changing operation submits a `PrivacyCall` encoding one or more **Orchard actions** (Zcash Protocol Specification, https://zips.z.cash/protocol/protocol.pdf):
+Every value-changing operation submits a `PrivacyCall` encoding one or more **Orchard actions** (Zcash Protocol Specification):
 
 - `actions` = `abi.encode(BundleAction[])`.
 - `bindingSig` = Schnorr binding signature `[Rx, Ry, s]` proving value conservation.
@@ -165,7 +165,7 @@ Without the `pubFields` ↔ calldata equality checks, a valid proof could be rep
 
 The bundle-level `bindingSig` MUST be verified over all action nullifiers, commitments, and the operation's `valueBalance` before any state mutation (see Method Semantics for encodings).
 
-Note encryption and key derivation follow the Orchard note format in the Zcash Protocol Specification (https://zips.z.cash/protocol/protocol.pdf); exact encodings are in the [Reference Implementation](#reference-implementation).
+Note encryption and key derivation follow the Orchard note format in the Zcash Protocol Specification; exact encodings are in the [Reference Implementation](#reference-implementation).
 
 ### Method Semantics
 
@@ -175,11 +175,11 @@ Identical to [ERC-20](./eip-20.md): public on-chain views.
 
 #### `transfer(PrivacyCall) → bool`
 
-Spends input Orchard notes (Zcash Protocol Specification, https://zips.z.cash/protocol/protocol.pdf) and creates output notes in a value-conserving action bundle (`valueBalance == 0`). Sender, recipient, and amount MUST remain private. Returns `true` on success; emits `NoteAdded` / `NoteConfirmed`, not `Transfer(from,to,value)`.
+Spends input Orchard notes (Zcash Protocol Specification) and creates output notes in a value-conserving action bundle (`valueBalance == 0`). Sender, recipient, and amount MUST remain private. Returns `true` on success; emits `NoteAdded` / `NoteConfirmed`, not `Transfer(from,to,value)`.
 
 #### `mint(amount, PrivacyCall)` / `burn(amount, PrivacyCall)`
 
-Same Orchard action verification path as `transfer` (Zcash Protocol Specification, https://zips.z.cash/protocol/protocol.pdf), with public `totalSupply` accounting:
+Same Orchard action verification path as `transfer` (Zcash Protocol Specification), with public `totalSupply` accounting:
 
 - `mint`: `totalSupply += amount` (`onlyIssuer`); `amount` public, recipient private. Mint MUST use the same anchor / nullifier / spend-auth path as `transfer` (no output-only branch). The circuit MUST constrain the consumed input to `v = 0` so the action represents net inflow; the contract does not read note value directly.
 - `burn`: `totalSupply -= amount`; any holder MAY burn own notes; `amount` public, burner private.
@@ -192,11 +192,11 @@ Same Orchard action verification path as `transfer` (Zcash Protocol Specificatio
 
 #### `balanceOf` (off-chain, private)
 
-Only the holder can compute their balance by scanning `NoteAdded` events, trial-decrypting Orchard notes (Zcash Protocol Specification, https://zips.z.cash/protocol/protocol.pdf) with their viewing key, and excluding spent nullifiers. There is no on-chain `balanceOf` and no way to query a third party's balance.
+Only the holder can compute their balance by scanning `NoteAdded` events, trial-decrypting Orchard notes (Zcash Protocol Specification) with their viewing key, and excluding spent nullifiers. There is no on-chain `balanceOf` and no way to query a third party's balance.
 
 #### `approve` / `allowance` / `transferFrom` (off-chain semantics; on-chain = `transfer`)
 
-Approved spending is built on ZIP-32 hierarchical accounts (https://zips.z.cash/zip-0032): each **EOA spender** receives a dedicated subaccount (`account_S`) with its own spending and viewing keys, cryptographically isolated from the owner's main account and from every other spender. This ERC maps [ERC-20](./eip-20.md) `approve` / `transferFrom` onto it as follows:
+Approved spending is built on ZIP-32 hierarchical accounts: each **EOA spender** receives a dedicated subaccount (`account_S`) with its own spending and viewing keys, cryptographically isolated from the owner's main account and from every other spender. This ERC maps [ERC-20](./eip-20.md) `approve` / `transferFrom` onto it as follows:
 
 1. **`approve(spender, N)`** — Owner derives an unused ZIP-32 subaccount, funds it with `N` via `transfer(PrivacyCall)`, and delivers that subaccount's spending key to the spender (encrypted off-chain). On-chain: one `transfer`.
 2. **`allowance(owner, spender)`** — Remaining balance of that subaccount, scanned with the subaccount viewing key. No on-chain mapping.
@@ -207,7 +207,7 @@ The allowance ceiling is enforced by the subaccount's actual note balance, not a
 
 ### Execution Requirements
 
-The on-chain state machine follows the Orchard shielded pool (Zcash Protocol Specification, https://zips.z.cash/protocol/protocol.pdf). Implementations MUST:
+The on-chain state machine follows the Orchard shielded pool (Zcash Protocol Specification). Implementations MUST:
 
 - Maintain a nullifier set; the same `nf` MUST NOT be spent twice.
 - Maintain an append-only commitment tree; historical roots queryable via `isValidAnchor`.
@@ -220,10 +220,10 @@ The on-chain state machine follows the Orchard shielded pool (Zcash Protocol Spe
 
 ## Rationale
 
-- **Orchard ZK-UTXO model.** Notes, nullifiers, and the commitment tree follow the Zcash Protocol Specification (https://zips.z.cash/protocol/protocol.pdf); this ERC defines the private token interface and per-asset deployment on EVM.
+- **Orchard ZK-UTXO model.** Notes, nullifiers, and the commitment tree follow the Zcash Protocol Specification; this ERC defines the private token interface and per-asset deployment on EVM.
 - **Private [ERC-20](./eip-20.md), not a different asset.** Same method surface; privacy changes openness (public view vs private query vs indistinguishable transfer), not user intent.
 - **One on-chain operation for all movement.** Collapsing `transfer` / `approve` / `transferFrom` removes approval metadata [ERC-20](./eip-20.md) unavoidably leaks.
-- **Approved spending via ZIP-32 subaccounts** (https://zips.z.cash/zip-0032). Each EOA spender gets an isolated hierarchical account instead of an on-chain `allowance` mapping; see Method Semantics.
+- **Approved spending via ZIP-32 subaccounts**. Each EOA spender gets an isolated hierarchical account instead of an on-chain `allowance` mapping; see Method Semantics.
 - **No `approve(contract)`.** A contract has no private key; placing a spending key on-chain would expose it to everyone. Programmable private spending (predicate-authorized notes, MPC custody) is future work, not part of this ERC.
 - **Wallet behavior is out of scope of the on-chain ABI.** Subaccount layout, encrypted key delivery, and note scanning are wallet/SDK responsibilities; a conformant reference is provided in the [Reference Implementation](#reference-implementation).
 
@@ -244,16 +244,16 @@ The [Reference Implementation](#reference-implementation) repository includes:
 
 ### Code
 
-Reference implementation: GitHub repository PERC20Labs/pERC20_ (https://github.com/PERC20Labs/pERC20_).
+Reference implementation: GitHub repository PERC20Labs/pERC20_.
 
 - Normative asset contract: `contracts/ptoken/PERC20.sol`.
 - Cryptographic and wallet formats (key derivation, `perc1` addresses, note encryption, nullifiers, approved-spending packaging): reference libraries and SDK in the same repository.
 
 ### Related Standards and Protocols
 
 - [EIP-20](./eip-20.md): Token Standard — the public fungible token interface that this ERC maps to.
-- Zcash Protocol Specification (https://zips.z.cash/protocol/protocol.pdf): Orchard shielded pool — note commitments, nullifiers, note encryption, and action structure adapted here for EVM Groth16 verification.
-- ZIP-32 (https://zips.z.cash/zip-0032): Shielded Hierarchical Deterministic Wallets — hierarchical account derivation used for per-spender subaccounts in `approve` / `transferFrom`.
+- Zcash Protocol Specification: Orchard shielded pool — note commitments, nullifiers, note encryption, and action structure adapted here for EVM Groth16 verification.
+- ZIP-32: Shielded Hierarchical Deterministic Wallets — hierarchical account derivation used for per-spender subaccounts in `approve` / `transferFrom`.
 
 ## Security Considerations
 
