Architecture

System Overview

Slabond is a decentralized protocol that guarantees the correct execution of off-chain API calls through a combination of hardware security (Intel SGX), cryptographic proofs (TLSNotary), economic incentives (bonding and slashing), and on-chain verification (Ethereum smart contracts).

The protocol enables a trust-minimized bridge between on-chain logic and off-chain actions — allowing smart contracts and AI agents to trigger real-world API calls (payments, webhooks, data fetches) with cryptographic and economic guarantees that the action was performed correctly.

Smart Contracts

SlabondSLA

The core contract managing the SLA lifecycle. Each SLA represents a single guaranteed API execution.

Responsibilities:

• Accept escrow deposits from users
• Lock operator bonds (calculated as a percentage of SLA value)
• Store SLA parameters: target URL, expected response, timeout, bond tier
• Execute settlement after successful proof verification
• Trigger slashing on proof failure or timeout

SlabondRegistry

Manages the operator network and TEE attestation verification.

Responsibilities:

• Register and deregister operators
• Store and verify DCAP attestation reports (Intel SGX remote attestation)
• Track operator reputation scores based on historical performance
• Enforce minimum bond requirements per operator tier
• Maintain the active operator set for job assignment

SlabondVerifier

Handles on-chain verification of TLSNotary proofs and dispute resolution.

Responsibilities:

• Verify TLSNotary proof structure and signatures
• Compare proof contents against SLA-defined expected outcomes
• Manage the dispute window (configurable per SLA, default 1 hour)
• Process challenges from watchers or users
• Execute slash distribution (80% to user, 20% to protocol treasury)

SLA Lifecycle

Each SLA follows a deterministic state machine with the following transitions:

State definitions:

State	Description
Created	SLA registered on-chain, escrow deposited. Awaiting operator.
BondLocked	Operator has accepted the SLA and locked collateral. TEE execution can begin.
ProofSubmitted	TLSNotary proof submitted on-chain. Dispute window is active.
Settled	Dispute window closed with no valid challenge. Operator receives escrow + bond return.
Cancelled	User cancelled before an operator accepted. Escrow returned.
Expired	No operator accepted within the timeout. Escrow returned.
Challenged	A watcher or user has submitted a valid challenge during the dispute window.
Slashed	Operator bond slashed due to timeout, invalid proof, or successful challenge.

TEE Execution Flow

API calls execute inside Intel SGX enclaves using Gramine LibOS, ensuring hardware-level isolation and tamper resistance.

Execution Pipeline

1. Job assignment — The watcher network assigns an SLA to a registered operator whose DCAP attestation is current and whose bond meets the SLA tier requirement.

2. Enclave initialization — The operator's TEE node boots a Gramine-shielded process. The enclave's measurement (MRENCLAVE) is verified against the registry's expected value.

3. TLSNotary session — Inside the enclave, a TLSNotary prover establishes a TLS connection to the target API. The TLSNotary protocol splits the TLS session between a prover (inside the enclave) and a verifier (the notary), ensuring neither party can forge the transcript.

4. API execution — The enclave executes the API call as specified in the SLA (HTTP method, headers, body). The full request and response are captured in the TLSNotary transcript.

5. Proof generation — The TLSNotary session produces a signed proof containing:

   • The complete HTTP request sent to the target API
   • The complete HTTP response received
   • TLS session parameters proving the connection was to the correct server
   • Notary signature over the transcript

6. DCAP attestation — The enclave generates a DCAP (Data Center Attestation Primitives) quote, binding the TLSNotary proof to the specific enclave instance and hardware platform.

7. Proof submission — The combined TLSNotary proof + DCAP attestation is submitted on-chain via the watcher relay, transitioning the SLA to ProofSubmitted.

Security Properties

Property	Mechanism
Execution integrity	Intel SGX enclave isolation — operator cannot modify code or data during execution
Transcript authenticity	TLSNotary proof — cryptographically binds the API response to the TLS session
Server identity	TLS certificate verification inside the enclave — proves the API call reached the correct server
Hardware binding	DCAP attestation — proves the proof was generated inside a genuine SGX enclave
Non-repudiation	On-chain proof storage — operator cannot deny the execution result

Watcher Network

Watchers are off-chain nodes that orchestrate the protocol's execution layer.

Responsibilities

• Event monitoring — Listen for SLACreated events on the SlabondSLA contract
• Job assignment — Match new SLAs to available operators based on bond tier, reputation, and capacity
• Proof relay — Accept proofs from TEE operators and submit them on-chain
• Timeout enforcement — Trigger slashing if an operator fails to submit a proof within the SLA timeout
• Challenge submission — Verify proofs independently and submit challenges if a proof is invalid

Architecture

Watchers run as stateless services that maintain a local view of the SLA contract state. Multiple watchers can operate in parallel for redundancy — the protocol is designed so that any single honest watcher is sufficient to ensure correct settlement.

Watchers do not need to trust each other. The on-chain contracts are the sole arbiter of SLA state, and any watcher can independently verify proofs and trigger settlements or slashes.