Skip to content

> FULL_SURFACE

Everything we cover, and how far each piece has got.

SSX360 sells signing products and scoped cybersecurity services. Matrix Scroll is the open protocol underneath, covering build steps, infrastructure changes, database migrations, API calls, contract deployments, and Git commits. Every line below names its delivery state and source.

The protocol covers five action types beyond Git, verified offline with no account and no key, and our scoped services cover four sectors. Naming a scheme anywhere on this page is an evidence mapping, not a certification claim.

6

signed action types

Git commit plus CI step, infrastructure, migration, API call and contract deploy

14

MCP verbs

Six read-only, five writing local artifacts, three that can reach ssx360.com

4

sectors assessed

Logistics, defense, finance and climate

6

engagements

Provenance Snapshot, Vulnerability & Audit Report, Stability Assessment, Embedded Sprint, Advisory Retainer and PQ Signature Inventory

How each surface is supplied

Matrix Scroll is open software. SSX360 products and services are commercial. Each proposal names which surface is being supplied and what remains available without an account.

Matrix Scroll

Open protocol and SDK

  • Apache-2.0 on PyPI and on GitHub at SSX360/matrixscroll, installable by anyone with no account.
  • Every verification path in the package runs offline. Signing, range checks and export need no key from us.
  • Three MCP verbs can reach ssx360.com when SSX360_API_KEY is set. Two of those three have an offline source you can use instead.
  • Release 0.7.0 includes the 14-tool MCP server and host integration for the SSX360 USB signer.

SSX360

Commercial products and scoped services

  • The completed RP2350 and NXP SE050 USB signer is produced and supplied through direct contact.
  • Six services: Provenance Snapshot, Vulnerability & Audit Report, Stability Assessment, Embedded Sprint, Advisory Retainer, PQ Signature Inventory.
  • The deliverable is a signed document and an evidence package, both verifiable without calling us.
  • Fees are quoted on the introductory call once the sectors and systems in scope are visible.
  • Service proposals name the evidence, methods, limits, and deliverables in scope.

Cybersecurity products and scoped services for signed evidence, machine authorization, and post-quantum migration.

Prove who authorized a change to your codebase

An envelope is the signed record itself, a small file that travels beside the change it describes. A commit envelope binds the declared actor type, producing tool and optional path scope to one commit, then signs that text with Ed25519 per RFC 8032. Verification re-runs the identical check with no network call.

  • Signed commit envelope

    Shipping

    Records actor type, tool, optional path scope and the commit tree against a commit SHA, then signs the canonical bytes with Ed25519.

    Protocolmatrixscroll/git.py, schemas/commit-envelope.v1.json

    [STABILITY_ASSESSMENT →]

  • Offline verification of one commit

    Shipping

    Re-checks the signature, the schema and the declared commit SHA from a local file with no account, no API key and no network.

    Protocolmatrixscroll/gate.py, matrixscroll verify

    [STABILITY_ASSESSMENT →]

  • Scroll Gate over a pull request range

    Shipping

    Walks every commit between two Git refs and fails the range when an envelope is missing, unsigned, or outside the trusted-key and actor policy.

    Toolingmatrixscroll/gate.py verify_envelope_range

    [STABILITY_ASSESSMENT →]

  • Git notes as the CI transport

    Shipping

    Writes each signed envelope into refs/notes/matrixscroll so a runner can read provenance from the clone. Pushing that ref to the remote stays a separate command you run.

    Protocolmatrixscroll/gate.py publish_envelopes_to_notes

    [STABILITY_ASSESSMENT →]

  • Pull request verification as a GitHub Action

    Shipping

    A composite action that installs matrixscroll 0.7.0, fetches the notes ref and runs the range check inside your workflow with no API key.

    ToolingSSX360/matrixscroll .github/actions/verify/action.yml

    [STABILITY_ASSESSMENT →]

  • SLSA source evidence notes

    Shipping

    Documents how commit envelopes and the protected-branch gate can support a source-provenance review, without presenting the mapping as certification or a complete SLSA implementation.

    Protocoldocs/SLSA_SOURCE_TRACK_MAPPING.md

    [STABILITY_ASSESSMENT →]

Prove what your pipeline, infrastructure, database and contracts did

