// AUDIENCE_FILTERShowing content for NIST / standards conformance. De-emphasized: Competitive positioning, the industry-landscape framing, and on-chain market operations — none of it is conformance evidence.
All evidence
// MULTI_CHAIN_LAB · NO_LOGIN_REQUIRED
A Demo Run That Ended in a Real Signature.
A multi-chain evaluation drove a demo run end to end and finished with a genuine
Sign on the evaluator’s software token, with correlated evidence recorded on both sides. That is a narrow result on a lab stack, and it is worth exactly what its conditions allow — which is why the conditions are here rather than in a footnote.How to read this surface
Generated artifacts you can download and check without an account — produced in a laboratory, not by a production deployment. Citing either half without the other misreads the page.
- Checkable
- The files are generated from real runs, and the ones that carry a signature verify with OpenSSL alone — no A3E9 tooling and no trust in this page.
- Not production
- What produced them is not a production deployment: Docker Compose on a single VM, driving software PKCS#11 modules with no certified hardware chassis.
- Not a certificate
- A3E9 holds no FIPS, CAVP or CMVP certificate of its own. No table on this surface is a verdict, and no row should be quoted as one.
- Amber is a limit
- Wherever a number or a result appears, the boundary on it is written in this colour. Scanning for amber finds every catch without reading each paragraph to the end.
The long version, with the reading map for every artifact page, is on the evidence index.
// BLACK_BOX_CONTRACT
The Rule That Makes the Result Mean Anything.
The multi-chain layer treats the signing service as a black box. It never invents a signature and never invents an audit line, and the pass condition is written so that it cannot quietly do either.
Dual evidence or it did not happen
A pass requires evidence rows on the multi-chain side and a matching audit record on the signing side for the same activity. A reported success with no corresponding audit line is recorded as a failure, not as a partial pass.
Two correlators, not one
The run carries a primary identifier on the multi-chain side and a secondary identifier that equals the request id in the signing service's own audit record. Matching them is what ties one system's claim to the other's evidence.
Real cryptography, real audit chain
The signature is produced by the signing service against its token, and the audit record enters the same HMAC-chained trail as any other operation. Nothing about this path is a simulation of the signing step.
Why the contract is stated first
An integration demo can always be made to look successful from one side. The contract is the reason this result is citable at all, so it precedes the result rather than qualifying it afterwards.
// THE_RUN
2026-08-05, With Its Identifiers.
A run described without being named is indistinguishable from a run that did not happen. These are the correlators the evaluation record carries on both sides.
- run_id — multi-chain side
- ff53932e-b864-4165-acfc-8fd10c454916
- hsm_request_id — equals the signing service’s own audit request_id
- 61be3659-240a-4fd6-8148-0ab7f6b43c98
- date
- 2026-08-05
What the run actually did
A demo run was created against a live EVM testnet — real nonce and fee fields from a live RPC call — and then invoked the signing service, which returned a real signature. The multi-chain layer assembled a real signed transaction from it. Six evidence rows persisted, all recording success, with the last three carrying the request id above.
Against the live environment, not a local one
The signing target was the evaluation VM's own token, not the local development instance an earlier pass had used. That distinction is the reason this run is cited rather than the earlier one: it exercised the deployed path end to end.
Broadcast was refused, as designed
The demo address is deliberately unfunded, so the network rejected the broadcast for insufficient balance. That is the expected outcome of signing a transaction nobody funded — it is not a signing failure, and it is also not a confirmed on-chain transaction. Nothing here demonstrates one.
One chain, for a stated reason
EVM only. The signing service exposes no RPC that returns a secp256k1 or Ed25519 public key from a key label alone, so demo wallets for the other chains cannot be provisioned the same way. EVM works because its signing response carries the address back.
// WHAT_WAS_DEFERRED
One of Three Checks Was Not Attempted.
The end-to-end signature and its dual evidence passed on the live stack. The third check — reading the signing service’s own audit log directly to cross-verify — was not attempted, by explicit choice rather than by failure.
Why it was deferred
The audit log is not reachable through the tunnel the multi-chain layer uses, by design — that tunnel carries the signing RPC and nothing else. Cross-checking the log directly needs access to the evaluation VM itself, which was out of scope for that session.
What that costs the result
The correlation was verified through the portal's audit surface rather than by reading the signer's log on the host. That is weaker than a direct read, and it is recorded as deferred rather than folded into the pass.
Limit
This is a lab result. The evaluation path runs plaintext transport inside an SSH tunnel rather than customer-grade mutual TLS, drives a software token rather than certified hardware, and moves no funded value. It demonstrates that the integration reaches a real signature under a contract that would catch a fake one. It is not a product, and no reading of it should describe it as a deployed service.
// WHAT_A_TOKEN_ADDS
The recorded run is one that already happened. A token lets you invoke a new demo run and correlate its identifiers yourself, which is a different claim from reading ours.
Everything above is checkable without contacting anyone, and is meant to be read first. The token exists because the remainder needs a provisioned environment — not because the evidence is being held back.