The Forge

• Use a different funded submitter wallet when reusing the deposit wallet would defeat your objective.
• Choose the recipient deliberately; leaving it blank pays the publicly visible submitter.
• Assume exact amount and timing can correlate entry and exit, especially while the pool is small.
• Do not treat a later swap, transfer, hpFLR action, or staking action as shielded.
• Keep the portable recovery kit and password separate, offline, and unavailable to anyone who should not control the account.
• Use your own network-privacy controls if needed; Forge does not hide IP, RPC, browser, or wallet-provider metadata.

Account label: a local organizer only; it is not sent to the contract and does not define an account. Labels must be unique, and Forge refuses to overwrite an existing recovery kit.

Password: protects the portable file; it is not a contract credential and never becomes an on-chain ledger key. Reuse does not merge accounts because every kit has an independent viewing key, fresh salt, and nonce, but one compromised password could expose every kit using it.

Payment reference: optional encrypted metadata. Reuse has no effect on commitments, ownership, or accounting.

Secret and nullifier: freshly generated for every initial or successor note and unavailable as form inputs. The contract rejects duplicate commitments and permits each domain-bound nullifier hash to transition only once.

Accounting: each recovery kit discovers its own on-chain notes and reconstructs one aggregate balance per enabled asset. Successful transitions consume an old note and create a fresh one for any remainder; the contract never maps balances to a wallet, label, password, or reference.

Contract binding: every commitment, nullifier, and proof includes a privacy domain derived from the exact chain ID and shielded-pool address. A proof made for a counterfeit deployment cannot authorize the configured pool.

Pre-unlock attestation: password fields remain disabled until the authentic client verifies the wallet/RPC chain, pool address and runtime code hash, verifier, hasher, registry, compliance oracle, mutual wiring, signer policy, and domain. It re-attests before deriving the password key and clears each field as soon as the value is read.

Hosted-code limit: no ordinary webpage can keep a typed password secret from malicious JavaScript already controlling that page or a hostile browser extension. Deployment binding prevents cross-contract proof use; it cannot stop compromised code from copying plaintext. Use the published standalone recovery client from a verified release on a clean device for higher-assurance recovery.

Each initial and successor note stores two ciphertexts: one decryptable through the user's recovery kit and one encrypted to the configured compliance key. The ciphertexts are public; their plaintext balances and note secrets are not.

The official disclosure workflow requires configured committee authorization, decrypts in the separate adapter, and rechecks the commitment, deposit transaction, asset, amount, and spent state before producing a public settlement projection.

ProofRails can sign, package, anchor, and later verify that evidence. It does not receive the secret or nullifier, does not create withdrawal authority, and does not turn public transaction fields into private data. A stolen compliance decryption key can bypass policy even though it cannot spend the note.