Add public single-signer AccountBlock-v1 unsigned preparation, canonical hashing, and verified signature attachment

[edgepillar]

Add public single-signer AccountBlock-v1 unsigned preparation, canonical hashing, and verified signature attachment

Status

Maintainer-aligned implementation plan. Work may proceed from the current main after #34 as three independently reviewable and shippable phases. At plan acceptance, main was 00a37f824e9eb3376c6063e489b6e412d42c2018.

This is additive work. Existing prepareBlock() and send() behavior must remain unchanged. This issue does not add publication, signer callbacks, wallet lifecycle management, cancellation, Dynamic Plasma, or a redesign of #27 multisig.

This body incorporates the three-phase implementation plan and the resolved contract decisions.

Resolved contract decisions

• Signature verification must match the pinned Go verifier exactly.
• Commit every pinned Go vector as a literal test fixture. Crypto.verify ships only if it matches every vector. Noble { zip215: false } is not assumed to be equivalent; any divergence must be reviewed explicitly.
• Use ZnnAccountBlockException, ZnnAccountBlockExceptionCode, and ZnnAccountBlockExceptionStage, following the SDK's Znn*Exception naming.
• The public method is zenon.prepareUnsigned(template, payer).
• The current getTxHash result is a legacy regression vector. A separately and independently sourced canonical vector is also required, and both must pass.
• PR feat: add mutable protocol-level multisig account support #27 remains separate. Do not change or replace its multisig API; its maintainer will update it after this work lands.

Pinned protocol evidence

• Chain account-block serialization and verification source: zenon-network/go-zenon@667a69d9e9a418edf7580b08492ba5dcb9efd63a.
• Go verifier implementation: Go 1.24.1, source commit 339c903a75c3fe936fb4ed6c355d15e6081d6af3.
• Differential corpus: filippo.io/mostly-harmless/ed25519vectors@v0.0.0-20210322192420-30a2d7243a94, repository commit 30a2d7243a949c5ec04d5026956319569200a40f, 768-vector JSON SHA-256 ed3dd0730ec5ef2dbfd629186fbefeb6299cbbf9a6ed94af0478f07291acacca.
• The pinned Go expectation accepts 198 vectors and rejects 570 vectors. The literal fixture must preserve source IDs, inputs, flags, and both accepted and rejected outcomes.
• Ordinary-valid corpus: Go's 128-vector sign.input.gz, SHA-256 ae02ad0b05f2aa54bbc1a90cd87d1733932caa298a243e69d6623f27d1251d5c, plus the official S >= L rejection case.

The fixture is read-only test evidence: no update, capture, regenerate, rewrite, or bless path may derive expected values from the candidate implementation.

Intended public surface

The completed work adds:

• computeAccountBlockHash
• computeAccountBlockHashBytes
• AccountBlockPayerIdentity
• PreparedUnsignedAccountBlock
• verifyAccountBlockSignature
• attachAccountBlockSignature
• ZnnAccountBlockException
• ZnnSDKException at the package root
• Zenon.prepareUnsigned(template, payer)

Internal helpers such as prepareUnsigned, getTxHash, normalizeAccountBlockAmount, prepareUnsignedTemplate, cloneAccountBlockTemplate, bytesEqual, and createPreparedUnsignedAccountBlock are not exported from the package root.

Phase 1 — exception taxonomy, hash module, and the block.ts seam

Part A — hash module

Files:

• test/utilities/accountBlockHash.spec.ts (new)
• src/utilities/errors.ts
• src/utilities/accountBlockHash.ts (new)
• src/utilities/block.ts

Work:

• Before moving production code, pin a fully specified current-HEAD getTxHash result as a legacy regression vector.
• Add a separately sourced canonical AccountBlock-v1 hash vector. It must not be generated by the candidate implementation.
• Add ZnnAccountBlockExceptionStage, ZnnAccountBlockExceptionCode, and ZnnAccountBlockException below ZnnBlockUtilitiesException.
• Move getTxHash verbatim from block.ts into the client-free leaf module accountBlockHash.ts.
• Add AccountBlockHashInput, normalizeAccountBlockAmount, module-private input validation, computeAccountBlockHashBytes, and computeAccountBlockHash.
• Import getTxHash into block.ts and re-export it there for existing internal consumers. Do not export it from the package root.
• Keep the canonical serializer in exactly one implementation.

Acceptance:

