Proof of Contribution V2 Whitepaper

Abstract

Proof of Contribution (POC) V2 is Topo's protocol for contribution settlement and on-chain Power. It accepts trusted contribution events produced by DApp state machines, lets every Validator independently recover the same finalized inputs and execute deterministic computation, requires a Quorum Certificate (QC) representing strictly more than two-thirds of voting power over one result, and uses an on-chain Candidate state machine for batched delivery and atomic activation.

POC V2 does not treat DApp logs, a single backend calculation, or provisional off-chain state as protocol authority. On-chain contracts govern trusted inputs, Committee and key authorization, QC admission, state continuity, and final activation. Validator Sidecars perform complex but reproducible period computation. Downstream applications read Activated Power only.

1. Problem and Scope

Contribution in an open DApp ecosystem is not equivalent to capital. Trades, fulfillment, creative work, completed tasks, liquidity, governance participation, and business growth may all create value, but they arise in different state machines, assets, and units of account.

Common alternatives have material limits:

• Product points are easy to operate but difficult to interpret as a public protocol input.
• Pure staking is readily verifiable but primarily measures capital.
• Centralized scoring can model complex behavior but requires unconditional trust in an operator.

POC does not replace DApp business logic. It provides a governed, reproducible, and verifiable contribution-settlement layer between DApps and on-chain weight consumers.

2. Objectives and Non-Goals

POC V2 must meet the following objectives:

Objective	Protocol requirement
Trusted input	Only finalized chain facts and ContributionEvent objects from the trusted POC path enter computation
Consistent input	Every Validator constructs Context from the same boundary, Active base, historical policy, Registry state, and price fence
Deterministic result	Sorting, integer arithmetic, rounding, Retention, Patch, Batch, and digest rules converge across implementations
Distributed attestation	Strictly more than two-thirds of full Committee voting power signs the same Context and Commitment
Minimal on-chain execution	The chain validates QC, object binding, and state continuity without re-executing the Power formula
Atomic visibility	Partial Batches, unactivated Candidates, and failed delivery never change downstream-visible Power
Automatic catch-up	Failure does not discard contribution; the next boundary recomputes from the unadvanced Active cursor
Auditability and recovery	Inputs, Artifact, Vote, QC, Batches, and activation can be replayed or reconciled by stable identity

The design keeps POC computation outside the base-consensus critical path. It does not introduce a second BFT protocol or a Period Coordinator, and governance cannot bypass QC to write Power directly.

3. End-to-End Protocol

The protocol follows ten steps:

1. A DApp state machine confirms that a trade, fulfillment, task, or other business result is mature.
2. The DApp issues its equity token through the trusted POC contribution path; Registry, token, and custody constraints are validated before a finalized ContributionEvent is emitted.
3. Each Validator ingests finalized transactions only and seals a continuous input snapshot after $\operatorname{PeriodClosed}(P)$.
4. The Validator derives the only valid covered range, $\mathcal{R}(L,P)$, from the on-chain Active cursor $L$.
5. Each Validator independently restores per-period Config, Registry, Contribution, Retention, and the Topo DEX latest stable prices at the Context fence.
6. Deterministic computation produces a Sparse Patch, post-state, Batches, Artifact, Context, and Commitment.
7. Validators sign exact Votes with independent BLS compute keys authorized by their Operators; strictly more than two-thirds voting power forms a QC.
8. The QC creates a Candidate; all committed Batches must arrive before Seal.
9. Atomic Activate switches the Active root, version, and cursor and creates the seed used for the next delivery-duty ordering.
10. Staking, Voting, and other modules consume Activated Power through the on-chain read interface.

4. Trusted Contribution Boundary

POC recognizes a trusted contribution event, not an ordinary DApp log. Entry into the protocol requires at least:

• an App registered and admitted in Registry;
• consistent App, equity-token, and custody bindings;
• a business state that satisfies an explicit maturity condition;
• equity-token issuance and ContributionEvent emission in one trusted execution path; and
• Topo finality for the resulting event.

This boundary separates business completion, entitlement issuance, and admission to POC computation. Candidate activity, frontend state, backend logs, and product-local points cannot create Power directly.

