> For the complete documentation index, see [llms.txt](https://argon-4.gitbook.io/argon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argon-4.gitbook.io/argon-docs/suresign/verification.md).

# Verification

How SureSign is verified: upstream pins, golden vectors, adversarial fixtures, live-network fixtures, continuous checks, and reproducible builds you can confirm yourself.

Confidence in a signing kernel should not rest on its authors' word. This page lists what is checked, how, and what you can check yourself.

## Pinned upstream

SureSign does not reimplement Kaspa consensus. It compiles the reference implementation's crates into the kernel at a fixed version and treats that version as the definition of correctness.

| Dependency            | Pin                                 | Role                                                                                               |
| --------------------- | ----------------------------------- | -------------------------------------------------------------------------------------------------- |
| rusty-kaspa           | `v2.0.1` @ `cfafeb4c`               | Transaction types, script engine, mass, sighash, addresses, covenant ids, KIP-5 hashing            |
| SilverScript compiler | `v1.0.0` @ `3ed97333`               | Reproduces the existing covenant artifacts unchanged; compiled output ships, the compiler does not |
| KCC standards         | `kaspanet/kccs` @ `ea5176aa`        | Covenant ABI and token conventions                                                                 |
| KIP-12 provider draft | `kaspanet/kips` PR #44 @ `4fc711ac` | dApp provider method set                                                                           |
| KIP-5 message signing | `kaspanet/kips` @ `0199f8d4`        | Personal message hashing, official vectors                                                         |
| Kasia cipher          | K-Kluster Kasia @ `acd3cf65`        | Deal Desk sealing, conformance fixtures from the upstream crate                                    |
| Rust toolchain        | `1.91.0`                            | Pinned in `rust-toolchain.toml`                                                                    |
| Node                  | `22.22.1`                           | Pinned in `extension/package.json`                                                                 |
| `wasm-bindgen-cli`    | `0.2.100`                           | Kernel bindings                                                                                    |

Every consensus-sensitive change cites the upstream commit it was read from. The full matrix, with dates last verified and open uncertainties, is in the repository's `docs/UPSTREAM_MATRIX.md`; a readable summary is under [Developers → Upstream pins](/argon-docs/developers/upstream.md).

## Kernel tests

The kernel carries about five hundred Rust tests, run in CI on every change with and without the WebAssembly feature. They fall into families:

* **Golden vectors.** Supported purpose-built covenant spend paths execute in the pinned reference script engine with a covenant context. Current-planner tests cover 17 spend/recipient cases with both inputs, constrained outputs, fee accounting, HD change, and correctly signed negative mutations. Separate family tests cover role/destination rules, continued identities, retired revisions, and supported integer widths. These tests do not enable the refused Lab or unknown-template families. Inscription construction for KRC-20, KRC-721, and KNS is checked against known payloads and the protocols' documented rules. KIP-5 official vectors pass. Kasia cipher fixtures produced by the upstream crate decrypt.
* **Invariant tests.** Policy invariants are exercised by tests that trigger them: a dApp-declared change output, a substituted sighash, a network mismatch, a stale Note, a fee the kernel did not compute, a post-sign byte that does not match the plan.
* **Adversarial fixtures.** Hidden recipient, fake change, altered amount, excessive fee, unexpected payload, wrong network, duplicate input, stale Note, malicious sighash, covenant id substitution, template substitution, token inflation, lying indexer, origin confusion, replayed authorization, corrupted vault, and more. Each must be refused with the right invariant named.
* **Fuzzing baseline.** The vault envelope, address, transaction, inscription, and pack JSON parsers are exercised with hostile bytes and must fail closed without panicking.
* **Historical network fixtures.** The 2026-09-04 testnet-10 records preserve accepted creates and selected spends, reported covenant ids, and directory names. Local replay independently recomputes all 32 serialized transaction IDs and checks selected blueprint and identity fields. Five rejection records lack transaction bytes and remain recorded node-response text. The replay does not reconstruct complete historical ReviewPlans, fee inputs, or node DAA/UTXO context, and it is not a byte-for-byte planner rebuild. Transaction IDs also exclude witness and mass commitments. Some post-window heir and TimeLock branches still lack recorded node-positive vectors; [Covenants](/argon-docs/suresign/covenants.md) states that limit.

## Host tests

The extension carries about seventy test files that pin the host's behaviour to the kernel's: the dApp method allowlist and error codes, origin binding and permission expiry, the host access list, the Enclave fee clamp and fallback, the KATCLAIM waiver rules, activity and journal rendering, session and auto-lock behaviour, and **design laws**: tests that read the source and fail if, for example, a component performs its own transaction arithmetic, a secret-shaped field crosses the transport, or a legal notice is missing from a review surface.

The extension is type-checked in strict mode and has no runtime dependency fetched from a CDN.

## Continuous checks

Every push runs: required-documentation presence, a wasm32 compile of the kernel, the Rust test suite (both feature sets), the extension tests and production build, `npm audit` at the high threshold for production dependencies, and `cargo deny` for advisories, licenses, and duplicate or banned crates. Security-critical changes are never auto-merged.

## Reproducible builds

A release is built from a clean checkout at a signed tag by `scripts/release.sh`. The build sets `SOURCE_DATE_EPOCH` to the commit time, sorts archive entries, and produces the unpacked extension, a software bill of materials, the store zip, and a `SHA256SUMS` manifest. Two builds of the same commit are byte-identical.

Tags are signed with SSH; the allowed signers are published in the repository (`docs/ALLOWED_SIGNERS`) so anyone can verify a tag without trusting a key server. The Chrome Web Store build is the release build; the published extension's files can be hashed and compared with the manifest.

To verify yourself, see [Developers → Verify a release](/argon-docs/developers/verify-a-release.md).

## Qualification before release

Before a version ships, the qualification record in `docs/TESTING.md` is updated with the build under test and, for every shipped flow, how it was exercised: on the release build against testnet-10 in both Compact and Studio (restore and discovery, network switch, send through to confirmation, vault create), from a traced mainnet exercise where a flow cannot run on testnet (escrow and the Deal Desk end to end, Igra carriers, Exchange and Earn providers), or from kernel vectors and unit tests, with anything lacking a recorded interface pass listed as a follow-up. The release gates and their closing conditions are in `docs/ENGINEERING.md` and the `docs/GATE_*.md` records.

## What is not claimed

SureSign has not yet had an independent third-party audit. The current release relies on the in-repo verification above, on pinned reference code for everything consensus-sensitive, and on the fail-closed policy that keeps unproven behaviour out of the signing path. An independent review is on the [roadmap](/argon-docs/suresign/roadmap.md); until then, the source is public and the builds are reproducible so that anyone may review it.