G

Proof-of-Contribution

Proof-of-Contribution

Contribution Dimensions#

Every node's contribution is scored across four dimensions:

Dimension

Measured by

Weight

Uptime

Validator challenges + availability proofs

35%

Performance

Execution quality, latency, throughput vs. declared SLA

25%

Volume

Total verified units delivered (compute-seconds, GB stored, GB relayed)

25%

Reliability

Consistency over time; penalized for spikes and gaps

15%

contribution_score =

(uptime_score      × 0.35) +
  (performance_score × 0.25) +
  (volume_score      × 0.25) +
  (reliability_score × 0.15)

All inputs to this formula come from validator-verified receipts. Self-reported data is not accepted. A node that submits fake receipts (detected by validators) receives a zero score for the affected period plus reputation penalties.

Scoring Period (MVP defaults — subject to governance)#

Parameter

Value

Epoch length

7 days

Score finalization

24 hours after epoch close

Dispute window

48 hours from score publication

Distribution

After dispute window closes

Scores for a completed epoch are immutable after the dispute window. No retroactive adjustment is possible once distribution has occurred.

Rail A Distribution#

Rail A is a finite allocation of protocol resources distributed to nodes with verified contribution above the minimum threshold. Key properties:

  • Finite total — the Rail A allocation is fixed at launch; it does not inflate

  • Declining rate — distribution per epoch decreases over time on a predetermined schedule

  • Performance-weighted — share is proportional to contribution_score within the epoch

  • No passive component — a node that is offline for an epoch receives zero Rail A for that epoch

node_rail_a_share =
  (node_contribution_score / total_network_contribution_score)
  × epoch_rail_a_allocation

The declining schedule means early participants who deliver verified service receive proportionally more than later participants — rewarding the risk of early infrastructure investment. The reward is always tied to verified delivery, never to holding. Rail A Eligibility per Epoch To be eligible for Rail A distribution, a node must:

  1. Be registered and active for the full epoch

  2. Achieve uptime score ≥ 85% for the epoch (MVP default — subject to governance)

  3. Pass at least one validator challenge during the epoch

  4. Have no active fraud investigation

  5. Have no pending slashing from the validator network Nodes that fall below the eligibility threshold in a given epoch receive zero Rail A for that epoch. There is no partial distribution below threshold.

Governance Weight#

Governance weight is a separate accumulation from Rail A distribution. It accrues to operators based on verified contribution history, independent of whether Rail A is still active.

// Accumulation each epoch
governance_weight += (contribution_score_this_epoch × epoch_weight_multiplier)

// Decay each epoch
governance_weight ×= (1 - decay_rate_per_epoch)

The decay rate means governance weight requires ongoing contribution to maintain. An operator who stops contributing sees their governance weight decay to zero over time. Governance influence cannot be banked indefinitely. Key properties:

  • Non-transferable — governance weight is bound to the node identity

  • Non-purchasable — buying $GAO tokens does not grant governance weight

  • Contribution-only — only verified infrastructure delivery accumulates weight

  • Decaying — ongoing participation required to maintain influence

Contribution Leaderboard#

The protocol maintains a public, real-time contribution leaderboard:

GET /v1/depin/leaderboard?type=compute|storage|bandwidth|all&period=7d|30d|90d
{
  "period": "7d",
  "type": "all",
  "nodes": [
    {
      "node_id":            "node.operator.gao",
      "contribution_score": 94.2,
      "rank":               1,
      "uptime":             99.8,
      "volume_units":       1420000,
      "governance_weight":  847.3
    }
  ]
}

The leaderboard is read-only and public. It is computed from validator-verified receipts — operators cannot self-report into it.

Verification Audit Trail#

Every contribution score is backed by an auditable trail. The following is an illustrative example:

Contribution score — epoch_0042 / node.operator.gao:  ← illustrative example
  Validator receipts:  14,203 verified receipts
  Challenge results:   12 challenges issued, 12 passed
  Uptime proofs:       168 hourly proofs submitted, 165 accepted
  Volume total:        94,200 CPU-seconds verified
  Score:               94.2 / 100
  Merkle root:         0xABC... (anchored on-chain)

Epoch scores are Merkle-anchored on-chain. Any party can independently verify any node's score for any epoch using the public Merkle proof system.

PoC Protocol Invariants (not subject to governance change)#

ID

Invariant

DEP-INV01

No compensation released without a quorum-verified receipt

DEP-INV02

No single validator can unilaterally approve or block a receipt

DEP-INV03

All challenge randomness is on-chain verifiable; no party can predict challenge timing

DEP-INV04

Governance weight is bound to node identity; non-transferable, non-purchasable

DEP-INV05

Rail A scoring inputs are validator-verified only; self-reported data not accepted

DEP-INV06

Epoch scores are Merkle-anchored on-chain; immutable after the dispute window

See validator-spec.md for how receipts are verified.
See node-operator-guide.md for registration and how to participate.