Mint credits owner under Poseidon(creator_pubkey); spec mandates SHA-256 address — minted assets invisible & unspendable to wallets

[TaprootFreak]

Summary

The Multi-Asset mint credits the creator's account under owner = Poseidon(creator_pubkey) (hash_bytes), but the normative spec defines the account address/owner as H(Pk₀) = SHA-256(pubkey₀). The mint owner is the only Poseidon-derived address in an otherwise fully SHA-256 address ecosystem (SDK, username-claim, SMT commitment key, receive path, docs).

Result: a minted asset is invisible and unspendable to any spec-conformant (SHA-256-addressed) wallet — the balance lands under a Poseidon key the wallet never queries.

Impact

• GET /api/balance?address=<sha256(pubkey)>&asset_id=<aid> returns balance: 0 after a successful mint — the credit sits under Poseidon(pubkey).
• The creator cannot spend the minted supply: a send from the minted (Poseidon) account fails the prove leg, while sends between SHA-256-keyed accounts succeed.
• Affects every creator using the SDK / spec-conformant address derivation. User-facing, core mint flow.

Root cause

The in-circuit issuer-mint gate hard-binds the owner to the Poseidon hash of the creator pubkey, and the off-circuit code matches it:

• program-plonky2/src/circuit/main.rs:665-666 — let owner_from_creator = builder.hash_n_to_hash_no_pad::<PoseidonHash>(creator_pubkey_limbs.to_vec());
• program-plonky2/src/circuit/main.rs:678-679 — let owner_eq = builder.is_equal(owner_from_creator.elements[i], owner.elements[i]); is_minting = builder.and(is_minting, owner_eq);
• main.rs:701-705 — is_minting is mandatory for any minted balance > 0 (assert_zero(not_condition * not_minting * balance)), so a mint is only provable when owner == Poseidon(creator_pubkey).
• Off-circuit: node/src/account_node.rs:966 — let owner = hash_bytes(creator_pubkey); and program-plonky2/src/types.rs AccountState::new derives owner = hash_bytes(initial_public_key).
• hash_bytes is Poseidon: program-plonky2/src/hash.rs:42 — PoseidonHash::hash_no_pad(&elements).

The circuit comment at main.rs:661 even reads "owner_from_creator = H(creator_pubkey) == hash_bytes(pubkey)" — i.e. it interprets the protocol hash H as Poseidon. The normative spec says H (for addresses) is SHA-256.

What the normative spec says (SHA-256)

Per zk-coins/research README, zk-coins/docs is the target-design specification (research = archived drafts). The docs are unambiguous:

• docs/specification.md:188 — "General hash (addresses, off-circuit ids) → SHA-256" (in-circuit hash → Poseidon, :187).
• docs/specification.md:281 — "Address = H(Pk₀) — SHA-256 of the initial spend public key … the protocol's only identity".
• docs/specification.md:248 — "an account A has exactly one address, address = H(Pk₀)".
• docs/architecture/addressing.md:16 — "The first 8 hex characters of the account's SHA-256 hash become the address: sha256(pubkey_0)".

Everything else already follows SHA-256 — SDK (zk-coins/sdk src/derivation.ts address = sha256(pk0)), username-claim gate (router.rs:3148 sha256(pubkey) == address), the SMT commitment key (state.rs sha256(commitment_pubkey)), and the receive path (keys by the wire recipient). The mint owner is the lone outlier.

Reproduction (against DEV, dev-api.zkcoins.app)

1. Two-phase creator-signed mint into a fresh wallet completes server-side (Mint prove: ok → mint_commit_flow: state.update persisted).
2. GET /api/balance?address=<sha256(pubkey)>&asset_id=<aid> → {"balance":0,...} (HTTP 200) — credit not visible at the SHA-256 address.
3. GET /api/balance?address=<poseidon(pubkey)>&asset_id=<aid> → shows the minted balance — confirming the credit is under the Poseidon key.
4. A send from the (Poseidon) minted account → job ends failed / "prove failed" (500, prove_account_update_with_in_and_out_coins_and_sources failed), while unrelated SHA-256-account sends complete successfully in the same window.

Note: the raw prover error for (4) is mapped to the generic "prove failed" and not logged verbatim, so the exact internal cause of the spend failure was not isolated; it is consistent with the minted account living on the wrong (Poseidon) key relative to the SHA-256-based send/commitment machinery, but should be re-validated after the fix.

Proposed fix

Derive the mint owner as SHA-256(creator_pubkey) to match the spec and the rest of the address ecosystem:

• In-circuit mint gate (circuit/main.rs:665) — compute owner_from_creator via the in-circuit SHA-256 of the pubkey instead of Poseidon. The spec explicitly budgets one in-circuit SHA-256 per mint for this binding.
• Off-circuit owner derivation — account_node.rs:966 (prepare_mint) and AccountState::new (types.rs) → SHA-256.

This makes minted accounts consistent with received accounts, the SDK, username claims, and the SMT — i.e. visible and spendable by spec-conformant wallets.

Blast radius / open points

• Requires a circuit change → verifier-key / proof regeneration; coordinate with any deployed proving artifacts.
• Existing DEV state may hold Poseidon-keyed minted accounts (orphaned after the fix) → consider a reset/migration on DEV.
• Cross-check the asset_id derivation against the spec while here: docs/specification.md:281 includes issuance_version in the AssetId preimage; program-plonky2/src/types.rs::calculate_asset_id does not appear to — likely a separate divergence to confirm.

How it surfaced

The node/tests/api_remote.rs E2E suite (correctly using the SHA-256 address_hex() per spec) fails its mint roundtrips with balance never reached mint amount; got 0 against DEV — directly exposing this bug.

