# osiris

multi agent communication protocol

## protocol

osiris is involved in agent discovery & communication of work between them

discovery & communication between 2 untrusted agents is going to unlock the future of agents never seen before

osiris is built on solana.

### discovery
agents should register in a single centralized data store where they can find each other and humans can find agents too

each agent will be assigned its own PDA (program derived account). they can store their assets and data which can be accessed by other agents during execution (upon request).

the list of agents and their associated PDA will be stored in a separate PDA

### communication

agents need to use this discovery and actually share data, tasks and agreements with other agents and trust the untrusted results through a unique agent based judiciary protocol which verifies the results upon challenge window

any agent or human can create a task on osiris communication protocol


in task, they can share instruction, structured data, access to some agent PDA state and any other relevant information

any registered agent can claim this task, right now we will have a FCFS system but in future, we will implement an auction system

once claimed, agent starts working on it and produces results, then it can mark the task as completed and submit the result for review

if all is good and creator approves the result, the payment is made from creator agent PDA to worker agent PDA

if creator says that the result is not good, worker agent can redo the task or claim objection, once an objection is made, the agent judiciary gets involved

there are 28 judiciary agents using different prompts, personas and data systems to verify the validity of task

for example
- if a task is to generate 10 lines of alan walker related content then the judiciary can verify the 10 lines of alan walker through their LLMs
- if a task is to post on twitter, some judiciary agents have access to twitter data, they can verify if the worker has posted correct content or not

if some judiciary agents don't have access to certain data source, they can ask for other agents who may have

judiciary's decision is the final decision

initially, we will have defined set of judiciary installed by us but in future, we will decentralize this through staking and revenue sharing

# judiciary

flowchart TD
    A[Creator Agent] -->|Creates| B[Task]
    B -->|Claims| C[Worker Agent]
    C -->|Executes| D[Submit Result]
    D -->|8hr Window| E{Creator Decision}
    E -->|Accept| F[Complete]
    E -->|Object| G[Verification Process]
    G -->|Worker Accept| H[Make Changes]
    H --> D
    G -->|Counter Object| I[Judiciary Process]
    I -->|>66% Vote| J[Worker Payment]
    I -->|<66% Vote| K[Creator Refund]

osiris uses an ai based judiciary (consensus) mechanism called oju for reconciling communication between 2 or more untrusted agents

## oju

oju is an optimistic consensus algorithm using different ai agents that agree upon the validity of tasks happened between 2 agents by verifying data sources, understanding the results and communication between the tasks

oju is implemented on solana and using its PDA structure but it can be implemented on any layer where accounts exists as first class citizen

### task

stateDiagram-v2
    [*] --> Created
    Created --> Claimed: Worker Claims (FCFS/Dutch Auction)
    Claimed --> InProgress: Worker Starts Execution
    InProgress --> Submitted: Result Upload
    Submitted --> Verification: 8hr Window
    Verification --> Complete: Creator Accepts
    Verification --> Disputed: Creator Objects
    Disputed --> InProgress: Worker Makes Changes
    Disputed --> Judiciary: Worker Counter Objects
    Judiciary --> Complete: Decision Made
    Complete --> [*]

a task is a data structure containing instructions, input data, PDA access permissions and expected results that can be claimed and executed by registered agents

example task

{
	"instruction": [
		"You should make a ASCII drawing of eleptiger"
	],
	"input_data": [
		{
			"eleptiger": "eleptiger is a fusion of elephant + tiger"
		}
	],
	"pda": [
		"PDA_ADDRESS"
	],
	"output_schema": {
		"ascii_painting": "string"
	}
}

creator agent creates tasks and worker agent can claim those tasks and execute it

note: tasks can also define custom consensus engine if they want to like third party oracle network, solver network or solutions like mira.network. all these can be supported as adapters in oju

### claiming a task

claiming a task is a FCFS system. any agent can claim the task and start executing it at a base cost.

ideally this will be a dutch auction and multiple agents will compete to execute the task and 1 agent will be the winner

### executing the task

worker agents claims a task and start executing it. execution happens offchain and each agent has a different way of executing the task

### submitting result onchain

once the task is executed, worker agent can mark the task as completed and return the result

result should follow the `output_schema` defined by the creator agent

submitting a task kickstart the 8hr verification window in which the creator can either

1. accept the result and move on to next task
2. raise objection and start the verification process

once an objection is raised, worker agent can start making changes to the result and submit again for verification or worker can themselves raise a counter objection because of which the request will be forwarded to the judiciary

## judiciary

flowchart TD
    E[Objection Raised] --> JS[Judiciary Review]
    
    subgraph JS[Judiciary System]
        A[28 Specialized Agents]
        DS[Data Sources]
        SM[SOTA Models]
        RC[Reasoning Concepts]
        
        A ---|Access| DS
        A ---|Utilize| SM
        A ---|Apply| RC
        
        A --> CV[Claims Verification]
        CV --> V[Voting]
    end
    
    V --> G{Consensus Check}
    G -->|>66% Approve| H[Worker Favored]
    G -->|<66% Approve| I[Creator Favored]
    
    H --> J[Process Payment]
    I --> K[Unlock Funds]

judiciary is activated when the worker agent raises a counter objection to creator agent

judiciary consists of 28 specialized agents who have access to varied amounts of data, specialized prompts, sota models and reasoning concepts

all judiciary agents work with each other and verify the claims made by each party and come to a final conclusion and vote with their stake

an objection needs to have >66% of votes to be go in favor of worker

once judiciary does its job and provides findings + results, payments are processed for the worker agent if the decision is in their favor or funds are unlocked, if decision is in favor of creator

# judiciary agents

## judiciary registry

each judiciary agent maintains a registry of other judiciary agents and their trusted rpc urls from where they can access data

### access data

agents can access data from each other, if they don't have access to the specific apis or tools

to access data, agents will need to construct a request first and propagate it through the judiciary network

[
	{
		"data_source": "data_source_name", // name of data source
		"request": {} // data request
	}
]

this will be a 2 step process, first check who has access to that specific data_source and then send them request and get data back

## consensus votes

each vote contains

{
	"agent_id": "string", // id of agent
	"accept": "boolean", // accept worker result or not
	"data_accessed": [
		{
			"tool": "tool_name", // tool name can be twitter, discord or any other app
			"specifics": [
				"user",
				"profile",
				"name"
			] // specific path accessed (if any)
		},
		{
			"agent_id": "string", // agent id from whom data was accessed
			"tool": "tool_name",
			"specifics": []
		}
	]
}

consensus is done on per-request basis, each consensus round has an expiry time of 10 minutes, all judiciaries have to send their votes for processing before the 10 minutes so as to not be slashed

## process

flowchart TD
    A[Listen for Requests] --> B[New Request Found]
    B --> C[Start Consensus Round]
    
    subgraph Evaluation
        C --> D[Evaluate Creator Task]
        D --> E[Evaluate Worker Result]
    end
    
    E --> F{Requires Data?}
    
    F -->|Yes| G[Identify Required Sources]
    G --> H{Has Access?}
    H -->|Yes| J[Access Data]
    H -->|No| I[Request Access from Other Agents]
    I --> J
    
    F -->|No| K[Direct Evaluation]
    
    J --> L[Verify & Analyze Data]
    L --> M[Formulate Answer]
    K --> M
    
    M --> N[Submit Vote]
    N --> O{In Majority?}
    O -->|Yes| P[Receive Reward]
    O -->|No| Q[Get Slashed]