System Architecture and Component Boundaries

1. Scope

This appendix defines POC V2 logical layers, component responsibilities, state ownership, cross-layer contracts, and deployment isolation. It answers who owns authority, who performs work, and how failures converge safely; it does not freeze final ABI, database schema, or capacity values.

The system has six functional layers. The shared poc-protocol package defines versioned objects, encoding, domains, and limits, but is not a seventh layer.

2. Six-Layer Architecture

Layer	Question answered	Core responsibility
L5 Business Applications	Why is Power produced or consumed?	DApp business logic, Staking, Voting, and downstream composition
L4 On-Chain Protocol and Authority	Which facts and transitions are globally valid?	Contribution, period/policy, Committee, QC Admission, Candidate, PowerStore, duty, and reward
L3 Result Coordination and Delivery	How do matching Votes form a QC and reach the chain?	Aggregator, durable QcReady, Settlement Worker, Public fallback, and reward claims
L2 Period Input and Deterministic Compute	How does one input produce one result?	Range, input interpretation, Compute Core, Artifact, and Isolated Signer
L1 Data Access and Persistence	How is off-chain work read, frozen, and recovered?	Finalized Chain Adapter, Event Store, Input Snapshot, authenticated state, and Journal
L0 Communication Foundation	How do signed objects propagate reliably?	Permissioned overlay, durable outbox, Validated Ingress, Ack, and repair

3. Authority Model

Authoritative subject	Sole authority	Non-authoritative copies
Contribution, Policy, Boundary, Committee	Finalized Topo state and events	Indexers, event stores, Peer messages
Active base and covered cursor	On-chain ActivePowerMeta	Local checkpoints and task records
Result attestation	Strictly-greater-than-two-thirds QC over one result	Aggregator choice, Peer count, message majority
Consumable Power	Active root/version/cursor after Atomic Activate	LocalCandidate, Artifact, Staging or Sealed Candidate
Settlement Duty Seed	Finalized seed generated by the previous Activate and held in current Active	Local ranking caches and submitter claims
Reward entitlement	On-chain bitmaps, Delivery Receipts, and frozen beneficiaries	Settlement records and Aggregator signer selection

When a required fact is missing, conflicting, or unverifiable, a component returns NotReady, Abstain, or preserves the previous Active state. Runtime latest values, defaults, and manual database edits cannot fill the gap.

4. End-to-End Object Flow

$$\mathcal{F} \longrightarrow \mathcal{S} \longrightarrow (\mathcal{C}, \mathcal{A}, \mathcal{V}) \longrightarrow \mathcal{N} \longrightarrow \mathcal{Q} \longrightarrow \mathcal{D} \longrightarrow \mathcal{X} \longrightarrow A_{\mathrm{pow}}$$

Here, $\mathcal{F}$ = L4 finalized facts; $\mathcal{S}$ = L1 snapshot; $(\mathcal{C}, \mathcal{A}, \mathcal{V})$ = L2 compute / Artifact / Vote; $\mathcal{N}$ = L0 network; $\mathcal{Q}$ = L3 aggregation + QcReady; $\mathcal{D}$ = L3 delivery; $\mathcal{X}$ = L4 admission + activation; and $A_{\mathrm{pow}}$ = L5 Activated Power.

There is no centralized result server in this path. Every Validator can compute independently, distribute Votes, aggregate QC, and deliver on-chain actions during its duty window.

5. L4 On-Chain Modules

Module	Responsibility	Explicitly excluded
poc_contribution	Validate trusted contribution transactions and emit finalized ContributionEvent	Compute final Power
Period / Policy	Seal boundaries and expose recoverable Config, Registry, Price/Oracle, and Retention identities	Select an off-chain result
Compute Key Registry	Validate Validator Operator, proof of possession, and epoch authorization for an independent BLS compute key	Custody a private key or add voting power
QC Verifier	Validate Committee, bitvec, multisignature, weighted threshold, object binding, replay protection, and base/cursor continuity	Recompute Contribution, Price, Retention, or Power
Candidate Store	Hold the hidden QC-bound result and Batch/Seal progress	Expose provisional Power to L5
PowerStore / PowerReadModel	Atomically switch Active root, version, and cursor and expose the only read interface	Accept a normal account write that bypasses QC
Validator Relay Binding / Duty	Bind relay and reward identities and derive duty windows statelessly from Active seed	Create QC weight or store per-Batch rankings
POC Reward	Store Vote-claim bitmap, Delivery Receipts, budget, and claim state	Enter the Power formula or block valid activation

6. Validator Sidecar

Each Validator Sidecar contains at least:

