Services Overview¶

Services are a planned Wasichain feature. This section documents the intended execution model and the contract ABI hook reserved for service-driven consensus.

Services let validators run nondeterministic logic outside the contract VM, then feed agreed results back into ordinary on-chain contract execution. They are designed for workflows such as price oracles, cron automation, and off-chain event reactors.

Like contracts, services are intended to be ordinary wasm32-wasip2 components rather than programs written for a custom chain-specific language. The difference is not the packaging format, but the execution role.

Services are not a replacement for contracts. A service observes or computes something off-chain, then emits one or more contract calls that become the durable on-chain result.

Execution shape¶

Services have a fixed component shape:

package chain:service@1.0.0;

interface service {
  /// On-chain addresses are represented as raw bytes.
  /// In practice these are expected to be 32-byte Wasichain addresses.
  type address = list<u8>;

  /// A single contract call candidate emitted by the service runtime.
  record service-response {
    /// Target contract address (32-byte on-chain address).
    contract: address,

    /// Payload that will be sent to the target contract.
    contract-data: list<u8>,

    /// How validators decide whether responses agree.
    consensus: consensus-strategy,

    /// Optional logical event key used to aggregate responses across requests.
    event-id: option<list<u8>>,
  }

  /// Strategy validators use to decide whether independently produced
  /// service responses should be treated as equivalent.
  variant consensus-strategy {
    /// Require the final contract payload bytes to match exactly.
    exact-match,
    /// Ask the referenced contract to deterministically normalize the
    /// payload before validators compare results.
    contract-query(address),
  }

  /// A service invocation may emit multiple candidate responses, and each
  /// candidate may independently succeed or fail during local execution.
  type service-responses = list<result<service-response, string>>;

  /// Execute the service with an application-defined input payload.
  /// The returned list is later fed into the service response consensus flow.
  execute: func(input: list<u8>) -> service-responses;
}

Each service invocation can yield zero, one, or many candidate contract calls. Every item is evaluated independently by the network's response-consensus process.

Response fields¶

Admission and activation¶

Services follow the same broad lifecycle as contracts:

1. A developer uploads the service component.
2. Validators validate and precompile it locally.
3. Validators vote on readiness.
4. Once quorum is reached, the network assigns a canonical on-chain service address and the service becomes callable.

This keeps heavyweight validation and compilation out of the consensus hot path.

Ephemeral runtime¶

Services do not have persistent storage of their own. If a service needs durable state, it should read from or write to contracts.

That split is intentional:

• services are allowed to use nondeterministic inputs such as HTTP APIs, hosted backends, or IPFS
• contracts remain the durable, deterministic source of truth
• service outputs only become authoritative after validators reach consensus on the response handling rules

Runtime model¶

Compared with contracts, the service runtime is expected to be much less restrictive. Network access, async execution, and broader host capabilities are part of the design space for services because the runtime is not itself the consensus boundary.

The consensus boundary is the response-aggregation step described in Request Flow & Consensus.

Example use cases¶

The initial set is:

• cron keepers
• price oracles
• contract event reactors
• feed or inbox watchers