Forge Pool

Appearance

Node Payouts ​

Forge Pool compensates compute providers for verified execution contributed to the planetary runtime.

Payouts are designed to reward:

  • useful computation
  • execution reliability
  • deterministic participation
  • replay-compatible contribution
  • operational integrity

The payout system exists to align three goals:

  • customers receive dependable execution
  • providers are compensated fairly
  • the runtime grows in useful and trustworthy capacity over time

Forge Pool does not reward mere infrastructure presence.

Payouts derive from attributable, verified execution activity.

1. Core Principle ​

Node Payouts are based on:

verified execution contribution

—not nominal hardware ownership or idle participation.

Execution must become:

  • attributable
  • verifiable
  • replay-compatible
  • settlement-eligible

before it contributes to canonical payout calculation.

This preserves trust in the economic model across heterogeneous infrastructure environments.

2. Relationship to Execution Accounting ​

Provider payouts are downstream of execution accounting.

Workloads pass through the canonical lifecycle:

text
request
→ planning
→ execution
→ verification
→ aggregation
→ settlement
→ finalized ledger record

Only finalized execution records may contribute to payout calculation.

Payout eligibility therefore depends on:

  • verified execution
  • finalized settlement state
  • replay-compatible attribution
  • provider accounting integrity

See Execution Accounting.

3. Who Can Participate ​

Compute providers may include:

  • individual operators
  • infrastructure teams
  • enterprise fleets
  • research institutions
  • universities
  • data-center operators
  • approved strategic infrastructure partners

Participation availability may depend on:

  • onboarding
  • technical validation
  • jurisdictional policy
  • governance classification
  • commercial eligibility

4. Qualification Requirements ​

Before participating in payouts, providers may be required to complete:

  • registration
  • identity or organization verification
  • key provisioning
  • technical validation
  • infrastructure checks
  • operational review
  • compliance review where applicable

Qualification systems exist to preserve:

  • payout integrity
  • runtime reliability
  • ecosystem trust
  • settlement correctness

5. How Payouts Are Calculated ​

Payouts are based on verified contribution rather than passive capacity advertisement.

Settlement may consider factors such as:

  • finalized workload volume
  • normalized execution contribution
  • replay consistency
  • execution reliability
  • aggregation correctness
  • provider trust weighting
  • operational quality

A simplified conceptual model may resemble:

text
node_share =
  (verified_execution_units * trust_weight)
  / total_verified_network_execution

Then:

text
node_payout =
  provider_pool * node_share

Actual production logic may incorporate additional accounting and policy controls.

6. Verification and Settlement Integrity ​

Payout integrity depends on execution verification.

Forge Pool may apply mechanisms such as:

  • replay validation
  • shard verification
  • aggregation consistency checks
  • anomaly detection
  • provider trust weighting
  • execution sampling

Execution that is:

  • invalid
  • unverifiable
  • inconsistent
  • fraudulent
  • operationally compromised

may be excluded from settlement.

Payouts derive from finalized accounting records rather than unverified execution claims.

7. Reliability and Reputation ​

Forge Pool may apply reliability-adjusted weighting to preserve execution quality.

Illustrative signals may include:

  • correctness
  • replay consistency
  • uptime
  • responsiveness
  • error rates
  • operational stability
  • long-term execution integrity

Reliable providers may receive proportionally greater execution participation and settlement weighting.

The objective is to reward stable, trustworthy contribution.

8. Disputed or Invalid Execution ​

Some execution activity may enter dispute or review states.

Illustrative examples may include:

  • replay divergence
  • settlement inconsistencies
  • accounting anomalies
  • execution corruption
  • infrastructure instability
  • suspected fraud

Where necessary, Forge Pool may:

  • delay settlement
  • withhold payouts
  • adjust attribution
  • invalidate execution contribution
  • initiate operational review

These controls exist to preserve trust across the execution economy.

9. Payout Frequency ​

Payout cadence may vary depending on:

  • provider class
  • deployment model
  • jurisdiction
  • governance status
  • commercial agreement

Illustrative patterns may include:

  • monthly payouts
  • enterprise settlement windows
  • custom partner settlement schedules

Supported settlement rails may include:

  • bank transfer
  • wire
  • account credits
  • approved regional payment methods

Availability may depend on compliance and operational constraints.

10. Provider Visibility ​

Provider dashboards and APIs may expose visibility such as:

  • executed workload volume
  • attributable execution activity
  • estimated settlement state
  • current-cycle earnings estimates
  • historical payouts
  • replay-linked accounting references
  • reliability metrics
  • operational health trends

This gives providers operational and financial visibility into their participation.

11. Compliance and Tax Requirements ​

Depending on jurisdiction and participation scale, providers may be required to supply:

  • organizational information
  • tax documentation
  • KYC or KYB information
  • settlement details
  • banking information
  • regulatory disclosures where applicable

Some participation models may require enhanced review.

12. Hybrid Enterprise Participation ​

Some organizations may participate simultaneously as:

  • customers consuming execution
  • providers contributing infrastructure
  • operators of private execution domains

Forge Pool may support hybrid accounting models such as:

  • separate billing and payout structures
  • netted settlement arrangements
  • enterprise-specific accounting scopes
  • private settlement domains

Commercial treatment may vary by deployment model.

13. Relationship to Economic Integrity ​

Payouts are one component of a broader execution-native trust system.

Payout integrity depends on:

  • deterministic attribution
  • replay compatibility
  • provider governance
  • execution verification
  • settlement correctness
  • ledger-backed accounting

See Economic Integrity.

14. Relationship to Provider Governance ​

Provider participation remains subject to governance systems and operational policy requirements.

Governance may affect:

  • payout eligibility
  • workload access
  • execution weighting
  • trust classification
  • settlement participation

See Provider Policy.

15. Future Evolution ​

The payout system may evolve to support:

  • advanced provider trust systems
  • execution attestation
  • regulated execution classes
  • delegated settlement systems
  • marketplace-native payout coordination
  • hybrid enterprise execution economies

Future evolution will preserve deterministic settlement principles.

16. Summary ​

Node Payouts are how Forge Pool converts distributed execution contribution into a replay-compatible provider economy.

The payout model is designed to be:

  • execution-native
  • verification-aware
  • replay-compatible
  • reliability-adjusted
  • auditable
  • enterprise-compatible

Forge Pool rewards useful and trustworthy execution contribution rather than passive infrastructure ownership.

Settlement derives from verified computation across the planetary runtime.