Skip to main content
This page is for the engineer running the tool in-house who wants its output on the Trusset platform. After reading it you will know which files leave your machine, which API calls consume them, and which leaves can back which claims. It is the one page in this section that assumes Trusset; every other page describes the tool on its own. The tool was built for this pipeline, which is why two of its defaults exist. country and investorType are always written in cleartext, and the batch index CSV keeps the column layout the platform’s batch verification consumes. Neither is needed by a counterparty verifying with the standalone verifier.

​
What leaves your infrastructure

Trusset never sees the underlying KYC data, and no endpoint accepts it. What travels is the evidence that a predicate held: A commitment carries no value and a STARK reveals nothing beyond its predicate, so uploading them discloses no personal data. secrets.enc and .trusset/keys.env stay on your machines.

​
Why country and investorType are plaintext

The platform stores the country on the customer record and uses it to evaluate transfer rules, and the investor type becomes an argument of the on-chain identity verification call. Both therefore travel in cleartext in the batch index CSV and in manifest.passthrough, and the tool marks their leaves plaintext. Their proofs still bind the disclosed value into kycHash, so a CSV row that disagrees with the bundle is detectable, but they add integrity rather than privacy. country is mandatory in every record and cannot be dropped from the mapping.

​
From bundle to verified customer

The full walkthrough, with SDK calls, is on KYC Proofs. The sequence:
1

Register the operator key, once

Set Operator Key records the ed25519 public key that npm run init and npm run show print, and sets proofVerificationEnabled and maxStalenessDays for the instance. Every manifest signature is checked against this key. Rotating it does not re-verify claims already filed; keep the old key with the bundles it signed.
2

Put the root on chain

verifyFromManifest in the SDK reads walletAddress, kycHash, country, investorType and the expiry days from the manifest and publishes the root. The index CSV maps row for row onto batch verification, up to 500 subjects per transaction.
3

File proof-backed claims

Add Claims from Proof takes the manifest, the signature and the base64 proof bytes of the leaves you select. It verifies each STARK and files one claim per leaf. Inspect Manifest reports beforehand which leaves are attestable and why the others are blocked.

​
Which claims a leaf can back

A canonical field proved with a different circuit is skipped rather than filed elsewhere. A commitment_only leaf cannot be attested under enforcement, because there is no STARK to verify. AML, TAX_RESIDENCY, SANCTIONS_CHECK and PEP_CHECK are not proof-backed and are added manually; they are also the only slots a leaf with no canonical meaning may be filed under.

​
Enforcement, staleness and trust anchors

A PRODUCTION instance requires the STARK bytes and rejects stub manifests whatever the instance setting says; a DEVELOPMENT instance does neither by default. Read proofVerificationEnforced from Get Operator Key and gate on it. maxStalenessDays bounds how old a bundle’s epochDays may be before submission is refused with PROOF_STALE. The tool records the batch date and never compares it with today; this is where that comparison happens. The network’s trust anchors decide which predicate parameters and which allowlist roots are accepted. A leaf outside them is refused with UNAPPROVED_PARAMS or UNAPPROVED_LIST. After you rotate an allowlist with npm run list-version, the new root must be added to the approved roots on the platform side before proofs made against it are accepted. Bundles proved against an earlier approved version keep verifying, since each leaf records the version it used.

​
Re-proving a subject

Every re-run produces a new root, because the batch date is inside every leaf hash. The new bundle is legitimate, but its root no longer matches the one on the registry, and Add Claims from Proof refuses it with HASH_MISMATCH. Attest Proofs rotates the on-chain root to the new bundle in the same flow as filing its claims. The platform’s own Revoke Proof revokes a claim slot on the registry. It is separate from the tool’s npm run revoke, which writes to the operator’s signed revocation registry.

​
The vendored verifier

The platform does not shell out to the native verifier. It vendors a wasm32 build of the tool’s verifier crate and drives its own per-leaf check ladder through the granular exports listed on Verification. scripts/rebuild-wasm.sh in the tool repository produces that artifact with a provenance record, and the artifact’s commit and SHA-256 feed the verifier version stamped on every verification report. Any addition to the signed manifest schema requires re-vendoring, or the recomputed signing view drops the new field and every production signature fails.

​
Further reading