5. Periods, Context, and Value Normalization

Let $P$ be the latest closed source period. Under normal timing:

$$B=P,\qquad C=P+1,\qquad T=P+2.$$

Here $B$, $C$, and $T$ denote the source boundary, compute period, and target period.

The Active cursor, not a local task record, determines the covered range:

$$\mathcal{R}(L,P)=[L+1,P].$$

Here $L$ is the current Active cursor, and $\mathcal{R}(L,P)$ is the covered source-period range.

Context binds chain and protocol identity, Active base root/version/cursor, covered range, per-period input roots, price-read fence and snapshot root, Committee epoch, ValidatorSet root, and compute-key root.

DApp equity tokens enter a common value basis through Topo DEX price identities. POC does not use the changing current-period price or query one source-period-specific price for every period. At the finalized price-read boundary following $\operatorname{PeriodClosed}(P)$, it resolves each required identity to its latest stable price once and binds the resulting price-snapshot commitment to Context. If any required identity has never formed a stable price, a Validator must Abstain; zero and default prices are prohibited.

6. Deterministic Power Model

Starting from a user's base value $V_L(u)$, the covered range is folded in source-period order:

$$\begin{aligned} R_p(u)&=\operatorname{Ret}\!\left(V_{p-1}(u),\rho_p\right), \\ \Delta_p(u)&=c_p(u)\,\pi_p\,w_p, \\ V_p(u)&=R_p(u)+\Delta_p(u),\qquad p=L+1,\ldots,P. \end{aligned}$$

Here $V_p(u)$ is user $u$'s period-end value; $R_p(u)$ is the post-Retention value; $\Delta_p(u)$ is the period increment; and $\rho_p$, $c_p(u)$, $\pi_p$, and $w_p$ are the Retention parameter, contribution, Context price, and App weight.

Every period applies $R_p\!\rightarrow\!\Delta_p$ in that order. The retention fraction $\rho_p\in[0,1]$ is fixed for period $p$. Every source period uses its own Config, Registry, price-identity mapping, and Retention, while actual prices come from the range-wide latest-stable snapshot frozen in Context.

The final Patch contains Affected users only, exactly once per user. A range with no Affected users still produces an Empty Patch with Context, Artifact, Vote, and QC. The root may remain unchanged after activation, but the cursor advances and Active version increases by one.

7. Validator-Driven Trust Architecture

Every Validator runs the same POC Sidecar instead of relying on a centralized calculator:

• L1 continuously reads finalized Topo facts and freezes an input snapshot.
• L2 independently computes the result, builds the Artifact, and revalidates signing eligibility.
• An isolated Signer uses a dedicated compute key and durable Journal to prevent equivocation.
• The L0 permissioned network uses direct push, durable outboxes, and repair to distribute Vote/QC objects.
• L3 Aggregators group matching results; they do not select or alter a result.
• L3 Settlement Workers submit QC, Batches, and Seal asynchronously after durable QcReady.
• L4 on-chain modules validate QC and govern Candidate and Active state.

The QC threshold is:

$$3S>2W.$$

Here $S$ is signed voting power, and $W$ is the full Committee voting power.

Offline Committee members, members without an active compute key, and members not running a Sidecar remain in the denominator. Network connection count, message count, PeerId, relay account, and reward address carry no QC weight.

8. Candidate and Atomic Activate

A valid QC does not immediately change Power. A non-empty result enters Staging; all committed Batches must be present before Sealed. An Empty Patch can use a zero-Batch Seal. Only Atomic Activate makes a result visible to downstream consumers.

State	Active root/version	Active cursor	Downstream visibility
Unrecorded / NoQuorum	Unchanged	Unchanged	Hidden
Staging / partial Batches	Unchanged	Unchanged	Hidden
Sealed	Unchanged	Unchanged	Hidden
Expired / Rejected	Unchanged	Unchanged	Hidden
Activated	Atomically switched	Advanced to $P$	Visible

Activation verifies Seal, base continuity, and covered-range continuity, then commits root, version, cursor, and the next Duty Seed in one state transition. No intermediate state or failed transaction may leave a partially activated result.

9. Automatic Catch-Up