• Both the legacy regression vector and independent canonical vector pass before and after the move.
• test/utilities/block.spec.ts passes without assertion changes.
• computeAccountBlockHash agrees with getTxHash for well-formed input.
• Validation failures use the new exception taxonomy and the expected code/stage pairs.
• The amount parity matrix uses 9007199254740994, the exactly representable Number immediately above 2^53; do not use 2^53 + 1.
• Returned hash bytes are detached from live Hash.core storage.
• accountBlockHash.ts has no value dependency on pow/pow.js or zenon.js.
• Hash field order, widths, encodings, SHA3-256 use, excluded fields, and zero-PoW nonce bytes remain byte-for-byte unchanged.

Part B — unsigned preparation seam

Work:

• Change checkAndSetFields to accept address: Address and publicKey: Buffer instead of a KeyPair.
• Add internal prepareUnsignedTemplate, composed from checkAndSetFields and setDifficulty.
• Keep prepareBlock behavior by calling prepareUnsignedTemplate with the current key pair's address/public key and then calling the existing hash/signature stage.
• Leave setDifficulty, setHashAndSignature, getTxSignature, getPoWData, autofillTxParameters, send, isSendBlock, and isReceiveBlock behavior unchanged.

Acceptance:

• Field mutation order, RPC order, zero-PoW nonce, fused Plasma selection, error messages, mutate-in-place behavior, returned object identity, hashing, and signing remain unchanged.
• Part A and Part B are separate commits within the Phase 1 PR so either can be reverted independently.

Phase 2 — Go-compatible Crypto.verify and Base64 round trips

Files:

• src/crypto/crypto.ts
• src/model/nom/accountBlock.ts
• test/crypto/crypto.spec.ts
• test/model/nom/accountBlock.spec.ts (new if absent)
• a committed versioned literal Go-verifier fixture under test/fixtures/

Work:

• Add Crypto.verify(signature, message, publicKey) and initialize SHA-512 before verification.
• Preserve exact pinned Go-verifier behavior. The implementation must pass every committed literal Go vector; a Noble option alone is not acceptance evidence.
• If any pinned vector diverges, stop and review the behavior instead of silently hardening or weakening it.
• Decode publicKey and signature as Base64 in both account-block fromJson implementations, preserving the empty-buffer fallback.
• Add valid-signature, tampered-message, wrong-key, first-call initialization, and full pinned-vector tests.
• Add toJson() → fromJson() byte-equality tests for both AccountBlockTemplate and AccountBlock.

Acceptance:

• Every pinned Go vector matches.
• Ordinary valid signatures verify; tampered messages and wrong keys do not.
• Verification works as the first Crypto call in a fresh process.
• Both account-block types round-trip the original public-key and signature bytes.
• The Base64 behavior change is called out explicitly in the commit body.
• The crypto and Base64 edits remain separately revertible commits.

Phase 3 — offline surface and public API

Part A — offline surface

Files:

• src/utilities/accountBlockSigning.ts (new)
• test/utilities/accountBlockSigning.spec.ts (new)

Work:

• Add bytesEqual, AccountBlockPayerIdentity, PreparedUnsignedAccountBlock, createPreparedUnsignedAccountBlock, cloneAccountBlockTemplate, verifyAccountBlockSignature, and attachAccountBlockSignature.
• Copy byte inputs and outputs defensively.
• Make signature verification a total boolean predicate: malformed inputs return false rather than throwing.
• Recompute and verify the AccountBlock hash before accepting or attaching a signature.
• Preserve the single-signature/multisig boundary without changing feat: add mutable protocol-level multisig account support #27's public surface.

Acceptance:

• Clones preserve the complete key set and JSON value while removing mutable aliases.
• Identity and prepared-handle accessors return detached values.
• Signature-buffer mutation and key cleanup cannot alter a prepared handle.
• Attachment uses ZnnAccountBlockException with the defined code/stage pairs and never leaks a bare parser or encoding error.
• Hash, public key, address, and signature bindings are independently verified.

Part B — online orchestration and exports

Files:

• src/utilities/unsignedBlock.ts (new)
• src/zenon.ts
• src/index.ts
• test/utilities/unsignedBlock.spec.ts (new)

Work:

• Add internal prepareUnsigned(zenonInstance, template, payer).
• Validate address, recipient, and token-standard core lengths before any toString() comparison so malformed cores cannot escape as bare bech32 errors.
• Add the public two-argument Zenon.prepareUnsigned(template, payer) method.
• Export the public classes, hash helpers, verification/attachment functions, ZnnAccountBlockException, and ZnnSDKException from the package root.
• Do not root-export internal orchestration or cloning helpers.