One verb, sign_action, produces a matrixscroll.action_envelope.v1 for five action types that have nothing to do with Git. Each type declares required payload fields and the signer rejects a payload that omits them, so a signed action is a checkable record rather than a free-text note.

  • Build and CI step provenance

    Shipping

    Signs a ci_step envelope carrying the pipeline, the step name and the run id, so a release can be traced to the run that produced it.

    Protocolmatrixscroll/provenance/actions.py, tests/test_provenance.py

    [STABILITY_ASSESSMENT →]

  • Infrastructure change provenance

    Shipping

    Signs an iac_change envelope carrying the tool (Terraform, Pulumi or another), the resource type and the resource id that changed.

    Protocolmatrixscroll/provenance/actions.py _REQUIRED_FIELDS

    [STABILITY_ASSESSMENT →]

  • Database migration provenance

    Shipping

    Signs a db_migration envelope carrying the migration id, the database and the direction, so an up or a rollback both leave a record.

    Protocolmatrixscroll/provenance/actions.py _REQUIRED_FIELDS

    [STABILITY_ASSESSMENT →]

  • API call provenance

    Shipping

    Signs an api_call envelope carrying the method, endpoint and returned status code for calls made by an automated process.

    Protocolmatrixscroll/provenance/actions.py _REQUIRED_FIELDS

    [STABILITY_ASSESSMENT →]

  • Contract deployment provenance

    Shipping

    Signs a contract_deploy envelope carrying the chain, the contract address and the transaction hash of the deployment.

    Protocolmatrixscroll/provenance/actions.py _REQUIRED_FIELDS

    [STABILITY_ASSESSMENT →]

  • Parent action links

    Shipping

    Carries a parent_actions list on an envelope so a deployment can point back at the CI step and the commit it came from.

    Protocolschemas/action-envelope.v1.json

    [STABILITY_ASSESSMENT →]

Hand an assessor something they can check without calling us

Export writes files an assessor opens on their own machine. The bundle is plain JSON envelopes plus an index. The GUAC serialization is in-toto statements as JSONL, and the evidence pack adds a framework tag on top of that bundle. Nothing in the offline path phones home.

  • Envelope bundle export

    Shipping

    Copies every envelope for a commit range into one directory with an index.json that also lists the commits holding no envelope.

    Toolingmatrixscroll/gate.py export_envelope_bundle

    [VULNERABILITY_&_AUDIT_REPORT →]

  • GUAC ingest export

    Shipping

    Serializes verified envelopes as in-toto statements in JSONL so a supply-chain graph can ingest them alongside build attestations.

    Toolingmatrixscroll/guac_export.py

    [VULNERABILITY_&_AUDIT_REPORT →]

  • Evidence pack export

    In development

    Writes an unsigned JSON index around an exported envelope bundle and adds one framework mapping. In 0.7.0, the underlying envelopes remain signed; the index is a convenience container and its annotation is evidence mapping, not a certification claim.

    Toolingmatrixscroll/ssx360_cli.py ledger export

  • Trusted key and actor policy

    Shipping

    Filters a verification run by signing mode, trusted public keys, allowed schemas, actor allow and deny lists, delegation requirements and declared scope.

    Protocolmatrixscroll/policy.py VerifyPolicy

    [VULNERABILITY_&_AUDIT_REPORT →]

  • Machine-checked gate specification

    Shipping

    Model-checks the gate, the canonical byte encoding and the dual-signature overlay as TLA+ specifications on every run of the formal-verify workflow.

    Protocolformal/tla/ScrollGate.tla, .github/workflows/formal-verify.yml

    [VULNERABILITY_&_AUDIT_REPORT →]

  • Transparency log publishing

    In development

    Writes a Rekor-shaped record locally today and shells out to rekor-cli when it is installed. The module still describes itself as a stub and no proof verification runs on our side.

    Toolingmatrixscroll/rekor_publish.py

Know when an MCP server's tools change

An MCP server can add a tool or rewrite an input schema after approval. Scanning fingerprints the surface at install time, signing pins that fingerprint, and a later scan diffs against the baseline. The same signing path covers a browser automation run log.

  • MCP tool surface fingerprint

    Shipping

    Hashes each tool name, its description and a canonical hash of its input schema, then combines them into one surface hash for the server.

    Toolingmatrixscroll/mcp_trust.py scan_mcp_server

    [PROVENANCE_SNAPSHOT →]

  • Signed MCP manifest

    Shipping

    Ed25519-signs the fingerprint as an ssx360.mcp-manifest.v1 document you can commit and verify later offline.

    Toolingschemas/ssx360.mcp-manifest.v1.json

    [PROVENANCE_SNAPSHOT →]

  • Tool surface drift detection

    Shipping

    Diffs a fresh scan against the signed baseline and reports added tools, removed tools and changed descriptions or input schemas.

    Toolingmatrixscroll/mcp_trust.py diff_mcp_manifests

    [PROVENANCE_SNAPSHOT →]

  • Browser run trace signing

    Shipping

    Hashes a JSONL run log, records its run id and step count, and emits a signed trace envelope that flags later edits.

    Toolingmatrixscroll/agent_trace.py

    [PROVENANCE_SNAPSHOT →]

  • Matrix Scroll MCP server, fourteen verbs

    Shipping

    Exposes the protocol to an MCP-compatible client over stdio: six read-only verbs, five that write local artifacts, and three that can reach ssx360.com when SSX360_API_KEY is set.

    Toolingmatrixscroll/mcp.py

    [PROVENANCE_SNAPSHOT →]

