Skip to content
Ryvion

Cryptographic Receipts

Every completed job on Ryvion produces a cryptographic receipt. The current RYV1 envelope signs a small core execution record with Ed25519, and Ryvion can attach additional audit metadata for provenance and review.

What is signed today

The current RYV1 signature covers these fields:

  • job_id -- the hub job identifier
  • node_public_key -- the public key of the node that submitted the receipt
  • result_hash -- the SHA-256 hash of the job result payload
  • metering_units -- the usage units reported for billing/reconciliation

These are the fields the verify page checks locally in your browser.

What can be attached as metadata

Receipts can also include attached metadata that is stored and displayed separately from the signed envelope:

  • Model -- model identifier or image selection
  • Jurisdiction -- requested or resolved country / region policy
  • Timestamps -- hub-created timestamps for audit review
  • Retrieved chunks -- document/chunk provenance for RAG-backed workflows
  • Other workload metadata -- object keys, manifest references, or operator-side details

Attached metadata is useful for audit trails and provenance, but it is not currently part of the Ed25519 signature.

How it works

  1. A job is submitted to the Ryvion hub
  2. The scheduler routes it to a verified GPU node
  3. The node executes the workload
  4. The node signs the RYV1 core receipt with its Ed25519 private key
  5. The hub verifies the signature and merges any hub-owned audit metadata
  6. The receipt is stored in the audit trail and can be exported later

Signature scheme

Receipts use Ed25519 signatures. Each node has a unique key pair:

  • The private key stays on the node and is used to sign receipts
  • The public key is registered with the hub during node verification
  • Anyone with the public key can independently verify the receipt

Why this matters

Compliance

For regulated industries, you need a durable execution record plus enough audit context to explain what happened. Ryvion receipts give you a signed core envelope and a place to attach review metadata like jurisdiction and retrieved chunks.

Audit trail

Every API call produces a verifiable record. View receipts in the dashboard or query them via the API.

Trust

Unlike centralized providers where you trust the provider's word, the signed RYV1 envelope is independently verifiable. Anyone with the node public key can verify the signature on the core fields without trusting Ryvion as an intermediary.

Cost verification

Receipts preserve the signed work units used for billing and reconciliation. That makes it easier to review what was charged, even when the broader audit metadata is attached separately.

Output hash

Every receipt includes a result_hash field -- a SHA-256 hash of the output payload. This lets you independently check that the response you received matches the signed result. If anyone tampers with the response in transit, the hash will not match.

Verification

Receipts are independently verifiable. Given a receipt and the node's public key, anyone can verify the Ed25519 signature on the RYV1 core fields without trusting Ryvion as an intermediary. The verified field indicates whether the hub has already confirmed that signature.

Viewing receipts

  • Dashboard: browse receipts in the Audit Trail section
  • API: each inference response includes receipt metadata
  • Bulk export: download receipt history for compliance reporting

Audit export

Ryvion audit exports include your receipts plus a bundle hash -- a single SHA-256 hash computed over the export payload. That makes it straightforward to verify the export is complete and unmodified. Organization-scoped exports can also be rendered as CSV for compliance review.

Receipt format

{
  "job_id": "job_xyz789",
  "node_public_key": "a4f4a5cf200138bf17695ce2dd29ae3e941e10ce7dd0f69a44825401e066abcb",
  "result_hash": "sha256:a3f2b8c1d9e4...",
  "metering_units": 142,
  "signature_hex": "hex-encoded-ed25519-signature",
  "verified": true,
  "attached_metadata": {
    "model": "phi-4",
    "jurisdiction": "CA",
    "timestamp": "2026-04-09T12:00:00Z",
    "retrieved_chunks": [
      {
        "chunk_id": "chunk_01",
        "document_id": "doc_123",
        "filename": "policy.pdf",
        "chunk_index": 2,
        "hall_type": "document",
        "relevance": 0.92,
        "content_hash": "sha256:..."
      }
    ]
  }
}