Acceptance:

• The caller's input template is not mutated.
• The prepared handle stores detached data and normalizes amount to bigint.
• Zero-PoW preparation retains the canonical zero nonce behavior.
• prepareUnsigned plus verified attachment produces the same hash and signature as prepareBlock for equivalent send and receive inputs.
• verifyAccountBlockSignature never throws for malformed input.
• Package-root ESM, declarations, packed consumers, and browser imports expose the intended public surface only.
• Part A and Part B are separate commits within the Phase 3 PR.

Validation and delivery

Each phase is a separate, independently reviewable Draft PR and must pass:

• targeted tests for the phase;
• the complete test suite;
• lint;
• coverage;
• the full build;
• package-root and packed-consumer export checks.

Phase 1 lands before Phase 3. Phase 2 is independent of Phase 1 and may proceed separately, but Phase 3 requires both. Keep every PR limited to its phase.

Non-goals

• changing existing prepareBlock() or send() semantics;
• transaction publication;
• signer callbacks or hardware-wallet lifecycle;
• cancellation or timeout APIs;
• Dynamic Plasma;
• multisig redesign or changes to PR feat: add mutable protocol-level multisig account support #27's public API;
• consumer deep imports or copied private serializer logic;
• placeholder signing, double preparation, or production dual execution.

[digitalSloth]

Thanks for the detailed writeup — confirming there's no conflict here. This is scoped separately from the protocol-level multisig work in #27 (mutable multisig accounts), and the non-goals section makes that explicit.

I'll hold off on further multisig changes until this lands, then rebase #27 on top of it. The "PR #27 coexistence" critique is fair — freezeBlock/signBlock/assembleMultisigAuth currently mutate the input template and don't independently recompute/verify the hash before signing or attaching a signature. If this API introduces the immutable-handle pattern you're describing, I'd like to bring the multisig signing path in line with it rather than keep a second, divergent approach.

[edgepillar]

Thanks for confirming that this is separate from #27 and for the feedback on immutable handles.

I checked the pinned protocol and verifier sources. The RPC conversion maps an empty nonce to eight zero bytes, so I found no decoder conflict with the proposed zero-PoW representation. The hash primitive is SHA3-256, and signature verification needs the exact pinned Go behavior rather than an assumed equivalent Noble option.

My proposed next step is the independent-fixture and canonical-hashing foundation, followed by unsigned preparation and verified signature attachment. Existing prepareBlock() and send() behavior, multisig work, and downstream wallet lifecycle changes would remain outside that implementation boundary.

With #34 changing package-root exports and browser packaging, would you prefer the first Draft PR against current main, or after #34 lands?

[digitalSloth]

@edgepillar Iv merged #34 now so base from main. Heres a plan i came up with, it was based off the feature/browser-bundles branch, should all still apply, see if it aligns with what you had in mind. Happy to review when the PR is ready.

---

Overview

Three phases, grouped along the dependency graph the spec's module table
already fixes: Phase 1 pins the consensus preimage with a hash vector, moves
the serializer into its own leaf module with the new exception taxonomy, and
then opens the block.ts seam (prepareUnsignedTemplate) that prepareUnsigned
later calls — both parts touch the same file/region and the second strictly
depends on the first, so they ship as one unit. Phase 2 lands the two small
prerequisites the offline half needs — Crypto.verify and the fromJson
base64 fix — and has no dependency on Phase 1, so it can be done in parallel.
Phase 3 depends on both and builds the rest of the feature: the offline
surface (identity, handle, clone, verify, attach) and the online
prepareUnsigned orchestration, Zenon method, and public exports, ending
with the parity cross-check against prepareBlock. Every phase compiles,
passes the full suite, and ships on its own.

Sub-steps inside each phase are still ordered and separately revertible
(noted per phase) — combining phases changes what ships as one PR, not the
order work happens in.

Phase 1 — exception taxonomy, hash module, and the block.ts seam

Goal. computeAccountBlockHash / computeAccountBlockHashBytes exist as a
client-free entry point, the canonical serializer lives in exactly one place,
and prepareUnsignedTemplate exists with prepareBlock composed from it,
with byte-for-byte identical behaviour throughout.

Scope.

Part A — hash module (highest risk in this phase; land and verify before Part B).

• test/utilities/accountBlockHash.spec.ts (new) — write the pinned hash
  vector first, before touching block.ts. Compute getTxHash over a fully
  specified template at current HEAD, record the 64-char hex literal. Risk 1.
