Security, Verification, and Production Readiness

1. Security Objectives

POC V2 is designed to preserve the existing Activated Power whenever input, computation, network, or delivery conditions are insufficient. An incomplete, conflicting, or insufficiently endorsed result shall never become visible to downstream consumers.

The protocol protects four properties:

Property	Requirement
Input integrity	Only continuous, finalized chain facts recoverable at an explicit fence enter computation
Computation consistency	Independent implementations produce bit-exact results from the same snapshot
Endorsement safety	Strictly more than two thirds of the full Committee voting power signs one result
State atomicity	Only Atomic Activate after a complete Seal can change downstream-visible Power

2. Threat Model

Threat	Primary control
DApp fabricates contribution	Registry, custody, equity token, and trusted poc_contribution issuance path
Indexer omits or alters facts	Continuous transaction scanning, chain identity, finalized fence, raw event bytes, and atomic checkpoint commit
Validators use different inputs	Input Snapshot, period history, price-snapshot root, and Context
Computation implementations diverge	Executable specification, golden vectors, independent verifier, differential testing, and shadow replay
Validator double-signs	Independent compute key, Signer Journal, and reserve-and-sign safety slot
Network injects or replays objects	Permissioned Overlay, scope validation, strict decoding, Validated Ingress, and semantic deduplication
Aggregator selects a result	Aggregation only for identical Context and Commitment, full Committee denominator, and multiple Aggregators
Relayer modifies a result	QC-bound Batches and on-chain verification of payload hash, index, and state continuity
Partial delivery becomes visible	Candidate remains invisible to L5 until Atomic Activate
Governance bypasses the protocol	Governance may pause, freeze, reject, or upgrade; it may not write Power or advance the cursor
Rewards are claimed early or repeatedly	Frozen beneficiary, first Delivery Receipt, claimed bitmap, and bounded reward budget

3. Key Security

Topo consensus key, Validator Operator, BLS compute key, POC PeerId, relay account, and reward address shall be physically or logically isolated.

Production requirements are:

• the current Operator authorizes the compute key on chain and proves possession;
• the Signer uses a distinct process or HSM boundary and an independent Journal;
• the Signer accepts structured Context and Commitment objects, not arbitrary bytes;
• Journal loss, identity mismatch, integrity failure, or suspected rollback causes fail-stop;
• each relay account has one sequence writer and remains isolated from compute-key authority; and
• the reward address is frozen when the Candidate is created and cannot be replaced by a delivery initiator.

4. Chain-Fact and Data Integrity

Each Validator shall independently read the finalized Topo chain source. Ingestion shall scan complete transactions continuously from an explicit next_tx_version, preserve in-transaction event_index order, and commit events and checkpoints in one transaction.

The following failures are safety-significant:

• transaction-version gap: stop and refetch;
• different bytes at the same cursor: raise SourceConflict and halt;
• undecodable known event: raise UnsupportedSchema; do not skip it;
• unavailable historical view or price fence: return NotReady or Abstain; and
• exhausted disk: stop ingestion or signing; do not delete unprocessed history automatically.

5. Determinism and Independent Verification

Production qualification shall include:

• golden vectors for one-period, multi-period, NoQuorum catch-up, and Empty Patch cases;
• boundary vectors for Registry event time, price fence, Retention, rounding, overflow, and Batch formation;
• either two implementations that do not share core helpers or one independent verifier;
• property tests over input ordering, pagination, concurrency, and retry behavior;
• multi-Validator shadow replay over real periods; and
• cross-implementation acceptance corpora for Rust and Move Context, Vote, BLS, bitvec, and QC encoding.

The first divergent root shall be traceable to period input, price, Affected set, base proof, Patch, post-state, Batch, or Artifact.

6. POC Network Security

POC uses a permissioned Overlay isolated from the Topo consensus network. The Overlay propagates signed Vote/QC objects and Artifact identities; it does not distribute authoritative chain facts or implement a leader, round, proposal, or second consensus protocol.

