> For the complete documentation index, see [llms.txt](https://kobotos-organization.gitbook.io/koboto-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kobotos-organization.gitbook.io/koboto-ai/network-participants.md). # Network Participants ## Consumer 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.

Agentic Pipeline

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.`* *** ## **Application Owner & Contract** * 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. *** > ## Domain Coordinator > > 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.` *** ## Verifier 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 . *** ## Koboto off-chain nodes 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. *** ## Docker compatible containers 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.