DEV Community: Tangle Network

Remote Providers, Direct Runtimes, and Where Payment-Native Ingress Belongs in Deployment Architecture

Tangle Network — Mon, 30 Mar 2026 21:49:49 +0000

The Architectural Decision Most Guides Skip

Most infrastructure guides treat deployment and payment as separate concerns: pick a deployment target, then bolt on monetization later. In Blueprint, that separation doesn't exist at the layer where it matters. X402Gateway implements BackgroundService — it runs concurrently with the job runner, not in front of it, not as a proxy, not as middleware. That single architectural choice changes how you compose payment-gated services across every deployment topology.

Before mapping the decision tree, it's worth understanding why this matters operationally.

A conventional payment gateway sits in front of compute: request → payment check → compute. The payment layer can only see requests that arrive through it. When it's down, no compute runs. When you want to add a second ingress — say, on-chain Tangle events alongside HTTP payments — you need a mux layer the gateway doesn't natively provide.

Blueprint's model inverts this. The runner is the mux. TangleProducer, X402Producer, and any other producers you wire in are concurrent streams feeding the same Router. Each producer is independent. The x402 payment HTTP server runs as a BackgroundService alongside heartbeats, metrics servers, and TEE auth services — it's structurally identical to those, just one more concurrent task in the runner's lifecycle.

This post covers what that looks like at each deployment layer.

DeploymentTarget: What Each Variant Means Operationally

Blueprint's remote provider crate models deployment topology as an enum. From crates/blueprint-remote-providers/src/core/deployment_target.rs:

pub enum DeploymentTarget {
    /// Deploy to virtual machines via SSH + Docker/Podman
    VirtualMachine {
        runtime: ContainerRuntime,
    },

    /// Deploy to managed Kubernetes service
    ManagedKubernetes {
        cluster_id: String,
        namespace: String,
    },

    /// Deploy to existing generic Kubernetes cluster
    GenericKubernetes {
        context: Option<String>,
        namespace: String,
    },

    /// Deploy to serverless container platform
    Serverless {
        config: std::collections::HashMap<String, String>,
    },
}

pub enum ContainerRuntime {
    Docker,
    Podman,
    Containerd,
}

Two helper methods on DeploymentTarget make the operational distinctions precise:

pub fn requires_vm_provisioning(&self) -> bool {
    matches!(self, Self::VirtualMachine { .. })
}

pub fn uses_kubernetes(&self) -> bool {
    matches!(
        self,
        Self::ManagedKubernetes { .. } | Self::GenericKubernetes { .. }
    )
}

VirtualMachine is the only target that triggers SSH provisioning. Both Kubernetes variants get kubectl-based deployment. Serverless is a platform-specific escape hatch backed by a HashMap<String, String> for whatever the target platform requires.

The DeploymentConfig builder methods make the intended usage explicit:

// VM: provision a Hetzner node, SSH in, run Docker
DeploymentConfig::vm(CloudProvider::BareMetal(vec!["95.216.8.253".into()]), "eu-central".into(), ContainerRuntime::Docker)

// Managed K8s: EKS cluster, blueprint-ns namespace
DeploymentConfig::managed_k8s(CloudProvider::AWS, "us-east-1".into(), "my-eks-cluster".into(), "blueprint-ns".into())

// Generic K8s: existing cluster, optional context switch
DeploymentConfig::generic_k8s(Some("staging-context".into()), "blueprint-remote".into())

CloudProvider: Local vs Remote Boundary

CloudProvider is defined in crates/pricing-engine/src/types.rs and re-exported throughout the remote provider crate:

pub enum CloudProvider {
    AWS,
    GCP,
    Azure,
    DigitalOcean,
    Vultr,
    Linode,
    Generic,
    DockerLocal,
    DockerRemote(String),
    BareMetal(Vec<String>),
}

DockerLocal is the development boundary. When this provider is selected, the runner executes containers on the host directly — no provisioning, no TLS tunnel, no remote endpoint registration. It's what you use during local development and integration testing.

The requires_tunnel extension method (from crates/blueprint-remote-providers/src/core/remote.rs) makes the network topology consequence explicit:

fn requires_tunnel(&self) -> bool {
    matches!(
        self,
        CloudProvider::Generic | CloudProvider::BareMetal(_) | CloudProvider::DockerLocal
    )
}

Generic, BareMetal, and DockerLocal require a tunnel for private networking — they don't have managed load balancers. AWS, GCP, Azure, DigitalOcean, Vultr, and Linode get LoadBalancer or ClusterIP service types from the managed Kubernetes provider, so they don't need one.

For CloudConfig — the top-level credentials structure — provider credentials are loaded from environment variables with priority ordering. From crates/blueprint-remote-providers/src/config.rs:

pub struct CloudConfig {
    pub enabled: bool,
    pub aws: Option<AwsConfig>,    // priority 10
    pub gcp: Option<GcpConfig>,    // priority 8
    pub azure: Option<AzureConfig>, // priority 7
    pub digital_ocean: Option<DigitalOceanConfig>, // priority 5
    pub vultr: Option<VultrConfig>, // priority 3
}

Priority is embedded in each provider config. When multiple providers are configured, higher-priority providers are preferred for deployment decisions.

SecureBridge: mTLS for Remote Execution

When a Blueprint job runs on a remote VM or remote Docker host, the manager needs a secure authenticated tunnel to that instance. That's SecureBridge in crates/blueprint-remote-providers/src/secure_bridge.rs.

The endpoint data structure:

pub struct RemoteEndpoint {
    pub instance_id: String,  // cloud instance ID
    pub host: String,         // hostname or IP
    pub port: u16,            // blueprint service port
    pub use_tls: bool,        // TLS for this connection
    pub service_id: u64,
    pub blueprint_id: u64,
}

SecureBridgeConfig defaults to mTLS on:

impl Default for SecureBridgeConfig {
    fn default() -> Self {
        Self {
            enable_mtls: true,
            connect_timeout_secs: 30,
            idle_timeout_secs: 300,
            max_connections_per_endpoint: 10,
        }
    }
}

In production (BLUEPRINT_ENV=production), certificate presence is enforced — the bridge fails hard if BLUEPRINT_CLIENT_CERT_PATH, BLUEPRINT_CLIENT_KEY_PATH, or BLUEPRINT_CA_CERT_PATH don't resolve to valid PEM files. In development, it falls back to system certs with a warning. Disabling mTLS entirely fails in production:

if is_production {
    return Err(Error::ConfigurationError(
        "mTLS cannot be disabled in production environment".into(),
    ));
}

There's also SSRF protection on endpoint registration. Endpoints that resolve to public IPs are rejected — only loopback and private ranges are accepted:

fn validate_endpoint_security(endpoint: &RemoteEndpoint) -> Result<()> {
    if let Ok(ip) = host.parse::<std::net::IpAddr>() {
        match ip {
            std::net::IpAddr::V4(ipv4) => {
                if !ipv4.is_loopback() && !ipv4.is_private() {
                    return Err(Error::ConfigurationError(
                        "Remote endpoints must use localhost or private IP ranges only".into(),
                    ));
                }
            }
            // ...
        }
    }
}

This means the SecureBridge is designed for tunneling to instances on private networks — not direct public internet exposure. The cloud provider's network layer (VPC, private subnet, VPN) is the outer security boundary; SecureBridge handles authentication within that perimeter.

X402Gateway as BackgroundService

Here's where the deployment model and the payment model intersect. X402Gateway implements BackgroundService. From crates/x402/src/gateway.rs:

impl BackgroundService for X402Gateway {
    async fn start(&self) -> Result<oneshot::Receiver<Result<(), RunnerError>>, RunnerError> {
        let (tx, rx) = oneshot::channel();
        let router = self.build_router();
        let addr = self.config.bind_address;

        tokio::spawn(async move {
            tracing::info!(%addr, "x402 payment gateway starting");
            // ... GC task for expired quotes ...
            let listener = tokio::net::TcpListener::bind(addr).await?;
            axum::serve(listener, router).await
        });

        Ok(rx)
    }
}

The build_router method registers four route families:

Router::new()
    .route("/x402/jobs/{service_id}/{job_index}", post(handle_job_request))
    .route("/x402/health", get(health_check))
    .route("/x402/stats", get(get_stats))
    .route("/x402/jobs/{service_id}/{job_index}/auth-dry-run", post(post_auth_dry_run))
    .route("/x402/jobs/{service_id}/{job_index}/price", get(get_job_price))

POST /x402/jobs/{service_id}/{job_index} is the payment-gated execution endpoint. The X402Middleware intercepts this route: absent payment header returns 402 with settlement options; present header is verified via the facilitator; settlement completes before the handler runs.

GET /x402/jobs/{service_id}/{job_index}/price is the discovery endpoint. Clients call this first to learn what payment is required — network, token, amount — without triggering execution.

POST /x402/jobs/{service_id}/{job_index}/auth-dry-run lets callers check RestrictedPaid access control eligibility before spending a payment. Useful for wallets that want to show the user whether they're permitted before presenting the payment UI.

GET /x402/stats exposes the GatewayCounters snapshot: accepted payments, policy denials, replay guard hits, enqueue failures. Low-overhead observability without external instrumentation.

The x402 server binds to a separate address from any primary runner ports (default 0.0.0.0:8402), configured in X402Config.bind_address.

The Producer Channel: How Payments Become JobCalls

The mechanical connection between the HTTP server and the job runner is X402Producer. From crates/x402/src/producer.rs:

pub struct X402Producer {
    rx: mpsc::UnboundedReceiver<VerifiedPayment>,
}

impl X402Producer {
    pub fn channel() -> (Self, mpsc::UnboundedSender<VerifiedPayment>) {
        let (tx, rx) = mpsc::unbounded_channel();
        (Self { rx }, tx)
    }
}

impl Stream for X402Producer {
    type Item = Result<JobCall, BoxError>;

    fn poll_next(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Option<Self::Item>> {
        match self.rx.poll_recv(cx) {
            Poll::Ready(Some(payment)) => Poll::Ready(Some(Ok(payment.into_job_call()))),
            Poll::Ready(None) => Poll::Ready(None),
            Poll::Pending => Poll::Pending,
        }
    }
}

X402Gateway::new creates both sides of this channel internally:

pub fn new(
    config: X402Config,
    job_pricing: HashMap<(u64, u32), U256>,
) -> Result<(Self, X402Producer), X402Error> {
    // ...
    let (producer, payment_tx) = X402Producer::channel();
    // ...
    Ok((gateway, producer))
}

The payment_tx sender lives inside the gateway. When a payment verifies and settles, the handler sends a VerifiedPayment through payment_tx. The X402Producer (which holds rx) is wired into the runner as a standard producer — the runner polls it alongside TangleProducer or any other source.

VerifiedPayment.into_job_call() stamps the resulting JobCall with metadata that job handlers can inspect:

pub const X402_QUOTE_DIGEST_KEY: &str  = "X-X402-QUOTE-DIGEST";
pub const X402_PAYMENT_NETWORK_KEY: &str = "X-X402-PAYMENT-NETWORK";
pub const X402_PAYMENT_TOKEN_KEY: &str  = "X-X402-PAYMENT-TOKEN";
pub const X402_ORIGIN_KEY: &str         = "X-X402-ORIGIN";
pub const X402_SERVICE_ID_KEY: &str     = "X-TANGLE-SERVICE-ID";
pub const X402_CALL_ID_KEY: &str        = "X-TANGLE-CALL-ID";
pub const X402_CALLER_KEY: &str         = "X-TANGLE-CALLER";

The job handler receives a JobCall identical in shape to one from Tangle, but the metadata tells it the call came from x402 and on which chain. Nothing in the dispatch path treats x402 jobs differently — the router doesn't know or care.

X402InvocationMode: Per-Job Access Control

Each job's x402 accessibility is independently configured via X402InvocationMode. From crates/x402/src/config.rs:

pub enum X402InvocationMode {
    #[default]
    Disabled,
    PublicPaid,
    RestrictedPaid,
}

Disabled (the default) means the gateway will return 403 for this job even if payment is provided — the job is not reachable via x402. PublicPaid is open to anyone who can pay. RestrictedPaid adds an isPermittedCaller check against a Tangle contract before execution.

For RestrictedPaid, X402CallerAuthMode determines how caller identity is asserted:

pub enum X402CallerAuthMode {
    #[default]
    PayerIsCaller,
    DelegatedCallerSignature,
    PaymentOnly, // invalid for RestrictedPaid — config validation rejects this
}

PayerIsCaller infers identity from the settled payment's payer address — simplest, works for wallets that pay for themselves. DelegatedCallerSignature supports scenarios where an agent pays on behalf of a user: the agent includes X-TANGLE-CALLER, X-TANGLE-CALLER-SIG, X-TANGLE-CALLER-NONCE, and X-TANGLE-CALLER-EXPIRY headers. The gateway verifies the signature and runs the Tangle permission check against the declared caller, not the payer.

RestrictedPaid requires both tangle_rpc_url and tangle_contract in the JobPolicyConfig. Config validation rejects RestrictedPaid with PaymentOnly auth or missing RPC config at startup.

The Full Builder Pattern

Here's how these pieces compose in BlueprintRunner. From crates/runner/src/lib.rs:

pub fn background_service(mut self, service: impl BackgroundService + 'static) -> Self {
    self.background_services.push(DynBackgroundService::boxed(service));
    self
}

pub fn producer<E>(
    mut self,
    producer: impl Stream<Item = Result<JobCall, E>> + Send + Unpin + 'static,
) -> Self { ... }

The x402 wiring:

let config = X402Config::from_toml("x402.toml")?;
let job_pricing = /* HashMap<(u64, u32), U256> from your pricing config */;

let (gateway, producer) = X402Gateway::new(config, job_pricing)?;

BlueprintRunner::builder(tangle_config, env)
    .router(router)
    .producer(tangle_producer)   // on-chain job source
    .producer(producer)          // x402 payment job source
    .background_service(gateway) // x402 HTTP server
    .run()
    .await?;

Both producers are polled concurrently in the same event loop. The gateway runs in its own tokio::spawn. The runner manages their lifetimes uniformly — when the runner shuts down, the oneshot::Receiver from each background service's start() signals completion or error.

Deployment Decision Tree

Putting the topology choices together:

DockerLocal + no SecureBridge: Development. No provisioning, no TLS tunnel, no external cloud credentials needed. Run cargo run locally, test x402 payment flow with a local facilitator.

VirtualMachine (AWS/GCP/DigitalOcean/Vultr/Hetzner) + SecureBridge mTLS: Production single-operator. The manager SSHes into provisioned VMs, starts containers, registers RemoteEndpoint in SecureBridge. The x402 gateway binds on the remote VM and is reachable via the provider's networking. SecureBridge handles manager-to-instance communication authenticated with client certs from /etc/blueprint/certs/.

ManagedKubernetes (EKS/GKE/AKS) + CloudProvider load balancer: Multi-job, horizontally scaled. EKS and AKS get LoadBalancer service type. GKE gets ClusterIP with an Ingress resource. The x402 gateway runs as a BackgroundService inside each pod — payment ingress is co-located with the job runner, not a separate service.

GenericKubernetes + tunnel: Existing clusters, staging environments, or on-prem. The context: Option<String> field lets you switch kubeconfig contexts without modifying the default. Paired with CloudProvider::Generic, which requires_tunnel() — you need to handle the private networking layer yourself.

BareMetal: Bare metal SSH hosts. The BareMetal(Vec<String>) variant takes a list of SSH-accessible hosts. Also requires_tunnel() — no managed networking, SecureBridge provides the auth layer within your existing network perimeter.

The x402 gateway placement is the same in all of these: .background_service(gateway) in the builder. The deployment target changes where the process runs and how it's networked. The payment ingress layer is identical code regardless of where the runner executes.

What This Buys You

The BackgroundService model solves a real operational problem: operator upgrade paths don't require payment gateway downtime. When you roll a new version of your blueprint, the runner and its BackgroundServices restart together. There's no separately managed payment proxy to upgrade, no version skew between the proxy and the business logic it fronts.

It also means x402 payment ingress scales with your runner. Add more pods — you get more payment capacity. No centralized payment router to scale separately, no single point of failure in the payment path.

The tradeoff is that the x402 HTTP endpoint is co-located with the job runner rather than edge-deployed. If you need CDN-level caching of price discovery responses or geographic distribution of payment ingress endpoints, you'd put a lightweight HTTP proxy in front. The price and auth-dry-run endpoints are stateless and safe to cache. The job execution endpoint requires the live runner — that one can't be edge-cached by definition.

For most Blueprint service operators — particularly ones using Tangle for decentralized AVS infrastructure — the co-location model is the right default. The runner is already the first layer worth scaling. Adding another independent service to manage introduces complexity that only pays off at scales most early-stage services won't hit.

S2-09 in the x402 Production Runway series. Previous: Operator Economics and Fee Distribution.

x402 and TEE Together: What Must Pass Before Promotion

Tangle Network — Mon, 30 Mar 2026 21:48:16 +0000

The Default That Will Burn You in Production

on_chain_verification defaults to false.

That single field in TeeKeyExchangeConfig is a production trap. With it disabled, a key exchange succeeds if the attestation report passes local structural checks — provider match, measurement comparison, debug mode flag — but nobody verifies that the attestation corresponds to the hash submitted on-chain at provision time. A compromised operator can substitute a different TEE's attestation during key exchange. The keys are exchanged. Secrets are injected. Nothing fails. The attestation mismatch is invisible.

// crates/tee/src/config.rs
pub struct TeeKeyExchangeConfig {
    pub session_ttl_secs: u64,
    pub max_sessions: usize,
    /// When enabled, key exchange performs dual verification:
    /// 1. Local evidence check: is this a real TEE with the right measurement?
    /// 2. On-chain hash comparison: does this attestation match the hash submitted
    ///    at provision time (keccak256(attestationJsonBytes) stored in contract)?
    ///
    /// This prevents a compromised operator from substituting a different TEE's
    /// attestation during key exchange.
    #[serde(default)]
    pub on_chain_verification: bool,
}

impl Default for TeeKeyExchangeConfig {
    fn default() -> Self {
        Self {
            session_ttl_secs: 300,
            max_sessions: 64,
            on_chain_verification: false,  // must be set true in production
        }
    }
}

This is not a papercut. It is the difference between a TEE system that can be spoofed and one that cannot. Every other gate below depends on knowing which enclave you are actually talking to.

Two Gates, Not One

Most Blueprint developers treat payment gating and TEE attestation as orthogonal concerns. Configure X402Middleware for payments, wire up TeeLayer for attestation, ship it. But in production, they compose into a single promotion condition. A service request that passes payment verification but comes from a debug-mode enclave is not production-safe. A TEE attestation that checks out locally but was never cross-referenced against the on-chain hash is not production-safe either.

The on-chain promotion path makes this concrete. A service moves from PendingRequest to Active only when approvalCount == operatorCount in ServicesApprovals.sol:

// tnt-core/src/core/ServicesApprovals.sol
function approveService(uint64 requestId, uint8 stakingPercent) external whenNotPaused nonReentrant {
    // ...
    _requestApprovals[requestId][msg.sender] = true;
    req.approvalCount++;

    emit ServiceApproved(requestId, msg.sender);

    if (req.approvalCount == req.operatorCount) {
        _activateService(requestId);
    }
}

_activateService is only called when every operator in the request has approved. A service with three operators named in the request does not activate after one approval. It does not activate after two. It activates exactly once: when the count matches the operator count. Payment and staking verification happen before an operator can even submit an approval — an operator that fails _staking.isOperatorActive(msg.sender) is rejected at the gate, before the count advances.

This is gate one. Gate two is inside the enclave.

The Eight Conditions

Before a Blueprint service with ConfidentialityPolicy::TeeRequired should be trusted in production, eight conditions must hold simultaneously. Failing any one of them means the service should not be promoted.

1. debug_mode must be false

// crates/tee/src/attestation/claims.rs
pub struct AttestationClaims {
    /// Whether the TEE is running in debug mode.
    /// Debug mode enclaves should never be trusted in production.
    #[serde(default)]
    pub debug_mode: bool,
    // ...
}

The comment is the policy: debug mode enclaves should never be trusted in production. A Nitro enclave built with --debug-mode produces attestation that any verifier can inspect and any tool can spoof. The hardware isolation properties do not hold. This field is populated from the raw attestation document — if the enclave set the debug flag, debug_mode is true, and promotion should be rejected.

2. on_chain_verification must be enabled

Already covered above. Without it, local attestation verification is the only check, and local verification cannot detect attestation substitution by a compromised operator. This must be true in TeeKeyExchangeConfig for any production deployment.

3. Attestation freshness: is_expired() must return false

// crates/tee/src/attestation/report.rs
impl AttestationReport {
    pub fn is_expired(&self, max_age_secs: u64) -> bool {
        let now = std::time::SystemTime::now()
            .duration_since(std::time::UNIX_EPOCH)
            .map(|d| d.as_secs())
            .unwrap_or(0);
        now.saturating_sub(self.issued_at_unix) > max_age_secs
    }
}

The default max_attestation_age_secs in TeeConfig is 3600 (one hour). An expired attestation means the report was generated more than an hour ago. The enclave may have been rebooted, reprovisioned with a different binary, or had its measurement changed. Any of those invalidate the on-chain hash comparison. is_expired must return false before key exchange is permitted.

4. Measurement pinning: the Measurement digest must match

// crates/tee/src/attestation/report.rs
pub struct Measurement {
    pub algorithm: String,
    pub digest: String,  // normalized to lowercase hex
}

pub struct AttestationReport {
    pub measurement: Measurement,
    // ...
}

The attestation report carries a hardware measurement — PCR values on Nitro, MRTD on TDX, the equivalent on SEV-SNP. At provision time, this measurement hash is submitted on-chain as keccak256(attestationJsonBytes). During key exchange with on_chain_verification: true, the verifier re-fetches that on-chain hash and checks it against the current report's evidence digest. If the enclave binary changed between provision and key exchange, the measurement changes, the evidence digest changes, and the on-chain comparison fails. Measurement pinning is the mechanism that makes TEE deployments immutable from the operator's perspective.

5. SecretInjectionPolicy must be SealedOnly

// crates/tee/src/config.rs
pub enum SecretInjectionPolicy {
    /// Only valid for non-TEE (container) deployments.
    EnvOrSealed,
    /// Container recreation is forbidden. Mandatory for all TEE deployments.
    SealedOnly,
}

The builder enforces this at construction time — any TeeConfig with a non-Disabled mode automatically gets SealedOnly. But configs deserialized from JSON or TOML go through validate() which applies the same check. The reason is not just security hygiene: env-var injection via container recreation invalidates attestation, breaks sealed secrets, and loses the on-chain deployment ID. If a deployed TEE service can have its secrets changed via environment variable, the entire attestation chain is moot.

6. Source filtering: ConfidentialityPolicy::TeeRequired restricts to container sources only

// crates/manager/src/protocol/tangle/event_handler.rs
fn supports_tee(source: &BlueprintSource) -> bool {
    matches!(source, BlueprintSource::Container(_))
}

fn ordered_source_indices(
    sources: &[BlueprintSource],
    preferred_source: SourceType,
    confidentiality_policy: ConfidentialityPolicy,
) -> Vec<usize> {
    let require_tee = matches!(confidentiality_policy, ConfidentialityPolicy::TeeRequired);
    let mut indexed: Vec<(usize, u8)> = sources
        .iter()
        .enumerate()
        .filter(|(_, source)| !require_tee || supports_tee(source))
        // ...
}

When ConfidentialityPolicy::TeeRequired, the event handler filters available sources to containers only. GitHub binaries and remote URLs are excluded — they run as native processes outside any enclave boundary. If the blueprint exposes no container source, the manager returns Error::TeeRuntimeUnavailable and the service does not start:

if matches!(
    metadata.confidentiality_policy,
    ConfidentialityPolicy::TeeRequired
) && ordered_source_idxs.is_empty()
{
    return Err(Error::TeeRuntimeUnavailable {
        reason: "Blueprint requires TEE execution but exposes no container source"
            .to_string(),
    });
}

7. Operator approval count must equal operator count

Covered in the contract section above. req.approvalCount == req.operatorCount is the exact condition. All operators named in the service request must call approveService before _activateService fires. A partial approval set means some operators have not committed their stake and agreed to the service parameters. The service does not go Active until the set is complete.

8. Payment and staking verified

Before any operator can submit an approval, _staking.isOperatorActive(msg.sender) must return true. The staking contract enforces that the operator has an active stake on-chain. Without active stake, the approval call reverts with OperatorNotActive. Payment verification on the client side happens before the initial service request is submitted — x402 payment headers are validated by the operator's gateway before the JobCall enters the execution pipeline. By the time a service request reaches the approval phase, the payment commitment is already part of the signed request that operators are approving.

How Operators Get Cryptographic Proof

Once a service is Active and jobs are running, operators need to know which enclave ran each job. This is what TeeLayer provides.

// crates/tee/src/middleware/tee_layer.rs
pub const TEE_ATTESTATION_DIGEST_KEY: &str = "tee.attestation.digest";
pub const TEE_PROVIDER_KEY: &str = "tee.provider";
pub const TEE_MEASUREMENT_KEY: &str = "tee.measurement";

TeeLayer is a Tower middleware layer. On every successful JobResult::Ok, it injects three metadata keys into the result head: the SHA-256 digest of the attestation evidence, the provider name, and the measurement string. Operators receive this in the job result and can independently verify: re-hash the evidence bytes and compare against the stored TEE_ATTESTATION_DIGEST_KEY. If the hash matches what was submitted at provision time, the operator has cryptographic proof that this specific job ran inside the specific enclave they approved.

// crates/tee/src/middleware/tee_layer.rs
fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
    // ...
    match result {
        Some(mut result) => {
            let JobResult::Ok { head, .. } = &mut result else {
                return Poll::Ready(Ok(Some(result)));
            };

            if let Some(digest) = this.attestation_digest.take() {
                head.metadata.insert(TEE_ATTESTATION_DIGEST_KEY, digest);
            }
            if let Some(provider) = this.provider.take() {
                head.metadata.insert(TEE_PROVIDER_KEY, provider);
            }
            if let Some(measurement) = this.measurement.take() {
                head.metadata.insert(TEE_MEASUREMENT_KEY, measurement);
            }

            Poll::Ready(Ok(Some(result)))
        }
        None => Poll::Ready(Ok(None)),
    }
}