Ingress validation shall proceed through frame limits, strict Wire decoding, chain/suite/Committee scope, hash and structure checks, membership and signature checks, semantic deduplication, and an atomic durable object/event commit. A successful semantic acknowledgement may be returned only after the commit completes.

Normal propagation uses per-target durable outboxes and direct push. Inventory/fetch repair retrieves only missing objects. Network partitions, slow peers, unavailable Aggregators, and overload may delay progress or produce NoQuorum, but shall not remove offline voting power from the denominator or reduce the threshold.

7. Artifact and Data Availability

Artifact content is addressed by digest; locators are discovery metadata only. A Validator shall read the complete Artifact and recompute its digest before signing and before delivery.

Production evidence shall demonstrate that:

• non-signing parties can reconstruct an Artifact from multiple providers;
• providers span at least two independent failure domains;
• Patch and Batch data remain available until Candidate finalization;
• corrupted or unavailable Artifacts stop Settlement instead of permitting incomplete Batches; and
• an expanded multi-period range remains replayable within explicit resource bounds.

8. Persistence and Crash Recovery

Three atomic boundaries are critical:

1. chain events and the ingestion checkpoint;
2. authenticated state nodes and the result root; and
3. exact Vote reservation and subsequent signature persistence.

Operations spanning a database, file system, P2P transport, and RPC shall follow the sequence “stable identity → durable intent or content → external action → finalized reconciliation”; they shall not assume a distributed transaction.

Kill-and-restart tests shall cover snapshot reads, Artifact publication, Signer reservation, signature persistence, outbox enqueue, QcReady persistence, and every Settlement action. An acceptable recovery outcome is limited to retry, byte-identical return of an existing Vote, Abstain, or fail-stop.

9. On-Chain State Safety

QC Admission shall validate domain, chain, ProtocolSuite, Committee, compute-key membership, signer bitvec, aggregate signature, strict threshold, Context/Commitment binding, replay protection, and base/cursor continuity.

The chain does not recompute Contribution, Registry, Price, Retention, Affected, Delta, or Power formulas. It relies on the QC as the Validator endorsement of one result and on the Candidate state machine as the delivery-completeness boundary.

Before Atomic Activate, Staging, partial Batch, Sealed, Expired, and Rejected states shall not change PowerReadModel. Under concurrent activation, only the Candidate matching the current base and cursor may succeed.

10. Settlement and Reward Safety

Settlement Workers shall operate asynchronously after durable QcReady. A transaction is successful only when its finalized on-chain effect matches the intent identity; RPC acceptance or mempool presence is not success evidence.

Duty order shall derive from the seed of the preceding Active version and the Validator address. It shall not derive from a rotatable relay account, QC hash, or signer bitmap. A finite Public fallback shall follow all Validator windows.

Rewards shall not enter Context, Commitment, QC voting power, or the Power formula. Duplicate Votes, duplicate Batches, Batch repartitioning, or claim replay shall not increase rewards. Insufficient Reward Pool balance may disable rewards and raise an alert, but shall not reject a valid QC or Activate operation.

11. Observability and Reconciliation

Signal	Purpose
Finalized-ingest lag and gap	Detect source and projection integrity failures
Latest-ready boundary and Active-cursor lag	Detect computation backlog and catch-up range
Snapshot, price, and period-input roots	Localize Validator input divergence
Commitment-group count	Detect deterministic-result divergence
Validated Vote count and signed-power ratio	Observe QC formation
Artifact availability and digest failures	Detect data-availability faults
QcReady depth and oldest age	Detect delivery backlog without coupling it to computation
Candidate state and accepted Batch count	Observe Staging, Seal, and expiry
Settlement finality lag and duty rank	Observe duty handoff and Public fallback
Active version, cursor, and seed generation	Reconcile Atomic Activate
Reward Pool, reserved amount, and claim state	Detect budget and duplicate-claim risk

