SCP Protocol Overview

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

Purpose

This document introduces SCP as a protocol, explains the problem space it governs, and shows how the major parts of the protocol fit together.

At the platform level, Symphony should first be understood as a decentralized privacy data platform for large-scale private data ingestion, storage, governance, protected query, business activities such as precision marketing, protected computation, and model training. SCP is the protocol layer that makes those platform capabilities trustworthy.

It is intentionally an overview document rather than a normative specification. Its job is to help readers understand:

1. why SCP exists
2. what parts of the system belong to the protocol boundary
3. how tasks, verification, settlement, rewards, and semantic evolution relate to one another
4. how protocol actors participate under privacy, governance, and economic constraints
5. which deeper documents to read next for detailed rules

What SCP Governs

SCP is a deterministic, privacy-preserving protocol for turning authorized work across Vault boundaries into verifiable and settleable protocol truth.

From the perspective of a decentralized data platform, one of SCP's core responsibilities is to let data remain outside any single central custodian while still allowing multiple Vaults, actors, and governance boundaries to converge on shared protocol truth.

That means SCP does not create consistency by forcing all data into one centralized system. Instead, it uses protocolized admission, semantic resolution, execution, verification, settlement, and governance rules so distributed data and distributed control can still cooperate safely.

At a high level, SCP governs:

1. how a request becomes protocol-recognized work
2. how work is executed without breaking private data boundaries
3. how execution output is verified and challenged
4. how verified results are turned into settlement and reward records
5. how protocol semantics evolve without silently changing meaning
6. how governance and economics constrain participants with authority or protocol impact

This means SCP is not only a task-processing protocol. It is also the protocol trust layer for a broader decentralized privacy data platform, preserving truth, incentives, and semantic meaning across a multi-Vault system.

Put differently, the decentralized role of SCP at the protocol layer is to:

1. allow data to remain inside its own Vault and local governance boundary rather than forcing centralized custody
2. let multiple actors coordinate around the same protocol semantics, verification rules, and settlement outcomes
3. give cross-Vault query, selection, computation, and training workflows a shared trust and audit basis
4. turn decentralized data collaboration into verifiable, governable, and settleable protocol facts

Core Protocol View

From an overview perspective, SCP can be read as a pipeline with five connected concerns:

1. task admission, where authorized intent enters the protocol
2. semantic resolution, where the task is interpreted against the active protocol meaning
3. execution and verification, where work is performed and checked
4. settlement and reward accounting, where accepted work becomes finalized protocol state
5. governance and evolution, where disputes, penalties, and semantic upgrades are handled without breaking replayability

These concerns are logically distinct even when an implementation realizes them inside fewer runtime components.

Lifecycle at a Glance

The protocol lifecycle starts when a caller submits authorized work and ends when the resulting contribution has either been finalized into protocol accounting or rejected by the protocol.

In broad terms:

1. a task is admitted under authorization, budget, and policy constraints
2. the task is interpreted under the active semantic and policy context
3. execution is assigned and performed within the permitted data boundary
4. results are verified, and may be accepted, challenged, or rejected
5. accepted work flows into settlement
6. finalized settlement becomes the basis for reward accounting and downstream payout

This lifecycle matters because SCP separates "work happened" from "the protocol recognizes that work as final truth." Finality only appears after verification and settlement, not at raw execution time.

Privacy and Vault Boundaries

SCP is designed for environments where source data may be sensitive, private, or locally governed.

The protocol therefore treats Vault boundaries as first-class. In practice, this means:

1. source records can remain inside authorized Vault or TEE boundaries
2. protocol-visible artifacts focus on commitments, references, evidence, and accounting context rather than unrestricted plaintext movement
3. verification, settlement, and reward logic must preserve the distinction between private data custody and protocol-visible truth

This is one of the key differences between SCP and a simple centralized task queue or payout ledger.

Protocol Actors

SCP brings multiple actor types into one governed protocol surface.

The major actor groups are:

1. ingress actors, such as data producers and task submitters
2. production actors, such as Vault operators, executors, and verifiers
3. governance and treasury actors, who adjudicate disputes, enforce rules, and transform finalized accounting into payout intent

These actors do not all play the same role:

1. ingress actors introduce data or demand for work into the system
2. production actors create, serve, execute, or validate protocol-relevant outputs
3. governance actors preserve dispute resolution, policy integrity, and penalty handling
4. treasury or payout actors sit downstream from finalized accounting rather than redefining protocol truth themselves

This actor model matters because SCP is not secured only by software correctness. It is also secured by who is allowed to do what, under what evidence, and under what economic consequences.

Semantic Namespace and Evolution

SCP does not assume that all meaning is fixed forever, and it does not treat attributes as ungoverned labels.

Instead, the protocol includes a semantic layer that makes room for:

1. domain-specific organization of meaning
2. protocol-recognized attributes
3. local or emerging attributes that may begin in one Vault or context
4. governed promotion of widely validated semantics into protocol-recognized meaning

This allows the system to evolve as new data types, concepts, and use cases appear, while still preserving stable interpretation for replay and audit.

In other words, SCP is designed to support semantic growth without allowing hidden drift in what previously settled work means.

Epoch as a Control Window

Epoch is best understood as a stable control window for protocol coordination, not as a prerequisite for the existence of raw data or a single task.

At the overview level, epoch matters because it provides a shared window for:

1. settlement grouping
2. reward calculation timing
3. payout preparation
4. semantic candidate aggregation
5. replayable partitioning of protocol events where batching matters

This design lets user-facing actions happen continuously while later-stage protocol accounting still converges around stable boundaries.

Economics and Governance

SCP includes economics and governance because protocol truth alone is not enough in an adversarial or incentive-driven environment.

The protocol therefore connects:

1. finalized work to reward eligibility
2. role authority to stake or other economic constraints where applicable
3. ingress behavior to quota, bond, or budget controls
4. bad behavior to challenge, penalty, blocking, suspension, or slashing pathways

This makes economics a protocol concern rather than a purely operational add-on. Rewards, penalties, and authority are all downstream from protocol-recognized state transitions.

Relationship to SCS

SCP defines protocol truth, meaning, and accounting semantics.

SCS is where those protocol ideas are realized as concrete system architecture, runtime orchestration, persistence, and integration patterns.

The distinction is useful:

1. SCP answers what must be true at the protocol level
2. SCS answers how a system may be built to realize those truths in practice

From the higher-level Symphony narrative, both sit beneath the platform concept:

1. Symphony is the decentralized privacy data platform
2. SCP is the protocol layer that governs trusted data use and computation
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:

1. read SCP Core Spec for lifecycle semantics, protocol layers, epoch behavior, and deeper state-model rules
2. read SCP Economics and Governance for rewards, staking, bonds, slashing, admission control, and governance effects
3. read Receipt Upload to Personal Vault for a concrete example of how the protocol maps into an end-to-end scenario
4. read Targeted Coupon Campaign for Recent Luckin Customers for an eligibility-based marketing activation scenario
5. read Privacy-Preserving Consumer Behavior Model Training for a training-oriented scenario built on protected consumer data
6. read SCS System Architecture and SCS Data and Integration for implementation-facing system realization

Summary

SCP is the protocol layer that turns authorized, privacy-constrained work into verifiable, governable, and economically meaningful protocol truth.

It combines:

1. task admission and execution
2. semantic interpretation and evolution
3. verification and settlement
4. reward accounting and downstream payout preparation
5. governance, challenge handling, and economic security

That combination is what makes SCP a full protocol framework for cross-Vault work, rather than only a task API, a data model, or a reward scheme.