UTILIA

PUBLIC REVIEW DRAFT HILT × UTILIA 2026-07-27

Payment settled.
Access and result proven.

This document maps Utilia's current x402 payment and result evidence to Hilt's settlement, receipt, entitlement, atomic usage, and idempotent replay contracts.

Review seven open questions Utilia OpenAPI
7review questions
1external-agent test
1 unitatomic consumption
0double consumption on retry

FIELD-BY-FIELD COMPARISON

What matches now, and what still needs binding.

Exact fields can be preserved directly. Semantic fields require stable identifiers or normalized vocabulary. Missing fields must be added before a receipt can authenticate payment, authorization, and result as one operation.

EXACT OR DIRECT

Settlement facts

  • x402 protocol version
  • transaction signature
  • network and settlement asset
  • atomic USDC amount
  • merchant receiver
  • payer when the facilitator supplies it
SEMANTIC

Needs normalization

  • paid route to stable product ID
  • network plus asset to rail ID
  • settlement event to status vocabulary
  • log timestamp to public settled-at time
  • one paid response to request-scoped access
  • successful result to one consumed unit
MISSING OR UNAUTHENTICATED

Required before proof

  • stable payment session and proof IDs
  • canonical receipt and receipt ID
  • request, result, and payment-term digests
  • issuer identity and Ed25519 signature
  • finality and idempotent replay state
  • durable entitlement and usage state

SMALLEST INTEROPERABLE ENVELOPE

Build the signed one-call receipt first.

Utilia currently sells exact per-call results. The first compatible artifact should bind the request, payment terms, settlement, and successful result without pretending that a reusable entitlement already exists. 

{
  "schemaVersion": "utilia.receipt.v1",
  "receiptId": "urc_...",
  "requestId": "uuid-or-caller-id",
  "productId": "solana.priority_fees",
  "livemode": true,
  "payment": {
    "protocol": "x402",
    "railId": "solana_usdc",
    "amountAtomic": "2000",
    "settlementReference": "transaction-signature"
  },
  "binding": {
    "requestDigest": "sha256:...",
    "resultDigest": "sha256:...",
    "paymentTermsDigest": "sha256:..."
  },
  "idempotentReplay": false,
  "issuer": {
    "id": "https://api.utilia.ink",
    "algorithm": "Ed25519"
  },
  "receiptDigest": "sha256:...",
  "signature": "base64url..."
}

PROPOSED COMPATIBILITY TEST

One paid operation, proven end to end.

Hilt proposed the correct acceptance test. The run should prove each state transition independently and make replay behavior observable.

  1. 01
    Settle

    An external agent accepts the exact x402 terms and settles.

  2. 02
    Issue

    The response exposes the payment receipt and entitlement state.

  3. 03
    Consume

    Exactly one usage unit is consumed before result delivery.

  4. 04
    Return

    The protected Utilia result is returned with its digest binding.

  5. 05
    Replay safely

    A retry returns stable identity and never consumes twice.

REQUEST FOR HILT REVIEW

Seven decisions before implementation.

  1. Can a direct x402 seller use a stable payment proof ID when no Hilt payment session exists?
  2. Which canonicalization algorithm produces Hilt's receipt hash and Ed25519 signature input?
  3. Are protected-request and result digests inside the canonical receipt, or should they be extension fields?
  4. Must settlement evidence authenticate finality and instruction-level payment terms, or only reference them?
  5. For one payment and one response, should access be a consumed one-unit entitlement or only a signed receipt?
  6. Which fields remain identical across idempotent replay, and which timestamps may change?
  7. What is the smallest Utilia receipt subset Hilt would independently verify?
Open Hilt's test proposal Contact Utilia