Compute marketplace

The Sigil compute marketplace lets providers sell verified inference and training capacity, and lets consumers buy it under escrow. Settlement is graduated across four verification tiers that trade latency for assurance.

​

Verification tiers

The consumer chooses the tier at job submission. Higher tiers offer stronger fraud resistance at the cost of longer settlement.

​

Lifecycle

​

Provider model

A provider record holds:

• DID and operator metadata.
• Capabilities JSON (informational, see known limitations).
• Bond.
• Reputation signals.
• Verification tier support (which tiers the provider can serve).
• TEE vendor capability flags (if enabled).

Tier eligibility is derived from on-chain stake and TEE attestation material, not from the capabilities JSON.

​

Lumen — T1.5 attestation

T15Lumen is Sigil’s deterministic inference-attestation tier. It sits between optimistic provider receipts and redundant multi-provider execution and gives validators a cheap, deterministic check that an inference receipt is bound to a specific job, model, prompt commitment, output commitment, precision declaration, sampled token window, and provider key. Lumen does not store prompts, outputs, model weights, hidden states, or private keys on chain. It is a launch-live native verifier; the implementation is in node/sigil-core/src/lumen.rs.

​

T3 — TEE attestation

T3 settlement requires a cryptographic attestation from a trusted execution environment. Sigil supports four vendors: AMD SEV-SNP, Intel SGX DCAP, Intel TDX, and Arm CCA. T3 is fail-closed by default on every chain; operators must populate per-vendor trust anchors before enabling. See TEE verifier readiness for the operator package and known limitations for the per-vendor gaps.

​

Escrow

When a consumer opens a job, they fund an escrow account scoped to the job id. The escrow debits at admission and locks until the receipt settles. On successful settlement the escrow releases to the provider (minus protocol fees). On dispute or revocation, the escrow returns to the consumer (minus penalty).

​

Challenges

Any party can challenge a receipt within the challenge window (default 24 hours per tier; configurable in sigil.system.parameters). A challenge:

1. Locks the provider’s bond.
2. Triggers an arbitration path: T2 re-execution by an independent provider, T3 re-attestation, or governance multisig for ambiguous T1 cases.
3. Resolves with the escrow flowing per the arbitration outcome, and the provider’s bond burned or refunded.

The challenge window is the only fraud-resistance mechanism for T1Optimistic. Consumers should price T1 jobs accordingly.

​

Storage

Provider records, jobs, receipts, escrow accounts, and challenges are stored under the compute/ partition. The state survives replay and restart.

​

RPC

​

Subscriptions

The compute topic emits job, receipt, and challenge events. Filters: provider_did, consumer_did, tier.

​

Implementation

• Types: node/sigil-core/src/compute.rs.
• Executor: node/sigil-node/src/executor_compute.rs.
• Durable state: node/sigil-node/src/compute_durable.rs.
• TEE verifiers: node/sigil-node/src/tee_verify/{sev_snp,sgx_dcap,tdx,arm_cca}.rs.

​

See also

• TEE verifier readiness
• Security overview