Contributing Execution Capacity
Execution providers contribute verified computational capacity to the Forge runtime.
They do not receive arbitrary computational work.
They participate in deterministic distributed execution governed by execution contracts, verification policies, replayable execution evidence, and documented execution semantics.
This guide explains how execution providers become trusted participants in the Forge runtime.
The Provider's Role
Applications describe computational intent.
Providers execute computation.
The runtime preserves execution truth.
Every provider participates in the following lifecycle:
Execution Contract
│
▼
Shard Assignment
│
▼
Distributed Execution
│
▼
Verification
│
▼
Deterministic Reduction
│
▼
Replay
│
▼
Economic SettlementExecution providers contribute computational evidence.
They do not independently determine computational truth.
Why Contribute Execution Capacity?
Forge transforms idle computational resources into structured execution capacity.
Provider nodes execute real computational workloads including:
- probabilistic simulation
- optimization
- graph computation
- numerical analysis
- AI execution
- scientific workloads
- enterprise analytics
Execution contributes measurable computational value.
Economic settlement derives from verified execution rather than speculative participation.
See:
- Economy
- Provider Rewards
Runtime Responsibilities
Execution providers are responsible for:
- operating reliable execution infrastructure
- maintaining healthy execution agents
- executing assigned shards
- preserving operational stability
- participating in verification
- contributing replay-compatible execution evidence
The runtime remains responsible for:
- execution planning
- shard construction
- scheduling
- verification
- deterministic reduction
- replay preservation
- execution accounting
Providers execute computation.
The runtime preserves execution integrity.
Registering an Execution Node
Execution nodes authenticate using Node Tokens.
Each Node Token:
- belongs to a single organization
- establishes execution identity
- associates execution with provider accounting
- defines trust boundaries
- may limit node registration
- may be revoked at any time
Node Tokens are generated inside Forge HQ.
See:
- HQ
- Authentication
Installing the Execution Agent
Forge Agents are responsible for executing assigned computational shards.
Linux installation:
curl -sL https://forgepool.io/install.sh | sudo bashWindows installation:
Set-ExecutionPolicy Bypass -Scope Process -Force
iwr https://forgepool.io/install.ps1 -UseBasicParsing | iexDuring installation you will configure:
- node name
- execution region
- node visibility
- supported execution modes
- Node Token
The installer automatically:
- installs the execution agent
- configures the runtime
- registers the service
- prepares execution directories
- starts the agent
Once registration succeeds, the node becomes eligible for workload scheduling.
Execution Identity
Every execution agent possesses a unique runtime identity.
Execution identity determines:
- authentication
- scheduling eligibility
- replay attribution
- execution accounting
- provider statistics
- operational history
Execution identity belongs to the node.
Computational truth belongs to the execution contract.
These responsibilities intentionally remain separate.
Node Configuration
Typical configuration includes:
- node identity
- execution region
- visibility
- supported execution targets
- verification participation
- execution limits
- authentication token
Configuration influences operational behavior.
It never changes computational semantics.
The Node Lifecycle
After startup, every execution agent follows the same lifecycle.
Authenticate
│
▼
Register
│
▼
Capability Discovery
│
▼
Scheduler Assignment
│
▼
Shard Execution
│
▼
Verification
│
▼
Result Submission
│
▼
Replay PreservationExecution begins only after successful registration and scheduler assignment.
Verification Participation
Execution providers participate in verification.
They do not control it.
Depending on execution policy, providers may participate in:
- redundant execution
- statistical validation
- shard verification
- replay generation
- execution evidence collection
Verification remains a runtime responsibility.
Providers contribute verified computational work.
See:
- Trust Layer
- Verification
Reliability
Reliable execution infrastructure improves both runtime stability and provider utilization.
Operational reliability may consider:
- successful execution rate
- verification consistency
- shard completion
- execution latency
- protocol compliance
- uptime
- operational stability
Reliability is continuously evaluated.
It is never permanently granted.
The Scheduler may adjust workload allocation according to observed execution quality.
Observability
Execution providers can inspect operational state through Forge HQ.
Typical inspection surfaces include:
- node health
- execution status
- assigned workloads
- verification outcomes
- replay references
- execution metrics
- operational history
- provider accounting
Execution remains observable throughout its lifecycle.
Economic Settlement
Forge compensates verified computational contribution.
Settlement derives from execution evidence rather than declared participation.
Provider accounting may incorporate:
- completed shard execution
- verification participation
- execution duration
- workload characteristics
- replay references
- reliability
Reliable execution increases scheduling opportunities.
Scheduling opportunities increase computational contribution.
Computational contribution determines economic settlement.
Production Operations
Production execution infrastructure should:
- maintain stable hardware
- preserve consistent operating environments
- synchronize system clocks
- monitor execution logs
- separate production and testing nodes
- secure authentication credentials
- monitor verification outcomes
- review replay evidence
- maintain operational uptime
Operational discipline directly contributes to execution quality.
Practical Mental Model
A useful way to understand execution providers is:
Execution Capacity
│
▼
Execution Contract
│
▼
Distributed Execution
│
▼
Verification
│
▼
Replay
│
▼
Economic SettlementProviders contribute execution capacity.
The runtime transforms that capacity into verified computational work.
Relationship to Clients
Applications and providers occupy complementary roles.
Applications define computational intent.
Providers supply computational capacity.
The Forge runtime connects both through deterministic execution.
Applications
│
Computational Intent
│
▼
Forge Runtime
▲
Verified Execution Capacity
│
ProvidersNeither side independently establishes computational truth.
Truth emerges from execution contracts, verification, deterministic reduction, and replay.
Where to Go Next
Continue with:
Forge Studio — compose execution systems visually.
HQ — inspect execution, providers, replay, and operational state.
Observability — monitor production execution.
Security — understand authentication, authorization, and runtime trust boundaries.
Trust Layer — learn how verification, replay, and heterogeneous execution establish computational trust.
Together these documents describe the complete operational lifecycle of the Forge runtime.
Final Thought
Execution providers are not infrastructure consumers.
They are infrastructure participants.
They do not sell processor time.
They contribute verified execution capacity to a deterministic execution system whose outputs remain inspectable, replayable, and independently verifiable long after computation has completed.