• src/utilities/errors.ts — add ZnnAccountBlockExceptionStage,
  ZnnAccountBlockExceptionCode, ZnnAccountBlockException below
  ZnnBlockUtilitiesException (errors.ts:3-8), reusing the ZnnSDKException
  import at errors.ts:1. Spec Design §2.
• src/utilities/accountBlockHash.ts (new) — AccountBlockHashInput,
  getTxHash moved verbatim from block.ts:24-49,
  normalizeAccountBlockAmount, module-private validateHashInput,
  computeAccountBlockHashBytes, computeAccountBlockHash. import type only
  for AccountBlockTemplate and BigNumberish. Spec Design §1.
• src/utilities/block.ts — delete :24-49; add
  import { getTxHash } from "./accountBlockHash.js"; plus a separate
  export { getTxHash }; (a bare re-export leaves block.ts:164 without a
  local binding). Drop the orphaned numberOrStringToBytes / numberToBytes /
  zeroPad import at block.ts:8; keep Hash for getPoWData.
• Rerun the pinned vector through the moved function before proceeding to Part B.

Part B — the block.ts unsigned seam (C1opt).

• checkAndSetFields(zenonInstance, transaction, address: Address, publicKey: Buffer)
  replaces the KeyPair parameter; body from block.ts:91-119 otherwise
  unchanged.
• New exported-but-internal prepareUnsignedTemplate = checkAndSetFields
  then setDifficulty.
• prepareBlock calls prepareUnsignedTemplate with
  currentKeyPair.getAddress() / getPublicKey(), then setHashAndSignature.
• setDifficulty, setHashAndSignature, getTxSignature, getPoWData,
  autofillTxParameters, send, isSendBlock, isReceiveBlock untouched.
  Spec Design §5.

Dependencies. None. (Part B depends on Part A within this phase.)

Success criteria.

• The pinned hex literal is identical before and after the move.
• test/utilities/block.spec.ts passes with zero assertion edits — this is
  the regression suite for both parts.
• computeAccountBlockHash agrees with getTxHash on well-formed input; each
  validateHashInput rule rejects with INVALID_TEMPLATE / hash.
• The amount parity matrix from the spec's Files table passes — use
  2**53 + 2 (or the literal 9007199254740994) in place of the spec's
  2**53 + 1, which evaluates to 2**53 and exercises nothing.
• Returned bytes are a copy, not the live Hash.core.
• accountBlockHash.ts imports neither pow/pow.js nor zenon.js, directly or
  transitively through a value import.
• Field mutation order, RPC call order, the "0000000000000000" zero-PoW
  nonce, fusedPlasma selection, the five pinned error message strings, and
  mutate-in-place-and-return semantics all preserved by Part B.

Risk. High — Part A is the consensus preimage; a changed byte breaks
every transaction the SDK signs. Part B is medium — a pure refactor of a hot
path, fully covered by the existing suite.

Rollback. One phase, two commits recommended (Part A, then Part B) so the
consensus-preimage move can be reverted independently of the seam refactor if
something surfaces later; nothing downstream exists yet to depend on either.

Order of attack. 1. Pinned vector test against HEAD. 2. errors.ts.
3. New hash module with the verbatim body. 4. normalizeAccountBlockAmount
and validateHashInput. 5. The two wrappers. 6. block.ts import/re-export
and import cleanup; rerun the pinned vector. 7. checkAndSetFields signature
and its two assignments. 8. Extract prepareUnsignedTemplate. 9. Rewrite
prepareBlock as the composition. 10. Full suite.

Phase 2 — Crypto.verify and the fromJson base64 fix

Goal. The two independent prerequisites of the offline half land and are
tested on their own.

Scope.

• src/crypto/crypto.ts — add
  static verify(signature: Uint8Array, message: Uint8Array, publicKey: Uint8Array): boolean,
  ensureSha512Sync() first, ed.verify(..., { zip215: false }), no catch. No
  existing signature changes. Spec Design §3.
• src/model/nom/accountBlock.ts — decode publicKey and signature as
  base64 in both fromJson implementations (:127-128, :252-253), with the
  ? : empty-buffer fallback. amount at :118 unchanged. Spec Design §8.
• test/crypto/crypto.spec.ts — valid signature, tampered message, wrong
  public key, and verify as the first Crypto call in the process.
• test/model/nom/accountBlock.spec.ts — create if absent; toJson →
  fromJson round-trip returns the original 32- and 64-byte buffers, for both
  AccountBlockTemplate and AccountBlock.

