Blueprints
Getting Started
Blueprints are reusable service definitions that let developers publish off-chain workloads (“jobs”) with clear on-chain interfaces and security assumptions. A blueprint becomes usable when operators run its off-chain runtime and customers create services from it.
Blueprint vs Service
- Blueprint: a developer-owned definition stored on-chain (schemas, sources, metadata, optional manager hooks).
- Service: a customer-owned instance created from a blueprint (operator set, permitted callers, TTL, payment model, security requirements).
What a Blueprint Contains
A blueprint definition typically includes:
- Schemas (registration, request, per-job params/result)
- Execution sources (native binaries and/or container images; WASM sources are reserved but may not be supported by all operator runtimes yet)
- Optional service manager hooks (an EVM contract the protocol calls during lifecycle events)
How Each Role Uses Blueprints
Developers
- Publish blueprints and (optionally) implement a manager contract for custom lifecycle logic.
- Define what “correct” results mean for jobs and when misbehavior should be slashed.
Customers
- Create services via request/approve (explicit operator set) or RFQ/quotes (operators sign quotes).
- Submit jobs and pay service fees.
Operators
- Register for blueprints, advertise preferences, and run the off-chain runtime.
- Consume job calls from chain and submit results + heartbeats.
Restakers / Delegators
- Delegate assets to operators and optionally constrain exposure to specific blueprints.
- Earn a share of service fees and (optionally) TNT incentives funded by explicit budgets.
Architecture Reference
Composability
Blueprints can be composed to create larger systems (e.g., MPC + attestations + orchestration). The protocol is designed to support services like MPC, ZK proving, agent automation, oracles, bridge co-processors, and other restaking-secured infrastructure.