When inputs are incomplete, Validator results diverge, signed power is insufficient, a Candidate expires, or delivery remains incomplete, the protocol preserves the previous Activated Power and does not advance the Active cursor. At the next boundary, every Validator recomputes the larger complete range from the same old cursor.

$$\operatorname{NQ}(P) \Longrightarrow L'=L,\qquad \mathcal{R}(L',P+1)=[L+1,P+1].$$

Here $\operatorname{NQ}(P)$ denotes NoQuorum at source period $P$, and $L'$ is the cursor at the next boundary; $L'=L$ records that the failed attempt did not advance it.

Catch-up is not a simple sum of failed periods. It restores each period's inputs and applies $R_p\!\rightarrow\!\Delta_p$ sequentially. The protocol must not truncate the earliest period, remove offline voting power, or let an administrator advance the cursor manually.

10. Verification and Audit Evidence

Auditability comes from a replayable object chain rather than a single “calculation succeeded” log:

Evidence object	What it proves
Finalized facts	Contribution, Policy, Registry, price updates, and boundaries originate on Topo
Input Snapshot / Context	Boundary, base, range, input roots, price root, and Committee are fixed
Artifact	Input slices, proofs, Patch, and Batches are replayable by digest
Vote / QC	The specified Committee attested to the same Context and Commitment
Candidate / Activate	Batch completeness, state continuity, and final atomic visibility are enforced on-chain

On-chain QC verification is not an on-chain proof of the business formula. Security also depends on honest Validators performing complete independent computation, a deterministic specification, data availability, golden vectors, and an independent verifier.

11. Delivery Duties and Incentives

Every Validator Sidecar runs a Settlement Worker. The current Active seed, together with Context, Commitment, action kind, Batch index, and Validator address, derives Primary and Secondary responsibilities. Duty windows use finalized fences. After all Validator windows expire, any Public Relayer may continue an incomplete QC, Batch, or Seal action.

Incentives have two independent paths: a Validator Vote reward for matching the final Activated result, and a Delivery reward for the first valid QC/Batch/Seal state transition. Both come from a pre-funded Reward Pool with Candidate and period caps and become claimable only after activation. Reward shortage or claim failure cannot block valid activation or alter Power.

12. Downstream Composition

PowerStore's Activated Power is the only public read interface. Staking, Voting, governance, reward, and partner protocols may compose it, but they must not read off-chain estimates, Artifacts, or provisional Candidate state.

Where Staking also requires an economic constraint, Activated POC Power may be combined with TOPO deposit coverage:

$$E(u)=\min\!\left(A(u),D(u)\right).$$

Here $E(u)$, $A(u)$, and $D(u)$ denote effective power, Activated POC Power, and deposit cover for user $u$.

This prevents either capital without contribution or contribution without economic commitment from unilaterally determining effective weight.

13. Security Assumptions and Boundaries

The core assumptions are:

• strictly more than two-thirds of Committee voting power can attest to one result;
• less than one-third of voting power is malicious or violates independent recomputation;
• finalized chain history and required Artifacts remain available during signing and delivery windows;
• compute, consensus, PeerId, Operator, relay, and reward identities remain isolated; and
• Topo continues finalizing blocks and at least one Settlement Worker or Public Relayer can deliver transactions.

When these conditions do not hold, the safe outcome is the previous Activated Power—not a lower QC threshold or an incomplete result.

14. Core Design Principles

POC V2 reduces to five principles: trusted contribution originates from a recognized on-chain path; computation inputs are frozen at finalized boundaries; every Validator derives the same result independently; a strictly-greater-than-two-thirds QC attests to one Commitment; and only Atomic Activate changes downstream-visible Power. Any failure preserves the previous Active state and is automatically carried forward through the unadvanced cursor.

15. Appendix Guide

• System Architecture and Component Boundaries: L5–L0 layers, module responsibilities, interfaces, and deployment isolation.
• Distributed Settlement Protocol: periods, Context, computation, Artifact, Vote/QC, Candidate, delivery, and catch-up.
• DApp Integration Reference Case: contribution maturity, trusted issuance, business settlement, and exception paths.
• Security, Verification, and Production Readiness: threat model, test matrix, observability, and launch gates.