---
description: >-
  Before we deep dive in the architecture will go through the network
  participants as a contract or as general participant.
---

# NETWORK PARTICIPANTS

### <mark style="color:blue;">CONSUMER</mark> <a href="#id-77bb" id="id-77bb"></a>

A inference consumer is a user who wants to achieve his goal without getting involved in intracacies or complexity of technology . Best UX for the user is going to come from the multi-modal models & multi interactive and inference aggregate agents in future which koboto.ai is a building modular interactive coordination network around it .

Lets take an example where a new user wants to put their recently acquired ETH to work and earn yield or want buy some memecoins around . This seemingly simple goal requires extensive research across multiple protocols, understanding complex concepts like liquidity pools, and executing multiple transactions and approvals .

<figure><img src="https://4179063717-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa91WFeWbDQoXU1jpMABw%2Fuploads%2FpiMQnaBrKOrtc2bh4ew4%2FScreenshot%202024-08-06%20at%203.40.40%20AM.png?alt=media&#x26;token=7e39cf8e-4304-4ae3-82df-3164e516e309" alt=""><figcaption><p>Agentic Pipeline</p></figcaption></figure>

Using natural language inputs into executable on-chain actions, bridging the gap between user intent and complex crypto interactions we can achieve user intent by leveraging multiple agents run by the node in the koboto network as a docker container .

#### **Consumer Address**:

* The **consumer address** corresponds to a specific Ethereum address within the koboto ecosystem.
* It represents an individual or entity (such as a decentralized application) that wants to initiate AI inference or computation.
* When a consumer submits a request for inference, they use their consumer address to interact with the network.

> _`***NOTE — By keeping Wallet(s) separate from application contracts, the system mechanism ensures safety through isolation. Only an owner and the domain coordinator itself can manage wallet balances.`_

***

### <mark style="color:blue;">**Application Owner & Contract**</mark> <a href="#id-9572" id="id-9572"></a>

* The **application owner** in koboto is typically the creator or maintainer of a specific decentralized application (Dapps) or smart contract.
* They can deploy the Application **contract** on the EVM compatible blockchain.
* The application contract acts as an interface between the Dapps and koboto.
* It manages interactions, tracks requests, and ensures proper communication with the koboto nodes .

#### **Application Contract**:

* The application **contract** holds the logic for submitting inference requests to koboto.
* It maps consumer addresses to specific AI tasks, such as running a model or performing a computation with consumer parameters mentioned in the intent or request.
* When a user interacts with the Dapps, the application contract facilitates the communication with koboto.
* It ensures that the correct consumer address initiates the inference process.

***

> ### <mark style="color:blue;">Domain Coordinator</mark> <a href="#f8e3" id="f8e3"></a>
>
> Domain coordinator in koboto coordinates between application contract and nodes (off-chain ) who delivers the output & proofs meanwhile considering some other things in guideline's -
>
> * Ensuring subscription responses are sent to the right owner
> * Ensuring only active subscriptions are fulfilled (remember, activeAt)
> * Ensuring current, not stale subscriptions are fulfilled (via period, interval)
> * Ensuring only up to frequency responses are sent each interval
> * Ensuring unique nodes respond each interval
> * Ensuring payments are escrowed and processed
> * Ensuring proof verification occurs successfully
> * Ensuring responses execute successfully
>
>
>
> #### **Node wallet**
>
> Node wallet is basically maintain by both coordinator contract and node PKI ( public key infrastructure ) as an escrow wallet for payment and staking , when inherently there is a fast finality proof by the user .
>
> > `***NOTE — Because smart contracts themselves don’t have a private key, we can elect an` [`Externally-owned account (EOA)`](https://ethereum.org/en/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) `via Delegator.sol that manages this process on behalf of the contract.`

***

### <mark style="color:blue;">Verifier</mark> <a href="#id-1859" id="id-1859"></a>

Verifier produces inference verifiability by leveraging optimistic , zk , TEE ( Trusted execution environment ) for the consumers in koboto .

In future koboto will implement self verifiable inference through the model which will lead to less compute & cost overhead for the users + decrease the risk of adversaries .

***

### <mark style="color:blue;">Koboto off-chain nodes</mark> <a href="#e610" id="e610"></a>

Node refers to a runtime instance of the koboto application, which is composed of multiple containers working together to provide a complete environment or microservice.

* The Node is a lightweight off-chain client responsible for fulfilling compute workloads.
* It listens for both on-chain (via the Coordinator contract) and off-chain (via the REST API) requests .
* Nodes orchestrate dockerized Containers, consuming inputs provided either on-chain or off-chain.

***

### <mark style="color:blue;">Docker compatible containers</mark> <a href="#faa1" id="faa1"></a>

Components of container -

**Container Manager**:

* Responsible for managing the lifecycle of all Docker containers.
* Pulls Docker images during node boot.
* Runs associated Docker containers on local ports based on provided configurations.
* Monitors container health and logs events throughout the node’s lifecycle.

**Guardian**:

* Validates job requests and manages container access using granular firewall rules.
* Checks if requested containers are supported, origin IPs are allowed, and payments meet requirements.
* Ensures secure interaction with containers.

**Job Orchestrator**:

* Executes job requests on the node.
* Runs a sequence of containers in strict order (input/output chaining).
* Provides job results based on container execution.

**Metric Sender**:

* Registers the Node with koboto chain.
* Monitoring the containers’ health involves regularly checking their status and performance, ensuring they are running smoothly and responding as expected. Logging associated events means keeping a record of any notable activities, errors, or changes that occur during the lifecycle of the node and its containers. This provides valuable information for troubleshooting and maintaining the environment.
* Periodically forwards statistics (e.g., node version, IP address, supported containers) to the database.

**Output Containers**:

* When an inference request is processed, the container generates the output.
* If the destination is **off-chain**, the output format can be flexible (e.g., a dictionary with custom keys).
* If the destination is **on-chain**, the output format must follow specific keys (e.g., raw input, processed input, raw output, proof).

**Location**:

* Containers live **off-chain**, running on Nodes.
* They execute computations and deliver results to consumers or smart contracts.
* The koboto (on-chain) is primarily responsible for managing subscriptions and payments.
