quantus
Repositories
5
 Projects Packages

@quantus/codec (0.3.0)

Published 2026-09-15 12:07:05 +00:00 by grenade in quantus/wasm

Installation

@quantus:registry=
npm install @quantus/codec@0.3.0
"@quantus/codec": "0.3.0"

About this package

@quantus/codec

Metadata-driven SCALE encode and decode for the Quantus chain, compiled to WASM.

Nothing in this package names a pallet, a call, a signed extension or a signature scheme. Everything is read from the metadata the node produced by running Metadata_metadata against the runtime WASM in a given block's state, which makes the runtime the oracle rather than this package's author.

Why not @polkadot/api

Three reasons, in increasing order of importance — the evidence is on quantus/api#1.

  1. @polkadot/types refuses fixed arrays longer than 2048 bytes. ML-DSA signatures are [u8;5261] and [u8;7219], so every Quantus extrinsic trips it.
  2. api.rpc.chain.getBlock throws on every block of this chain, at the timestamp inherent. The extrinsic preamble byte's top two bits are a type tag (0b00 bare, 0b10 signed, 0b01 general) and the low six are the version; Quantus emits 0x84 — signed, v4 — and 0x05 — bare, v5 — in the same block while the metadata declares version 4. polkadot-js reads that byte as a version.
  3. It guesses that signed extensions it does not recognise contribute nothing to the signed payload, logging Unknown signed extensions … treating them as no-effect.

The third is why this package exists rather than a patch. The guess is correct only while every unrecognised extension happens to be zero-sized. This chain's encoding has already changed between runtimes — transactionVersion has gone 2 → 3 → 6 across four upgrades, each an extrinsic-format change — and when the guess stops being correct the wallet keeps signing. Those signatures are cryptographically valid, over a payload missing bytes the runtime put there, and the chain reports them as BadProof, which is also what it reports for a wrong key. Silent, remote, and indistinguishable from the one thing it is not.

Here the registry decides. An extension whose declared type encodes to nothing contributes nothing; anything else must be supplied by the caller or no payload is produced at all.

Use

import { Runtime } from '@quantus/codec';

const runtime = Runtime.fromMetadata(await fetchMetadata()); // state_getMetadata

const call = runtime.encodeCall('Balances', 'transfer_keep_alive', {
  dest: { Id: '0x…' },
  value: '1000000000'
});

const values = runtime.standardExtensions({
  blockHash: genesisHash, // immortal era
  genesisHash,
  nonce,
  specVersion,
  transactionVersion
});

const payload = runtime.signerPayload(call, values);
// sign `payload` with @quantus/crypto under the QUANTUS_EXTRINSIC context,
// hashing it first with BLAKE2b-256 if it is longer than 256 bytes
const extrinsic = runtime.encodeExtrinsic(
  { Id: accountId },
  signature,
  runtime.encodeExtra(values),
  call
);

standardExtensions fills in the extensions Substrate itself defines. Anything else this runtime declares as non-empty is refused by name — see above for why that is the desired behaviour rather than a limitation.

Build

./scripts/build-quantus.sh quantus-codec

Same constraints as @quantus/crypto: a modern toolchain (separate from wasm-crypto's 2022 nightly), initSync over base64+zlib for the MV3 CSP, wasm-bindgen's own glue rather than @polkadot/wasm-bridge, and binaryen 123 — version 105 silently corrupts the output. See quantus/wasm#1 and #3.

Dependencies

Dependencies

ID Version
fflate ^0.8.2
tslib ^2.7.0
Details
npm
quantus/wasm
2026-09-15 12:07:05 +00:00
1
Quantus Network Developers
Project Site
Apache-2.0
137 KiB
Assets (1)
codec-0.3.0.tgz 137 KiB
Versions (5) View all
0.5.0 2026-09-15
0.4.0 2026-09-15
0.3.0 2026-09-15
0.2.0 2026-09-15
0.1.0 2026-09-15
Issues