Logs shall not contain private keys, complete signing requests, Authorization headers, production DSNs, or unbounded high-cardinality fields. PeerId, full hashes, and addresses belong in restricted diagnostics rather than metric labels.

12. Verification Matrix

Domain	Required coverage
Contribution	Invalid application/token/custody, duplicate issuance, pause, event order, and finality
Input	Gap, empty period, historical configuration, price NeverObserved, stale stable price, and inactive-user Retention
Numeric rules	Scale, stepwise rounding, zero, bounds, division by zero, overflow, and maximum Power
State	Member and non-member proof, Patch, post root, Empty Patch, and deterministic Batch formation
Signer	Idempotent identical request, conflicting request, crash points, key rotation, and revocation
Network	Unauthorized peer, duplicate, reordering, partition, Busy, repair, and store rebuild
QC	Insufficient threshold, incorrect denominator, different Commitment, invalid proof of possession, and cross-epoch key
Candidate	Duplicate or reordered Batch, partial Batch, Expire, Reject, and concurrent Activate
Settlement	RPC, gas, and nonce faults; unavailable Primary; unavailable Validators; Public fallback
Reward	Signer subset, duplicate Receipt, insufficient budget, repeated claim, and deadline recovery

13. Production Stages and Evidence Gates

Gate	Required evidence
G0 Business semantics	Multi-period $R_p\!\rightarrow\!\Delta_p$ is unambiguous, where $R_p$ is the post-Retention value and $\Delta_p$ is the period increment; Mature Contribution is uniquely defined
G1 Input consistency	Independent nodes obtain identical period, price, and Context roots
G2 Result consistency	Independent implementations obtain bit-exact Patch, post root, and Commitment
G3 QC safety	Operator-to-compute-key authority, proof of possession, full denominator, double-sign protection, and threshold are enforced
G4 Minimal on-chain logic	Move contains no Power business formula and negative state-transition tests pass
G5 Automatic catch-up	The protocol recovers the complete range from the Active cursor after consecutive NoQuorum periods
G6 Atomicity and Empty Patch	Partial Batch remains invisible; an empty result still advances cursor and version
G7 Capacity and data availability	Maximum range, Artifact, Committee, and recovery windows remain executable
G8 Settlement liveness	Primary, Secondary, and Public handoff works without backpressuring computation
G9 Incentive safety	Receipt, bitmap, budget, claim, and funding source expose no duplicate issuance path

14. Prohibited Patterns

Prohibited pattern	Risk
Substitute historical input with a local latest or default value	Validators can compute different results
Use one service to compute and require Validators to co-sign	Creates a centralized result authority
Remove offline peers from the QC denominator	A network partition can reduce the safety threshold
Expose an arbitrary-bytes Signer interface	Bypasses structured validation and double-sign protection
Treat RPC acceptance as Settlement success	Delivery can be lost or repeated after restart
Expose Staging or Sealed Power	Downstream systems can read incomplete state
Permit an administrator to advance the cursor or write Power	Bypasses QC and automatic catch-up
Use wall-clock time, thread count, or gas estimates in protocol results	Breaks cross-implementation determinism
Mint unbounded rewards per Vote or Batch	Duplicate activity or repartitioning can inflate issuance

15. Production-Readiness Declaration

POC V2 may enter a limited production pilot only when repeatable evidence supports all of the following statements:

1. Two independent Validators derive bit-exact results from the same finalized history.
2. Insufficient signed power, a partial Batch, or an invalid Candidate cannot change Active Power.
3. No single Indexer, Worker, Aggregator, Settlement Worker, peer, or administrator can independently change the result.
4. NoQuorum, network partition, crash, and complete Validator-delivery failure preserve the previous state and allow safe recovery.
5. A POC resource failure cannot impair Topo base-consensus readiness.
6. Any unresolved P0 parameter remains restricted to shadow or testnet operation and is not represented as production-ready.