Skip to main content

Processor placement

For v1, Liskov selects one eligible processor through the Acurast open market. The processor is a phone that accepts the job and runs it in a trusted execution environment (TEE). Its exact identity and market terms are launch-time facts, not values you should hard-code.

If your Application declares secrets, a processor is eligible when it has published a usable encryption key of either kind, p256 or secp256k1. Which runtime versions decrypt each kind is described under Processor key kinds.

Supported declaration​

{
  "deployment": {
    "parallelism": 1,
    "placement": {
      "requirements": {
        "trustProfile": "proof.liskov.attested-runtime.v1"
      },
      "processorSelection": {
        "mode": "open_market"
      }
    }
  }
}

The trust profile is mandatory and cannot be weakened. Omit requirements if you only need its secure default. The open market can return a different processor for a later job.

Authored requirements versus observed facts​

The policy may contain durable requirements. Current processor availability, quoted market reward, chosen processor, manager, assignment time, and observed performance belong to deployment evidence. Treat them as outcomes to inspect, not promises encoded in an Application description.

The V4 schema can express counted geography groups, topology constraints, manager selection, static processor IDs, heartbeat filters, and other selection controls. Those features are not enabled for the first public capability set. A structurally valid field may still fail publication with unsupported_policy_feature or entitlement_exceeded.

When processor-pin advice is shown​

For an existing exact pin, the Action Plan may show Review processor pin after a recorded scheduling or heartbeat check. Follow that link to the existing Policy placement setting, or leave the pin unchanged and wait. Opening the suggestion changes nothing; it does not change the pin automatically, create a Hold, or stop automatic retries.

Advice does not enable placement controls outside the supported capability set. Apply any supported policy change through the existing publish workflow, with its admission and spend checks. Publication can start new work and reserve Service Credits. Verify the resulting policy digest, processor assignment, and signed runtime contact; opening the link or advice expiring proves none of those. See Optional processor-pin advice for the recorded checks and unavailable or incomplete advice.

Verify​

After submission, wait for processor assignment, then verify the processor and job IDs in the deployment timeline. Assignment proves a market participant accepted the job; wait for signed runtime contact before calling the Application ready.

See Deployments, jobs, and timelines for the evidence sequence and Capabilities and limits for availability.