Decide where the signing key lives

Matrix Scroll supports a local software signer and the completed SSX360 USB signer. The labels below separate released software, the available product, and experimental integrations.

  • Software signer, emulated mode

    Shipping

    Generates and stores an Ed25519 key locally and signs canonical manifest bytes through the cryptography package. This is the default and the supported evaluation path.

    Protocolmatrixscroll/providers/emulated.py, matrixscroll/crypto_backend.py

    [STABILITY_ASSESSMENT →]

  • Post-quantum overlay

    Shipping

    Attaches an ML-DSA or SLH-DSA signature alongside the Ed25519 one through liboqs, covering ML-DSA-44, 65 and 87 and SLH-DSA-SHA2-128s and 128f. Read the scope limit below before relying on it.

    Protocolmatrixscroll/pqc.py, matrixscroll[pqc] extra

    [PQ_SIGNATURE_INVENTORY →]

  • SE050 secure element signing

    Available product

    An NXP SE050 signs the same canonical bytes over an RP2350 USB serial bridge while the private Ed25519 key remains inside the secure element.

    Hardwaredocs/hardware-provider.md, matrixscroll/providers/hardware.py

  • Pico 2 W and GMT130 display bring-up

    Available product

    The produced SSX360 USB signer uses an RP2350 bridge and displays signing state on a GMT130 ST7789 panel. Physical units are supplied through direct contact.

    Hardwaredocs/operations/HARDWARE-M1-SE050-ACCEPTANCE.md

  • YubiKey PIV signer

    In development

    Sits behind an explicit experimental environment flag and signs with ECDSA over PIV, which does not match the Ed25519 byte contract the verifier enforces.

    Hardwarematrixscroll/providers/yubikey.py

  • TPM signer

    In development

    Probes for a TPM, then signs with a file-backed Ed25519 key regardless. Nothing is sealed to the TPM yet.

    Hardwarematrixscroll/providers/tpm.py

Scope a cybersecurity service

Six engagements, four sectors, one deliverable shape: a signed document with findings ranked by what blocks a decision and an evidence package that verifies offline. Durations are public. Fees are quoted on the call once scope is visible.

  • Provenance Snapshot

    Shipping

    A five to seven day provenance read for an acquirer deal team, signed before the close date. Covers model provenance, training-data origin and what the target's automated systems are authorized to execute.

    Servicelib/services.ts ENGAGEMENTS

    [PROVENANCE_SNAPSHOT →]

  • Vulnerability & Audit Report

    Shipping

    A focused five to seven day audit of one system, site or counterparty, with the gaps we can prove ranked by decision urgency.

    Servicelib/services.ts ENGAGEMENTS

    [VULNERABILITY_&_AUDIT_REPORT →]

  • Stability Assessment

    Shipping

    A sector-mapped assessment of exposure across logistics, defense, finance and climate, delivered over two to three weeks as one signed document. This is the flagship.

    Servicelib/services.ts ENGAGEMENTS

    [STABILITY_ASSESSMENT →]

  • Embedded Sprint

    Shipping

    Three weeks embedded alongside your operation with signed findings on a decision cadence. One slot a quarter. Retainer conversion is named in the engagement letter.

    Servicelib/services.ts ENGAGEMENTS

    [EMBEDDED_SPRINT →]

  • Advisory Retainer

    Shipping

    Monthly analyst-run sector coverage with quarterly re-assessment. Available once an assessment has completed.

    Servicelib/services.ts ENGAGEMENTS

    [ADVISORY_RETAINER →]

  • PQ Signature Inventory

    Shipping

    A three to four day inventory of classical signature surfaces and migration touchpoints. Included inside Stability when that surface is in scope.

    Servicelib/services.ts ENGAGEMENTS

    [PQ_SIGNATURE_INVENTORY →]

  • Four-sector signal coverage

    Shipping

    Logistics corridors, defense open-source reporting, financial counterparties and climate stress indicators are the four sectors every engagement draws on.

    Servicelib/claims.ts SECTORS

    [STABILITY_ASSESSMENT →]

Read the research before you buy anything

