Commercial unit
Verified payment-authorization record tier
Exact pricing remains quote-based until pilot scope, deployment, and service requirements are validated.
Financial services & high-value workflows
YQ Trust
Verify dual-layer classical records for high-value payment authorization.
YQ Trust is a bounded classical dual-layer record product. The default pilot workflow is payment authorization: an original KMS-backed signature and an ML-DSA-65 endorsement are verified independently over the same canonical bytes (yq-json-c14n.v1). An optional Line review-pack may appear only as SHA-256 digests — review evidence, not quantum-link assurance.
The dual-layer classical record path is operational. Optional review-pack digests are hashes only; they are not Line calibration or quantum-link assurance. The interactive workspace needs authorized access.
Security specifications
Public cryptographic architecture
Standards, verification boundaries, and customer-visible controls are public. Private keys, shared secrets, customer data, proprietary calibration methods, and raw failed measurements are not.
Added endorsement
ML-DSA-65
FIPS 204 algorithm profile for the second layer of the classical record.
Canonical record
yq-json-c14n.v1
Deterministic UTF-8 bytes define exactly what is signed and verified.
Evidence digest
SHA-256
Customer evidence is represented by a digest inside the signed record boundary.
Line review-pack digest
Optional SHA-256 hashes
Bell, photon, fidelity, and disposition may appear only as digests plus an observation window and bind nonce. That bind is not quantum-link assurance.
Freshness and replay
Expiry + durable nonce
Verification evaluates record freshness and whether the one-time nonce has already been used.
Original signature
Preserved
The source KMS-backed signature remains part of the record.
Verification
Dual layer
Original KMS and ML-DSA-65 signatures are evaluated independently.
Record boundary
Organization scoped
Creation, retrieval, and verification follow the authenticated customer context.
Security boundaries
These are current product boundaries, not blanket certification or authorization claims.
Open the Trust Center- Signing seeds and private-key material remain server-side and are never exposed by the public experience.
- Trust records are persisted with opaque identifiers, fingerprints, timestamps, and verification outcomes.
- Access is entitlement-gated and scoped to the authenticated customer organization.
- Use of ML-DSA-65 is not itself a claim that a deployment or cryptographic module has CMVP validation.
- Yoon Labs does not sell ML-DSA-65 or post-quantum signatures as a standalone product.
Product brief
What the organization is buying
Start with one bounded payment-authorization workflow. Verify the original KMS-backed signature and the ML-DSA-65 endorsement independently, then agree retention, rotation, and exception handling before any later expansion. Settlement evidence can reuse the same record shape; it is not the default first pilot.
Primary buying group
Risk executives, security leaders, payment owners, treasury teams, and enterprise architects
High-value use cases
- High-value payment authorization and instruction records
- Settlement, custody, and treasury evidence
- Machine-to-machine identity and approval chains
- Long-retention trust records that outlive today’s cryptographic assumptions
Measurable outcomes
- 1A reviewable record containing original and dual-layer signature checks
- 2Independent verification results with key and signature fingerprints
- 3A governed path for retention, rotation, exceptions, and production evidence
Contact Yoon Labs
Turn YQ Trust into a bounded, measurable pilot.
A useful first conversation defines the buyer, system boundary, measurable outcome, deployment posture, and diligence requirements. We will bring the technical team into that conversation from the start.
YQ Trust pilotTechnical diligenceSecurity review
Talk with Yoon Labs
The prepared email asks for only the information needed to scope the first conversation.
Start the conversationDo not send classified, export-controlled, regulated, or customer-confidential technical data in the first email.