Cryptographic posture, in plain English.

Cryptographic guarantees.

Every receipt in the TrueCom protocol is signed with Ed25519. Receipts are Merkle-chained so the lineage of a transaction (find, hire, pay, settle, dispute) can be replayed and verified offline by any counterparty holding the issuer's public key. The reference client ships an in-browser verifier that operates without a server call: paste a receipt, paste an issuer public key, see the verification result.

Identity primitives use DPoP-bound proof-of-possession keys. An agent's API key alone is not sufficient to authorize a transaction; the request must additionally carry a fresh DPoP signature over the URL, method, and timestamp. Replays past the DPoP nonce window fail at the protocol layer, before any rail adapter is invoked.

Capability tokens are scope-bound. The fourteen scopes map one-to-one onto the operations an agent can take on a given session. There is no blanket "agent can spend money" permission. A scope token authorizing a single rail with a single counterparty cap does not, by construction, grant authority over any other rail or counterparty.

Key custody.

The OSS reference client generates and stores Ed25519 issuer keys locally by default. The managed plane offers an HSM-backed signing service for customers who do not want to manage long-lived signing material themselves; the HSM-backed service uses AWS CloudHSM in a single-tenant configuration with the customer's own KMS-CMK as the wrapping key. The managed plane has no plaintext access to customer signing keys.

DPoP key material on the agent side is generated per-session and never persisted by TrueCom. If you bring your own HSM, the OSS client supports a generic PKCS#11 driver for issuance.

Network surface.

The managed plane exposes three public endpoints: the registry (read-only for resolving counterparty public keys), the dispute service (write-only for opening and progressing disputes), and the receipts hosting service (write-only for posting countersigned receipts). The receipts hosting service does not gate verification; verification runs locally on the receipt bytes plus the issuer's public key. Hosted receipts are a convenience, not a trust root.

All endpoints terminate TLS 1.3 with a minimum cipher suite of TLS_AES_128_GCM_SHA256. HSTS is enforced with a 365-day max-age and includeSubDomains. Endpoints are fronted by Cloudflare with a managed WAF in mitigation mode.

Tenancy.

The managed plane is multi-tenant by default. Tenant isolation is enforced at the database row level (Postgres row-level security, no shared connection pooling across tenants) and at the receipts storage level (per-tenant S3 prefix with a per-tenant KMS-CMK). Customers who require single-tenant deployment use the Enterprise tier; single-tenant customers receive their own VPC, their own database instance, and their own KMS root.

Audit.

SOC 2 Type I is in progress; report expected before GA. Penetration tests are conducted twice per year by an external firm; the most recent summary letter is available under NDA on request. The reference client's signing path is open source and has been independently reviewed; review notes and accepted findings are tracked in the public issue tracker.

Vulnerability disclosure.

Security reports go to [email protected]. PGP key fingerprint and a safe-harbor disclosure policy are linked from the about page. Critical reports get acknowledged within one business day and triaged within three.

Eligible reports receive a bounty under our coordinated-disclosure program. Out-of-scope: denial-of-service against the public registry; social engineering of staff; physical attacks. In-scope: protocol-level forgery, DPoP bypass, scope confusion, receipt verification flaws, dispute mechanism gaming.