Skip to content

Receipt Format

Every SIX inference returns a signed receipt -- a cryptographic proof of execution integrity, routing, and settlement. This page documents what each field proves and how to use receipts for audit and compliance.

Receipt Object

{
  "receipt_id": "rcpt_f8c505ce3a7b4d2e9f1a...",
  "routing": "sovereign",
  "commitment": "04a7f3c2d8e6b5a9...e9b1d0f",
  "signature": "0x69c8a3f7...f98c8",
  "verified": true
}

Field Reference

receipt_id

Property Value
Type string
Format rcpt_ prefix + unique identifier
Proves This specific inference execution is uniquely trackable

The receipt ID is the primary key for later verification. Store this value to verify the inference at any future point via the Verification Endpoint.

routing

Property Value
Type string
Values standard, sovereign, confidential
Proves Your request was routed according to the specified privacy tier

This field confirms the actual compute path your request took. If you requested sovereign routing and the receipt shows sovereign, you have cryptographic confirmation that your data stayed within your boundary.

Value Guarantee
standard Processed on shared compute within provider boundary
sovereign Processed on dedicated compute within your boundary
confidential Processed in hardware-isolated environment

commitment

Property Value
Type string
Format Hex-encoded cryptographic commitment
Proves All receipt fields are bound together and tamper-evident

The commitment is a cryptographic binding of all receipt fields. It functions as a tamper seal: if any field in the receipt is modified after issuance, the commitment will not match, and verification will fail.

Think of it as a wax seal

The commitment binds the receipt fields the way a wax seal binds a letter. Break the seal (modify a field), and the tampering is immediately evident.

signature

Property Value
Type string
Format Hex-encoded digital signature
Proves The receipt was issued by SIX infrastructure and has not been altered

The signature is produced by the SIX signing infrastructure over the commitment. You can verify this signature independently using the SIX public key, proving that:

  1. The receipt was generated by authorized SIX infrastructure
  2. The commitment (and therefore all fields) are authentic
  3. No intermediary modified the receipt in transit

verified

Property Value
Type boolean
Proves Server-side verification passed at time of issuance

This is a convenience field. SIX verifies the receipt at issuance and reports the result. For compliance purposes, you should perform independent verification rather than relying solely on this field.

Do not rely solely on this field

The verified field is a server-side assertion. For regulatory audit trails, perform independent verification using the Verification API or CLI tooling. An auditor wants to see that you verified, not that the issuer claims it verified.

What the Receipt Proves (Summary)

Question Receipt Field How
Did this inference run? receipt_id Unique, verifiable identifier for the execution
Where did it run? routing Confirms the compute path and data boundary
Were any fields altered? commitment Cryptographic binding breaks on any modification
Who issued this receipt? signature Digital signature verifiable against SIX public key
Is the receipt valid? verified Server-side check (verify independently for compliance)

Receipt Lifecycle

Inference Execution
       |
       v
  Attestation Generated (execution proof)
       |
       v
  Commitment Computed (fields bound)
       |
       v
  Signature Applied (tamper-evident seal)
       |
       v
  Receipt Returned (with response)
       |
       v
  Independent Verification (by you, any time)

Storage Recommendations

For compliance and audit readiness:

Recommendation Reason
Store the full receipt object Required for independent verification
Store alongside the response Links the AI output to its proof
Include in your audit log Satisfies audit trail requirements
Retain per your data retention policy Receipts can be verified at any future date

Full Schema

Extended Receipt Schema
The full receipt schema includes additional fields for settlement anchoring, attestation metadata, and ledger references. These are documented in the complete technical specification available to NDA partners.

Request full schema →

Next Steps