Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.compose.market/llms.txt

Use this file to discover all available pages before exploring further.

MAL proof bundles are hash artifacts. They are useful for audit, but they are not trusted execution environment attestations.

​
Proof Bundle

When a plan sets requireProof: true, the interpreter accumulates:
FieldMeaning
planHashHash of the canonical plan before execution.
steps[]Per-step input hash, output hash, op, success flag, and optional inference run ids.
inferenceRunIds[]Run ids surfaced by subagent/tool execution.
sandboxOptional Daytona metadata when isolation is active.
proofCidPinata CID when pinning succeeds.
The pinned bundle schema version is compose.proof.v1.

​
Honest Trust Model

ClaimStatus
Step inputs and outputs can be hash-checked against the bundle.Yes.
The bundle can point to inference run ids for cross-checking receipts.Yes.
Pinata can store the proof bundle CID.Yes, when PINATA_JWT is configured.
The runtime emits a live EVM signature in this module.No. signProofBundle() is a placeholder.
Daytona proves TEE-grade execution.No. The sandbox path is isolation, not TEE attestation.

​
Receipts

x402 receipts belong to the API and inference layers. Harness proof bundles can reference inference run ids; verifiers should cross-check those ids against Compose/x402 receipts rather than treating the proof bundle as payment authority.