SCP Economics and Governance

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

Purpose

This document defines the protocol-level economics, challenge effects, governance rules, staking requirements, and ingress-control rules of SCP.

Canonical protocol terms used here follow SCP Core Spec.

It answers:

1. when work becomes reward-eligible
2. how penalty and slashing affect protocol accounting
3. how payout relates to finalized reward records
4. which governance rules must be preserved by implementations
5. how staking and ingress control protect the protocol from malicious actors

Reward Principles

The protocol requires:

1. reward only finalized work
2. no reward without accepted verification and finalized settlement
3. append-only reward accounting
4. payout systems to remain downstream from protocol accounting

Reward Inputs

Reward eligibility depends on:

1. epoch_id
2. accepted verification context
3. finalized settlement context
4. contributor role and units
5. policy_version
6. penalty or suspension references
7. stake-compliance state where the actor is a staking actor

Reward Lifecycle

The canonical reward lifecycle is:

1. pending_input
2. eligible
3. calculated
4. finalized
5. blocked
6. adjusted

Protocol Actors

The protocol-level economic and governance participants are:

1. Data Producer
2. Task Submitter
3. Vault Operator
4. Executor
5. Verifier
6. Governance Actor
7. Treasury / Payout Authority

These are protocol actors, not required one-to-one runtime services.

Actor Duties

Data Producer

Protocol duties:

1. upload source data into an authorized Vault boundary
2. avoid flooding the system with garbage, duplicate, or misleading inputs
3. respect quota, retention, and ingestion controls before data enters protocol-relevant processing

Task Submitter

Protocol duties:

1. submit valid tasks with correct authorization context
2. supply or authorize the budget, payment source, or quota consumption for the requested work
3. avoid abusive, fraudulent, or replay-conflicting task submission

Vault Operator

Protocol duties:

1. maintain private data boundaries
2. expose only authorized record material
3. preserve consistency between canonical records and Commitment references

Executor

Protocol duties:

1. perform authorized computation
2. produce deterministic and auditable execution output
3. avoid unauthorized access, fabricated output, or duplicate claims

Verifier

Protocol duties:

1. validate execution correctness and integrity
2. issue replayable VerificationDecision artifacts
3. accept, reject, or challenge output according to evidence

Governance Actor

Protocol duties:

1. open, review, or adjudicate challenges within governance authority
2. confirm or reject penalty outcomes based on replayable evidence
3. preserve the integrity of challenge and slashing procedures

Treasury / Payout Authority

Protocol duties:

1. transform finalized reward accounting into payout intent
2. execute authorized payout obligations on the designated chain
3. preserve payout integrity, reconciliation, and signer isolation

Staking Principles

The protocol uses two distinct economic control models:

1. stake for slashable production and governance actors
2. bond or budget lock for ingress actors that consume protocol capacity

The protocol requires:

1. actors eligible for network reward and protocol authority to maintain sufficient active stake
2. reward eligibility to depend on both finalized work and stake compliance
3. malicious or negligent behavior to be punishable through slashing, blocking, or suspension
4. data and task ingress abuse to be constrained through quota, bond, and budget controls

Data Producer is not a staking actor by default.

Task Submitter is not a staking actor by default.

Stake Requirements by Actor

Shared Rules

The following actors are staking actors:

1. Vault Operator
2. Executor
3. Verifier
4. Governance Actor
5. Treasury / Payout Authority

For these actors:

1. insufficient active stake may block participation or reward finalization
2. accepted penalties may slash stake
3. severe or repeated violations may cause suspension in addition to slashing

Vault Operator

Stake rule:

1. must maintain active stake to remain an eligible data-serving and reward-receiving actor

Executor

Stake rule:

1. must maintain active stake to receive execution reward and remain eligible for protocol execution authority

Verifier

Stake rule:

1. must maintain active stake to receive verification reward and remain eligible to issue authoritative verification outcomes

Governance Actor