[TaprootFreak]

Fix design (implementation-ready)

Deep follow-up analysis (spec mechanics, circuit feasibility, adversarial soundness review). Net: the owner derivation is woven through the soundness-critical mint circuit and the core account-identity type, so this is a protocol change / hard fork (verifier-key regeneration → all existing proofs & account state invalid → mandatory state reset on each network). It needs a maintainer decision between two approaches.

What the spec actually requires

docs/specification.md is explicit that H (addresses/owner) = SHA-256 and that the mint binding is enforced in-circuit:

• :188 "General hash (addresses, off-circuit ids) → SHA-256"; :281/:248 address = H(Pk₀) = SHA-256.
• :764 (§2.4) "the mint-path binding H(creator_pubkey) == owner … one SHA-256 per mint. The reference instantiation uses a standard Plonky2 SHA-256 gadget."
• :529/:1790 the v1 mint clauses (incl. H(creator_pubkey) == owner) are "the entire v1 mint circuit"; §1.7.8 "any refinement of the in-/out-of-circuit boundary is a version bump".

The current circuit instead computes owner = Poseidon(creator_pubkey) (circuit/main.rs:665-666, comment :661 literally equates H with hash_bytes). That is the bug.

Two viable fixes

Variant A — spec-true (in-circuit SHA-256 owner). Replace the in-circuit owner == Poseidon(creator_pubkey) binding (circuit/main.rs:665-666,678-679) with owner == SHA-256(creator_pubkey) using a Plonky2 SHA-256 gadget (matches :764). Off-circuit owner → SHA-256 everywhere.

• Pros: strictly v1-conformant.
• Cons: no SHA-256 gadget present today; high gate cost; risk for the fixed-shape cyclic recursion; largest, highest-risk change.

Variant B — pragmatic, soundness-safe (off-circuit SHA-256 owner; drop the in-circuit owner binding). Remove circuit/main.rs:665-666 (owner_from_creator) and :678-679 (owner_eq) so is_minting = (asset_id == Poseidon(creator…)) AND (pubkey == creator). Derive owner = SHA-256(creator_pubkey) off-circuit.

• Adversarial soundness review: no forge/inflation/theft path opens — owner is a private witness (not a public input; main.rs:600), used only in account_state_hash and the coin.recipient == owner check; forge protection is fully held by the remaining in-circuit asset_id == Poseidon(creator) (:673-677) + pubkey == creator (:691-694) bindings + the in-circuit BIP-340 signature. Send/AccountUpdate is unaffected (owner is opaque outside the mint gate).
• Cons: technically a v1 spec deviation (the in-/out-of-circuit boundary moves → a version bump per §1.7.8); the "minted supply lands at H(creator)" invariant is no longer circuit-enforced (only honestly computed by the node — acceptable under the self-hosted trust model, since a malicious prover only hurts itself).

Recommendation: Variant B as the pragmatic fix that restores consistency with the entire SHA-256 address ecosystem now, with Variant A as the strict-v1 upgrade if/when a SHA-256 gadget is added. Either is a maintainer call (version-bump implication).

Prerequisite (BLOCKER, both variants) — harden digest_from_bytes

program-plonky2/src/hash.rs:65 uses F::from_canonical_u64 although its own doc (:56-59) promises from_noncanonical_u64. For an externally-supplied 32-byte value (a SHA-256 address) with an 8-byte chunk ≥ the Goldilocks modulus (P≈9.3e-10/chunk) this debug-panics / yields a non-canonical element → not roundtrip-safe. This already affects all SHA-256 address parsing today. Fix: from_canonical_u64 → from_noncanonical_u64 (one line, aligns code with doc).

Exact change scope (Variant B)

• program-plonky2/src/hash.rs:65 — digest_from_bytes hardening (prerequisite); add a SHA-256(pubkey) → HashDigest helper (needs a sha2/bitcoin::hashes dep in this crate).
• program-plonky2/src/circuit/main.rs:665-666, 678-679 — remove the owner binding; update comments :626-638,:661-664.
• program-plonky2/src/types.rs:124 — AccountState::new owner → SHA-256 helper.
• node/src/account_node.rs:966 (prepare_mint) and node/src/flow.rs:112 (MintIdentity) — owner → SHA-256.
• Tests asserting a Poseidon owner: program-plonky2/src/types.rs:325, node/src/account_node.rs tests (~:85,:99).

Separate divergences (own issue, do NOT fold in)

calculate_asset_id (types.rs:235-246, main.rs:648-659) vs docs/specification.md:281: missing issuance_version in the preimage; genesis_tag string "zkcoins:asset-genesis:v1" vs spec "zkCoins/v1/genesis"; name_hash Poseidon vs spec SHA-256. Same circuit-impact class → handle in a dedicated issue.

Validation (no deployed node needed)

cargo test -p node account-node integration tests covering the mint owner + mint→send→commit (e.g. the mint_funded_asset path, prepare_mint_rejects_remint_into_existing_asset_account); add a mint-gate negative test that witnesses a free owner and confirms the balance>0-only-with-creator-binding still holds. The api_remote E2E roundtrips validate post-deploy.

Test side (separate, mergeable now)

The node/tests/api_remote.rs multi-asset contract fix (asset_id threading, two-phase creator-signed mint, repurposed negatives) is on SHA-256 per spec; the mint→balance/send roundtrips are #[ignore]d referencing this issue until the node fix lands. Draft PR forthcoming.

Deployment

Any circuit change regenerates the verifier key → existing proofs/state invalid → DEV needs reset_state; sequence the deploy accordingly (and treat as a hard fork on any network carrying value).