The attestation is injected from a shared Arc<Mutex<Option<AttestationReport>>>. The layer uses try_lock on the hot path to avoid blocking the service call. If the lock is contended, the keys are omitted from that result with a warning — a tradeoff that keeps job execution from stalling on attestation state reads.

The Key Exchange Session Lifecycle

Sealed secrets are how configuration, API keys, and model weights enter a TEE without the operator ever seeing them. The flow is two-phase: TEE generates an ephemeral X25519 keypair, attests the public key, and the client encrypts secrets to it after verifying the attestation.

// crates/tee/src/exchange/protocol.rs
pub struct KeyExchangeSession {
    pub session_id: String,
    pub public_key: Vec<u8>,
    private_key: Vec<u8>,  // zeroed on drop
    pub created_at: u64,
    pub ttl_secs: u64,
}

impl Drop for KeyExchangeSession {
    fn drop(&mut self) {
        self.private_key.zeroize();
    }
}

Private keys are zeroed on drop via zeroize. The default session TTL is 300 seconds. Sessions are one-time use — consume_session atomically removes the session from the map on consumption, so the same session ID cannot be replayed:

// crates/tee/src/exchange/service.rs
pub async fn consume_session(&self, session_id: &str) -> Result<KeyExchangeSession, TeeError> {
    let mut sessions = self.sessions.lock().await;

    let session = sessions
        .get(session_id)
        .ok_or_else(|| TeeError::KeyExchange(format!("session not found: {session_id}")))?;

    if session.is_expired() {
        sessions.remove(session_id);
        return Err(TeeError::KeyExchange(format!("session expired: {session_id}")));
    }

    // Session is valid — remove and return it (one-time use)
    let session = sessions
        .remove(session_id)
        .expect("session exists; checked above");

    Ok(session)
}

A background cleanup task runs every max(ttl_secs, 30) seconds to evict expired sessions that were never consumed. The TeeAuthService holds an AbortHandle to this task, which is cancelled on drop — no orphaned background tasks if the service is torn down.

The maximum concurrent sessions defaults to 64. If the limit is reached, create_session evicts expired sessions first before rejecting with a capacity error. This prevents session exhaustion from stale entries accumulating.

The Production Checklist

Putting it together: a Blueprint service with ConfidentialityPolicy::TeeRequired is production-ready when:

Condition	Where enforced	Default
`debug_mode: false`	`AttestationClaims` from hardware	false
`on_chain_verification: true`	`TeeKeyExchangeConfig`	false — must override
Attestation not expired	`AttestationReport::is_expired()`	3600s max age
Measurement matches on-chain	`on_chain_verification` flow	disabled by default
`SecretInjectionPolicy::SealedOnly`	`TeeConfig` builder	auto-enforced when TEE enabled
Container source available	`ordered_source_indices` filter	fails hard if missing
All operators approved	`approvalCount == operatorCount`	contract-enforced
Operator staking active	`_staking.isOperatorActive`	contract-enforced

Six of eight are enforced automatically by the type system or contracts. The two that require explicit action: on_chain_verification must be set to true, and the blueprint must expose a container source when TEE is required. Everything else fails closed.

Previous in the series: RFQ, Job Quotes, and On-Chain Verification. Next: TBD.

Operator Economics After Payment: Distribution, Exposure Weighting, and Fee Routing

Tangle Network — Sat, 28 Mar 2026 18:43:42 +0000

When a client pays an x402 Blueprint job, the USDC moves to the operator's pay_to address on the settlement chain. That's the end of the client's story. It's the beginning of the operator's.

The payment lands as a cross-chain deposit. Before operators can claim anything, the Tangle protocol has to decide who gets what. An operator running a high-stakes Blueprint with a large staking pool behind it gets a different cut than one running the same Blueprint with minimal backing. The distribution isn't arbitrary — it's driven by exposure, USD-weighted delegation scores, and blueprint selection mode. This post opens that system.

Where payments enter the distribution layer

After x402 settlement, the Tangle contract calls distributeServiceFee on ServiceFeeDistributor. This is the on-chain entry point for all service-fee revenue.

function distributeServiceFee(
    uint64 serviceId,
    uint64 blueprintId,
    address operator,
    address paymentToken,
    uint256 amount
)
    external
    payable
    override
    nonReentrant

Only the Tangle contract can call this — msg.sender != tangle reverts. The function handles both native ETH (paymentToken == address(0)) and ERC-20 tokens. For ERC-20, it expects no msg.value; for native, it requires msg.value == amount. This prevents a class of accounting bugs where msg.value doesn't match what the caller claimed to send.

Source: tnt-core/src/rewards/ServiceFeeDistributor.sol

Streaming vs immediate distribution

The first branch after validation isn't about who gets the fee — it's about when they get it.

Types.Service memory svc = ITangleSecurityView(tangle).getService(serviceId);
if (svc.ttl > 0 && address(streamingManager) != address(0)) {
    uint64 startTime = svc.createdAt;
    uint64 endTime = svc.createdAt + svc.ttl;
    if (block.timestamp > startTime) {
        startTime = uint64(block.timestamp);
    }
    if (endTime > startTime) {
        IERC20(paymentToken).safeTransfer(address(streamingManager), amount);
        streamingManager.createStream{ value: paymentToken == address(0) ? amount : 0 }(
            serviceId, blueprintId, operator, paymentToken, amount, startTime, endTime
        );
        return;
    }
}
_distributeImmediate(serviceId, blueprintId, operator, paymentToken, amount);

If the service has a TTL and StreamingPaymentManager is configured, the entire payment transfers to the streaming manager and gets distributed pro-rata over the service lifetime. If a delegation changes mid-service, the distributor drips the stream first — paying out at the current score ratios — then applies the delegation change. This prevents retroactive gaming: you can't bond more stake after a job runs and claim a larger slice of revenue that was already earned at lower backing levels.