The Intelligence Log is free and stays free. Two standing data products are named on /research and both are still being built, so the honest count today is one published report.

  • Intelligence Log

    Shipping

    Biweekly field notes across the four sectors on a permanent archive URL. One report is published as of August 2026, so weigh the archive at that size.

    Researchlib/research-reports.ts, /research

    [INTELLIGENCE_LOG →]

  • Sector risk index

    In development

    A recurring score of logistics, defense, finance and climate exposure signals, with headline scores intended to stay public. No issue has been published.

    Researchlib/claims.ts RESEARCH_PIPELINE

  • Incident registry

    In development

    A cross-sector count of disruption incidents tagged by root cause. Scoped and named, with no entries published yet.

    Researchlib/claims.ts RESEARCH_PIPELINE

Install the protocol

pip install "matrixscroll==0.7.0"

Pin the version. 0.7.0 is the release on PyPI and the newest tag in SSX360/matrixscroll, and the verify action defaults to the same number.

What the signer display shows

The SSX360 USB signer draws its state on a GMT130 240 by 240 display. Each face is shown at native pixel scale so the labels match the physical panel.

  • The signer's resting face, drawn for the 240 by 240 display

    Resting

    Idle, with no signing session open.

  • The signer's active face, drawn for the 240 by 240 display

    Active

    A signing session is open.

  • The signer's alert face, drawn for the 240 by 240 display

    Alert

    Waiting for the touch that approves a signature.

  • The signer's revoked face, drawn for the 240 by 240 display

    Revoked

    The key is retired, and the device signs nothing.

What this surface does not cover

A capability page with no edges reads as a brochure. Each line below is a standing decision recorded in docs/DOCTRINE.md, and none of them sits in a backlog waiting for demand.

  • Identity, access control and secrets

    Matrix Scroll records a declared actor type. It does not authenticate the human behind it, issue credentials, or manage keys for your systems.

  • Automation runtimes, sandboxing and input filtering

    The protocol signs a record of what software did. It does not run the software, contain it, or inspect its inputs.

  • Version control and forge hosting

    We ride on Git, GitHub, GitLab, Forgejo and Gitea. Building any of them is on the kill list in docs/DOCTRINE.md.

  • Certification under any scheme

    We produce evidence that a scheme's own accredited assessors can read. Certification is theirs to grant.

  • General-purpose monitoring SaaS

    SSX360 does not currently offer a general-purpose monitoring subscription. Hosted Matrix Scroll tools that call ssx360.com require an API key and are listed separately below.

  • USB signer cryptographic scope

    The USB signer holds an Ed25519 key in the SE050. Matrix Scroll's ML-DSA and SLH-DSA overlay is a separate software path through liboqs.

Evidence mark

Read the scope before the seal.

The evidence package and report define the full scope. The USB signer remains an Ed25519 product; Matrix Scroll's ML-DSA and SLH-DSA evaluation path runs separately through liboqs and carries the technical limits published on this page.

Honest limits on the list above

Where we name a scheme such as PCI DSS, SOC 2 or the EU AI Act, we are describing evidence mapping, not a certification claim. Certification under any scheme named here comes from that scheme's own accredited assessors.

The full scope of what an SSX360 assessment covers is set out in our legal terms. Durations, audiences and deliverables for the six engagements sit on the engagements page.

Request a call
  1. 01

    What this site calls a signed evidence record is one signed document per action, plus a range check that names the changes holding no signed document at all. There is no Merkle tree, no inclusion proof and no consistency proof in the package, and this page will not describe one until the code exists.

  2. 02

    Post-quantum signing implements the ML-DSA and SLH-DSA algorithms specified in FIPS 204 and FIPS 205, through liboqs. That is an algorithm implementation, not a CMVP-validated cryptographic module, and we will not describe it as FIPS validated. liboqs itself states that it should not be relied on in production or to protect sensitive data, which is a limit we repeat rather than bury.

  3. 03

    The completed SSX360 USB signer holds an Ed25519 private key in the NXP SE050 and is supplied through direct contact. This hardware path does not provide ML-DSA or SLH-DSA signing.

  4. 04

    The 0.7.0 evidence-pack export is an unsigned index over a bundle of signed envelopes. Its framework annotation is evidence mapping, not a certification claim; the index itself is not a signed attestation.

  5. 05

    Hosted Scroll Gate, org-wide envelope listing and hosted audit export call ssx360.com and need SSX360_API_KEY. The offline equivalents cover range verification and export; hosted listing has no offline equivalent.

  6. 06

    The Intelligence Log has one published report and the sector risk index and incident registry have none. Anyone weighing the research should weigh it at that size.