Dependencies. None — independent of Phase 1, can be done in parallel.
Phase 3 needs it.

Success criteria.

• Crypto.verify returns true for a Crypto.sign output and false for a
  tampered message or wrong key, in a process where no other Crypto method
  ran first.
• The round-trip test asserts byte equality on publicKey and signature.
• Full suite green; no existing test compensated for the base64 bug.

Risk. Medium — the fromJson change is a behaviour change for any consumer
that round-trips blocks today (Risk 5). Call it out as a fix in the commit
body.

Rollback. Two independent one-file edits within the phase; either reverts
alone.

Order of attack. 1. Crypto.verify plus its tests. 2. Both fromJson
sites plus the round-trip test. 3. Full suite.

Phase 3 — the offline surface and the public API

Goal. AccountBlockPayerIdentity, PreparedUnsignedAccountBlock,
verifyAccountBlockSignature, attachAccountBlockSignature, and
prepareUnsigned all work end to end, the feature is reachable as
zenon.prepareUnsigned(...), and the new symbols are exported.

Scope.

Part A — offline surface.

• src/utilities/accountBlockSigning.ts (new) — bytesEqual,
  AccountBlockPayerIdentity, PreparedUnsignedAccountBlock,
  createPreparedUnsignedAccountBlock, cloneAccountBlockTemplate,
  verifyAccountBlockSignature, attachAccountBlockSignature. Spec Design §4,
  including the byte-type rule from §3 (Uint8Array out, Buffer.from(...) at
  Buffer-typed call sites).
• test/utilities/accountBlockSigning.spec.ts (new) — the full matrix in the
  spec's Files table. In the cross-process round-trip amounts, substitute
  2**53 + 2 for 2**53 + 1.

Part B — online orchestration and public API (depends on Part A).

• src/utilities/unsignedBlock.ts (new) — the free
  prepareUnsigned(zenonInstance, template, payer), seven steps per spec
  Design §6. Zenon imported with import type.
• In-flight correction (spec §6 step 1): run the
  address / toAddress / tokenStandard core-length checks before the
  template.address.toString() identity comparison. An oversized core reaching
  Address.toString() first throws a bare untyped Error from bech32.encode's
  length limit and bypasses the taxonomy. This matches the ordering already used
  in the attach template path in Part A.
• src/zenon.ts — the two-parameter instance method next to prepareBlock
  (zenon.ts:104-113), delegating with Zenon.getInstance(), plus imports.
  Spec Design §7. Document Risks 6 and 7 on the method: the input template is
  not mutated, and handle.block.amount is always a bigint.
• src/index.ts — append the export block from spec Design §9 after
  index.ts:118-122, including export { ZnnSDKException } from "./exception.js";.
  Nothing from unsignedBlock.ts.
• test/utilities/unsignedBlock.spec.ts (new) — per the spec's Files table,
  reusing the makeZenon duck-typed factory from
  test/utilities/block.spec.ts:18-37, and
  afterEach(Zenon.clearPowProvider).

Dependencies. Phase 1 (Part A needs the hash module; Part B needs the
block.ts seam) and Phase 2 (Part A needs Crypto.verify and the fromJson
fix).

Success criteria.

• verifyAccountBlockSignature never throws on any input in the test matrix —
  including null publicKey, a new Address("z", Buffer.alloc(3)), and a
  non-Buffer data — and returns false instead.