For services without TTL (or if streaming isn't configured), distribution is immediate via _distributeImmediate.

How drip math works

The StreamingPaymentManager holds the full fee amount and releases chunks over time:

durationSeconds = currentTime - p.lastDripTime;
uint256 duration = p.endTime - p.startTime;
uint256 remaining = p.totalAmount - p.distributed;
uint256 chunk = (p.totalAmount * durationSeconds) / duration;
if (chunk > remaining) {
    chunk = remaining;
}

Each drip is proportional to elapsed time. At 50% of the service lifetime, 50% of the payment is dripable. The dripped chunk gets forwarded back to ServiceFeeDistributor for immediate distribution at current scores.

Source: tnt-core/src/rewards/StreamingPaymentManager.sol

USD-weighted scoring: why your asset mix matters

Once funds reach _distributeImmediate, the contract needs to split the payment across delegators. The split is proportional to USD-weighted score, not raw token amounts. This is the core economic mechanism.

Each delegator's score for an operator is tracked in two modes:

All mode (selectionMode = All): the delegator's stake covers all blueprints the operator runs. Score accumulates in totalAllScore[operator][assetHash].
Fixed mode (selectionMode = Fixed): the delegator's stake is allocated to specific blueprint IDs. Score accumulates in totalFixedScore[operator][blueprintId][assetHash].

Score is computed at delegation time:

scoreDelta = (amount * lockMultiplierBps) / BPS_DENOMINATOR;

The lock multiplier rewards longer-duration commitments with more score per unit of capital. Score decreases on withdrawal proportional to the principal reduction, preserving the effective rate.

The fee then splits between All-mode and Fixed-mode pools proportionally:

uint256 allAmount = (amount * allUsdTotal) / totalUsd;
uint256 fixedAmount = amount - allAmount;

Where allUsdTotal and fixedUsdTotal are the USD values of effective (post-slash) scores for each pool. Within each pool, fees are distributed using an accumulator-per-score pattern:

accAllPerScore[operator][assetHash][paymentToken] +=
    (share * PRECISION) / allScore;

This is O(1) per asset per payment token — no loop over delegators. Delegators claim by computing score * accPerScore - debtAtLastSync. A delegator who bonded after a fee was distributed has their debt initialized at the current accumulator level, so they only earn on fees distributed after they joined.

Exposure weighting: committed capital drives reward share

For services with AssetSecurityRequirements, the USD computation adds an exposure layer. Each operator declares how much of their delegation they're willing to have at risk for a service — commitmentBps — and the exposed amount drives both slashing and fee allocation.

uint256 allExposed = (allEffective * commitmentBps) / BPS_DENOMINATOR;
allUsdTotal += _toUsd(a, allExposed);

Higher exposure means higher risk (you can be slashed on more of your stake) and higher reward (you earn a larger share of the service fee). Operators who run low-commitment configurations take less slashing risk but earn proportionally less revenue. The ExposureCalculator library encodes this directly:

/// @notice Calculate reward share based on exposure percentage
/// @dev Higher exposure = higher risk = higher reward share
function calculateRewardShare(
    uint256 delegatedAmount,
    uint16 exposureBps,
    uint256 totalReward,
    uint256 totalExposedValue
) internal pure returns (uint256 rewardShare) {
    if (totalExposedValue == 0) return 0;
    uint256 exposedAmount = calculateExposedAmount(delegatedAmount, exposureBps);
    return (totalReward * exposedAmount) / totalExposedValue;
}

exposureBps is bounded between MIN_EXPOSURE_BPS = 1 (0.01%) and MAX_EXPOSURE_BPS = 10_000 (100%), defined in ExposureTypes. An operator at 5000 bps (50% exposure) earns half of what the same operator at 10000 bps (full exposure) would earn, all else equal.

The USD weighting uses a price oracle to normalize across assets. An operator backed by ETH and one backed by stablecoins compete on USD-equivalent exposed value, not raw token count.

Source: tnt-core/src/exposure/ExposureCalculator.sol

TNT score boost

The distributor supports a configurable TNT token score rate:

/// @dev If tntScoreRate = 1e18, then 1 TNT = $1 score regardless of actual market price.
/// If tntScoreRate = 0, TNT uses oracle price like other tokens.
uint256 public tntScoreRate;

When tntScoreRate is set above the oracle price of TNT, delegators backing operators with TNT earn amplified score per dollar of capital — a direct incentive to hold and stake the native token. At tntScoreRate = 1e18 with TNT at $0.10 market price, TNT earns 10× the fee share of its market value relative to other tokens.

Treasury fallback

If an operator has zero stakers or zero USD-weighted score when a fee arrives, the fee doesn't sit in the contract — it routes to the protocol treasury:

if (totalUsd == 0) {
    _transferPayment(ITangleSecurityView(tangle).treasury(), paymentToken, amount);
    return;
}

Same behavior if the operator has no asset hashes tracked at all. Fees are never stranded in the distributor.

The payment metadata trail

On the Blueprint SDK side, X402Producer propagates the payment context into the job metadata so that operators can trace which payment triggered which execution:

pub const X402_QUOTE_DIGEST_KEY: &str = "X-X402-QUOTE-DIGEST";
pub const X402_PAYMENT_NETWORK_KEY: &str = "X-X402-PAYMENT-NETWORK";
pub const X402_PAYMENT_TOKEN_KEY: &str = "X-X402-PAYMENT-TOKEN";
pub const X402_ORIGIN_KEY: &str = "X-X402-ORIGIN";
pub const X402_SERVICE_ID_KEY: &str = "X-TANGLE-SERVICE-ID";
pub const X402_CALL_ID_KEY: &str = "X-TANGLE-CALL-ID";

Every job that came from an x402 payment carries its quote digest, payment network (CAIP-2), token, service ID, and a synthetic call ID for tracking. This metadata is consumed by the runner, not by the distribution layer — but it's the operator's audit trail linking an HTTP payment to a specific on-chain service invocation.

Source: blueprint/crates/x402/src/producer.rs

What's wired vs what's planned

Two items in the distribution system are architecturally present but not fully live:

Security-adjusted pricing. calculate_security_rate_adjustment in the pricing engine returns Decimal::ONE unconditionally. The hook exists and is wired through calculate_resource_price, but the implementation is a stub (// TODO: Implement security requirement adjustments). Premium pricing for high-exposure operators isn't in production yet.

Slashing impact on distribution. Slash factors are live in ServiceFeeDistributor. _allSlashFactor and _fixedSlashFactor are applied via _applySlashFactor before USD scoring:

uint256 allEffective = _applySlashFactor(allScore, _getAllSlashFactor(operator, assetHash));

The slashing mechanism in ServiceFeeDistributor is operational. What feeds those slash factors — the slashing protocol itself — depends on the staking and governance layer, which is out of scope here.

The economic signal in the design

The fee distribution design encodes a specific opinion about what operators should optimize for: committed, long-duration, diversified backing. Operators with high USD-weighted exposure earn more per fee unit. Operators with mixed asset backing benefit from oracle normalization. Operators who attract All-mode delegators (stake that covers the full service roster) earn from a broader pool than operators whose delegators make narrow Fixed-mode bets.

The streaming payment design punishes late entry. Delegation after a service starts doesn't capture retroactive fees — drips happen at the score ratios that were in place at drip time. This is intended: an operator who can attract capital before a service launches is more valuable to the protocol than one who can attract it after the fact.

The Three Numbers That Keep Your Blueprint Online

Tangle Network — Thu, 26 Mar 2026 07:35:26 +0000

Operator Monitoring and Health Checks for Tangle Blueprint Nodes

Tangle is a programmable infrastructure network where operators run modular services called Blueprints and get selected for paid jobs based on on-chain health signals. Three signals govern whether your operator stays in rotation: on-chain heartbeats submitted through the OperatorStatusRegistry, quote freshness (5-minute default lifetime, 1-hour protocol maximum), and capacity utilization (activeLoad vs. maxCapacity). The orchestrator's health tracker maintains a rolling window of the last 10 job outcomes, requiring a minimum 30% success rate to stay selectable, with a 60-second cooldown after each failure. Fall behind on any one of these and the orchestrator silently skips you. Jobs stop arriving with no error message and no notification.

Getting a Blueprint operator online is the easy part. Keeping it selected for jobs is where most operators quietly fail. The thresholds governing selection aren't obvious from the outside. They live in the orchestrator's health tracker, in on-chain registry contracts, and in protocol constants spread across multiple config files. This post pulls those numbers into one place and explains how they interact, so you can build monitoring that catches problems before they cost you revenue.

Heartbeats: the on-chain pulse check

Operators prove liveness by submitting heartbeats on-chain through the OperatorStatusRegistry. Each heartbeat carries a service ID, blueprint ID, status code, and an optional metrics payload. The registry tracks four values per operator per service:

lastHeartbeat: timestamp of the most recent submission
consecutiveBeats: how many in a row without a miss
missedBeats: accumulated misses
lastMetricsHash: hash of the most recent metrics payload

Two functions expose the result: isHeartbeatCurrent() returns whether the latest heartbeat is within the configured interval, and isOnline() combines heartbeat freshness with status code to give a binary liveness signal.

Status codes and what they mean

The protocol defines five status codes:

Code	Name	Range Convention
0	Healthy	Exactly 0
1	Degraded	1-99
2	Offline	100+
3	Slashed	200+ (slashable)
4	Exiting	Voluntary exit in progress

The range convention matters. A status of 15 still reads as "degraded" to the registry, but you can use the specific number to encode granularity for your own monitoring. Some operators use values like 10 for "high memory pressure" and 20 for "disk nearing capacity" while staying in the degraded band.

Each service configures its own HeartbeatConfig with an interval (how often heartbeats are expected), a maxMissed threshold (how many misses before consequences), and an optional customMetrics flag. This is per-service, not global, so an operator running three different blueprints might have three different heartbeat cadences.

Querying your own state

You can inspect your operator's on-chain health at any time:

// Binary liveness check
registry.isHeartbeatCurrent(serviceId, operatorAddr);
registry.isOnline(serviceId, operatorAddr);

// Full state inspection
registry.getOperatorState(serviceId, operatorAddr);
// Returns: lastHeartbeat, consecutiveBeats, missedBeats, status, lastMetricsHash

// Individual metric values (if customMetrics enabled)
registry.getMetricValue(serviceId, operatorAddr, "cpu_utilization");

The getMetricDefinitions(serviceId) call returns the schema for a service's expected metrics, including name, minValue, maxValue, and whether each metric is required. If your blueprint defines required metrics and you stop submitting them, the registry logs the violation on-chain.

The health tracker's rolling window

On-chain heartbeats are only half the picture. The orchestrator that routes jobs to operators maintains its own health tracker with a separate, more aggressive set of thresholds.

The health tracker is a rolling window of the last 10 job outcomes per operator (HEALTH_WINDOW_SIZE = 10). From that window, it computes a success rate. If the rate drops below 30% (MIN_SUCCESS_RATE = 0.3), the operator is marked unhealthy and stops receiving new work.

A 30% floor sounds lenient, and it is, deliberately. The system tolerates occasional failures (network blips, transient resource pressure) without immediately pulling an operator from rotation. But the companion mechanism is less forgiving: after any failure, the operator enters a 60-second cooldown (FAILURE_COOLDOWN = 60s) during which it won't receive jobs regardless of its overall success rate.

The practical effect: a single failure costs you at least a minute of downtime. Three failures in quick succession won't necessarily drop you below the 30% floor (depending on your recent history), but the cooldowns stack. If you're failing every other job, you're spending half your time in cooldown even though your 50% success rate is above the threshold.

How selection works

When the orchestrator needs to assign a job, it sorts available operators using three criteria in priority order:

Health status: healthy operators before unhealthy
Available capacity: operators with more open slots first
Success rate: higher rates preferred as a tiebreaker

Available slots are computed as maxCapacity - activeLoad. If your activeLoad equals your maxCapacity, you won't be selected regardless of health. This is the capacity utilization number, and it's the one most operators forget to monitor.

The health summary for each operator looks like this:

type OperatorHealthSummary = {
  address: `0x${string}`;
  successRate: number;
  healthy: boolean;
  activeLoad: number;
  maxCapacity: number;
  availableSlots: number;
  onCooldown: boolean;
};

New operators with fewer than 3 recorded outcomes are assumed healthy. This grace period lasts until your third job completes.

Quote lifetimes: the tuning surface nobody talks about

When a user requests a job, the operator's pricing engine generates a quote. That quote has a lifetime, and getting the lifetime right matters more than most operators realize.

Quote validity duration is the number of seconds a price quote remains acceptable to the protocol after generation. The default is 5 minutes (quote_validity_duration_secs: 300 in operator.toml). The protocol enforces a hard cap of 1 hour (MAX_QUOTE_AGE = 1 hours in ProtocolConfig.sol). Anything between those bounds is your call.

Why shorter isn't always better

A short quote lifetime (say, 30 seconds) limits your price exposure. If the cost of the resources you're committing changes between quote generation and job execution, a shorter window reduces the risk that you're locked into a stale price. For operators dealing with volatile token pricing, this matters.

But short lifetimes create user friction. The user needs to receive the quote, review it, sign the payment, and submit the request before the quote expires. On a congested network, that flow can easily take more than 30 seconds. An expired quote means a failed request, a retry, and a frustrated user. It also counts as a job failure in the health tracker's rolling window, which means short quote lifetimes can indirectly damage your health score.

Why longer isn't always better

A long quote lifetime (approaching the 1-hour cap) is comfortable for users but risky for operators. Resource costs can shift, token exchange rates can move, and you're committed to the quoted price for the entire window. If you're pricing in wei (the protocol's denomination-neutral unit for cross-chain, multi-token pricing), exchange rate drift compounds with any staleness in your benchmark data.

Practical guidance

For most operators, the 5-minute default works well for stablecoin-denominated services where price volatility is low. Consider adjusting in these scenarios:

Volatile token pricing: Drop to 60-120 seconds. Accept the increased retry rate as a cost of price accuracy.
Long user flows: If your users are interacting through UIs with multiple confirmation steps, extend to 10-15 minutes. Monitor your expired-quote rate.
High-value jobs: Shorter is safer. A 1-hour quote on a job that costs several hundred dollars in compute creates real exposure.

Keep your quote server address current on-chain via updateOperatorPreferences on the ITangleOperators interface. A stale address means quotes can't be fetched at all, which is worse than any lifetime misconfiguration.

The pricing engine under the hood

Quotes aren't arbitrary numbers. The pricing engine runs automated benchmarks on your hardware when a service activates (ServiceActivated event), measuring CPU, memory, storage, network, and GPU performance. Results are cached locally by blueprint ID.

The quote formula is: Base Resource Cost x Time Multiplier x Security Commitment Factor.

Resource pricing is configured per-blueprint in your operator.toml:

[blueprint.resources]
cpu = { count = 8, price_per_unit = "0.001" }
memory = { count = 16384, price_per_unit = "0.00005" }
storage = { count = 1024000, price_per_unit = "0.00002" }

The pricing engine's full config controls benchmark behavior and the quote server:

database_path = "./data/price_cache"
benchmark_duration = 60
benchmark_interval = 1
keystore_path = "./data/keystore"
rpc_bind_address = "127.0.0.1"
rpc_port = 9000
rpc_timeout = 30
rpc_max_connections = 100
quote_validity_duration_secs = 300

If rpc_max_connections is too low for your traffic, quote requests will queue and potentially time out, which looks identical to an offline quote server from the user's perspective. For operators expecting high request volume, bumping this above the default 100 is worth doing.

The degradation cascade: signals before slashing

Operators don't get slashed out of nowhere. There's a predictable four-stage cascade, and every stage produces signals you can catch if you're watching.

Stage 1: Heartbeat drift. Your heartbeat interval starts slipping. Maybe a network issue, maybe resource contention on the node. The consecutiveBeats counter resets and missedBeats starts climbing. On-chain, your status is still Healthy, but the trend is visible.

Stage 2: Degraded status. Once missedBeats crosses a threshold (per your service's HeartbeatConfig.maxMissed), the status shifts to Degraded (codes 1-99). You're still selectable for jobs, but the orchestrator's health tracker may start reflecting failures if the underlying issue is also affecting job execution.

Stage 3: Offline. Continued misses push the status to Offline (codes 100+). isOnline() returns false. The orchestrator stops sending you work entirely. You're still staked, still committed, but earning nothing.

Stage 4: Slashing risk. If the offline period extends beyond the grace window, slashing becomes possible. The dispute window is 14 rounds (3.5 days, since each round is 6 hours). An exit takes 56 rounds (14 days). These are not fast processes, which is intentional: they give operators time to recover from legitimate outages.

Every stage before slashing is recoverable. Fix the underlying issue, submit a successful heartbeat, and the cascade resets. The operators who get slashed are the ones who aren't watching.

What metric violations actually do

The MetricDefinition system lets services define bounds (minValue, maxValue) for custom metrics like CPU utilization or memory usage. When a submitted metric falls outside those bounds, the violation is logged on-chain. Currently, violations don't trigger automatic slashing. They create an on-chain record that can be used in governance-driven disputes, but the enforcement path is manual. This may change as the protocol matures, so treat metric bounds as soft limits today and hard limits tomorrow.

Revenue: what you're protecting

The default fee split for job revenue is:

Recipient	Share
Operators	40%
Developers	20%
Protocol	20%
Stakers	20%

These percentages are governance-configurable. On top of job revenue, operators can earn TNT incentives from the InflationPool and commission from delegator RewardVaults. But all of these revenue streams depend on one thing: staying in rotation. An operator that's offline, in cooldown, or at capacity earns nothing.

Building your monitoring stack

The QoS endpoints on your node give you the raw signals:

# Quick health check
curl -s http://localhost:9090/health

# Prometheus metrics (for Grafana dashboards)
curl -s http://localhost:9090/metrics | head -n 20

This Prometheus alerting config catches problems at Stage 1 of the degradation cascade, before they affect job selection:

groups:
  - name: blueprint_operator
    rules:
      - alert: HeartbeatDrift
        expr: increase(operator_missed_beats_total[30m]) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Operator {{ $labels.instance }} missed >2 heartbeats in 30m"
          description: "Heartbeat drift detected. Investigate before status degrades."

      - alert: CapacityExhausted
        expr: (operator_active_load / operator_max_capacity) > 0.9
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Operator {{ $labels.instance }} at >90% capacity for 10m"

      - alert: SuccessRateDropping
        expr: operator_job_success_rate < 0.5
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Operator {{ $labels.instance }} success rate below 50%"
          description: "Below 30% triggers removal from rotation."

The metrics you should alert on, mapped to the three numbers that matter:

Heartbeat health:

consecutiveBeats trending downward
missedBeats incrementing
Status code changing from 0 to anything else

Quote freshness:

Quote generation latency approaching quote_validity_duration_secs
Expired-quote rate (track client-side 402 retries if possible)
Benchmark cache age (stale benchmarks produce stale prices)

Capacity utilization:

activeLoad / maxCapacity ratio approaching 1.0
Available slots dropping to zero during peak hours
Job queue depth if your blueprint supports queuing

The protocol's timing constants give you the boundaries for alert thresholds:

Constant	Value	What it means for alerting
`ROUND_DURATION_SECONDS`	21,600 (6 hr)	Rounds are the unit of protocol time
`ROUNDS_PER_EPOCH`	28 (7 days)	Epoch boundaries trigger reward distribution
`DISPUTE_WINDOW_ROUNDS`	14 (3.5 days)	Time to respond to slashing disputes
`OPERATOR_DELAY_ROUNDS`	56 (14 days)	Minimum exit timeline
`MAX_QUOTE_AGE`	1 hour	Absolute ceiling for quote validity
`MIN_SERVICE_TTL`	1 hour	Shortest allowed service commitment

FAQ

How many heartbeats can I miss before getting slashed?

There is no single fixed number. Slashing risk comes from a cascade, not a threshold: missed beats push you to Degraded, then Offline, then into a slashing-eligible window with a 14-round (3.5-day) dispute period. Your service's HeartbeatConfig.maxMissed setting controls when the Degraded transition happens, and that value varies by blueprint. The practical answer: set up alerts on missedBeats incrementing (Stage 1 of the cascade) and you'll catch drift long before slashing is on the table.

Should I set my quote lifetime to the maximum 1 hour?

Almost certainly not. The 1-hour MAX_QUOTE_AGE is a protocol ceiling, not a recommendation. A 1-hour quote locks you into pricing that may not reflect current resource costs or token exchange rates. The 5-minute default is a reasonable starting point. Only extend it if your users consistently need more time to complete the quote-to-submission flow, and even then, 10-15 minutes is usually sufficient.

What happens if my node is healthy but at full capacity?

You stop receiving new jobs. The orchestrator's selection algorithm checks availableSlots (maxCapacity -activeLoad) and skips operators with zero slots. You won't be marked unhealthy, but you'll earn nothing until capacity frees up. If this happens regularly during peak hours, either increasemaxCapacity` (if your hardware supports it) or run additional operator instances.

Do metric violations lead to automatic slashing?

Not currently. When a submitted metric falls outside the bounds defined in MetricDefinition, the violation is logged on-chain but enforcement is governance-driven, not automatic. That said, the on-chain record exists and could be used against you in a dispute. Treat metric bounds as constraints you should respect, because the enforcement mechanism will likely tighten over time.

What's the minimum success rate to stay in rotation?

30%, calculated over a rolling window of your last 10 jobs. This sounds generous, but the 60-second cooldown after each failure is the real constraint. If you're failing frequently, the cooldowns accumulate and you spend significant time unable to receive work, even if your success rate stays above the floor. An operator failing every third job has a 67% success rate (well above the floor) but loses at least 20 seconds of every minute to cooldowns.

On-Chain RFQ for Compute: How Job Quotes, Verification, and Slashing Work

Tangle Network — Wed, 25 Mar 2026 03:51:07 +0000

Subscription vs Pay-Per-Request API Pricing: Tradeoffs, Implementation, and When to Use Each

Tangle Network — Tue, 24 Mar 2026 18:50:12 +0000

Pay-per-request API pricing charges consumers per call with no accounts or billing infrastructure. It fits sporadic usage, machine-to-machine calls, and operators who want zero billing ops. Subscription pricing charges a flat recurring fee, enabling customer relationships, volume discounts, feature gating, and predictable revenue, but it requires payment processing integration and account management. The right choice depends on call frequency (subscriptions win for high-volume, predictable usage), consumer type (organizations prefer subscriptions with invoices; autonomous agents prefer per-request), and how much billing infrastructure you're willing to maintain. Some architectures support both simultaneously, routing pay-per-request and subscription clients through the same service handlers via a unified job dispatch layer.

This isn't a new problem. Twilio built a $4B business on pay-per-request (fractions of a cent per SMS). Slack charges per seat per month. AWS meters to the millisecond. According to OpenView's 2023 SaaS Benchmarks report, roughly 45% of SaaS companies now offer some form of usage-based pricing, up from 34% in 2020, and companies with usage-based models report 120% net dollar retention compared to 110% for pure subscription. The trend is clear: the industry is moving toward usage-based models, but subscriptions aren't going anywhere.

What makes this question interesting right now is that blockchain settlement protocols like Coinbase and Cloudflare's x402 have made pay-per-request radically cheaper to implement. Where you once needed Stripe, an accounts database, and a credits ledger, you can now accept payment with a config file. Blueprint SDK's pricing engine takes this further by defining both models at the protocol level, letting operators configure their billing model without changing application code. This post uses Blueprint's implementation as a concrete reference, but the tradeoffs apply to any API service.

When to Use Which

Before diving into implementation, here's the decision framework. Everything that follows supports this table.

Dimension	Pay-Per-Request	Subscription	Resource-Based
Billing infrastructure	Near zero (config files only)	Significant (Stripe, accounts, webhooks)	Moderate (benchmarking + metering)
Latency overhead	1-3 sec per call (on-chain settlement)	None per call (pre-authorized)	None per call (pre-authorized)
Customer visibility	Anonymous wallets	Full identity, usage analytics	Full identity, usage analytics
Revenue predictability	Variable, follows demand	Recurring, plannable	Variable, follows demand
Ideal call pattern	Sporadic, high-value calls	Frequent, predictable volume	Long-running compute jobs
Consumer type	Machines, agents, anonymous users	Organizations, teams	Infrastructure buyers
Volume discounts	Not natively possible	Natural (tiered plans, credit packs)	Natural (bulk rates)
Ops cost to operator	Minimal	High (billing UI, support, churn mgmt)	Moderate (benchmarking maintenance)

Pay-per-request fits when:

Calls are infrequent or unpredictable. If users call your service once a week or once a month, a subscription is a hard sell. Per-request pricing lets them pay exactly for what they use.
You want zero billing ops. No Stripe account, no accounts to manage, no invoices to send, no chargebacks to dispute.
Your consumers are machines, not people. AI agents making API calls don't need a billing dashboard. They need a 402 response they can programmatically respond to.
The value per call is high enough to justify the latency. That 1-3 second settlement overhead is trivial for a $3 AI inference call. It's a dealbreaker for a $0.0001 data lookup.

Subscription fits when:

Calls are frequent and predictable. A service handling thousands of requests per day is a natural subscription product. The consumer wants cost certainty; the operator wants revenue predictability.
You need customer relationships. Tier-based feature gating, usage analytics, churn prevention, upselling: these require knowing who your customers are.
You want to capture value above cost. Subscriptions let you price on value delivered, not compute consumed. A $99/month plan for a service that saves hours of manual work is good economics regardless of server cost. Bessemer's 2024 Cloud Index shows that the highest-margin SaaS companies price on value, not cost, with top-quartile gross margins above 80%.
Your consumers are organizations. Companies want invoices, contracts, and SLAs. A "pay with your wallet per request" model doesn't fit procurement processes.

Resource-based pricing (charging by actual compute consumed) fits a third niche: long-running GPU jobs, storage provisioning, infrastructure rentals. The price derives from hardware benchmarks, not a business decision. It's honest math, well-suited for commodity compute where transparency builds trust.

Pay-Per-Request: x402 and the Billing Stack Collapse

HTTP status code 402 has been "reserved for future use" since 1999. Twenty-seven years later, Coinbase and Cloudflare's x402 protocol gave it a real job. A client hits an endpoint, gets back a 402 response with pricing information, signs a stablecoin payment, and resends the request with an X-PAYMENT header containing proof of settlement. No API keys, no billing dashboard, no invoices.

What makes this interesting for service operators is what it eliminates. A traditional paid API requires an account system, API key management, a credit balance ledger, reconciliation logic, dispute resolution, and fraud detection. With x402, the blockchain is the billing system. The wallet is the API key. The transaction receipt is the invoice.

Implementation

The x402 gateway integrates into a Blueprint as a middleware layer. Two TOML files and a few lines of Rust:

let mut config = X402Config::from_toml("x402.toml")?;
let pricing = load_job_pricing(&std::fs::read_to_string("job_pricing.toml")?)?;
let oracle = CachedRateProvider::new(CoinbaseOracle::new(), Duration::from_secs(60));
refresh_rates(&mut config, &oracle, "ETH").await?;
let (gateway, x402_producer) = X402Gateway::new(config, pricing)?;

BlueprintRunner::builder((), BlueprintEnvironment::default())
    .router(router())
    .producer(x402_producer)
    .background_service(gateway)
    .run()
    .await?;

Job prices are set in wei per job type. Why wei? Because operators can accept multiple tokens across different chains, and wei provides a denomination-neutral base unit. At request time, the gateway runs a deterministic conversion:

Concretely: a 0.001 ETH job at an ETH price of $3,200 with a 200 basis point operator markup becomes 0.001 * 3200 * 1.02 = 3.264 USDC.

Settlement-First Design

The operator gets paid before doing any work. The X402Gateway calls .settle_before_execution(), confirming the stablecoin transfer on-chain before the job handler fires. This adds 1-3 seconds of latency on Base for the facilitator round-trip, but it means the operator never does unpaid work.

Compare this to traditional API billing, where you bill after the fact and hope the credit card doesn't bounce. The tradeoff is latency for certainty.

Access Control

Three access modes, configured in x402.toml:

Disabled (default): no payment gateway active.
PublicPaid: anyone who sends valid payment can call the service.
RestrictedPaid: payment required, plus an on-chain isPermittedCaller check via eth_call. Paid service with an allowlist.

What You Give Up

No customer relationships. No usage analytics per customer. No volume discounts. No feature gating. No trials. Every request is an anonymous economic transaction. If a customer calls your service 10,000 times a month, you have no way to offer them a better rate and no way to identify them.

Exchange rates are static, operator-configured values. This removes runtime dependency on Chainlink or DEX price feeds, but operators need to manage their own rate refresh. The config uses Arc<Mutex<JobPricingConfig>> for runtime updates without restart, but the responsibility is yours.

The quote registry is in-memory with a 300-second TTL. Quotes are lost on restart. For high-availability deployments, plan accordingly.

Subscription: Predictable Revenue, More Moving Parts

Blueprint's pricing engine defines subscription as a first-class model via a PricingModelHint enum:

PAY_ONCE = 0;        // resource x rate x TTL
SUBSCRIPTION = 1;    // flat rate per billing interval
EVENT_DRIVEN = 2;    // flat rate per event

Subscription pricing is configured per service:

[default]
pricing_model = "subscription"
subscription_rate = 0.001
subscription_interval = 86400    # daily (seconds)
event_rate = 0.0001

Price calculation is simple: subscription_rate * security_factor. No resource benchmarking, no TTL math. Both subscription and event-driven pricing produce the same output as pay-per-request: a signed EIP-712 quote with price, timestamp, and expiry. This uniformity matters because downstream job dispatch doesn't care which model generated the quote.

The EVENT_DRIVEN variant sits between subscription and pure pay-per-request. It charges a flat rate per event without x402's full HTTP 402 handshake and stablecoin settlement. Think of it as "pay-per-call without the on-chain overhead."

What Subscriptions Enable in Practice

The partner billing system in blueprint-agent shows what a production subscription looks like. Three tiers: Starter ($99/month, 500k credits), Growth ($349/month, 2M credits), Enterprise ($999/month, 10M credits). Credits convert at roughly 10,000 per dollar. Overages are calculated as excessCredits * monthlyPriceCents / includedCredits and charged via Stripe.

This model enables things pay-per-request structurally cannot:

Feature gating per tier: quest limits, leaderboards, verification types, custom domains, SLA guarantees.
Volume discounts: credit packs at decreasing per-unit cost (100k for $10, 5M for $350).
Customer relationships: you know who your users are, what they use, and when they churn.
Predictable revenue: monthly recurring revenue is easier to plan around than variable per-request income.

The cost is infrastructure. Stripe integration, webhook handlers for invoice.payment_succeeded, idempotency checks, credit pool management, and a billing UI. That's real engineering investment, and for small operators it can outweigh the pricing model's benefits.

The Architectural Trick: Running Both at Once

Here's the design insight that makes this more than a binary choice. The x402 gateway converts incoming paid HTTP requests into JobCall values, the same type that every other trigger source produces: on-chain events, cron schedules, webhooks. Job handlers don't know how they were triggered.

This means a single service can accept payments through multiple models simultaneously. An X402Producer handles pay-per-request clients. A subscription verification layer handles subscribers. Both feed the same router, the same job handlers, the same execution path.

x402 client ------> X402Producer ----\
                                      +---> Router ---> Job Handlers
subscription -----> SubProducer -----/

The PricingModelHint enum already supports this at the protocol level. The economic model becomes a configuration choice, not an architectural fork. This is the same pattern Twilio uses: programmatic callers pay per API call, while enterprise customers negotiate volume contracts, but the underlying telephony infrastructure doesn't care which billing model triggered the call.

The Economics, Spelled Out

Consider a Blueprint running AI inference at $0.002 compute cost per call.

Pay-per-request at $0.01/call: At 10,000 calls/month, that's $100 revenue, $20 cost, $80 margin. At 100 calls/month, it's $1 revenue. The operator earns proportionally but has no revenue floor.

Subscription at $99/month (500k credits): At 10,000 calls/month, the consumer uses 2% of their allocation. The operator gets $99 regardless. At 100,000 calls/month, the consumer still pays $99 and the operator's margin compresses.

The math clarifies the tradeoff. Pay-per-request aligns revenue perfectly with usage but provides no predictability. Subscription provides a revenue floor but creates margin risk on heavy consumers. The right answer depends on your usage distribution: if most consumers cluster around a predictable volume, subscription wins. If usage is highly variable or long-tail, per-request is safer for the operator.

Roadmap: What's Not Shipped Yet

The pricing engine's subscription model has config, calculation logic, and signed quote output. But there's no on-chain enforcement equivalent to the x402 gateway for subscriptions today. The partner billing system handles subscription enforcement through Stripe (off-chain). An on-chain subscription verification layer is the gap for fully trustless subscription services.

The x402 facilitator at facilitator.x402.org is currently centralized. A decentralized facilitator Blueprint is spec'd but not shipped. For now, settlement routes through a single facilitator service.

FAQ

Can I run both subscription and pay-per-request on the same service?

Yes. Both models produce the same JobCall type through different producers feeding the same router. The PricingModelHint enum defines both at the protocol level. You'd wire an X402Producer for pay-per-request alongside a subscription verification producer, both routing to identical job handlers.

How do I handle exchange rate drift with x402?

Rates are static in your config, not oracle-fed. The Arc<Mutex<JobPricingConfig>> allows runtime updates without restart, so you can run a background task that periodically refreshes from a price feed. The CachedRateProvider wrapping a CoinbaseOracle with a 60-second cache is one pattern in the SDK examples. Rate freshness is the operator's responsibility.

What happens to x402 quotes if my service restarts?

The QuoteRegistry is in-memory. On restart, all outstanding quotes are lost. The default 300-second TTL limits exposure. For high-availability deployments, you'd want very short TTLs or a persistent quote store, though neither is provided out of the box.

How does the per-event model differ from x402 pay-per-request?

Both are usage-based, but they operate at different layers. x402 runs a full HTTP 402 handshake with on-chain stablecoin settlement per request. The event-driven model (EVENT_DRIVEN in the pricing engine) charges a flat rate per invocation through the pricing engine's quote system, without the HTTP 402 flow or settlement overhead. Event-driven is lighter-weight but relies on whatever payment enforcement layer is wired upstream.

What's the minimum setup to test x402 payments?

Two TOML files: job_pricing.toml with per-job prices in wei, and x402.toml with gateway config and accepted tokens. Wire them into BlueprintRunner with X402Gateway and x402_producer. The /x402/stats endpoint gives you counters for accepted, rejected, and enqueued payments. Test against Base testnet with test USDC.

Pricing without hand-waving: wei pricing, token conversion, markup, and dynamic price tags

Tangle Network — Mon, 23 Mar 2026 22:31:11 +0000

The pricing problem nobody wants to solve

Every API platform hits the same question eventually: how do you charge for compute? AWS solved it with a 200-page pricing calculator. Stripe solved it with a dashboard and a billing team. Most blockchain protocols punt entirely, letting operators pick a number and hope it covers costs.

The hard version of this problem shows up when your operators are running heterogeneous workloads (CPU-bound inference, GPU rendering, long-running agent tasks) across different chains, settling in different tokens, with different exchange rates, and they need quotes that are cryptographically verifiable before a single cycle burns. Tangle's pricing engine was built for exactly this. The core of it is a conversion pipeline: operators price jobs in wei (the smallest ETH unit), and at settlement time the engine divides by 10^18 to get ETH, multiplies by an exchange rate (e.g., 3,200 USDC/ETH), applies an operator-defined markup in basis points, then scales to the token's smallest unit and floors the result to an integer. A job priced at 0.001 ETH with a 3,200 USDC/ETH rate and 2% markup (200 bps) yields 3,264,000 USDC micro-units, or $3.264. Every resulting quote is EIP-712 signed with expiry and replay protection.

That conversion layer sits on top of a dual-denomination pricing system (USD for resource provisioning, wei for per-job calls), three pricing models, hardware benchmarking, and a full anti-abuse stack. This post walks through each layer, what the config looks like, and where the sharp edges are.

Blockchain API pricing: the conversion formula

Before getting into the pricing engine's architecture, here's the function that makes cross-token settlement work. The convert_wei_to_amount function is the bridge between blockchain-native pricing and stablecoin payments:

pub fn convert_wei_to_amount(&self, wei_price: &U256) -> Result<String, X402Error> {
    let wei_decimal = Decimal::from_str_exact(&wei_price.to_string())?;
    let native_unit = Decimal::from(10u64.pow(18));
    let native_amount = wei_decimal / native_unit;
    let token_amount = native_amount * self.rate_per_native_unit;
    let markup = Decimal::ONE + Decimal::from(self.markup_bps) / Decimal::from(10_000u32);
    let final_amount = token_amount * markup;
    let token_unit = Decimal::from(10u64.pow(u32::from(self.decimals)));
    Ok((final_amount * token_unit).floor().to_string())
}

Five steps, each doing one thing:

Wei to ETH: divide by 10^18
ETH to token value: multiply by the exchange rate (e.g., 3,200 USDC per ETH)
Apply markup: basis points divided by 10,000, added to 1.0 (200 bps = 1.02x)
Scale to smallest unit: multiply by 10^decimals (10^6 for USDC, 10^18 for DAI, 10^8 for WBTC)
Floor: no fractional atomic units

The formula's output depends heavily on the token's decimal places. Here's the same 0.001 ETH job at a 3,200 rate with 200 bps markup across four tokens:

Token	Decimals	Smallest Unit	Raw Conversion	Final (with 2% markup)
USDC	6	micro-dollar	3,200,000	3,264,000
USDT	6	micro-dollar	3,200,000	3,264,000
DAI	18	wei-equivalent	3,200,000,000,000,000,000	3,264,000,000,000,000,000
WBTC	8	satoshi	320,000,000	326,400,000

The USDC and USDT rows look identical because both use 6 decimals. DAI's 18 decimals produce enormous integers. WBTC's 8 decimals land in between. The floor operation matters most for low-decimal tokens on small transactions, where rounding could eat a meaningful fraction of the payment.

Two monetary worlds: USD and wei

The pricing engine doesn't pick one denomination and force everything through it. Instead, it maintains two separate pricing paths that serve different purposes.

Resource-based pricing works in USD with arbitrary decimal precision. Operators configure rates like "$0.001 per CPU core per second" in a TOML file, and the engine multiplies those rates against benchmarked hardware profiles and time-to-live values. This is the path for service provisioning, where the cost depends on what resources you're reserving.

Per-job pricing works in wei, the smallest unit of ETH (1 ETH = 10^18 wei). Operators map each (service_id, job_index) pair to a raw wei amount stored as a string (because U256 values overflow standard integer types). This is the path for individual job execution, where the cost is a flat fee per call.

# Resource pricing: USD, decimal precision
[default]
resources = [
  { kind = "CPU", count = 1, price_per_unit_rate = 0.001 },
  { kind = "MemoryMB", count = 512, price_per_unit_rate = 0.0005 },
  { kind = "GPU", count = 1, price_per_unit_rate = 0.01 },
]

# Job pricing: wei, string-encoded U256
[1]
0 = "1000000000000000"       # Job 0: 0.001 ETH
6 = "20000000000000000"      # Job 6: 0.02 ETH
7 = "250000000000000000"     # Job 7: 0.25 ETH

Why two systems instead of one? Because the cost structures are fundamentally different. A service that provisions a container with 4 CPUs and a GPU for 30 minutes has costs that scale with resources and time. An LLM inference call has a roughly fixed cost per invocation regardless of how long the operator's machine has been running. Forcing both through the same formula would mean either over-abstracting the resource model or under-specifying the job model.

The split also matches how operators think about pricing. Infrastructure costs map naturally to USD rates per resource unit. Per-call API pricing maps naturally to "this job costs X." Asking operators to mentally convert between these two frames adds friction without adding clarity.

The resource pricing formula

For resource-based pricing (the PAY_ONCE model), the engine computes total cost as the sum of each resource's cost: count × price_per_unit_rate × ttl_blocks × block_time × security_factor.

The implementation in pricing.rs breaks this into composable pieces:

pub fn calculate_resource_price(
    count: u64,
    price_per_unit_rate: Decimal,
    ttl_blocks: u64,
    security_requirements: Option<&AssetSecurityRequirements>,
) -> Decimal {
    let adjusted_base_cost = calculate_base_resource_cost(count, price_per_unit_rate);
    let adjusted_time_cost = calculate_ttl_price_adjustment(ttl_blocks);
    let security_factor = calculate_security_rate_adjustment(security_requirements);
    adjusted_base_cost * adjusted_time_cost * security_factor
}

block_time() is hardcoded at 6 seconds. security_factor currently returns Decimal::ONE, a placeholder for future adjustment based on asset security requirements. The hook exists in the formula so that when security-weighted pricing ships, it slots in without changing the calculation structure.

The interesting part is where count comes from. Rather than trusting operators to self-report their hardware, the engine benchmarks the actual machine for CPU, memory, storage, GPU, and network. These benchmark profiles are cached per blueprint ID in RocksDB. The engine then multiplies the benchmarked resource usage against the configured per-unit rates. If you're coming from cloud pricing, think of it as the operator publishing a rate card while the engine measures the meter.

Ten resource types, six on-chain

The engine defines ten resource types: CPU, MemoryMB, StorageMB, NetworkEgressMB, NetworkIngressMB, GPU, Request, Invocation, ExecutionTimeMS, and StorageIOPS, plus a Custom(String) escape hatch.

Only the first six map to on-chain resource commitments in the signer. The rest (Request, Invocation, ExecutionTimeMS, StorageIOPS) are priced and included in the cost calculation, but they don't generate on-chain commitments. This distinction matters: on-chain commitments are what the protocol enforces. Off-chain resource types let operators factor in costs that are real but not worth the gas to commit individually.

Blueprint-specific overrides

Pricing config supports per-blueprint overrides with a fallback chain. The engine looks up the blueprint_id first; if no match exists, it falls back to default:

[default]
resources = [
  { kind = "CPU", count = 1, price_per_unit_rate = 0.001 },
]

[42]
resources = [
  { kind = "CPU", count = 1, price_per_unit_rate = 0.0015 },
]

Blueprint 42 gets premium CPU pricing. Everything else gets the default. This is a simple pattern, but it means operators can run dozens of blueprints with a single pricing config file, overriding only where the economics differ.

Three pricing models

The protobuf definition in pricing.proto specifies three models:

PAY_ONCE (0) is the resource-based model described above. It requires hardware benchmarks, computes cost from resource counts, rates, and TTL, and produces quotes for createServiceFromQuotes() on-chain. This is the model for long-running service provisioning.

SUBSCRIPTION (1) is a flat rate per billing interval. No benchmarks needed.

[default]
pricing_model = "subscription"
subscription_rate = 0.001        # USD per interval
subscription_interval = 86400    # 1 day in seconds

[5]
pricing_model = "subscription"
subscription_rate = 0.005
subscription_interval = 604800   # 1 week

EVENT_DRIVEN (2) is a flat rate per event or job invocation. Also no benchmarks.

[default]
pricing_model = "event_driven"
event_rate = 0.0001              # USD per event

The subscription and event-driven models bypass the benchmark-and-resource calculation entirely. They exist because not every service has costs that correlate with hardware usage. A notification service that sends webhooks has a per-event cost structure. A monitoring service that runs continuously has a subscription cost structure. Forcing these through resource-based pricing would produce nonsensical numbers.

Accepted token configuration

Each token an operator accepts gets its own config block with the exchange rate, markup, and settlement details:

[[accepted_tokens]]
network = "eip155:8453"
asset = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
symbol = "USDC"
decimals = 6
pay_to = "0xYourOperatorAddressOnBase"
rate_per_native_unit = "3200.00"
markup_bps = 200
transfer_method = "eip3009"
eip3009_name = "USD Coin"
eip3009_version = "2"

The markup_bps field is the operator's margin, defined in basis points (1 bp = 0.01%). Set it to 0 for break-even pricing. Set it to 500 (5%) if you want a buffer against exchange rate fluctuation. Set it to 2000 (20%) if you're running premium infrastructure and the market bears it.

rate_per_native_unit is a static config value. There's no oracle feed or automatic rate refresh built into the engine. If ETH/USDC moves 10% in a day, your prices are 10% stale until you update the config. This is an explicit design choice: operators own their exchange rate assumptions. For operators running high-volume services, a cron job that polls a price feed (Chainlink, CoinGecko, or a centralized exchange API) and rewrites the TOML is the practical solution. The Arc<Mutex<>> runtime config described below makes it possible to update rates without restarting the server.

On-chain representation: the scale factor

USD amounts need to live on-chain as integers. The engine uses a 10^9 scale factor where 1 USD = 1,000,000,000 atomic units.

pub const PRICING_SCALE_PLACES: u32 = 9;

pub fn decimal_to_scaled_amount(value: Decimal) -> Result<U256> {
    let scaled = (value * pricing_scale()).trunc();
    let int_value = scaled.to_u128()?;
    Ok(U256::from(int_value))
}

Zero prices are explicitly rejected. If you want a free tier, the engine forces you to implement that logic explicitly rather than setting a price of zero. This is a deliberate choice: a price of zero is ambiguous (is it free? is it misconfigured?), while explicit free-tier logic is unambiguous.

Trust nothing: the anti-abuse stack

A pricing API that returns unsigned numbers over unauthenticated RPC invites abuse. The pricing engine layers four defenses.

1. Proof of work on every request

Before the pricing engine will even process an RPC request, the client must solve a SHA-256 proof of work challenge. The default difficulty requires 20 leading zero bits. The challenge input is SHA256(blueprint_id || timestamp), and the timestamp must be within 30 seconds of server time.

The point is to make it expensive to spam the quoting endpoint. An attacker trying to scrape prices across thousands of configurations has to burn real CPU time for each request.

2. EIP-712 signed quotes

Every quote the engine returns is signed using EIP-712 structured data with domain TangleQuote version 1. Service quotes commit the totalCost, blueprintId, ttlBlocks, security commitments, and resource commitments. Job quotes commit serviceId, jobIndex, price, timestamp, and expiry.

A client can present a quote to a smart contract and the contract can verify that (a) the operator actually issued it, (b) it hasn't been tampered with, and (c) it covers exactly the resources and price claimed. No trust in the relay, the client, or any middleware.

3. Configurable expiry with a hard ceiling

Quotes have a configurable validity duration (quote_validity_duration_secs, default 5 minutes). The on-chain contract enforces a separate maxQuoteAge (default 1 hour) as a hard ceiling. Even if an operator sets quote validity to a week, the contract won't accept anything older than an hour.

This two-layer expiry means operators can tune freshness for their use case (tighter for volatile prices, looser for stable services) while the protocol prevents ancient quotes from being replayed.

4. On-chain replay protection

After a quote is submitted on-chain, its digest is marked as used. Presenting the same signed quote twice fails. Combined with the expiry window, this creates a tight lifecycle: a quote is valid for minutes, usable exactly once, and cryptographically bound to specific parameters.

From static config to dynamic pricing

The pricing system is designed as a stack that operators can climb incrementally.

Level 1: Static TOML. Start with a default_pricing.toml and job_pricing.toml. Set your rates, deploy, done. This covers most operators who want simple, predictable pricing.

Level 2: Per-blueprint overrides. Add sections for specific blueprint IDs with different rates. Still static config, but now you can price premium workloads differently from commodity ones.

Level 3: Runtime mutation. The job pricing config lives behind an Arc<Mutex<>>, which means it can be updated programmatically at runtime without restarting the server:

let job_config = load_job_pricing_from_toml(
    &std::fs::read_to_string("job_pricing.toml")?
)?;
let service = PricingEngineService::with_job_pricing(
    config, benchmark_cache, pricing_config,
    Arc::new(Mutex::new(job_config)),
    signer,
);

An operator could wire this to a monitoring system that adjusts prices based on load, time of day, or competitive dynamics. The config structure doesn't change; only the values behind the mutex do.

Level 4: x402 settlement with markup. Layer on cross-chain stablecoin settlement with per-token exchange rates and markup:

let service = service.with_x402_settlement(x402_config);

The builder pattern (with_job_pricing().with_subscription_pricing().with_x402_settlement()) makes each level of sophistication an additive change rather than a rewrite.

Standalone quote signing

Not every operator needs the full pricing engine. For simple cases where an operator knows the price and just needs a signed quote, the JobQuoteSigner can be used directly:

use blueprint_tangle_extra::job_quote::{
    JobQuoteSigner, JobQuoteDetails, QuoteSigningDomain
};

let signer = JobQuoteSigner::new(
    keypair,
    QuoteSigningDomain { chain_id, verifying_contract }
);

let signed = signer.sign(&JobQuoteDetails {
    service_id: 1,
    job_index: 7,
    price: U256::from(250_000_000_000_000_000u64), // 0.25 ETH
    timestamp: now,
    expiry: now + 3600,
});

This is useful for operators who compute prices through their own logic (ML-based pricing, auction mechanisms, manual overrides) and just need the signing infrastructure.

Sharp edges worth knowing

Exchange rates are your responsibility. The rate_per_native_unit in your token config is static. If you're accepting USDC and pricing in wei, a 15% ETH price swing means your USD-equivalent revenue shifts by 15%. High-volume operators should automate rate updates from a price feed.

Gas costs aren't factored in. The pricing engine calculates the cost of compute, not the cost of submitting the quote on-chain. For expensive jobs (0.25 ETH), gas is a rounding error. For cheap jobs (0.001 ETH), gas might be a meaningful fraction of the price. Operators should account for this in their markup or base prices.

Benchmarks measure the machine, not the blueprint. The benchmark system profiles the operator's hardware: CPU speed, memory bandwidth, storage throughput. It doesn't measure what a specific blueprint actually consumes during execution. If your blueprint uses 10% of available CPU, the benchmark still reflects 100% capacity. The count field in resource config is where operators specify expected per-unit resource consumption.

The security factor is a placeholder. calculate_security_rate_adjustment() returns Decimal::ONE today. The function signature and its position in the pricing formula signal that security-weighted pricing is planned, but it doesn't affect prices yet.

Putting it together

The pricing engine is built on a specific thesis: blockchain API pricing should be as structured and auditable as cloud pricing, but with cryptographic guarantees that cloud providers don't offer. An AWS pricing page tells you what things cost. A signed EIP-712 quote proves what things cost, who said so, when they said it, and that nobody changed the numbers in transit.

For operators, the practical upshot is a system that starts simple (edit a TOML file, set your rates) and scales to sophisticated (dynamic pricing, multi-token settlement, per-blueprint overrides) without architectural changes. The pricing formula is transparent, the conversion math is explicit, and the anti-abuse stack is built in rather than bolted on.

The next article in this series covers the settlement flow end-to-end: what happens after the client receives a signed quote, how the x402 payment proof is constructed, and how the on-chain verification contract validates everything before compute starts.

FAQ

How do operators decide what to charge per job in wei?

The engine doesn't prescribe a specific method. Operators set the (service_id, job_index) → wei_amount mapping in job_pricing.toml based on their own cost analysis. For compute-heavy jobs, estimate your per-call infrastructure cost (GPU time, memory, network), convert to wei at current ETH rates, and add your desired margin. The markup_bps field in the x402 config gives you a separate knob for margin on the settlement side, so you can keep base prices at cost and let markup handle profit.

Can an operator accept multiple tokens on different chains?

Yes, configure one [[accepted_tokens]] block per token/chain combination. Each block has its own exchange rate, markup, decimals, and pay-to address. A single operator can accept USDC on Base, USDT on Ethereum, and DAI on Arbitrum simultaneously. The conversion formula runs independently for each token, so different decimals and rates are handled automatically.

What happens if a quote expires before the client submits it?

The on-chain contract rejects it. Quotes default to 5 minutes of validity (configurable via quote_validity_duration_secs), and the contract enforces a hard 1-hour maxQuoteAge ceiling regardless of the operator's setting. Clients should treat quotes as short-lived and re-fetch before submission if their pipeline has latency.

How does the proof-of-work difficulty affect client experience?

At 20 leading zero bits (the default), solving takes roughly tens of milliseconds on modern hardware. Legitimate clients making occasional requests won't notice it. Attackers trying to scrape or spam the quoting endpoint at thousands of requests per second will. Operators can adjust the difficulty parameter if their threat model or client base requires it.

Can I use the pricing engine without x402 settlement?

Yes. The x402 settlement layer is added via the with_x402_settlement() builder method and is entirely optional. Without it, the engine produces quotes denominated in the native unit (wei for jobs, scaled USD for resources) and operators handle settlement through their own mechanism or the standard on-chain submitJob flow.

The x402 Facilitator Problem: Removing the Centralized Trust Bottleneck

Tangle Network — Mon, 23 Mar 2026 01:10:48 +0000

The x402 Facilitator Problem

Originally published at tangle.tools

A Permissionless Protocol with a Permissioned Bottleneck

HTTP status code 402 sat dormant for 27 years before Coinbase and Cloudflare's x402 protocol gave it a purpose: a client hits an endpoint, receives pricing info in a 402 response, signs a stablecoin payment off-chain, and resends the request with cryptographic proof of payment. No API keys. No billing dashboards. No invoices. Just math proving money moved before compute burned. But every x402 payment today routes through a single centralized HTTP service called the facilitator, which verifies and settles stablecoin transfers with zero cryptographic proof of correctness. This means a compromised facilitator can fabricate settlements, censor valid payments, or take down every x402-gated service by going offline. The fix is a phased migration: first verify the facilitator's claims against on-chain receipts, then move signature validation into the operator's gateway, then have operators submit settlement transactions directly on L2s where gas costs are sub-cent, and finally enforce payment-job atomicity through on-chain slashing.

The protocol itself is clever. EIP-3009's transferWithAuthorization lets clients sign USDC transfers without spending gas. The server verifies the signature, settles the payment on-chain, and serves the response. For Blueprint operators, this means any job can become a paid HTTP endpoint with a TOML config change. But between the client's signed payment and the operator's job execution sits that single facilitator service, and it deserves a lot more scrutiny than it gets.

The Three Failure Modes

The x402 facilitator problem is the set of risks created by routing all payments through a single unverified HTTP service. Concretely, there are three failure modes:

Fabrication. A compromised facilitator can claim payments settled when they didn't. The operator runs the job, burns compute, and receives nothing. The gateway never checks the chain.
Censorship. The facilitator can refuse to verify or settle valid payments. Since it's the only settlement path, a censoring facilitator locks clients out of services entirely.
Downtime. If https://facilitator.x402.rs goes offline, every x402-gated Blueprint stops accepting payments. Not because anything is wrong with the operator, the client, or the blockchain. Because one HTTP endpoint is unreachable.

A protocol built for permissionless infrastructure has a permissioned chokepoint at its economic core. This post breaks down exactly where the trust assumptions hide, why the incentive structure is wrong, and what a concrete path to removing the bottleneck looks like.

What the Facilitator Actually Does

The facilitator is an HTTP service that exposes three endpoints:

POST /v2/x402/verify    — confirm a client's signed payment is valid
POST /v2/x402/settle    — execute the on-chain token transfer
GET  /v2/x402/supported — list supported chains and tokens

When a client sends a request with a payment header, the operator's gateway calls verify first, then settle. If both succeed, the job runs. The entire flow:

Client ──► x402 HTTP Server ──► Payment Verified ──► JobCall injected
              (axum + x402-axum)     (facilitator)       (Producer stream)

In Blueprint's gateway, the facilitator is wired in as middleware:

X402Middleware::new(self.config.facilitator_url.as_str())
    .settle_before_execution();

And the facilitator itself is configured with a single field:

facilitator_url = "https://facilitator.x402.rs"

One URL. No fallback. No quorum. No alternative.

Trusted by Default, Verified by Nobody

Look at how the gateway handles the facilitator's settlement response:

fn parse_settlement_details(headers: &HeaderMap) -> Option<SettlementDetails> {
    let raw = headers.get(HEADER_SETTLEMENT)?.as_bytes();
    let decoded = Base64Bytes::from(raw).decode().ok()?;
    let settlement: SettleResponse = serde_json::from_slice(&decoded).ok()?;
    match settlement {
        SettleResponse::Success { payer, network, .. } => { /* trusted */ }
        SettleResponse::Error { network, .. } => { /* trusted */ }
    }
}

The gateway decodes a base64 blob from a response header, parses it as JSON, and acts on whatever it says. There is no signature over the settlement response. No on-chain receipt verification. No transaction hash lookup. The facilitator says "payment settled," and the gateway believes it.

Other decentralized payment relay systems don't work this way. Lightning Network nodes never trust a routing peer's claim that a payment forwarded successfully. Every hop produces a cryptographic preimage that proves the payment reached its destination, and the sender can verify this proof independently. Meta-transaction relayers like OpenGSN require relayers to post bonds and produce on-chain receipts that the relayed transaction executed; if a relayer claims to have relayed but didn't, the bond is forfeitable. The x402 facilitator offers neither cryptographic proofs nor economic bonds. It occupies a design space where the operator simply takes the facilitator's word for it.

The protocol spec is explicitly facilitator-agnostic. The config takes any URL. But in practice, one implementation exists, operated by one entity, with no cryptographic accountability for its outputs.

The Incentive Misalignment

Beyond the trust gap, the current architecture puts the wrong party in control of payment verification.

Consider who has skin in the game. The operator runs infrastructure, pays for compute, and needs to be paid for jobs. The client wants a service and is willing to pay. The facilitator? The facilitator is a third party with no economic stake in either side of the transaction.

Today's operator config includes economics that are entirely honor-system:

[[accepted_tokens]]
network = "eip155:8453"
asset = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
symbol = "USDC"
decimals = 6
pay_to = "0xYourOperatorAddressOnBase"
rate_per_native_unit = "3200.00"
markup_bps = 200

The markup_bps field (200 basis points, a 2% markup) is set locally in TOML. Nothing enforces it on-chain. The quote registry that prices jobs is ephemeral and in-memory:

QuoteRegistry::new(Duration::from_secs(config.quote_ttl_secs))  // default 300s TTL

Quotes live for five minutes, in RAM, on one machine. There's no audit trail. No way for a client to prove they were quoted a different price than what was settled. No way for an operator to prove the facilitator settled the correct amount.

This is an architecture where the party verifying payment correctness is the party with the least reason to care about payment correctness.

The On-Chain Pieces Already Exist

Most of the hard work is already done. The missing piece isn't cryptography or smart contracts. It's a different arrangement of components that already exist.

Verification is already a client-side operation

EIP-3009's transferWithAuthorization produces a signature over a structured payload: from, to, value, validAfter, validBefore, nonce. Anyone with access to the token contract can verify this signature. You don't need a facilitator to tell you a payment authorization is valid. You need ecrecover and a balance check.

The gateway already makes eth_call for other purposes. Restricted job access control works exactly this way:

// eth_call dry-run against Tangle contract
isPermittedCaller(uint64 service_id, address caller)

This is an on-chain verification that the gateway performs directly, without trusting a third party. The same pattern applies to payment verification: call the token contract, check the authorization signature, confirm the balance covers the amount.

Settlement is a single transaction

The facilitator's settle step submits a transferWithAuthorization call to the USDC (or DAI) contract. This is one transaction. The authorization is already signed by the client. Any address with gas can submit it. There is nothing about this transaction that requires a privileged intermediary.

The facilitator exists because someone needs to pay gas for settlement, and having the client do it would add friction. But operators already run Tangle nodes. They already have RPC access. They already have funded accounts for on-chain operations. Submitting one additional transaction per paid job is operationally trivial for infrastructure that's already making eth_call for access control.

What a local facilitator looks like

Replace the HTTP call to facilitator.x402.rs with a local module that:

Validates the transferWithAuthorization signature against the token contract using eth_call
Checks the payer's balance covers the payment amount
Submits the transferWithAuthorization transaction to the chain
Waits for the transaction receipt
Returns the receipt (with transaction hash) to the gateway

Steps 1-2 replace the facilitator's verify endpoint. Steps 3-5 replace settle. The gateway already has RPC access for isPermittedCaller. The same provider handles payment settlement.

The config change:

# Before: trust a third party
facilitator_url = "https://facilitator.x402.rs"

# After: verify and settle locally
facilitator_mode = "local"
settlement_rpc = "https://base-mainnet.g.alchemy.com/v2/..."

No new cryptography. No new smart contracts. Just cutting out the middleman from operations the gateway can already perform.

Removing Trust Assumptions, One Layer at a Time

Ripping out the facilitator in one shot would be reckless. The right approach removes trust assumptions incrementally. Each phase is independently deployable and backward-compatible, and each one closes a specific class of attack.

Phase 1: A compromised facilitator can no longer fabricate settlements

Keep the facilitator in the loop, but stop trusting it blindly. After the gateway receives a SettleResponse::Success, check the chain:

// After facilitator claims settlement succeeded
let receipt = provider.get_transaction_receipt(tx_hash).await?;
match receipt {
    Some(r) if r.status == 1 => { /* confirmed on-chain, proceed */ }
    _ => { /* facilitator lied or tx failed, reject */ }
}

This is a read-only change. The facilitator still does the work. But the gateway independently confirms that work actually happened. After this phase, the fabrication attack vector is closed: a facilitator that claims "payment settled" when it didn't gets caught by the receipt check. The operator never runs a job without on-chain proof.

This adds one eth_call per payment, roughly 50-100ms on L2s. Negligible for job execution workloads where the job itself takes seconds to minutes.

Phase 2: The facilitator can no longer censor valid payments

Move signature validation and balance checking into the gateway. The facilitator's verify endpoint becomes redundant. The gateway calls the facilitator only for settlement (the part that costs gas), and then confirms the settlement on-chain per Phase 1.

The trust surface shrinks here. Before Phase 2, a censoring facilitator could silently refuse to verify valid payments, and neither the operator nor the client would know whether the refusal was legitimate. After Phase 2, the gateway knows independently whether a payment is valid. If the facilitator refuses to settle a payment the gateway has already verified, the operator can log the discrepancy, alert on it, or fall back to self-settlement.

Phase 3: The facilitator is no longer in the path at all

The gateway submits transferWithAuthorization transactions directly. The facilitator_url field is removed from config entirely. The operator pays gas for settlement, a few cents on L2s like Base, and recoups it through markup_bps. That field, which was previously just a number in a TOML file with no enforcement, now reflects a real cost the operator bears and a real margin they control.

After this phase, operator availability depends only on the operator's own infrastructure and the underlying chain. No third-party HTTP service can take down payment processing.

Phase 4: Misbehavior becomes economically irrational

Move the quote registry on-chain so pricing is transparent and auditable. Enforce markup_bps in a smart contract rather than TOML config. Add slashing conditions: if an operator accepts payment (verifiable on-chain via the transferWithAuthorization receipt) but doesn't execute the job (verifiable via Tangle's job result reporting), their stake gets slashed.

The Tangle staking and slashing infrastructure already exists for Blueprint operators. Extending it to cover payment-job atomicity is an extension of existing infrastructure, not a new primitive. The trust model shifts from "trust the facilitator, then trust the operator" to "misbehavior by anyone is economically punishable."

The Gas Question

The obvious objection: if operators settle payments themselves, they pay gas. The facilitator abstracts this cost today.

On Ethereum mainnet, this is a real concern. A transferWithAuthorization call costs roughly 50,000-80,000 gas. At 30 gwei and $3,200 ETH, that's $5-8 per settlement. For a $0.50 API call, the economics don't work.

But x402 Blueprint deployments primarily target L2s. On Base, the same transaction costs fractions of a cent. The operator config in the sources explicitly targets Base:

network = "eip155:8453"  # Base

At L2 gas prices, self-settlement adds negligible cost. The markup_bps field exists precisely to let operators cover their costs. An operator running on Base who sets markup_bps = 200 (2%) on a $1.00 job call earns $0.02 in markup, more than enough to cover a sub-cent gas cost.

For mainnet settlement, a batching approach works: accumulate multiple transferWithAuthorization signatures and submit them in a single multicall transaction, amortizing gas across many payments. This adds latency (the operator extends credit for the batching window) but keeps gas costs manageable.

When operators submit transferWithAuthorization transactions through public RPCs, they enter the mempool where searchers can observe them. But the practical MEV risk is negligible: transferWithAuthorization transfers tokens from a specific address to a specific address with a specific nonce, so there's no extractable value from front-running or redirecting the funds. On L2s where gas is already cheap, sandwich profits would be trivial. For operators who want additional protection, private RPC endpoints (Flashbots Protect on mainnet, equivalent services on L2s) solve this without architectural changes.

The Blueprint-as-Facilitator Model

There's a clear endgame. Facilitator logic (verify signature, check balance, submit transaction, return receipt) is a stateless, deterministic service. That's exactly what Blueprints are designed to run.

A "Facilitator Blueprint" would be a Tangle service that operators opt into. Instead of each operator running their own settlement logic, a set of staked operators collectively provide facilitation as a service. Payment verification happens through the same job execution and result reporting infrastructure that all Blueprints use. Incorrect facilitation (claiming a payment settled when it didn't) is caught by Tangle's result verification and punished via slashing.

This turns the facilitator from a trusted singleton into a decentralized service with cryptoeconomic guarantees. The trust model shifts from "Coinbase won't misbehave" to "misbehavior is economically irrational because the facilitator's stake exceeds the value of any individual payment."

The config for an operator using this model:

facilitator_mode = "blueprint"
facilitator_service_id = 42  # Facilitator Blueprint service

The gateway calls the Facilitator Blueprint through Tangle's job submission, receives a signed result with an on-chain receipt, and proceeds. Same flow, different trust model.

Remaining Open Questions

Two areas deserve deeper treatment than this post can give them.

Multi-chain complexity. The current facilitator handles settlement across Base, Ethereum, Polygon, Arbitrum, and Optimism. Each chain has different gas markets, confirmation times, and token contract addresses. A self-settling operator needs RPC endpoints and funded accounts on every chain they accept payment on. This is manageable but not free, and the operational burden scales with the number of supported chains.

The Permit2 path. EIP-3009 (transferWithAuthorization) is natively supported by USDC and DAI with clean, self-contained signatures. The Permit2 fallback, used for tokens without native meta-transaction support, involves a different approval flow. The decentralization path described here applies most cleanly to EIP-3009 tokens. Permit2 settlement through a decentralized facilitator is feasible but adds complexity that deserves its own analysis.

Note that the x402 protocol repository contains reference facilitator code, but Coinbase's production deployment at facilitator.x402.rs may differ from the open-source reference. Operators building local facilitator logic should work from the protocol spec and reference implementation, not assume the production service behaves identically. For operators in regulated jurisdictions, note that the centralized facilitator may serve compliance functions (KYC/AML screening) that pure on-chain settlement would bypass. The decentralization path here targets permissionless contexts; compliance-sensitive operators can still enforce policy through transparent, auditable on-chain logic rather than opaque HTTP responses.

From Convenience to Correctness

The x402 facilitator was the right design for bootstrapping the protocol. Coinbase hosting a reliable settlement service removed friction and let the ecosystem focus on building applications rather than payment infrastructure. That's how protocols grow: centralize the hard parts, prove the concept, then decentralize.

But the protocol is past the bootstrap phase. Real operators are running real services with real money flowing through a single point of trust. The gateway code is architecturally ready for decentralization. It already makes eth_call for on-chain verification. The EIP-3009 signatures it processes are publicly verifiable. The L2s it targets make self-settlement economically viable.

The migration path is incremental: verify the facilitator's claims, then verify payments locally, then settle locally, then move the whole thing on-chain with cryptoeconomic guarantees. Each step is independently valuable. Each step removes a specific trust assumption. None of them require breaking changes to the x402 protocol itself.

The protocol's original insight was right: HTTP 402 should mean "pay and retry." The next step is making sure "pay" doesn't require asking permission from a single server in Virginia.

FAQ

Can operators run a local facilitator today without any protocol changes?
Yes. The facilitator_url config field accepts any URL, so an operator can deploy their own facilitator service that implements the same three endpoints (verify, settle, supported). The x402 reference implementation provides a starting point. The phased approach described here goes further by eliminating the facilitator abstraction entirely, but self-hosting is possible right now.

What happens to in-flight payments during a migration from centralized to local facilitation?
Each phase is backward-compatible. In Phase 1 (receipt verification), the facilitator still handles settlement; the gateway just adds a check afterward. An operator can switch modes between jobs with no coordination required. Payments in progress complete through whichever facilitator mode was active when the job started.

How does self-settlement affect payment finality guarantees for the client?
It improves them. Today, the client trusts the facilitator to settle honestly, with no proof. With operator self-settlement, the operator has direct economic incentive to settle correctly (they don't get paid otherwise), and the on-chain receipt is publicly verifiable by both parties. The client can independently confirm their payment landed by checking the transaction hash.

Why not skip straight to Phase 4 (on-chain enforcement)?
Phase 4 requires smart contract development, slashing parameter tuning, and governance decisions about stake requirements. Phases 1-3 are pure gateway logic changes that a single operator can deploy independently. The incremental approach lets operators capture most of the security benefit immediately while the protocol-level work proceeds in parallel.

Does this break compatibility with clients built against the current x402 spec?
No. The client-side protocol is unchanged across all four phases. Clients still send the same payment headers, receive the same 402 responses, and sign the same EIP-3009 authorizations. The decentralization happens entirely on the server side, in how the gateway processes and settles those payments.

How Blueprint SDK Turns x402 Payments into Runnable Jobs

Tangle Network — Sat, 21 Mar 2026 01:13:47 +0000

HTTP Status 402 Finally Has a Job

HTTP status code 402 has been "reserved for future use" since 1999. For twenty-seven years it sat in the spec, a placeholder for a payments web that never materialized. In 2025, Coinbase and Cloudflare's x402 protocol gave it real work: a client hits an endpoint, receives a 402 response with pricing information, signs a stablecoin payment, and resends the request with proof of settlement attached as an HTTP header. No API keys, no billing dashboard, no monthly invoices. Just cryptographic proof that money moved before compute burned.

Blueprint SDK integrates the x402 payment protocol through its blueprint_x402 crate, which runs an axum HTTP server that verifies x402 payment headers via an external facilitator, settles payments on-chain before execution, and converts each verified payment into a standard JobCall. If you're new to the blueprint model, How Blueprints Work covers the architecture. Job handlers work identically whether triggered by x402 payments on Base, on-chain Tangle events, or cron. You write a function that takes bytes and returns bytes, set prices in a TOML config, and the gateway handles payment verification, multi-chain exchange rate conversion, access control, and replay protection. Integration requires adding the blueprint_x402 dependency, configuring accepted tokens and job prices in two TOML files, and wiring the X402Gateway and X402Producer into BlueprintRunner.

This post walks through how that works: the payment verification flow, the price conversion pipeline, the producer abstraction that makes it composable, and the configuration that ties it together.

Integration Checklist

Before the deep dive, here's the end-to-end wiring at a glance:

Add blueprint_x402 as a dependency (requires Blueprint SDK and Rust 2021 edition)
Create x402.toml with facilitator URL, accepted tokens, and per-job access policies
Create job_pricing.toml with base prices in wei for each job
Initialize X402Gateway and X402Producer from the config
Wire the producer and gateway into BlueprintRunner alongside your job router
(Optional) Configure a CachedRateProvider for live exchange rates

Each step is covered in detail below.

The Problem with Credit-Based APIs

If you've built a paid API before, you know the pattern. Users sign up, get an API key, load credits into an account, and you decrement their balance on each call. It works, but it comes with a billing system, an accounts database, dispute resolution, fraud detection, and a support queue for "why was I charged twice."

For infrastructure operators building AI services on Tangle, this overhead is significant. You want to expose a compute job over HTTP and get paid for it. You don't want to run a SaaS billing platform on the side.

x402 removes the account layer entirely. The client proves payment in the HTTP request itself. The server verifies that proof before executing anything. There's no balance to track, no credits to reconcile, no API key to rotate. Each request is a self-contained economic transaction.

x402 Payment Protocol Integration with Blueprint SDK

Settlement Before Execution

Blueprint SDK makes an opinionated design choice: the operator gets paid before doing any work.

The gateway uses X402Middleware (in blueprint_x402::gateway) configured with .settle_before_execution(). When a request arrives at /x402/jobs/{service_id}/{job_index}, the middleware extracts the X-PAYMENT header, sends it to an external facilitator (by default, https://facilitator.x402.org), and the facilitator verifies the payment signature and settles it on-chain. Only after settlement confirms does the request proceed to the job handler.

This is the opposite of the typical API pattern where you serve the response and bill afterward. The tradeoff is latency: settlement adds a round-trip to the facilitator plus on-chain confirmation time. The benefit is that operators never perform free work and never chase unpaid invoices.

The facilitator is a trust boundary worth understanding. The gateway itself does not verify on-chain transactions. It delegates that to the facilitator and trusts the response. For production deployments, you'll want to evaluate whether the public facilitator at x402.org meets your trust requirements, or whether you need to run your own.

The Translation Layer: From Payment to JobCall

The central design decision in blueprint_x402 is how it connects payments to the existing job system. Rather than building a separate execution path for paid requests, it converts every verified payment into a JobCall (defined in blueprint_sdk::core::job::call), the same type that every other producer in the system emits.

A JobCall is a pair: Parts (containing a JobId, a MetadataMap of headers, and an Extensions map) plus a body as raw Bytes. When the x402 middleware verifies a payment, it constructs a VerifiedPayment and converts it:

pub struct VerifiedPayment {
    pub service_id: u64,
    pub job_index: u32,
    pub job_args: Bytes,
    pub quote_digest: [u8; 32],
    pub payment_network: String,  // "eip155:8453"
    pub payment_token: String,    // "USDC"
    pub call_id: u64,
    pub caller: Option<Address>,
}

The conversion injects x402-specific metadata into the MetadataMap (payment network, token, quote digest, synthetic call ID) and passes the original request body through as job arguments. Downstream, the job handler receives this as a normal JobCall. If it cares about payment metadata, it can inspect the headers. If it doesn't, it just reads the body.

This means a job handler like this works identically whether triggered by x402 or any other source:

pub async fn echo(body: Bytes) -> Bytes {
    body
}

pub async fn hash(body: Bytes) -> Bytes {
    Bytes::copy_from_slice(alloy_primitives::keccak256(&body).as_slice())
}

pub fn router() -> Router {
    Router::new().route(0, echo).route(1, hash)
}

The Job trait uses an extractor pattern borrowed from axum. Any async function with the right signature auto-implements Job. You can also use FromJobCall and FromJobCallParts extractors to destructure arguments ergonomically, and apply Tower middleware like ConcurrencyLimitLayer via Job::layer().

The Producer Model

The mechanism connecting the HTTP gateway to the job router is X402Producer, which implements Stream<Item = Result<JobCall, BoxError>>. It's backed by an unbounded mpsc channel:

pub struct X402Producer {
    rx: mpsc::UnboundedReceiver<VerifiedPayment>,
}

impl X402Producer {
    pub fn channel() -> (Self, mpsc::UnboundedSender<VerifiedPayment>) {
        let (tx, rx) = mpsc::unbounded_channel();
        (Self { rx }, tx)
    }
}

The gateway sends verified payments into the channel. BlueprintRunner polls the producer alongside its other producers (on-chain events, cron, webhooks) and dispatches each JobCall through the same router. This is why the handler doesn't know its trigger source: all producers converge into one stream.

A note on the unbounded channel: under a payment flood, this queue grows without limit. That's a deliberate simplicity-over-backpressure tradeoff. For production deployments handling high throughput, monitor queue depth via the /x402/stats endpoint, which exposes counters for accepted, rejected, and enqueued calls.

Pricing: Wei, Exchange Rates, and Oracle Composition

Job prices are denominated in wei, the smallest unit of the native chain currency. This might seem odd for services priced in stablecoins, but it solves a real problem: operators accept multiple tokens across multiple chains, and wei provides a denomination-neutral base unit. The gateway converts to token amounts at request time.

The conversion formula (from blueprint_x402::config):

token_amount = (wei / 10^18) × rate_per_native_unit × (1 + markup_bps / 10000) × 10^decimals

A concrete example: you price your echo job at 1000000000000000 wei (0.001 ETH). With a rate of 3200 USDC per ETH and a 2% markup (200 basis points): 0.001 × 3200 × 1.02 = 3.264 USDC, represented as 3264000 in USDC's 6-decimal smallest units.

Pricing configuration lives in two TOML files. job_pricing.toml sets base prices per job:

[1]
0 = "1000000000000000"       # echo: 0.001 ETH
1 = "10000000000000000"      # hash: 0.01 ETH

And x402.toml configures accepted tokens with their exchange rates and markup:

[[accepted_tokens]]
network = "eip155:8453"
asset = "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
symbol = "USDC"
decimals = 6
pay_to = "0xYourOperatorAddressOnBase"
rate_per_native_unit = "3200.00"
markup_bps = 200

When a client calls the price endpoint, it gets back a response with settlement options:

{
  "service_id": 1,
  "job_index": 0,
  "options": [
    {
      "network": "eip155:8453",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "symbol": "USDC",
      "amount": "3264000",
      "pay_to": "0xYourOperatorAddressOnBase",
      "quote_digest": "0xabc...",
      "ttl_secs": 300
    }
  ]
}

The quote_digest ties this price to a specific calculation. The client includes it in the payment, and the gateway matches it against the QuoteRegistry to ensure the payment covers the quoted amount.

Static rates in a config file are fine for getting started, but production operators need live pricing. The PriceOracle trait and its implementations handle this. You can compose oracles: load base prices from TOML, apply a ScaledPriceOracle for surge pricing (say, 1.5x during peak hours), and keep exchange rates fresh via CachedRateProvider<CoinbaseOracle> with a 60-second TTL. Chainlink and Uniswap V3 TWAP oracles are also available behind feature flags. None of this touches your job handler code.

Three Access Modes

Not every job should be publicly callable. The gateway supports three invocation modes per job, configured in x402.toml:

Disabled (the default): the job isn't exposed via x402 at all.

PublicPaid: anyone can call, as long as they pay. No identity checks beyond the payment itself.

RestrictedPaid: payment required, AND the caller must pass an on-chain isPermittedCaller check. The gateway makes an eth_call dry-run against the Tangle contract to verify the caller is authorized for this service.

[[job_policies]]
service_id = 1
job_index = 0
invocation_mode = "public_paid"

[[job_policies]]
service_id = 1
job_index = 1
invocation_mode = "restricted_paid"
caller_auth = "delegated_caller_signature"
tangle_rpc_url = "https://rpc.tangle.tools"
tangle_contract = "0x..."

For RestrictedPaid, the gateway needs to know who the caller is. Two options: PayerIsCaller infers identity from the payment's payer address, and DelegatedCallerSignature lets a third party pay on behalf of a caller. In the delegated case, the caller signs a set of headers:

X-TANGLE-CALLER: 0x<address>
X-TANGLE-CALLER-SIG: <signature>
X-TANGLE-CALLER-NONCE: <unique-nonce>
X-TANGLE-CALLER-EXPIRY: <unix-timestamp>

The signature payload is x402-authorize:{service_id}:{job_index}:{keccak(body)_hex}:{nonce}:{expiry}. A DelegatedReplayGuard tracks used nonces to prevent replay attacks.

This matters for agent-to-agent scenarios where a coordinator agent pays for compute on behalf of worker agents that have their own on-chain identities.

Double-Spend and Replay Protection

Two mechanisms prevent payment reuse. The QuoteRegistry (in blueprint_x402::quote_registry) tracks outstanding price quotes and atomically consumes them when a payment arrives. Each quote has a TTL (configurable, default 300 seconds). Attempting to reuse a consumed quote returns None, and the request is rejected. The registry uses DashMap for lock-free concurrent reads.

One production consideration: the QuoteRegistry is in-memory. If the gateway restarts, all outstanding quotes are lost. Clients will need to re-request price quotes after a restart. For most deployments this is fine (quotes are short-lived), but it's worth knowing if you're running behind a load balancer with rolling restarts.

The DelegatedReplayGuard provides separate replay protection for delegated caller signatures, tracking nonces and rejecting expired or reused ones.

Wiring It All Together

Here's what a complete Blueprint setup looks like with x402 enabled:

use blueprint_runner::BlueprintRunner;
use blueprint_x402::{X402Gateway, X402Config};
use x402_blueprint::{router, load_job_pricing};
use x402_blueprint::oracle::{CoinbaseOracle, CachedRateProvider, refresh_rates};

// Load gateway config and per-job pricing
let mut config = X402Config::from_toml("x402.toml")?;
let pricing = load_job_pricing(&std::fs::read_to_string("job_pricing.toml")?)?;

// Initialize a cached exchange rate oracle
let oracle = CachedRateProvider::new(CoinbaseOracle::new(), Duration::from_secs(60));
refresh_rates(&mut config, &oracle, "ETH").await?;

// Create the gateway and its producer
let (gateway, x402_producer) = X402Gateway::new(config, pricing)?;

// Wire into the runner
BlueprintRunner::builder((), BlueprintEnvironment::default())
    .router(router())
    .producer(x402_producer)
    .background_service(gateway)
    .run()
    .await?;

The gateway runs as a background service. The producer feeds JobCalls into the runner. The router dispatches to handlers. Each piece is independent: you can swap the oracle, add jobs to the router, or change access policies without touching the others.

Observability

The gateway exposes GatewayCounters at GET /x402/stats, tracking: accepted requests, policy denials, policy errors, replay rejections, enqueue failures, job-not-found errors, quote conflicts, and auth dry-run results (allowed, denied, error). These are the numbers you'll want in your monitoring stack.

The full endpoint surface:

Endpoint	Method	Purpose
`/x402/health`	GET	Health check
`/x402/stats`	GET	Operator diagnostics
`/x402/jobs/{sid}/{jid}/price`	GET	Price discovery for clients
`/x402/jobs/{sid}/{jid}`	POST	Execute job (x402 payment required)
`/x402/jobs/{sid}/{jid}/auth-dry-run`	POST	Test caller authorization without paying

The auth-dry-run endpoint is useful during integration: clients can verify their caller signature and on-chain permissions before committing real money.

What This Gets You

x402 collapses the billing stack into the transport layer. Instead of maintaining user accounts, API keys, credit balances, and a reconciliation pipeline, you get a per-request payment proof verified before execution. Blueprint SDK's contribution is making that payment proof look identical to every other job trigger, so your handler code stays clean and your infrastructure stays composable.

You write a function that takes bytes and returns bytes. You set a price in a TOML file. The gateway handles payment verification, exchange rate conversion, access control, replay protection, and dispatch. When a payment clears, your function runs. When it doesn't, nothing happens and you burned zero compute.

For operators running AI agent services, the billing system is the blockchain, the API key is a wallet, and the invoice is a transaction receipt. To understand how Tangle verifies work beyond payment settlement, that post covers the full verification stack.

FAQ

How does the client know what to pay?
The client calls GET /x402/jobs/{service_id}/{job_index}/price, which returns available settlement options: accepted tokens, networks, amounts, and a quote with a TTL. The client picks an option, signs the payment, and includes it as an X-PAYMENT header on the next request. Client libraries like @x402/fetch handle this negotiation automatically.

What happens if the gateway restarts mid-operation?
Outstanding price quotes are lost (the QuoteRegistry is in-memory), so clients will get a stale-quote rejection and need to re-request pricing. Payments that have already settled on-chain are unaffected. Jobs already dispatched to the runner continue executing.

Can I accept payments on multiple chains simultaneously?
Yes. The [[accepted_tokens]] array in x402.toml supports multiple entries across different networks (Base, Ethereum, Arbitrum, etc.) using CAIP-2 identifiers like eip155:8453. Each entry specifies its own pay_to address, exchange rate, and markup. The client chooses which option to use from the price endpoint response.

What's the latency overhead of x402 compared to a normal API call?
The main addition is the facilitator round-trip for payment verification and settlement. On Base (which has fast block times), this typically adds 1-3 seconds depending on the facilitator's confirmation requirements. The gateway processing itself (quote lookup, metadata injection, channel dispatch) adds negligible latency.

Can I use this without Tangle's on-chain job system?
The x402 gateway and producer are designed to plug into BlueprintRunner, which is Tangle's job execution framework. RestrictedPaid mode specifically depends on Tangle's on-chain permission contracts. PublicPaid mode has a lighter dependency since it only needs the facilitator for payment verification, but the job dispatch still runs through the Blueprint runner infrastructure.

Trusted Execution on Tangle: How TEE Works in the Blueprint SDK

Tangle Network — Tue, 03 Mar 2026 06:52:21 +0000

Previous posts covered why decentralized AI infrastructure matters, how blueprints work, verification mechanisms, building from idea to production, and AI services with inference and sandboxes. This post covers what just shipped: first-class TEE support in the Blueprint SDK.

The problem TEE solves for blueprints

Verification in Day 3 covered how Tangle proves work was done correctly. But verification happens after execution. TEE flips this: it proves the execution environment itself is trustworthy before and during computation.

For AI inference, this matters. A model running inside an AWS Nitro Enclave or an Azure Confidential VM can prove it's running the exact binary you expect, on hardware that isolates it from the operator. The operator can't read the model weights. They can't tamper with the inference. The hardware enforces this, not a smart contract.

Tangle's TEE integration lets blueprint developers declare TEE requirements at the SDK level, and the runtime handles provisioning across AWS Nitro, GCP Confidential Space, Azure CVM, or direct hardware (Intel TDX, AMD SEV-SNP).

Three deployment modes

The SDK supports three modes, each for a different operational model:

Direct mode. The blueprint runner itself executes inside a TEE. Device passthrough gives it access to /dev/tdx_guest or /dev/sev-guest. The runner produces attestation by hashing its own binary. This is the highest-integrity path with the fewest network trust links.

```rust title="src/main.rs"
let tee = TeeConfig::builder()
.requirement(TeeRequirement::Required)
.mode(TeeMode::Direct)
.allow_providers([TeeProvider::IntelTdx])
.build()?;

BlueprintRunner::builder(config, env)
.tee(tee)
.router(router)
.run()
.await?;




**Remote mode.** The runner provisions workloads into cloud TEE instances. It calls the AWS EC2 API to launch Nitro Enclave instances, the GCP Compute API for Confidential Space VMs, or the Azure ARM API for DCasv5 CVMs. The runner manages the lifecycle; the workload runs in hardware isolation.

**Hybrid mode.** Some jobs route to TEE, some don't. A pricing engine might run in a standard container while the model inference runs in a Nitro Enclave. Routing is controlled by a policy file that maps job types to execution environments.

## How attestation flows through the system

When a TEE deployment starts, attestation follows this path:

1. The backend provisions the workload (EC2 instance with enclave, Confidential Space VM, etc.)
2. The sidecar inside the TEE reads hardware attestation (NSM document on Nitro, OIDC token from `teeserver.sock` on GCP, vTPM report on Azure)
3. The attestation report includes a measurement (hash of the running binary) and a timestamp
4. This report is cached in the deployment handle for idempotent re-submission
5. The on-chain contract stores `keccak256(attestationJsonBytes)` so anyone can verify

The `AttestationVerifier` trait lets you plug in verification logic per provider. Each provider has different evidence formats, but they all answer the same question: is this binary running on genuine TEE hardware?



```rust title="crates/tee/src/verifier.rs"
pub trait AttestationVerifier: Send + Sync {
    fn verify(
        &self,
        report: &AttestationReport,
        config: &TeeConfig,
    ) -> Result<VerifiedAttestation, TeeError>;
}

Built-in verifiers check provider type, debug mode flags, measurement hashes, and attestation freshness. The GCP verifier, for example, rejects debug-mode attestations unless explicitly configured to allow them (a security fix that shipped with this PR).

Sealed secrets: why container recreation is forbidden

Standard Docker deployments inject secrets via environment variables. When a config changes, you recreate the container with new env vars.

TEE deployments can't do this. Recreating the container invalidates the attestation, breaks sealed secrets, and loses the on-chain deployment ID. The SDK enforces this at the type level: any TEE-enabled config automatically sets SecretInjectionPolicy::SealedOnly.

Recreating a TEE container invalidates attestation, breaks sealed secrets, and loses the on-chain deployment ID. The SDK prevents this at the type level.

Instead, secrets flow through a key exchange protocol:

The TEE generates an X25519 key pair
The public key is embedded in the attestation report
Clients encrypt secrets to this key using ChaCha20-Poly1305
Only the TEE holding the private key can decrypt

The TeeAuthService manages ephemeral key exchange sessions with configurable TTL and automatic cleanup. It runs as a background service alongside the blueprint runner.

Cloud backends: what each provider looks like

The SDK includes real implementations for three cloud providers, not stubs or mocks.

AWS Nitro launches EC2 instances with EnclaveOptions: true, generates user-data scripts that configure nitro-cli, sets up vsock proxies for communication between the parent instance and the enclave, and polls DescribeInstances until the enclave is healthy.

GCP Confidential Space creates Compute Engine VMs with confidentialInstanceConfig and tee-image-reference metadata. The Confidential Space launcher auto-pulls the container image, starts it inside the TEE, and exposes OIDC attestation tokens via a Unix socket. Supports both AMD SEV-SNP (N2D machines) and Intel TDX (C3 machines).

Azure CVM provisions Confidential VMs (DCasv5/ECasv5 series) through the ARM REST API, retrieves attestation from Microsoft Azure Attestation (MAA), and supports Secure Key Release from Key Vault. The HCL generates ephemeral RSA key pairs sealed to the vTPM.

All three are feature-gated so the default build stays lightweight:

```toml title="Cargo.toml"
[features]
aws-nitro = ["dep:aws-sdk-ec2", "dep:aws-config"]
gcp-confidential = ["dep:gcp-auth", "dep:reqwest"]
azure-snp = ["dep:reqwest"]




## Blueprint requirements: telling the manager you need TEE

A blueprint declares its TEE needs through `TeeRequirements`, which the blueprint manager inspects at deploy time to route the workload to an appropriate host:



```rust {1-3,5-8}
let requirements = TeeRequirements {
    requirement: TeeRequirement::Required,
    providers: TeeProviderSelector::AllowList(vec![
        TeeProvider::AwsNitro,
        TeeProvider::GcpConfidential,
    ]),
    min_attestation_age_secs: Some(3600),
};

This is how the manager knows to deploy on TEE-capable infrastructure rather than a standard Docker host. The requirement field controls whether TEE is mandatory (fail if unavailable) or preferred (degrade gracefully). The providers field narrows which cloud backends are acceptable.

What's real and what's next

Everything described above is shipped and tested (162 tests across attestation, config, exchange, middleware, and runtime). The cloud backends make real API calls to provision real VMs.

What's coming next:

Periodic attestation refresh. Re-attest on a schedule and update the on-chain hash, catching enclave reboots and measurement drift.
Contract-driven hybrid routing. Read the teeRequired flag from the on-chain contract instead of a local policy file.
Hardware-specific attestation. TDX TDREPORT via /dev/tdx_guest ioctl, SEV-SNP report via /dev/sev-guest. Currently the direct backend uses software measurement (binary hash); hardware attestation integration requires platform SDK work.

If you're building a blueprint that handles sensitive data, model weights, or private inference, TEE is how you prove to users that their data stays confidential. The SDK handles multi-cloud provisioning, attestation verification, and sealed secret management so your blueprint code stays focused on the service logic.

Blueprint SDK on GitHub · TEE crate source · Previous: Building AI Services on Tangle

Building AI Services on Tangle: Inference and Sandboxes

Tangle Network — Sun, 01 Mar 2026 03:36:54 +0000

Building AI Services on Tangle: Inference and Sandboxes

Day 5 of the Tangle Re-Introduction Series

An AI agent just analyzed your private financial data, generated a Python script, executed it, and returned investment recommendations. How do you know the model was real? That your data wasn't logged? That the code ran correctly? You don't. That's the problem Tangle solves.

The Full Picture: Inference + Sandbox, Chained

Tangle chains verified inference and sandboxed execution into one accountable pipeline for AI agents.

Most posts about verifiable AI focus on one piece. We're starting with the combined pattern because that's what agents actually do in practice: reason, then act.

Agent receives task
  → Inference service generates code (verified model, TEE-attested)
  → Sandbox service executes code (isolated, resource-tracked)
  → Agent returns verified result with full accountability chain

Here's what this looks like as a Tangle blueprint:

use blueprint_sdk::Router;
use blueprint_sdk::tangle::TangleLayer;
use blueprint_sdk::tangle::extract::{TangleArg, TangleResult};

/// Agent that analyzes data using generated code
pub async fn analyze(
    TangleArg(request): TangleArg<AnalysisRequest>,
) -> TangleResult<AnalysisResult> {
    // Step 1: Generate analysis code via inference
    let code_response = inference(TangleArg((
        "gpt-4".to_string(),
        format!("Write Python to analyze this data: {:?}", request.schema),
        InferenceConfig::default(),
    ))).await?;

    // Step 2: Execute the generated code in sandbox
    let exec_result = execute(TangleArg((
        code_response.text.clone(),
        "python3".to_string(),
        request.data.clone(),
        SandboxConfig::default(),
    ))).await?;

    TangleResult(AnalysisResult {
        output: exec_result.stdout,
        code_used: code_response.text,
        model_hash: code_response.model_hash,
    })
}

The customer gets the analysis result, the code that produced it, and the model hash proving which model generated the code. Full accountability chain, two services, one request. Tangle is a purpose-built infrastructure where AI inference and code execution both carry cryptoeconomic guarantees.

Now let's look at how each piece works.

The Trust Problem

Current AI inference APIs require blind trust in the provider.

When you call an inference API, you're trusting:

They're running the model they claim (not a cheaper substitute)
They're not logging or selling your prompts
They're not modifying outputs (filtering, biasing, watermarking)
They're actually running inference (not returning cached or fabricated responses)

Most inference APIs ask you to trust their reputation. Tangle makes these properties verifiable. And the same class of problems applies to code execution: operators could observe your data, modify results, or lie about resource usage.

How Payment Works: x402

Agents pay per-request using x402 HTTP payment headers, no accounts or API keys required.

x402 is an HTTP-native micropayment protocol that lets AI agents pay for compute with a signed payment header, settling transactions on-chain in seconds. This is where Tangle diverges from other "verifiable compute" projects. Agents don't sign up for accounts or manage API keys. They pay per-call using x402 payment headers, the HTTP 402 protocol for machine-to-machine payments.

The flow:

Agent sends request with x402 payment header (signed token amount)
  → Operator verifies payment is sufficient for the job
  → Executes job inside TEE
  → Returns result + attestation
  → Payment settles automatically on-chain

In practice, the agent's HTTP request includes a payment header alongside the normal job payload. The following is pseudocode illustrating the x402 flow (no official Python SDK exists yet):

# Pseudocode -- conceptual x402 flow
import requests

response = requests.post(
    "https://operator.example/inference",
    headers={
        "X-402-Payment": sign_payment(amount=0.003, asset="TNT"),
        "Content-Type": "application/json",
    },
    json={
        "model": "gpt-4",
        "prompt": "Analyze this portfolio...",
        "config": {"max_tokens": 2048}
    }
)

# Response includes result + attestation
result = response.json()
assert verify_attestation(result["attestation"])

This means agents can autonomously discover operators, compare prices, pay for compute, and verify results. No human in the loop. The economic layer and the verification layer are the same system: if an operator cheats, they lose their stake. If they deliver, they get paid. x402 makes this settlement automatic.

Inference Service

Verifiable AI inference runs a model inside a TEE with cryptographic proof of execution.

An inference service runs AI models on behalf of customers. The customer sends a prompt, the operator runs it through the model, and returns the response with proof.

The Blueprint

The inference blueprint defines request types, runs the model, and returns an attested response.

Note: The inference logic below is application code. The SDK provides the service framework (Router, TangleArg, TangleResult, TangleLayer) while you bring the AI logic. Model loading and attestation are your responsibility, not SDK types.

use blueprint_sdk::Router;
use blueprint_sdk::tangle::TangleLayer;
use blueprint_sdk::tangle::extract::{TangleArg, TangleResult};
use serde::{Deserialize, Serialize};

// --- Application types (your code, not SDK types) ---

#[derive(Serialize, Deserialize)]
pub struct InferenceConfig {
    pub max_tokens: u32,
    pub temperature: f32,
    pub top_p: f32,
}

#[derive(Serialize, Deserialize)]
pub struct InferenceResponse {
    pub text: String,
    pub tokens_used: u32,
    pub model_hash: [u8; 32],
}

/// Your model loading logic -- bring your own inference runtime
/// (e.g., candle, llama.cpp bindings, or an external API client)
async fn load_model(model_id: &str) -> anyhow::Result<MyModel> {
    // Application code: load weights, verify hash, etc.
    todo!("Implement model loading for your runtime")
}

/// Job 0: Run inference on a prompt
///
/// The SDK handles job routing and result submission.
/// You handle model loading and inference execution.
pub async fn inference(
    TangleArg((model_id, prompt, config)): TangleArg<(String, String, InferenceConfig)>,
) -> TangleResult<InferenceResponse> {
    let model = load_model(&model_id).await
        .expect("model loading failed");
    let output = model.generate(&prompt, config.max_tokens, config.temperature);
    let hash = model.weight_hash();

    TangleResult(InferenceResponse {
        text: output.text,
        tokens_used: output.token_count,
        model_hash: hash,
    })
}

pub fn router() -> Router {
    Router::new()
        .route(0, inference.layer(TangleLayer))
}

Verification

Tangle combines TEE attestation, multi-operator consensus, and on-chain model hashes.

When TEE hardware is available, every response can include an attestation signed by the enclave. This proves code ran inside an enclave, a specific model binary was loaded, and the hardware is genuine. Customers verify attestations client-side. An on-chain model registry that maps model identifiers to their verified weight hashes is currently in development. Tangle is a purpose-built platform combining multi-operator verification with cryptoeconomic settlement via x402, giving agents a single request that pays for compute and verifies the result.

Multi-operator consensus. For additional security, configure inference to require multiple operators. If three operators independently run the same prompt and two must agree, an operator running a cheaper substitute model gets caught. This works today, even without TEE hardware.

Hardware Reality

TEE-based inference works but has memory and GPU constraints today.

SGX memory is limited (~256MB), AMD SEV-SNP is more generous but still bounded, and GPU TEE support (NVIDIA H100 Confidential Computing) exists but isn't widely deployed. For now, TEE attestation covers model loading and result signing, with GPU computation verified through multi-operator consensus. This is a real tradeoff, not a solved problem.

What This Doesn't Solve

Verification proves fidelity and execution integrity, not output quality or model safety.

Output quality. We verify the right model ran. We don't verify the output is "good." Quality is subjective.

Prompt injection. If the model itself has been fine-tuned maliciously, the TEE faithfully runs the malicious model. Verification proves fidelity, not safety.

Side-channel leakage. TEEs have known side-channel vulnerabilities. For most use cases, this risk is acceptable. For state-level adversaries, it isn't.

Sandbox Service

Sandboxed execution runs untrusted code in an isolated container with strict resource limits.

A sandbox service executes arbitrary code in an isolated environment. The customer sends code, the operator runs it, and returns the result.

Sandboxes need isolation in both directions: protecting operators from malicious customer code, and protecting customers from operators who might observe data or tamper with results.

The Blueprint

The sandbox blueprint accepts code, a language, inputs, and a config, then executes in isolation.

Note: VM-level sandboxing is infrastructure provided by the Blueprint Manager (using the vm-sandbox feature with cloud-hypervisor), not an application-level API. The types below are application code; the SDK provides the service framework.

use blueprint_sdk::Router;
use blueprint_sdk::tangle::TangleLayer;
use blueprint_sdk::tangle::extract::{TangleArg, TangleResult};
use serde::{Deserialize, Serialize};
use std::process::Command;

// --- Application types (your code, not SDK types) ---

#[derive(Serialize, Deserialize)]
pub struct SandboxConfig {
    pub max_memory_mb: u32,
    pub max_cpu_seconds: u32,
    pub allow_network: bool,
}

#[derive(Serialize, Deserialize)]
pub struct ExecutionResult {
    pub stdout: String,
    pub stderr: String,
    pub exit_code: i32,
}

/// Job 0: Execute code in isolated environment
///
/// The operator's infrastructure handles VM-level isolation.
/// This function implements the execution logic within that sandbox.
pub async fn execute(
    TangleArg((code, language, inputs, config)): TangleArg<(String, String, Vec<u8>, SandboxConfig)>,
) -> TangleResult<ExecutionResult> {
    // Application code: spawn a subprocess with resource limits
    // VM-level isolation is handled by the Blueprint Manager's
    // vm-sandbox feature, not by application code
    let output = Command::new(&language)
        .arg("-c")
        .arg(&code)
        .output()
        .expect("execution failed");

    TangleResult(ExecutionResult {
        stdout: String::from_utf8_lossy(&output.stdout).to_string(),
        stderr: String::from_utf8_lossy(&output.stderr).to_string(),
        exit_code: output.status.code().unwrap_or(-1),
    })
}

pub fn router() -> Router {
    Router::new()
        .route(0, execute.layer(TangleLayer))
}

When the Blueprint Manager runs with the vm-sandbox feature enabled, each execution runs in a fresh VM (powered by cloud-hypervisor) with configurable memory limits, CPU quotas, and network isolation. VMs are destroyed after execution. No state persists.

Verification Approaches

Verification strategy depends on whether the workload is TEE-attested, deterministic, or general.

TEE-enabled execution. Hardware attestation proves the sandbox ran the code correctly. Strongest guarantee, but requires TEE-capable operators.

Deterministic code (WASM, seeded execution). Replay verification. Run the same inputs through multiple operators and compare outputs. Exact match required.

General code (Python, Node). Most real code isn't deterministic. Dict ordering, floating-point operations, and timing-dependent behavior vary across runs. For these workloads, multi-operator consensus with semantic similarity checking is the practical approach.

Honest limitation: For workloads that are neither TEE-attested nor consensus-verifiable, economic security (operator stake at risk) is the primary deterrent. This is weaker than cryptographic verification, but often sufficient for lower-stakes computation.

How Tangle AI Services Compare

Tangle is the only platform combining TEE-attested inference, sandboxed execution, and x402 payments.

Here's how the full stack compares to existing inference and execution platforms:

Feature	Tangle	Together AI	Replicate	Ritual
Inference verification	TEE + multi-operator	None (trust-based)	None	On-chain proof
Code execution	Sandboxed + verified	N/A	Container-based	N/A
Payment model	x402 micropayments	API key + billing	Per-prediction	Token-based
Model substitution protection	Multi-operator consensus (canary prompts on roadmap)	None	None	ZK attestation
Agent-native	Yes	No	No	Partial

Real Use Case: AI Agent Tool Execution

Agents generate code via inference and execute it in a sandbox, getting verified results in one pipeline.

# Agent generates this code via inference service
def analyze_data(data):
    import pandas as pd
    df = pd.DataFrame(data)
    return {
        "mean": df["value"].mean(),
        "std": df["value"].std(),
        "outliers": df[df["value"] > df["value"].mean() + 2*df["value"].std()].to_dict()
    }

The sandbox executes it safely, the agent gets results, and with TEE the operator can't see the data. Chain this with the inference service and you get the full pattern from the top of this post.

What's Shipped vs. What's Coming

The Blueprint SDK, multi-operator verification, and x402 settlement are live; TEE integration is next.

Developers deserve to know what works today and what's still being built. Blueprint SDK v0.1.0-alpha.22 (Rust 2024 edition, minimum Rust 1.88) enables building verifiable AI inference services in under 200 lines of Rust, using the same Router and extractor patterns shown throughout this series.

Shipped. The Blueprint SDK (Router, TangleArg, TangleResult, TangleLayer), multi-operator verification, container isolation, and x402 payment settlement. You can build and deploy inference and sandbox services today using these primitives.

Design complete, building now. TEE attestation integration with the Blueprint SDK, and the on-chain model registry for hash-verified model loading.

Roadmap. A canary prompt is a challenge input with a known expected output used to detect model substitution without the operator's knowledge. Canary prompts would run on a configurable interval, providing ongoing model verification without degrading throughput. Full GPU-in-TEE support will arrive as NVIDIA hardware matures. WASM deterministic replay will enable bit-exact verification across operators.

The gap between "shipped" and "roadmap" is real. Multi-operator consensus and economic security work today. Hardware-level attestation is close. Full deterministic replay for arbitrary code is a harder research problem. We're building in that order because each layer adds value independently.

Frequently Asked Questions

Common questions about Tangle's AI inference, sandbox execution, and verification services.

What is verifiable AI inference?
Verifiable AI inference is running a model inside a TEE so the customer receives cryptographic proof of which model executed their prompt.

How does TEE attestation work for AI models?
TEE hardware signs an attestation proving that a specific model binary loaded inside an isolated enclave the operator cannot observe.

What is a sandboxed code execution service?
A sandboxed execution service runs untrusted code in an isolated container with no capabilities, no persistent state, and strict resource limits.

How does x402 payment work for AI services?
An agent sends an HTTP request with a signed payment header; the operator verifies payment, executes the job, and settlement happens on-chain automatically.

Can AI agents chain inference and code execution together?
Yes. A single blueprint can call the inference service to generate code and the sandbox service to execute it, returning a fully verified result chain.

What is canary prompt verification?
A canary prompt is a challenge input with a known expected output, sent periodically to detect whether an operator has substituted a cheaper model.

How does Tangle prevent model substitution?
Tangle uses multi-operator consensus (multiple operators must agree on results) and TEE hardware attestation to detect substitution. Weight hash verification via an on-chain model registry and canary prompts are on the roadmap.

What's Next

Day 6 covers Tangle's roadmap, ecosystem positioning, and infrastructure bets.

Day 6 covers where Tangle is headed: the features in the pipeline, where we fit in verifiable compute, and the bets we're making on where AI infrastructure goes next.

Start building:

Join the conversation:

Building on Tangle: From Idea to Production Service

Tangle Network — Sun, 01 Mar 2026 03:04:23 +0000

Building on Tangle: From Idea to Production Service

Day 4 of the Tangle Re-Introduction Series

The previous posts covered why decentralized infrastructure matters and how verification works. This one is practical: how do you actually build something?

Most "developer experience" posts in crypto are marketing dressed as documentation. They show a hello-world example, claim it's easy, and leave you to figure out the hard parts yourself. This post tries to be honest about what building on Tangle actually involves, where the rough edges are, and what the path to production looks like.

What You're Building

You create a blueprint that operators run and customers pay for, earning a share of every transaction without managing infrastructure yourself.

When you build on Tangle, you're creating a blueprint: a template that defines a type of service. Operators register to run your blueprint. Customers pay to use instances of your service. You earn a share of every transaction.

This is different from traditional SaaS:

Traditional SaaS	Tangle Blueprint
You run the infrastructure	Operators run it
You handle scaling	Network handles it
You're liable for uptime	Operators stake collateral
Revenue = your pricing	Revenue = share of operator fees

Unlike traditional serverless platforms like AWS Lambda or Vercel Functions, Tangle blueprints give developers revenue sharing from every transaction their code processes. The tradeoff: you give up direct control in exchange for not running infrastructure. Whether that's good depends on what you're building.

How the Blueprint SDK Compares

The Blueprint SDK offers Rust-native development with integrated testing, AI support, and built-in payments.

Here's how the Blueprint SDK stacks up against other platforms for building verifiable services:

	Blueprint SDK	Eigenlayer AVS	Ritual	Giza
Primary language	Rust	Go/Solidity	Python	Cairo
Setup complexity	Single CLI command	Multi-contract deploy	Docker + API	Circuit compilation
Testing	Integrated test harness	Manual	Manual	Prover testing
AI-native	Yes (inference + sandbox)	No (generic)	Yes (inference only)	Yes (ZK ML only)
Payment	Built-in x402	Custom	Custom	Custom

When Tangle Makes Sense

Tangle fits services where trust, accountability, or multi-party coordination matter more than raw latency.

Good fits:

Services where trust matters more than latency (custody, signing, verification)
Compute you want others to run but need accountability (AI inference, code execution)
Multi-party protocols that need distributed operators (MPC, threshold signatures)
Infrastructure you'd rather not operate yourself

Poor fits:

Sub-10ms latency requirements (blockchain coordination adds overhead)
Simple CRUD apps (traditional infrastructure is simpler)
Services where you need direct customer relationships (blueprints abstract this)
Anything requiring proprietary infrastructure you control

If you're building a standard web app, use Vercel. Seriously. Tangle is for services where decentralized operation and cryptoeconomic accountability provide value that justifies the complexity.

The SDK

Blueprint SDK is a Rust framework for building verifiable services on Tangle, using async job functions with typed extractors.

The Blueprint SDK is Rust-based. Blueprint SDK supports Rust, with TypeScript and Python SDKs on the roadmap. If you're comfortable with Rust, the learning curve is manageable. If you're not, you'll be learning Rust and Tangle simultaneously, which is harder.

Core Concepts

Jobs, routers, layers, and extractors are the four building blocks of every blueprint.

Jobs are units of work. A job is a single unit of work submitted to a blueprint, executed by one or more operators. A customer submits a job, operators execute it, results come back. Jobs have IDs, typed inputs, and typed outputs.

Router wires jobs to handlers. You define which function handles which job ID, and what protocol layer processes it.

Layers add protocol-specific behavior. TangleLayer handles Tangle EVM integration, including job routing and result submission.

Extractors parse job inputs. TangleArg<T> extracts ABI-encoded arguments from incoming job data. TangleResult<T> wraps return values for on-chain submission. Together, these extractors provide type-safe input parsing and output encoding without manual serialization.

A Minimal Blueprint

A working blueprint needs a Cargo.toml, one async function per job, and a router.

First, your Cargo.toml:

[package]
name = "squaring-service"
version = "0.1.0"
edition = "2024"
rust-version = "1.88"

[dependencies]
blueprint-sdk = { version = "0.1.0-alpha.22", features = ["tangle"] }
tokio = { version = "1", features = ["full"] }

Then the blueprint itself:

use blueprint_sdk::Router;
use blueprint_sdk::tangle::TangleLayer;
use blueprint_sdk::tangle::extract::{TangleArg, TangleResult};

/// Job 0: Square a number
///
/// The function receives ABI-encoded input via TangleArg
/// and returns ABI-encoded output via TangleResult.
pub async fn square(TangleArg((x,)): TangleArg<(u64,)>) -> TangleResult<u64> {
    let result = x * x;
    TangleResult(result)
}

/// Job 1: Square with multi-operator verification
///
/// Same logic, but the job is configured to require
/// multiple operator results before completion.
pub async fn verified_square(TangleArg((x,)): TangleArg<(u64,)>) -> TangleResult<u64> {
    let result = x * x;
    TangleResult(result)
}

/// Router wires jobs to the Tangle protocol layer
pub fn router() -> Router {
    Router::new()
        .route(0, square.layer(TangleLayer))
        .route(1, verified_square.layer(TangleLayer))
}

What this shows:

Jobs are plain async functions with extractors
TangleArg<(T,)> extracts typed input from ABI-encoded job data (primitive types are tuple-wrapped for ABI compatibility; structs defined with sol! do not need wrapping)
TangleResult<T> wraps output for on-chain submission
Router maps job IDs to handlers with protocol layers
No macros required for basic functionality

What the SDK Handles

The SDK manages protocol communication, job routing, operator lifecycle, and fee distribution.

Protocol communication (you don't touch raw blockchain)
Job routing and result submission
Operator lifecycle management
Fee distribution
Event emission for indexing

What You Handle

You write business logic, set operator requirements, and define pricing recommendations.

Business logic (the actual computation)
Operator requirements (who can run your service)
Pricing recommendations (though operators set final prices)

Verification Through Aggregation

Verification is a protocol property, not application code: you configure how many operators must agree, and the aggregation service enforces it.

The previous post mentioned verification. Here's how it actually works in the SDK:

Verification isn't a function you write. It's a protocol property configured when you deploy. Jobs can require:

Single operator (1 result completes the job)
Multi-operator (N results required before completion)
Threshold consensus (M-of-N operators must agree)

// Same job logic, different aggregation requirements
pub async fn square(TangleArg((x,)): TangleArg<(u64,)>) -> TangleResult<u64> {
    TangleResult(x * x)
}

// Configured at deployment:
// - Job 0: 1 operator required
// - Job 1: 2 operators required (verified)
// - Job 2: 3 operators required (consensus)

Tangle's aggregation service collects operator results and verifies BLS signatures before finalizing job completion. The aggregation service collects results from operators, verifies BLS signatures, and only finalizes when the threshold is met. If operators submit different results, the protocol detects the disagreement.

Slashing

Slashing penalizes operators who disagree or fail to respond, enforced at the contract level.

When operators disagree or fail to respond, the protocol can slash their stake. This is handled at the contract level, not in your Rust code. You configure:

Which behaviors trigger slashing
How much stake is at risk
Grace periods for operator response

Local Development

The local dev environment simulates the full Tangle network so you can iterate without touching testnet.

Prerequisites

You need Rust 1.88+, Docker, and Node.js 18+ installed locally.

Rust 1.88+ (stable, 2024 edition)
Docker (for local network)
Node.js 18+ (for tooling)

Setup

Run four commands to install the CLI, scaffold a project, build, and start the local network.

# Install the cargo-tangle CLI (scaffolds, builds, tests, and deploys in one toolchain)
cargo install cargo-tangle --git https://github.com/tangle-network/blueprint

# Create a new project
cargo tangle blueprint create --name my-service
cd my-service

# Build
cargo build

# Run locally against the Tangle protocol
cargo tangle blueprint run --protocol tangle

The local environment simulates the full network: a Tangle node, test operators, and mock customers. You can test job submission and operator behavior without touching testnet. Notably, cargo-tangle scaffolds a new blueprint project in under 10 seconds, so you spend your time writing logic rather than wiring boilerplate.

Testing

Write standard Rust tests with SDK utilities for both unit and integration coverage.

#[cfg(test)]
mod tests {
    use super::*;
    use blueprint_sdk::testing::utils::setup_log;

    #[tokio::test]
    async fn test_square_correct() {
        setup_log();

        // Direct function test (primitives are tuple-wrapped for ABI compatibility)
        let result = square(TangleArg((5u64,))).await;
        assert_eq!(*result, 25);
    }

    #[tokio::test]
    async fn test_square_overflow() {
        setup_log();

        // Test edge cases
        let result = square(TangleArg((u64::MAX,))).await;
        // Depending on your requirements, this might panic or wrap
    }
}

For full integration testing with aggregation, the SDK provides testing utilities. The built-in test harness simulates multi-operator verification locally, so you can validate aggregation thresholds before deploying to testnet:

use blueprint_sdk::testing::utils::setup_log;
use blueprint_tangle_aggregation_svc::{
    AggregationService, ServiceConfig, SubmitSignatureRequest,
};

#[tokio::test]
async fn test_aggregation_flow() {
    setup_log();

    let service = AggregationService::new(ServiceConfig::default());

    // Initialize task requiring 2 operator signatures
    service.init_task(
        service_id,
        call_id,
        output_bytes.clone(),
        2, // total operators
        2, // threshold required
    )?;

    // Submit signatures from operators
    // Verify threshold behavior
    // Check aggregated result
}

Debugging

Use cargo tangle blueprint debug and cargo tangle blueprint jobs show to trace issues locally.

# Debug a running blueprint
cargo tangle blueprint debug

# Check job status
cargo tangle blueprint jobs list
cargo tangle blueprint jobs show <job-id>

Testnet Deployment

Testnet uses real Tangle infrastructure with test tokens so you can simulate production before going live.

When local testing passes, deploy to testnet:

# Deploy to testnet
cargo tangle blueprint deploy --target tangle --network testnet

# Your blueprint is now live at:
# Blueprint ID: 0x...

Keys are managed separately via the cargo tangle key subcommand (generate, import, export, list).

Testnet uses real Tangle infrastructure but test tokens. Operators can register (with test stake), and you can simulate real usage patterns.

Production Deployment

Production deployment registers your blueprint on mainnet, where real operators stake real collateral and real customers pay for your service.

Pre-Launch Checklist

Verify tests, thresholds, slashing conditions, fees, and operator documentation before mainnet.

Before mainnet:

[ ] All tests pass (unit, integration, e2e)
[ ] Aggregation thresholds match your security model
[ ] Slashing conditions are well-defined
[ ] Operator requirements match your needs
[ ] Fee structure makes economic sense
[ ] Documentation exists for operators
[ ] You've tested with real operators on testnet

Deployment

Deploy to mainnet with one command.

cargo tangle blueprint deploy --target tangle --network mainnet

After Launch

Operators discover, evaluate, register, and begin processing jobs on your live blueprint.

Your blueprint is now live. What happens:

Operators discover it via the registry
Operators evaluate if it's worth running
Operators register by meeting requirements and staking
Customers find your service
Jobs flow through registered operators
You earn a share of every transaction

What Can Go Wrong

Common failure modes include insufficient operators, collusion, economic attacks, and early SDK bugs.

Being honest about failure modes:

No Operators

Zero operators registered means zero service availability.

If your blueprint isn't profitable enough, operators won't run it. Zero operators = zero service.

Mitigation: Set realistic fee structures. Start with guaranteed operators (run some yourself initially). Make operator setup easy.

Operator Collusion

Colluding operators can defeat verification, which is why operator diversity matters.

If all operators collude, verification fails. This is why operator diversity matters.

Mitigation: Require geographic distribution, different staking sources, TEE attestation from different manufacturers.

Economic Attacks

Rational attackers will exploit any gap where value at risk exceeds total operator stake.

If the value protected exceeds total operator stake, rational attackers will attack.

Mitigation: Match stake requirements to value at risk.

SDK Bugs

Early adopters should expect SDK bugs and start with lower-value services.

The SDK is software. It has bugs. Early adopters will find them.

Mitigation: Start with lower-value services. Monitor closely. Have incident response ready.

Real Blueprint Examples

Production blueprints include FROST threshold signatures and cross-chain verification infrastructure.

Threshold Signatures (FROST)

FROST enables distributed Schnorr signing with 5-of-7 operator threshold consensus.

A production blueprint for distributed Schnorr signatures:

Job: Sign a message with threshold key
Operators: 5 of 7 must participate
Verification: Signature verifies against known public key
Slashing: Invalid signature or non-participation

Cross-Chain Infrastructure

Blueprints power cross-chain message verification for LayerZero DVN and Hyperlane.

Blueprints powering LayerZero DVN and Hyperlane:

Job: Verify cross-chain message
Operators: Multiple independent verifiers
Verification: Consensus on message validity
Slashing: Incorrect verification

What's Missing

The SDK works but IDE support, error messages, and documentation still have rough edges typical of early-stage infrastructure.

Honest gaps in the current developer experience:

IDE support is minimal. No VSCode extension with autocomplete, no inline documentation. You're reading docs and source code.

Error messages could be better. Some SDK errors are cryptic. We're improving them.

Documentation has gaps. Some advanced features are documented only in code comments.

Tooling is young. The CLI works but isn't polished. Expect rough edges.

We're a small team shipping fast. The core functionality works. The developer experience is improving but not yet where we want it.

Getting Started

Install the cargo-tangle CLI, scaffold a project, and have a local blueprint running in under 10 minutes.

Read the docs: docs.tangle.tools
Clone an example: github.com/tangle-network/blueprint
Join Discord: discord.gg/cv8EfJu3Tn
Start small: Build something simple first. Learn the patterns.

The best way to understand Tangle is to build something on it. The second-best way is to ask questions in Discord. We're small enough that you'll talk to people who wrote the code.

Frequently Asked Questions

How do I build a blueprint on Tangle?
Install the cargo-tangle CLI, run cargo tangle blueprint create --name my-service, write your async job functions in Rust, and wire them into a router with TangleLayer.

What is TangleArg and TangleResult?
TangleArg<T> is an extractor that parses ABI-encoded job input into a typed Rust value. TangleResult<T> wraps your return value for on-chain submission.

How do I deploy a blueprint?
Build locally, test with cargo tangle blueprint run --protocol tangle, deploy to testnet with cargo tangle blueprint deploy --target tangle --network testnet, and promote to mainnet with --network mainnet.

How does Tangle handle multi-operator jobs?
You configure how many operators must submit matching results at the contract level. The aggregation service collects results, verifies BLS signatures, and finalizes only when the threshold is met.

What testing tools does Blueprint SDK provide?
The SDK provides unit test utilities via blueprint_sdk::testing, local blueprint execution with cargo tangle blueprint run, integration test helpers for aggregation flows, and debugging with cargo tangle blueprint debug.

What programming language is required for Tangle blueprints?
Blueprints are written in Rust using the Blueprint SDK (version 0.1.0-alpha.22+), requiring Rust 1.88+ with the 2024 edition.

How do blueprint developers earn revenue?
Blueprint developers receive a configurable share of every transaction processed by their blueprint, paid automatically by the service contract with no invoicing or manual settlement.

What's Next

The next post covers AI services specifically: how to build verified inference and sandboxed code execution on Tangle.

Links: