SCP Protocol Overview

Version: v1.0 (Draft) Status: Draft Authoritative: Yes

Purpose

This document introduces SCP (Symphony Core Protocol) — the protocol layer that makes a decentralized privacy data platform trustworthy.

It is intentionally an overview, not a normative specification. Its job is to give a reader a complete mental model of the protocol in one pass, covering:

1. what problem SCP solves
2. how the protocol is structured
3. who participates and what they do
4. how data flows from upload to settlement
5. how economics and governance keep the system honest
6. where to read the detailed rules

For normative definitions, see SCP Core Spec and SCP Economics and Governance.

What Problem SCP Solves

The world generates vast amounts of private data — receipts, transactions, behaviors, preferences — scattered across millions of individuals and thousands of enterprises. This data is valuable for analytics, marketing, and AI training, but using it faces a fundamental tension:

1. Data holders (individuals, enterprises) want privacy, control, and fair compensation
2. Data users (brands, researchers, platforms) want access, quality, and scale
3. Neither side trusts a centralized intermediary to be fair

SCP resolves this tension by defining a protocol where:

• data stays inside the owner's control boundary (Vault), never exposed as plaintext
• computation happens inside trusted environments (TEE), not by moving data out
• every operation is verified, settled, and rewarded through deterministic protocol rules
• governance and economics are protocol-level concerns, not afterthoughts

The result: data can be used without being seen, and every participant is held accountable by the protocol rather than by trust in any single party.

Protocol Architecture: 3 Planes + 2 Services

SCP is structured as a sequential pipeline of three planes, supported by two cross-cutting services:

  Request ──► [Admission Plane] ──► [Execution Plane] ──► [Settlement Plane] ──► Result
                    │                      │                      │
                    ▼                      ▼                      ▼
              ┌─────────────────────────────────────────────────────────┐
              │              Data Sovereignty Service                    │
              │     (record storage, consent, privacy budget, access)   │
              ├─────────────────────────────────────────────────────────┤
              │                Governance Service                       │
              │     (policy version, epoch, staking, proposals)         │
              └─────────────────────────────────────────────────────────┘

Admission Plane — the public-facing entry point. It validates the caller's identity, checks authorization and consent, resolves semantic meaning, reserves privacy budget, and assembles an immutable TaskEnvelope that all downstream processing can trust.

Execution Plane — where computation happens. It drives the task state machine, coordinates multi-Vault fan-out, performs computation inside Vault or TEE boundaries, runs secure aggregation, and manages composite task iteration.

Settlement Plane — where results become final. It verifies execution output, manages challenges, calculates rewards and penalties, and anchors irreversible accounting on the settlement chain.

Data Sovereignty Service — a cross-cutting service that manages record storage, consent, privacy budget, and Vault access control. All three planes access it, but none can override its sovereignty decisions.

Governance Service — a cross-cutting service that manages policy versions, epochs, actor staking, and governance proposals. It configures how the protocol behaves without processing tasks itself.

Node Architecture

SCP runs on a distributed network of nodes:

Master Nodes (3 fixed) — operated by the Symphony Foundation. They run the Admission Plane, Settlement Plane, and Governance Service. The three master nodes form a BFT consensus group where protocol finality requires agreement from at least 2 of 3 nodes. Master nodes stake S_master SYM.

Enterprise Nodes (approved membership) — operated by approved enterprises that contribute internal data. They run Vault storage (Data Sovereignty Service) and optionally contribute compute capacity. Enterprise nodes apply through governance and stake S_enterprise SYM. Their incentive is twofold: earning task fee shares when their data is used, and accumulating data contribution credits that offset their own platform usage.

End Users (not nodes) — individuals who upload data (Data Producers) and submit tasks (Task Submitters). Data Producers may optionally stake S_producer SYM to receive full rewards (100%) instead of reduced rewards (50%).

Task Model

The task is SCP's primary work unit. Every protocol operation — from parsing a receipt to training an AI model — is represented as a task.

Task Classes

SCP recognizes four task classes, each with distinct protocol constraints:

Class	What It Does	Example
parse	Single-record interpretation within one Vault	Receipt OCR, document extraction
query	Governed retrieval or audience selection across Vaults	"Find users who bought coffee in Singapore"
compute	Bounded computation against authorized records	Eligibility evaluation, feature derivation
train	Iterative model training across Vaults	Consumer behavior model, recommendation engine

Task Lifecycle

Every task moves through a deterministic state machine:

accepted → resolving → dispatched → verifying → awaiting_settlement → completed
    │          │           │            │               │
    └──rejected └──rejected └──rejected  └──challenged   └──challenged
    └──timed_out           └──timed_out  └──timed_out

The forward path is: admit → resolve semantics → execute → verify → settle → complete.

At any point, a task can be rejected (validation failure), timed out (deadline exceeded), or challenged (dispute opened). These are the only legal transitions — the protocol explicitly forbids skipping states.

TaskEnvelope

When a task passes admission, the Admission Plane produces an immutable TaskEnvelope containing everything downstream processing needs: task identity, classification, caller context, authorization, consent references, semantic version, policy version, privacy budget reservation, and coordination parameters. No downstream plane may override or extend it.

Semantic Model

SCP does not treat data attributes as ungoverned labels. It defines a three-layer semantic model that makes meaning explicit, evolvable, and auditable.

Three Attribute Layers

Canonical Attributes — protocol-recognized semantic truth. "What does this record field mean?" Every canonical attribute belongs to exactly one domain, has a lifecycle (proposed → registered → active → deprecated → retired → superseded), and is versioned under semantic_version. Some canonical attributes are marked directly_queryable for efficient query use.

Query Attributes — governed projections for retrieval. "What signal can be safely exposed for search?" Each query attribute is derived from canonical attributes through an explicit DerivationRule (bucket, hash, boolean, aggregate, threshold, etc.) and carries a structured QueryGranularity that controls how much information is revealed.

Local Attributes — emerging semantics not yet canonical. They accumulate inside individual Vaults and may be promoted to vault-scoped query attributes (for local use) or to full canonical attributes (after cross-Vault validation and governance approval).

Domains

Attributes are organized into domains — semantic namespaces with governance boundaries. Domains form a hierarchy: global domain → domain family → concrete domain → optional sub-domain. Cross-domain derivation requires explicit governance approval.

Attribute Composition

Real queries combine multiple attributes (e.g., "Singapore" AND "coffee" AND "last 30 days"). SCP treats composition as a protocol-level concern because combining attributes can narrow result sets enough to compromise anonymity. Every composition declares a minimum_result_cardinality below which results are suppressed.

Data Protection

SCP protects private data through three complementary mechanisms:

Consent and Authorization

Two layers must both be satisfied:

1. Vault-level authorization: the Vault operator permits this actor and task class to access records
2. Data-subject consent: the individual whose data is stored has agreed to this usage category (personal, marketing, analytics, training)

Consent is revocable. Revocation blocks new tasks but does not retroactively invalidate settled work.

Privacy Budget

A per-data-subject, per-usage-scope budget bounds cumulative disclosure. The protocol uses a reserve-commit model:

1. admission reserves estimated budget
2. execution commits actual consumption
3. failure before execution releases the reservation
4. failure after execution commits at the estimated level (information may already have been disclosed)
5. replenishment occurs only at epoch boundaries under governance

TEE (Trusted Execution Environment)

For cross-Vault computation, data must be processed inside an attested TEE — a hardware-enforced enclave that proves what code ran on what inputs. The protocol treats TEE as a temporary extension of the Vault privacy boundary, not an independent custodian. TEE attestation is part of the task evidence chain.

Multi-Vault Coordination

When a task needs data from multiple Vaults, SCP decomposes it into:

1. a coordination envelope with shared context and quorum requirements
2. per-Vault execution slices that run independently inside each Vault
3. a secure aggregation step that combines slice results inside a trusted environment

The aggregator must not be the task submitter, must not retain per-Vault outputs, and must produce cryptographic proof linking the aggregate to its inputs.

Composite and Iterative Tasks

Training tasks are decomposed into sub-tasks (rounds). Each round may itself be a multi-Vault task. This creates a three-level hierarchy:

• Parent task → Sub-task (round) → Execution slice (per-Vault)

For N rounds across M Vaults, the protocol manages: 1 parent + N sub-tasks + (N × M) slices. Each level has its own lifecycle, evidence, and settlement context.

Settlement and Challenge

Challenge Lifecycle

Any verified result can be challenged before settlement finalizes. Challenges follow their own lifecycle (opened → reviewing → confirmed/not_confirmed → approved/closed_without_penalty → penalty_recorded). Challenge evidence must be replayable.

For composite tasks, challenges can target a specific slice, sub-task, aggregation step, or the composite result as a whole.

Settlement

Settlement converts verified execution into irreversible accounting:

1. collecting → verifying_inputs → candidate_ready → finalizing → finalized

Finalized settlement is the basis for reward distribution, payout, and protocol audit.

Token Economics (SYM)

SYM is the native token. It circulates through the protocol as follows:

How SYM is Spent

Task Class	Pricing Basis	Who Pays
parse	Free	Protocol absorbs cost
query	Base fee + per-Vault + per-record + per-epsilon	Task Submitter
compute	Base fee + compute units + data volume + per-epsilon	Task Submitter
train	Base fee + per-round compute + aggregation + per-epsilon	Task Submitter

How SYM is Earned

Mechanism	Who Earns	Basis
Task fee distribution	Vault Operators, Executors, Verifiers	Proportional to contribution in settled tasks
Data quality rewards	Data Producers	Per-record score based on parsability, completeness, freshness, non-duplication, domain demand
Data usage dividends	Data Producers	When their records are used by query/compute/train tasks
Node operation rewards	All nodes	During bootstrap phase only (inflation-funded)

Data Producers who stake S_producer receive 100% of rewards. Unstaked producers receive 50%.

Token Supply

Hybrid model: fixed genesis supply + declining early inflation (8% → 5% → 3% → 1.5% → 0% over 5 years). After bootstrap, all rewards come from task fee redistribution.

Smart Contract Custody

All protocol-managed SYM is held by smart contracts on Aptos: staking contracts, escrow contracts, reward contracts, and treasury contracts. No actor holds SYM on behalf of another outside of smart contract custody.

Governance

The Governance Service manages:

1. Policy versions — configurable parameters (fee rates, privacy thresholds, staking amounts) that change only at epoch boundaries
2. Epochs — stable time windows for settlement, reward, and aggregation grouping
3. Actor registry — three-tier staking (S_master, S_enterprise, S_producer) with graduated slashing
4. Governance proposals — policy changes, attribute promotion, challenge adjudication

All governance is operated by the 3 master nodes with BFT consensus.

Protocol Configuration

Policy Version

A policy_version captures all configurable protocol parameters at a point in time. Tasks are evaluated under the policy version active at their admission, even if it is later deprecated. No retroactive application.

Epoch

An epoch is a stable window for settlement grouping, reward calculation, and replay partitioning. Epochs are closed by time, capacity, or governance triggers. Composite tasks may span multiple epochs.

Determinism

SCP requires that equal inputs and equal replay context produce equal outputs. Parameter resolution is a deterministic function of epoch_id, semantic_version, and policy_version.

Relationship to SCS

SCP defines what must be true at the protocol level. SCS (Symphony Core System) defines how a system is built to realize those truths in production.

Concern	SCP	SCS
Task lifecycle	Defines states and legal transitions	Implements state machine and orchestration
Semantic resolution	Defines resolution rules and invariants	Implements registry services and caches
Privacy	Defines budget model and consent rules	Implements Vault storage and TEE integration
Settlement	Defines finality conditions	Implements on-chain settlement contracts
Economics	Defines pricing, reward, and penalty rules	Implements fee escrow, reward distribution, and payout

From the Symphony narrative:

1. Symphony is the decentralized privacy data platform
2. SCP is the protocol layer that governs trusted data use
3. SCS is the system realization layer that delivers those guarantees in production

How to Read the SCP Documents

Use this document as the entry point, then follow the topic that matches your question:

Question	Document
Task lifecycle, semantic model, data protection, execution, settlement	SCP Core Spec
SYM token, pricing, rewards, staking, penalties, governance	SCP Economics and Governance
Receipt upload end-to-end example	Receipt Upload to Personal Vault
Cross-Vault marketing campaign example	Targeted Coupon Campaign for Recent Luckin Customers
Privacy-preserving model training example	Privacy-Preserving Consumer Behavior Model Training
System architecture and implementation	SCS System Architecture

Summary

SCP is the protocol layer that turns private, distributed data into verifiable, governable, and economically meaningful outcomes — without ever exposing plaintext.

It combines:

1. a 3 Planes + 2 Services architecture for clear separation of concerns
2. a four-class task model (parse, query, compute, train) with deterministic lifecycle
3. a three-layer semantic model (canonical, query, local) with governed evolution
4. three-mechanism data protection (consent + privacy budget + TEE)
5. a SYM token economy where data contributors are rewarded and bad actors are penalized
6. a distributed node network (3 master + N enterprise) secured by staking and BFT consensus

That combination is what makes SCP a complete protocol for privacy-preserving data collaboration, not merely a task API, a data model, or a reward scheme.