Architecture At A Glance¶
Last updated: 2026-06-28
Cortensor routes work through a session/task lifecycle. A client submits a request to a router, the router creates or selects a session task, miners execute the work, validators/oracles close the lifecycle, and contracts preserve the coordination state.
Product surfaces hide most session and contract detail while still using router primitives underneath.
Router Node handles request shape, auth, route selection, session resolution, and response assembly.
Execution roles move tasks through assignment, precommit, commit, validation, and quality sampling.
Eliza modules coordinate network state while off-chain storage handles large or encrypted payloads.
System Map¶
Request Flow¶
Gateway or router receives a hosted API, direct router, delegate, validate, or factcheck request.
The router resolves session, model, payment, privacy, timeout, and storage policy.
Miners run the assigned model/runtime and submit precommit and commit data.
Oracle, validator, and quality roles close the lifecycle and produce verdict or quality signals.
The caller receives output, URN, validation result, retry guidance, or error metadata.
sequenceDiagram
participant App as Application / Product
participant Gateway as Portal Gateway
participant Router as Router Node
participant Queue as Session Queue
participant Miner as Miner Nodes
participant Validator as Oracle / Validator
participant Contracts as Eliza Contracts
App->>Gateway: optional hosted API request
Gateway->>Router: /api/v3/completions or managed route
App->>Router: direct completion/delegate/validate
Router->>Contracts: read session, role, payment, privacy state
Router->>Queue: create or enqueue task
Queue->>Miner: assign work
Miner->>Queue: precommit result hash
Miner->>Queue: commit result or off-chain URN
Validator->>Queue: validate lifecycle
Router->>App: response, verdict, or task data
Task Lifecycle¶
stateDiagram-v2
[*] --> RequestReceived
RequestReceived --> SessionResolved: router selects session
SessionResolved --> TaskQueued: task created
TaskQueued --> Assigned: miner accepts work
Assigned --> Precommitted: result hash submitted
Precommitted --> Committed: result or off-chain URN submitted
Committed --> Validating: oracle / validator review
Validating --> Completed: accepted
Validating --> Disputed: mismatch or policy failure
Disputed --> Completed: arbitration / retry resolved
Completed --> [*]
Data Boundary¶
flowchart LR
Prompt["Prompt / request payload"] --> Router["Router"]
Router --> Policy{"Route version<br/>and privacy mode"}
Policy -->|"plain or small payload"| ChainTask["On-chain task data"]
Policy -->|"large or encrypted payload"| Blob["Off-chain blob"]
Blob --> URN["URN reference"]
URN --> ChainTask
ChainTask --> Miner["Miner execution"]
Miner --> ResultPolicy{"Result handling"}
ResultPolicy -->|"plain result"| ChainResult["On-chain result"]
ResultPolicy -->|"large or encrypted result"| ResultBlob["Off-chain result blob"]
ResultBlob --> ResultURN["Result URN"]
ResultURN --> ChainResult
Planes¶
| Plane | Main components | Notes |
|---|---|---|
| Protocol | ACL/IAM, Runtime, NodePool, Session, SessionQueue, SessionPayment, PrivacySetting, stats modules. | Active network tables carry chain-specific values. |
| Execution | Router, miner, oracle, validator, pool, quality, and tool roles. | Runtime role names match the packaged cortensord roles. |
| Product | Portal, API gateway, dashboard, Corgent, Bardiel, PyClaw-facing integrations. | Product readiness varies by surface. |
| Ops | SaltStack, L3/RPC/sequencer/explorer notes, Nginx router configs, systemd patterns. | Publish chain, RPC, explorer, bridge, and service values with each deployment. |
Prompt/result payloads may be on-chain strings or off-chain URNs depending on route version and privacy mode. v2/v3 completion paths move large or encrypted payloads off-chain and submit references into the task lifecycle.
Deployment boundary
Active network addresses, session IDs, storage providers, and route availability vary by deployment.