Blueprints
A Blueprint is a template for software that can run as a service.
Think of it like a deployable backend definition. A Blueprint describes what code runs, what jobs it exposes, what inputs those jobs accept, how operators run it, and how customers create running instances of it.
A Service is a running instance of a Blueprint.
For example, an LLM inference Blueprint can define the model-serving code, the job API, pricing rules, and operator requirements. A customer can then create a Service from that Blueprint with a chosen operator set, payment method, and runtime configuration.
Quick Start
The Basic Model
There are three core objects:
| Object | What it means |
|---|---|
| Blueprint | A reusable service template. It defines the software, jobs, metadata, artifacts, and optional protocol logic. |
| Service | A live instance of a Blueprint. It has a requester, operators, configuration, payment terms, and lifecycle state. |
| Job | A callable unit of work inside a Service. Jobs can be called by users, systems, smart contracts, webhooks, cron schedules, or machine payment APIs. |
Blueprints do not have to be blockchain applications. A Blueprint can be a normal web service, an app backend, an AI model server, a scheduled worker, a data pipeline, a prover, or an automation service.
Tangle adds protocol coordination around that software: discovery, operator registration, service creation, payments, incentives, and lifecycle tracking.
What Developers Build
Developers build Blueprints by packaging application logic into jobs and publishing the metadata needed to run them.
A Blueprint usually includes:
- Executable code: a native binary, container image, WASM module, or another artifact operators can run.
- Jobs: typed functions or handlers that perform work.
- Inputs and outputs: schemas for job parameters and results.
- Triggers: the events that call jobs.
- Metadata: name, description, source repository, image/logo, docs, job descriptions, and UI hints.
- Optional protocol contract: a Blueprint Service Manager that customizes registration, service requests, verification, payments, or slashing.
The Blueprint SDK provides the Rust framework, runner, and CLI for building and testing this package.
How Jobs Are Triggered
A Blueprint can be designed around one trigger type or several:
| Trigger | Use it for |
|---|---|
| HTTP or webhooks | API calls, SaaS integrations, callbacks, GitHub events, payment events, and external system events. |
| Cron | Scheduled jobs such as batch processing, periodic inference, monitoring, rebalancing, or data refreshes. |
| Onchain events | Blockchain events emitted by smart contracts, transactions, or protocol state changes. |
| x402 / machine payments | Paid HTTP APIs where a caller pays to trigger a job. |
| Custom producers | Any event source a developer connects to the Blueprint Runner. |
The same Blueprint can expose a normal API and also react to onchain events. That is the point: the application logic lives in the Blueprint, while the trigger layer decides when that logic runs.
Where Tangle Fits
Tangle is the coordination layer for Blueprints.
When a Blueprint is registered with Tangle Network, the protocol can track:
- who published the Blueprint;
- what metadata and artifacts define it;
- which operators registered to run it;
- which Services were created from it;
- which operators were selected for each Service;
- what payments, fees, and incentives apply;
- which lifecycle events happened.
The onchain part is handled by Tangle Protocol contracts. The offchain part is handled by operators running the Blueprint Manager and the Blueprint Runner.
This means a Blueprint can have blockchain-native lifecycle tracking without forcing all application logic to run inside a smart contract. Most real services should run offchain. Smart contracts are used for coordination, payment, verification, and state.
Roles
Developers
Developers write the Blueprint.
They define the jobs, package the artifacts, publish metadata, and optionally deploy a Blueprint Service Manager contract. The manager contract can customize:
- How operators register for the Blueprint.
- How customers create Services.
- How jobs are authorized.
- How job results are verified.
- How payments, fees, or slashing rules work.
Developers can build simple Blueprints with minimal protocol customization, or advanced Blueprints with custom contracts and verification logic.
Customers
Customers create Services from Blueprints.
They choose a Blueprint, configure the instance, select operators or operator requirements, choose payment terms, and submit the service request. After the Service is active, they use its job API or wait for configured triggers to run it.
Operators
Operators run Services.
They register for Blueprints they are willing to operate, run the required artifacts, listen for jobs, execute those jobs, and return results. Operators earn fees and may earn protocol incentives when those incentives are enabled.
Payments
Blueprints can support several payment paths:
- fixed service creation fees;
- subscriptions;
- per-job pricing;
- operator-signed quotes;
- x402 and machine payment compatible APIs;
- custom payment logic in a Blueprint Service Manager.
For protocol-level payment details, see Pricing & Payments and the tnt-core pricing guide:
https://github.com/tangle-network/tnt-core/blob/main/docs/PRICING.md
A Simple Example
Imagine a video transcription Blueprint.
The developer publishes:
- a container image that runs the transcription service;
- a job called
transcribe; - an input schema with a video URL and language hint;
- an output schema with transcript text and timestamps;
- metadata with docs and repository links;
- pricing rules for each transcription job.
Operators register for the Blueprint and run the container. A customer creates a Service from the Blueprint. Then the job can be triggered by an HTTP request, a webhook when a video is uploaded, a cron schedule, an onchain event, or a paid x402 API call.
The software still looks like a normal backend service. Tangle adds operator coordination, payment, lifecycle tracking, and optional protocol verification around it.