v11.2.0

• NormalizeInnerTransaction no longer rewrites the transaction it is given (#157). The method strips TxnSignature, Signers and LastLedgerSequence and overwrites Fee, SigningPubKey and Flags. It did that to the caller's own JsonObject and returned that same instance, so anything a consumer held and passed in came back altered. It now normalises a copy and leaves the argument alone.

  • the two overloads no longer disagree. NormalizeInnerTransaction(object) rewrote its argument when the runtime type happened to be a JsonObject and did not when it was anything else - the same call, with aliasing decided by a type test the caller cannot see
  • SignAsBatchPart depended on the mutation, and not visibly. It normalises each inner transaction, hashes the results into the batch preimage, and finally encodes outer into the blob - and the normalised fields reached that blob only because normalisation rewrote the objects living inside outer. The call site read as though it merely collected a list for the txIDs. It now writes the normalised transaction back explicitly, which is what the old code achieved by side effect
  • nothing pinned any of this. The batch fixture supplied inner transactions that already carried Fee = "0", SigningPubKey = "" and tfInnerBatchTxn, so normalisation was a no-op on them: making the method return a copy left all 1215 unit tests green while the emitted blob carried inner transactions the signature never committed to. Both halves are now pinned - that the blob carries normalised inners, and that the signature covers a preimage built from them (#158)
  • a caller who relied on the old behaviour was relying on something the documentation denied until it was corrected in #156

• A malformed RawTransactions entry is named instead of failing inside a converter (#160). An element that is not a JSON object was refused by System.Text.Json as Expected StartObject token thrown from DictionaryObjectConverter - the first thing a caller saw about a malformed batch, naming neither the field nor the position, while every other malformed input on this path answers with a ValidationException that says what is wrong. GetBatchSignerAccounts, the gate every batch-signing path reaches before any XLS-56 check, now refuses it as RawTransactions[i] must be an object., and the same holds one level down for RawTransactions[i].RawTransaction.

  • an element is judged by what it serializes to, never by its runtime type. A JsonArray built through Add<T> holds a JsonValue rather than a JsonObject and still writes a JSON object; testing the node type would have refused input the old code accepted, and would have accepted or rejected the same object depending on whether it arrived in a JsonArray or a List<object>
  • SignAsBatchPart no longer filters its inner-transaction loop on n is JsonObject either. That guard cannot fire - the gate above refuses such an element first, shown by mutation - but a silent skip is the wrong thing to leave behind, and every other malformed input in that loop is refused rather than dropped
  • Batch.Validate called such an element null in its message when it was, for instance, a string. It now says what is actually wrong

• GetBatchSignerAccounts no longer rewrites the batch it is asked to report on (#161). The method returns the root account and the accounts required to sign, and it also replaced RawTransactions[i].RawTransaction in the caller's own dictionary with a converted copy - the IEnumerable branch aliases an element that is already a Dictionary, so the assignment landed in the caller's object. It is the gate every batch-signing path reaches through VerifyBatchSubmitter, so this happened on every signature.

  • the conversion is still made, for reading; only the store-back is gone. No consumer needed it: every reader of RawTransaction works from a JsonNode built by re-serializing the transaction, not from the dictionary that was passed in
  • that the two representations sign identically is now pinned by a test of its own, since it is the property that makes dropping the store-back safe rather than merely tidy