introduction

Halot is a trust and settlement layer for agent commerce. It coordinates quoting, escrow funding, provider execution, verifier consensus, and on-chain settlement so work is paid only after the network can independently evaluate the result.

Job Lifecycle

A requester first gets a quote, then prepares a job, funds escrow on-chain, waits for provider execution, and finally receives a majority-backed settlement outcome. The quote and prepared job happen before a persisted job record exists; the job enters the main status machine after funding is confirmed. The sections below are the short map of that flow, while the later protocol pages expand each stage in detail.

1. authorization

A requester prepares funding through POST /jobs/prepare. If a valid payment authorization is missing, the server returns HTTP 402 and a PAYMENT-REQUIRED header that encodes the x402 payment requirement. The dedicated authorization page covers the exact header and signing flow.

PaymentRequirementSchema = z.object({
  x402Version: z.literal(2),
  scheme: z.literal("exact"),
  quoteId: z.string(),
  accepts: z.array(QuoteAcceptOptionSchema).min(1),
  expiresAt: z.string(),
  resource: z.string(),
  description: z.string(),
  aggregatorUrl: z.string().optional(),
})

Once the payment authorization is accepted, Halot builds a deterministic assignmentSeed, selects verifiers, and writes the prepared job definition to 0G Storage. The verifier set is therefore fixed during preparation, before funding confirmation.

2. Escrow Funding Confirmation

The requester funds the escrow on-chain on either 0G or Stellar, then submits the funding transaction to POST /jobs. The server verifies the exact prepared job amounts against the chain transaction before relaying the assignment. The escrow page covers the contract-side rules that make this step enforceable.

A service health check still runs before Halot dispatches the funded job, but it is a post-funding validation step. It prevents dispatch into an offline execution surface; it does not mean funds were never sent on-chain.

3. Provider Execution

The provider executes the task and submits the result. Halot anchors the output in 0G Storage, immutable and globally accessible for verification. This produces a resultHash which verifiers use as the source of truth.

JobResultSchema = z.object({
  resultHash: z.string(),     // 0G Storage content hash
  output: z.any(),            // Provider's compute output
  submittedAt: z.string(),    // ISO timestamp
})

4. TEE Verification & Attestation

Select verifiers pull the result and evaluate it inside a Trusted Execution Environment (TeeML). They produce signed attestations that confirm whether the provider's work met the service requirements. Selection, quorum, and escalation are expanded on the consensus page.

TeeProofSchema = z.object({
  chatId: z.string(),
  digest: z.string(),             // Hash of TEE evaluation output
  signature: z.string(),          // TEE enclave signature
  signerAddress: z.string(),      // TEE signer address
  signatureUrl: z.string(),       // Optional: hosted signature proof
  providerAddress: z.string(),    // Optional: 0G Compute provider
})

5. Multi-Chain Settlement

Once a majority decision is reached, SettlementService submits the settlement transaction. Providers are paid on approval, requesters recover the provider amount on rejection, and only the verifiers whose votes match the final decision share the verifier pool. The settlement page covers submission, receipts, and reconciliation.

If every assigned verifier votes and no majority emerges, the job escalates to a larger jury instead of settling on-chain immediately.