• cloneAccountBlockTemplate: Object.keys(clone) equals
  Object.keys(original) and clone.toJson() deep-equals original.toJson()
  (Risk 3 tripwire for PR feat: add mutable protocol-level multisig account support #27's multisigAuth).
• Every accessor on the handle and the identity returns a detached copy;
  mutating a returned value and calling KeyPair.clear() leave the handle
  verifiable.
• attachAccountBlockSignature template path: every pre-check throws a
  ZnnAccountBlockException with the code/stage pair from the spec's table,
  and a malformed Address/TokenStandard core never escapes as a bare
  Error.
• Round-trip through handle.block.toJson() → fromJson → detached signature
  → attach yields a block whose hash is byte-identical to handle.hash.
• The parity cross-check: prepareUnsigned +
  attachAccountBlockSignature(handle, keyPair.sign(handle.hash)) yields
  byte-identical hash and signature to prepareBlock for the same inputs,
  on both the send and receive RPC paths.
• Every pre-check and post-check raises its spec-table code/stage pair; an
  oversized address core raises INVALID_TEMPLATE / input, never a bare
  Error.
• ZnnBlockUtilitiesException from receive-block validation surfaces as
  RECEIVE_BLOCK_INVALID / autofill with its original message text;
  ZnnClientException propagates untouched.
• The caller's input template is unmutated after the call.
• handle.block.amount is a bigint for a number input while the hash
  matches prepareBlock's.
• Zero-PoW path yields nonce "0000000000000000".
• A consumer can import { computeAccountBlockHash, ZnnSDKException, … } from
  the package root; prepareUnsigned, getTxHash, normalizeAccountBlockAmount,
  prepareUnsignedTemplate, cloneAccountBlockTemplate, bytesEqual and
  createPreparedUnsignedAccountBlock are not exported from src/index.ts.

Risk. Medium-high overall. Part A is the largest new surface, and the
pre-check ordering is where a bare Error can escape the taxonomy — assert
the exception type in every rejection test, not just that it throws. Part B
is orchestration over already-tested parts (Part A plus Phase 1's core); the
RPC-order and Plasma branches are covered by Phase 1's suite.

Rollback. Two commits recommended (Part A, then Part B) so the offline
surface can be reverted or held back independently of wiring it into the
public API; nothing imports Part A's module until Part B.

Order of attack. 1. bytesEqual and cloneAccountBlockTemplate plus the
key-set/toJson test. 2. AccountBlockPayerIdentity. 3.
PreparedUnsignedAccountBlock and its factory. 4.
verifyAccountBlockSignature. 5. attachAccountBlockSignature — step 0, then
each resolve path, then the three shared steps. 6. The template-path rejection
matrix. 7. prepareUnsigned steps 1-3 (pre-checks with the corrected
ordering, clone, amount normalisation). 8. Step 4 core call and its rewrap.
9. Steps 5-7. 10. zenon.ts method. 11. src/index.ts exports. 12. Tests,
parity cross-check last. 13. Full suite plus a build.

[edgepillar]

Thanks — the three-phase decomposition and basing the work on current main generally align with what I had in mind. Before I start Phase 1, I’d like to pin three contract details so the implementation and tests do not encode conflicting behavior:

1. Verifier behavior. The current Add public single-signer AccountBlock-v1 unsigned preparation, canonical hashing, and verified signature attachment #31 text requires exact parity with the pinned Go verifier and explicitly notes that Noble { zip215: false } is not consensus-equivalent. Should Phase 2 preserve that Go-compatible contract and differential corpus, with Crypto.verify used only if it matches every pinned vector, or should Add public single-signer AccountBlock-v1 unsigned preparation, canonical hashing, and verified signature attachment #31 be revised to define a deliberately different hardened profile?
2. Public API and errors. The plan uses ZnnAccountBlockException and a two-argument zenon.prepareUnsigned(template, payer), while Add public single-signer AccountBlock-v1 unsigned preparation, canonical hashing, and verified signature attachment #31 currently specifies AccountBlockV1Error and a third expectedChainIdentifier options argument. Should the plan replace those declarations, or should the implementation still conform to the issue text?
3. Hash evidence. I agree with pinning the current getTxHash result before moving the serializer. I would treat that as a legacy regression vector and add an independently sourced canonical vector, rather than use the current implementation as the sole oracle. Is that the intended acceptance boundary?

I also rechecked #27 at its current head. It remains open and overlaps src/utilities/block.ts, src/model/nom/accountBlock.ts, and src/index.ts, so I will keep the single-signature work compatible with its existing surface and avoid changing its multisig API.

Once these points are aligned, I can open an early Draft PR for Phase 1 from current main.

[digitalSloth]

1. Keep the Go-compatible contract. Crypto.verify ships only if it matches every pinned Go vector; commit the literal vectors as a test fixture. If Noble diverges on any of them, we decide then, not silently.
2. The plan replaces the issue text. Use ZnnAccountBlockException (the SDK's Znn*Exception naming) and the two-argument zenon.prepareUnsigned(template, payer). Please update the issue to match.
3. Agreed. The current getTxHash result is a legacy regression vector; add an independently sourced canonical vector, and both must pass.

Dont worry about the multisig PR, its still a draft so I'll just update it after this lands

[edgepillar]

Updated the issue body to reflect the resolved contract decisions and the agreed three-phase implementation plan. It now uses ZnnAccountBlockException, the two-argument zenon.prepareUnsigned(template, payer) API, exact Go-verifier compatibility with literal vectors, and both legacy and independently sourced canonical hash vectors.