Appearance
Provider Policy
This document defines the operational and participation policies governing compute providers within Forge Pool.
Providers contribute execution capacity to the planetary runtime and participate in the shared execution economy.
Because Forge Pool operates as a deterministic execution infrastructure, provider participation must preserve:
- execution integrity
- replay correctness
- accounting trust
- operational reliability
- ecosystem safety
This policy exists to protect customers, providers, and the network itself.
1. Purpose
The Provider Policy establishes:
- provider eligibility expectations
- operational requirements
- infrastructure standards
- integrity obligations
- governance rules
- participation boundaries
This policy supplements:
- Terms of Service
- Provider Agreement
- Security documentation
- applicable commercial agreements
2. Role of Providers
Providers contribute compute resources that may participate in:
- distributed execution
- probabilistic workloads
- aggregation support
- replay operations
- specialized execution classes
Providers do not control execution semantics.
Forge Pool remains the canonical orchestration and settlement authority.
3. Provider Categories
Forge Pool may support multiple provider categories.
Illustrative categories include:
Individual Operators
Independent participants operating approved infrastructure.
Enterprise Providers
Organizations contributing internal fleets, clusters, or infrastructure capacity.
Institutional Providers
Universities, research labs, public institutions, and approved scientific infrastructure partners.
Strategic Infrastructure Partners
Dedicated or high-capacity providers operating under separate commercial agreements.
Different categories may have different onboarding, compliance, and operational requirements.
4. Participation Requirements
Before participating in the runtime, providers may be required to complete:
- registration
- technical validation
- key provisioning
- security checks
- operational verification
- jurisdictional review where applicable
Forge Pool may reject participation requests at its discretion.
5. Infrastructure Expectations
Providers are expected to operate infrastructure that is:
- lawful
- stable
- secure
- reasonably maintained
- capable of deterministic execution
Illustrative expectations may include:
- modern operating system support
- secure networking
- stable connectivity
- accurate system clocks
- secure credential handling
- isolation between workloads
Forge may define additional requirements for specialized execution classes.
6. Security Obligations
Providers must take reasonable measures to protect:
- execution integrity
- system credentials
- workload confidentiality
- runtime stability
Providers must not:
- intercept workload data
- tamper with execution
- manipulate outputs
- bypass orchestration controls
- impersonate other providers
- falsify execution metrics
Security violations may result in immediate suspension or termination.
7. Deterministic Execution Requirements
Forge Pool depends on reproducible execution semantics.
Providers must not intentionally introduce:
- nondeterministic execution manipulation
- hidden workload mutation
- unauthorized runtime modifications
- replay divergence
Where required, Forge may verify execution consistency through:
- replay sampling
- cross-node validation
- aggregation checks
- anomaly detection
8. Reliability Expectations
Providers are expected to maintain reasonable operational reliability.
Illustrative signals may include:
- uptime
- responsiveness
- execution completion rates
- error rates
- replay consistency
- operational stability
Forge Pool may apply reliability-adjusted weighting to execution attribution and payouts.
9. Reputation and Trust Weighting
Forge Pool may maintain provider trust and reputation systems to preserve execution integrity.
Trust signals may include:
- long-term reliability
- verification success rate
- operational consistency
- security history
- execution correctness
Trust weighting may affect:
- workload eligibility
- execution priority
- payout share
- participation scope
- access to specialized execution classes
Trust systems exist to improve runtime quality, not to create social ranking systems.
10. Geographic and Jurisdictional Restrictions
Participation availability may vary by jurisdiction.
Forge Pool may restrict or prohibit participation based on:
- sanctions laws
- export controls
- local regulations
- operational risk
- fraud risk
- geopolitical considerations
Providers are responsible for complying with applicable laws in their jurisdiction.
11. Data Handling Expectations
Providers may process execution fragments or transient workload data depending on workload type and execution policy.
Providers must:
- avoid unauthorized inspection
- avoid persistent retention unless permitted
- avoid secondary usage of workload data
- protect transient execution state
Some workloads may use additional encryption, fragmentation, or isolation controls.
12. Specialized Execution Classes
Some workload categories may require additional qualification.
Illustrative examples include:
- regulated workloads
- enterprise-isolated execution
- memory-sensitive workloads
- security-sensitive execution
- low-latency execution classes
- scientific reproducibility workloads
Additional onboarding or infrastructure validation may apply.
13. Prohibited Conduct
Providers must not:
- manipulate accounting records
- falsify capacity claims
- create fraudulent nodes
- artificially inflate workload metrics
- interfere with orchestration
- attack or probe other providers
- abuse execution routing
- bypass governance controls
Forge Pool may investigate suspicious behavior.
14. Monitoring and Verification
Forge Pool may monitor provider participation for:
- operational health
- security anomalies
- replay divergence
- accounting inconsistencies
- fraud indicators
- infrastructure abuse
Monitoring exists to preserve integrity of the runtime and economic model.
15. Suspension and Termination
Forge Pool may:
- suspend workloads
- restrict participation
- reduce trust weighting
- withhold payouts
- terminate provider access
Examples may include:
- security violations
- fraud
- persistent instability
- legal requirements
- operational abuse
- attempts to manipulate execution integrity
Termination decisions may occur without advance notice where necessary to protect the network.
16. Payout Eligibility
Participation alone does not guarantee compensation.
Payout eligibility depends on:
- verified execution contribution
- finalized accounting records
- policy compliance
- operational integrity
- settlement status
Additional commercial terms may apply.
See Node Payouts.
17. Enterprise and Institutional Participation
Some providers may operate hybrid participation models in which they:
- consume execution as customers
- contribute infrastructure as providers
- operate private execution domains
- participate in dedicated settlement arrangements
These deployments may operate under custom commercial or operational agreements.
18. Policy Evolution
This policy may evolve as the runtime expands.
Future additions may include:
- specialized provider classes
- execution certifications
- hardware attestation requirements
- regulated execution domains
- advanced trust and verification systems
Forge Pool will attempt to preserve reasonable continuity where possible.
19. Relationship to Governance
Provider participation is part of a broader ecosystem governance model.
Operational participation does not imply:
- ownership rights
- governance authority
- control over execution semantics
- authority over settlement logic
Forge Pool remains the canonical orchestration and policy authority.
Final Statement
Providers contribute capacity to a shared execution system.
Participation is based on verified contribution, operational integrity, and trust-preserving behavior — not mere hardware presence.
Forge Pool rewards useful execution while protecting deterministic computation across the planetary runtime.