Stake rule:

1. must maintain active stake to receive governance incentive and retain challenge or adjudication authority

Treasury / Payout Authority

Stake rule:

1. must maintain active stake to retain payout authority and any operational compensation eligibility

Ingress Control for Data Producers

Data Producer is governed by quota and bond controls rather than network staking.

Shared Rules

The protocol may require:

1. storage quota
2. ingestion quota
3. ingestion bond for protocol-relevant data intake
4. retention and pruning rules for invalid or low-value data

Quality and Abuse Controls

The protocol requires:

1. obviously invalid, duplicate, or abusive uploads not to gain automatic entry into protocol processing
2. low-quality or malicious uploads to be rate-limited, deprioritized, or pruned under policy
3. repeated ingress abuse to cause bond forfeiture, blocking, or suspension from further protocol-relevant upload pathways

Task Admission and Budget Control for Task Submitters

Task Submitter is governed by budget and admission controls rather than network staking.

Shared Rules

The protocol may require:

1. budget lock before task acceptance
2. challenge bond where challenge privileges are used
3. task class policy and cost estimation before admission
4. rate limits and concurrency caps per actor or policy scope

Admission Rules

The protocol requires:

1. insufficiently funded or unauthorized tasks not to enter accepted
2. tasks whose estimated cost, complexity, or policy class exceeds limits to be rejected, delayed, or split under policy
3. repeated abusive or non-computable task submission to trigger budget forfeiture, blocking, or suspension

Reward Model by Actor

Shared Rules

The protocol distinguishes between:

1. reward recipients, who earn protocol rewards for valid contribution
2. budget or payment sources, who fund or authorize work but do not earn task rewards by default
3. operating authorities, who may receive operational compensation but are not primary task-production reward recipients

Primary reward recipients are typically:

1. Vault Operator
2. Executor
3. Verifier

Conditional governance or operational incentives may apply to:

1. Governance Actor
2. Treasury / Payout Authority

Task Submitter is normally the budget or payment source, not a reward recipient.

Data Producer is normally the source-data contributor, not a reward recipient.

No actor receives protocol reward if:

1. the relevant work is not finalized
2. the actor is blocked or suspended
3. the actor is a staking actor and not stake-compliant
4. a challenge or penalty state still blocks reward finalization

Data Producer

Reward policy:

1. does not receive protocol reward by default for merely uploading data
2. may receive policy-defined credits or rebates only if explicitly configured
3. cannot use raw upload volume alone to claim protocol reward

Task Submitter

Reward policy:

1. does not receive task-production reward by default
2. receives utility from successful task completion rather than protocol issuance
3. may receive refunds, credits, or explicit governance compensation only if defined by policy
4. cannot receive task admission privilege without satisfying budget lock and admission requirements

Vault Operator

Reward policy:

1. may receive reward for making authorized data access available
2. may receive reward for preserving data integrity and protocol-usable record quality
3. reward amount is policy-governed and tied to eligible, finalized work
4. reward finalization may be blocked if active stake is insufficient or pending penalties exist

Executor

Reward policy:

1. receives reward for valid execution work that reaches accepted verification and finalized settlement
2. reward amount may depend on units of work, task class, policy parameters, or epoch context
3. no reward is due for rejected, invalidated, or unresolved execution output
4. reward finalization may be blocked if active stake is insufficient or pending penalties exist

Verifier

Reward policy:

1. receives reward for valid verification work
2. may receive differentiated reward for correctly confirming valid output or correctly identifying invalid output
3. no reward is due for unverifiable, incorrect, or bad-faith verification outcomes
4. reward finalization may be blocked if active stake is insufficient or pending penalties exist

Governance Actor

Reward policy:

1. may receive governance incentive for valid challenge or adjudication activity
2. governance incentive applies only where policy recognizes the action as valid and protocol-useful
3. no governance reward is due for frivolous, abusive, or unsubstantiated actions
4. governance incentive may be blocked if active stake is insufficient or pending penalties exist