Component	Layer	Required guarantee
Finalized Chain Adapter	L1	Read an explicit chain identity, continuous transactions, and finalized fences only
Event / Policy Store	L1	Commit events and checkpoint atomically; recover historical periods by boundary
Input Snapshot	L1	Bind boundary, Active base, range, Committee, and per-period fact references
Compute Core	L2	Remain a pure function without RPC, SQL, P2P, clock, randomness, or environment access
Authenticated State / Artifact Store	L1/L2	Verify roots and proofs; publish and reread Artifact by content digest
Isolated Signer / Journal	L2 security boundary	Accept structured requests, revalidate eligibility, and prevent equivocation durably
POC Network Service	L0	Provide direct push, semantic Ack, durable outbox, and repair
Aggregator	L3	Group only identical Context/Commitment results and weight the full Committee
QcReady Store	L1/L3	Persist a self-verified QC before asynchronous delivery
Settlement Worker	L3	Idempotently submit QC/Batch/Seal using an isolated relay account, queue, and RPC pool

7. Key and Identity Separation

Identity	Purpose	QC weight?
Validator Operator account	Authorize, rotate, and revoke compute keys	No
Topo consensus key	Base consensus	No; reuse is prohibited
BLS compute key	Sign POC Votes	Yes, with weight from the frozen Committee
PeerId key	Authenticate POC Overlay connections	No
Relay account	Pay gas and submit QC/Batch/Seal	No
Reward address	Receive Vote and Delivery rewards	No

The POC network never holds the compute private key. The Signer exposes no sign(bytes) endpoint. It operates the key only after validating a structured Context/Commitment request and durably reserving the exact Vote.

8. Cross-Layer Contracts

These names express stable responsibility boundaries rather than final language signatures:

Port	Caller → implementation	Required guarantee
FinalizedContributionSource	L1 → Topo Chain	Finalized, continuous, explicit chain identity
BoundaryAndActiveSource	L1/L2 → Topo Chain	Boundary and Active from a verifiable fence
HistoricalPolicySource	L2 → L1	Per-source-period recovery; no latest fallback
AuthenticatedStateRepository	L2 → L1	Consistent base, root, proof, and checkpoint
ArtifactRepository	L2/L3 → L1	Put-if-absent, read by digest, and reverify
ComputeSigner	L2 → Isolated Signer	Typed preimage, equivocation prevention, durable barriers
VotePublisher	L2 → L0	Accept durable Signed Votes only
DurableNetworkEventSource	L3 → L0	Validated, replayable, monotonic cursor
DurableQcReadySource	Settlement → L1/L3	Persistent QC task with at-least-once consumption
ChainPowerSubmission	L3 → L4	Idempotent QC, Batch, Seal, confirmed by finalized state
ActivePowerRead	L5 → L4	Return Activated Power only

9. Data and Recovery Boundaries

Off-chain state falls into three classes:

1. Chain-rebuildable: event projections, period facts, input snapshots, Committee, Candidate, and Settlement progress.
2. Digest-verifiable or reconstructible: authenticated-state checkpoints, Artifact, and Vote/QC network caches.
3. Not safely reconstructible: Signer Journal. Loss or suspected rollback requires the associated compute key to stop signing.

Inputs satisfying $p > L$, where $p$ denotes the input source period and $L$ denotes the Active cursor, Artifacts referenced by unfinished Candidates, and historical Retention needed for dormant users cannot be deleted by ordinary TTL policies.

10. Deployment and Resource Isolation

• POC Sidecar and Topo consensus use separate runtimes, ports, identity keys, quotas, and readiness signals.
• CPU/cryptographic work uses bounded worker pools; IO, queues, connections, pages, Artifacts, and Batches have hard limits.
• Settlement uses an executor, RPC pool, and circuit breaker independent of Compute and Aggregator.
• RPC, gas, nonce, database pressure, or a POC OOM can reduce POC liveness but cannot block Topo consensus readiness.
• Artifacts may have multiple providers, but locators are not authoritative; content is verified by digest before use.

11. DApp Integration Boundary

A DApp owns its business state machine, maturity condition, equity-token issuance, and trusted ContributionEvent entry. It does not execute the POC Power formula, choose a Validator result, or write PowerStore directly. Frontends and backends may display projections, but must distinguish business completion, contribution issuance, Candidate processing, and Power activation.

12. Architecture Acceptance Criteria

• Documentation and implementation use L5–L0 as the only functional layers.
• L4 is independent of off-chain availability and is the sole authority for Contribution, Candidate, and Active Power.
• Every Validator independently builds its snapshot and result from finalized facts.
• L2 Compute Core has no IO or nondeterministic environment dependency.
• Vote publication follows Artifact reread, eligibility revalidation, and Signer durable barriers.
• Aggregators use the full Committee and the strictly-greater-than-two-thirds threshold.
• Settlement backlog cannot backpressure Compute, Signer, L0, or base consensus.
• Partial Batches, Expired/Rejected Candidates, and reward failures do not alter Active Power.
• L5 reads Activated Power through PowerReadModel only.