Treasury / Payout Authority

Reward policy:

1. is not a primary task-production reward recipient
2. may receive operational compensation for correct payout execution if policy allows
3. operational compensation must remain downstream from finalized reward accounting
4. operational compensation may be blocked if active stake is insufficient or pending penalties exist

Penalty Model by Actor

Shared Penalty Forms

The protocol may apply three broad forms of consequence:

1. block: temporarily prevent reward finalization or payout progression
2. slash: append negative economic records or forfeitures
3. suspend: temporarily or permanently remove actor eligibility or authority

These consequences must be evidence-based, append-only in accounting effect, and governable through the challenge process where applicable.

For staking actors:

1. slash is primarily applied against active stake

For ingress actors:

1. forfeiture is primarily applied against budget lock, challenge bond, or ingestion bond

Data Producer

Penalty policy:

1. repeated garbage, duplicate, or misleading uploads may trigger quota restriction, bond forfeiture, or blocking
2. malicious upload behavior that pollutes protocol-relevant intake may trigger suspension from further upload-driven task pathways
3. invalid uploads should not automatically create protocol reward or semantic promotion opportunity

Task Submitter

Penalty policy:

1. abusive or fraudulent submission may trigger rejection, blocking, or budget forfeiture
2. forged authorization or replay abuse may trigger suspension from further submission
3. malicious challenge abuse may trigger governance penalty or challenge bond forfeiture

Vault Operator

Penalty policy:

1. unauthorized disclosure or misuse of private data may trigger severe slashing or suspension
2. supplying false, inconsistent, or non-committed record material may trigger penalty
3. refusing required protocol duties after accepted commitment may block or remove reward eligibility
4. accepted penalties may directly slash active stake

Executor

Penalty policy:

1. fabricated execution results may trigger slashing
2. unauthorized access or policy violation may trigger suspension or expulsion
3. duplicate claiming or replay abuse may trigger both blocking and negative economic adjustment
4. accepted penalties may directly slash active stake

Verifier

Penalty policy:

1. knowingly incorrect approval or rejection may trigger slashing
2. fabricated evidence or collusion may trigger suspension or expulsion
3. persistent low-quality or bad-faith verification may block future reward eligibility
4. accepted penalties may directly slash active stake

Governance Actor

Penalty policy:

1. frivolous or malicious challenge activity may trigger penalty
2. collusive or bad-faith adjudication may trigger slashing and governance disqualification
3. governance abuse that stalls protocol progress without evidence may be penalized
4. accepted penalties may directly slash active stake

Treasury / Payout Authority

Penalty policy:

1. duplicate payout, withheld authorized payout, or payout tampering may trigger severe penalty
2. signer misuse or treasury abuse may trigger suspension of payout authority
3. incorrect chain effects must be corrected explicitly and may produce governance or economic consequences
4. accepted penalties may directly slash active stake

Governance and Slashing Rules

The protocol requires:

1. challenge evidence to be replayable
2. open challenge to block affected reward finalization
3. approved penalties to append new economic records rather than rewrite history
4. already confirmed chain effects to be corrected explicitly, not silently rolled back
5. staking, reward, and penalty state to remain economically consistent with each actor's current eligibility

Blockchain Obligation Boundary

SCP defines the obligation to prepare payout instructions from finalized reward records.

At the protocol level:

1. Aptos is the current primary payout chain
2. SYM is the canonical payout token
3. PayoutInstructionSet must preserve deterministic payout identity
4. payout failure must not mutate finalized reward records

Implementation details for submission, retry, signer management, and reconciliation belong to SCS.

Trust and Security Assumptions

The protocol assumes:

1. private plaintext remains inside Vault or authorized TEE boundaries
2. append-only evidence and accounting are mandatory
3. signer compromise and payout tampering are treated as governable security incidents
4. reconciliation drift must be detectable