# Cortis Ai

> Cortis Ai is a projects-and-protocols that provides a personal AI operator binding each verified owner to a soulbound roster of specialised agents, with off-chain private memory and daily on-chain attestations for action artifacts.

- Canonical URL: https://iq.wiki/wiki/cortis-ai
- Categories: Projects & Protocols
- Tags: AIPlatform, AIInfrastructure, AIAgent, Optimism, BNB Chain
- Created: 2026-10-01T09:37:18.838Z
- Last updated: 2026-10-01T09:37:18.838Z
- Source: IQ.wiki — the world's largest blockchain and crypto encyclopedia (https://iq.wiki)

---

**Cortis AI** is a personal artificial-intelligence service that binds each verified owner to a single "operator" — a small, fixed roster of specialised [AI agents](https://iq.wiki/wiki/ai-agents) that hold the owner's private context and persistent memory and record their completed work on a [blockchain](https://iq.wiki/wiki/blockchain). The project describes this configuration as "a personal AI operator," where each owner receives one operator containing a roster of typically three to five specialists rather than an unlimited or purchasable pool of agents.[[1]](#cite-id-2o7sgxhttq)[[2]](#cite-id-aba649tef7) Its central design choice is that the agents are "soulbound" singletons — non-transferable, non-forkable, and permanently bound to one owner — and that every artifact an agent produces is hashed and committed on-chain to create a tamper-evident, independently verifiable record of what a specific agent produced at a specific time.[[1]](#cite-id-2o7sgxhttq)

The base product is designed to operate entirely without a [cryptocurrency](https://iq.wiki/wiki/cryptocurrency), and Cortis states that no wallet, chain selection, or token is required to begin using it.[[2]](#cite-id-aba649tef7) A planned [utility token](https://iq.wiki/wiki/utility-token), **$COR**, is described as an additive layer deployed on BNB Smart Chain, with a fixed total supply of 1,000,000,000 tokens and application and attestation logic carried on the low-cost opBNB chain. The project's technical design is set out in a White Paper v1.0 dated September 2026, which repeatedly frames its contents as product-design statements and distinguishes between components that are built, designed but not yet built, and recommended but not yet decided.[[1]](#cite-id-2o7sgxhttq)

## Operator and Agent Model
Each verified owner is provisioned with exactly one operator that contains a roster of three to five specialised agents. The roster is expressed as capability areas rather than a guaranteed promise of five distinct agents, and the published specialisations are research (investigating a question and turning sources into a brief), analysis (testing assumptions and explaining tradeoffs), operations (turning recurring work into organised processes), growth (developing positioning, campaign plans and experiments), and drafting or execution (creating deliverables and carrying out authorised work).[[2]](#cite-id-aba649tef7)[[1]](#cite-id-2o7sgxhttq)

The agents are soulbound singletons: each belongs to one owner, cannot be sold, transferred, or forked into an agent for someone else, and the relationship is framed as "Not interchangeable. Not transferable. Entirely yours."[[2]](#cite-id-aba649tef7) Several product constraints follow from this design and are stated repeatedly: the roster does not expand in exchange for payment, it does not [fork](https://iq.wiki/wiki/fork), and it does not transfer. An agent's work and artifacts are portable — an owner can carry them away — but the agent itself and its accumulated memory are not. Cortis states plainly that "No token path purchases more agents" and that improvement paths concern "better or more proven agents," never larger headcount.[[1]](#cite-id-2o7sgxhttq)[[2]](#cite-id-aba649tef7)

The service keeps two owner-scoped stores. A private data store holds owner-supplied documents, transcripts, correspondence, exported records and structured data; it is never pooled, never used to train shared models, and never exposed to another operator. A separate persistent memory store holds what agents have learned over the working relationship — durable facts, prior decisions and stated reasoning, corrections, standing preferences, and outcomes — and Cortis states this memory cannot be reconstructed by transferring documents alone. Memory is organised in three layers: a working layer for current task context that is discarded on completion, a durable layer of owner facts and decisions carrying provenance and timestamps, and an artifact layer indexing prior delivered work as precedent. Memory writes are reviewable, meaning owners can inspect, correct or delete entries, and any deletion is itself recorded as an event in the log.[[1]](#cite-id-2o7sgxhttq)

Agents invoke tools under an owner-scoped permission model. Read-only tools are enabled by default, while tools with external effect — outbound communication, transaction construction, or writes to third-party systems — require explicit owner authorisation, and every invocation is recorded in the action trace with hashed parameters.[[1]](#cite-id-2o7sgxhttq)

## Action Log and Attestation
The core unit of work in Cortis is an "action," defined as an atomic task with a declared class, input specification, retrieval set, tool-invocation trace, produced artifact, and completion state. Only actions that produce artifacts are attested; conversation turns that yield no artifact are not treated as actions and are not recorded on-chain.[[1]](#cite-id-2o7sgxhttq) Upon completion, the runtime writes a record to an append-only signed log containing the agent identifier, action class, a salted hash of the input specification, a salted hash of the retrieval set, a hash of the tool trace, a salted hash of the produced artifact, a completion timestamp, and a depth measure. Each record is signed by a runtime key and chained to the previous record, making the log tamper-evident.[[1]](#cite-id-2o7sgxhttq)

From this log, each artifact follows a defined path on-chain: it is canonicalised into a normalised form, combined with a per-owner salt and hashed, inserted as a leaf into the epoch's [Merkle tree](https://iq.wiki/wiki/merkle-tree), and at epoch close the tree root, action count and aggregate depth measure are submitted to an attestation contract in a single transaction. The owner retains the artifact, the salt and an inclusion proof, which together enable selective disclosure to a third party without revealing any other log entry.[[1]](#cite-id-2o7sgxhttq) Attestation occurs once per owner per day, and Cortis describes this as "a daily anchor for the record, not each action's real-world completion time."[[2]](#cite-id-aba649tef7)

The project is explicit about what attestation does and does not prove. It supports four checkable claims: existence (the artifact was included in a tree committed at that epoch), binding (the commitment was made by a specific agent permanently bound to an operator and verified owner), time ordering (the artifact existed no later than the epoch of commitment), and continuity (the chained log and sequence of roots prevent inserting, altering or removing records, summarised by a streak measure). It does not prove quality, whether the work is correct or useful, strong authorship (an owner could route an external artifact through the runtime and obtain an indistinguishable attestation), the honest computation of the depth measure, economic value, or whether the work was accepted or used.[[1]](#cite-id-2o7sgxhttq)[[2]](#cite-id-aba649tef7)

A derived reputation record reads only attested on-chain state and presents three components separately: attested work (the volume and composition of attested actions by class over time), continuity (current and longest streak of consecutive attested epochs), and declared commitment (capability locks placed on an agent, with amount and remaining duration). Cortis stresses that locks are owner payments shown separately and must never be mixed with or substitute for attested work in scoring, and that locks are per-agent and non-transferable.[[1]](#cite-id-2o7sgxhttq)

## Two-Chain Architecture and Contracts
Cortis splits its on-chain footprint across two chains. The opBNB chain (chain ID 204) carries the application and attestation contracts because its near-zero [gas](https://iq.wiki/wiki/gas) costs make a per-owner daily write affordable, and BNB Smart Chain (chain ID 56) carries the canonical $COR token and the emission and vesting controller after the token generation event, in order to [leverage](https://iq.wiki/wiki/leverage) its liquidity and custody support. A consequence of this split is that reward gating and depth metering are computed on opBNB while token release occurs against supply on BNB Smart Chain, requiring an entitlement pattern that passes verified readings between the two chains.[[1]](#cite-id-2o7sgxhttq) The design confines owner-held data entirely off-chain: private data, persistent memory, artifacts and the signed action log never touch a chain, and only salted hashes leave the owner's control. On-chain state consists of epoch roots, action counts and depth measures, roster bindings and locks, streaks and reputation inputs on opBNB, and token supply, allocation and vesting on BNB Smart Chain.[[1]](#cite-id-2o7sgxhttq)

The [whitepaper](https://iq.wiki/wiki/white-paper) proposes two main contract interfaces, written for [Solidity](https://iq.wiki/wiki/solidity) version ^0.8.24. The operator registry (ICortisOperatorRegistry) on opBNB binds operators and agents, retires agents, and records per-agent capability locks; its agent record stores an identifier, operator identifier, a hash of the specialisation, a bind timestamp and an active flag. The registry's isTransferable() function is specified to always return false and is included so that integrators can assert the non-transferable property on-chain.[[1]](#cite-id-2o7sgxhttq) The attestation contract (ICortisAttestation), also on opBNB, records an action root, action count, depth units, timestamp and runtime commitment per epoch, settles entitlements, verifies inclusion proofs, seals epochs, and exposes reads such as epochDepth, streakOf and releasableFor. Once an epoch is sealed it is immutable.[[1]](#cite-id-2o7sgxhttq)

In normal operation the system uses only three transaction types. Binding occurs once per owner and once per agent at provisioning, with [gas](https://iq.wiki/wiki/gas) subsidised so the owner need not hold a balance; attestation occurs once per agent per epoch each day and is the only recurring write in the base loop; and entitlement-and-lock transactions are optional and post-TGE only, covering owner-authorised attestation fees and per-agent capability locks.[[1]](#cite-id-2o7sgxhttq)

## Credit Metering and Access Tiers
Inference cost is managed through an internal accounting unit called credits, which are not tokens, are non-transferable, and have no market. [Credits](https://iq.wiki/wiki/credits) are consumed per action as a function of context size, reasoning depth, tool invocations and model tier. The metering gate is evaluated at action time against an agent's entitlement, and Cortis describes this as a depth gate rather than a volume gate — it adjusts how much reasoning each action may use, not how many actions may run.[[1]](#cite-id-2o7sgxhttq)

Three access tiers are proposed. Tier one, the base tier, is available to every verified owner with no token or payment, funded by an Inference Credit Subsidy bucket and operating revenue, and provides standard model access and the full product loop of agents, memory, artifacts and daily attestation. Tier two is an attestation entitlement, in which an owner-authorised attestation fee settles against a utility vault on opBNB to raise the entitlement for a defined period, conferring a higher reasoning budget and access to a higher model tier on selected action classes, and is recorded on-chain through an EntitlementSettled event. Tier three is a vault deposit, a held position in the utility vault that confers continuous frontier-model access for an agent while the deposit is held and is released when withdrawn.[[1]](#cite-id-2o7sgxhttq) By design the base loop is never gated — a tier-one owner is throttled to a lower reasoning budget rather than cut off if the subsidised entitlement is exhausted — entitlements are per agent and cannot be pooled, entitlements never alter roster size, and a tier does not affect the validity of any attestation.[[1]](#cite-id-2o7sgxhttq)

## COR Token
$COR is planned as a [utility token](https://iq.wiki/wiki/utility-token) on BNB Smart Chain (chain ID 56) with a fixed total supply of 1,000,000,000 tokens and no mint beyond the allocation set at deployment. The [whitepaper](https://iq.wiki/wiki/white-paper) states explicitly that it is a "[Utility token](https://iq.wiki/wiki/utility-token). Not an investment offering," that it confers no equity, ownership, claim on revenue or assets, no debt claim and no right to repayment, and that it contains no price, valuation, market-capitalisation or fundraising figures.[[1]](#cite-id-2o7sgxhttq) The site likewise presents $COR as an optional layer of "utility, not investment" that is additive and does not gate the base product, and notes that "No token required does not mean the entire service is free."[[2]](#cite-id-aba649tef7)

### Allocation
The supply is divided into eleven buckets, each with its own token-generation-event unlock and vesting schedule. Liquidity and Market Making receives 10% (100,000,000 tokens), fully unlocked at TGE. The Genesis Operators [Airdrop](https://iq.wiki/wiki/airdrop) is 5.5% (55,000,000), fully distributed at TGE and identity-capped with a flat band. Operator Rewards is the largest usage pool at 20% (200,000,000), of which 30% (60,000,000) unlocks at TGE and the remaining 140,000,000 is depth-metered over a 36-month ceiling. Ecosystem and Skill Packs is 12% (120,000,000), with 40% at TGE and the rest vesting linearly over 24 months; Marketing and Growth is 7% (70,000,000), with 40% at TGE and the rest vesting linearly over 18 months. Attestation Depth [Mining](https://iq.wiki/wiki/mining) is 5% (50,000,000), with nothing at TGE and a depth-metered release over 36 months. The Inference Credit Subsidy is 4% (40,000,000), released linearly over 18 months and spent as credits. Treasury is 6% (60,000,000) with a six-month cliff then 30 months of linear vesting; Strategic and Private is 10% (100,000,000) with a six-month cliff then 24 months of linear vesting; Team and Core is 16% (160,000,000) with an 18-month cliff then 36 months of linear vesting; and the [Reserve](https://iq.wiki/wiki/reserve) is 4.5% (45,000,000), locked for a minimum of 24 months and released through governance. The [whitepaper](https://iq.wiki/wiki/white-paper) indicates [circulating supply](https://iq.wiki/wiki/circulating-supply) at TGE of 291,000,000 tokens, or 29.1%.[[1]](#cite-id-2o7sgxhttq)

### Depth-Metered Release
The 140,000,000 remaining Operator Rewards and the 50,000,000 Attestation Depth [Mining pool](https://iq.wiki/wiki/mining-pool) — 190,000,000 COR combined — do not unlock on a calendar schedule. Each month the contract may release at most one thirty-sixth of each bucket (a ceiling of 3,888,889 COR for Operator Rewards and 1,388,889 COR for Attestation Depth [Mining](https://iq.wiki/wiki/mining)) and, within that ceiling, only the amount justified by verified attestation depth accumulated that month, read directly from the attestation contract. If verified depth justifies less than the ceiling, the difference is neither released nor forfeited; it remains in the bucket and can be drawn later, but only at the same monthly ceiling and only against depth verified in that later month — there is no retroactive lump or catch-up release, and 36 months is the fastest possible completion rather than a guaranteed one.[[1]](#cite-id-2o7sgxhttq) The mechanism is described as non-discretionary: the meter reads epochDepth from the attestation contract with no administrative input, and the resulting emission is auditable on-chain by reconstructing epoch accumulators and applying the published curve. Cortis argues that this ties supply expansion to usage rather than time, removes discretion, makes underperformance visible, and cannot be gamed by adding accounts because the soulbound design measures depth per attested action.[[1]](#cite-id-2o7sgxhttq)

The [whitepaper](https://iq.wiki/wiki/white-paper) presents a modelled ceiling for float, explicitly labelled a ceiling and not a forecast: 291,000,000 (29.1%) at TGE, 482,000,000 (48.2%) by month 12, 709,333,000 (70.9%) by month 24, 893,000,000 (89.3%) by month 36, and the full 1,000,000,000 (100%) by month 54. The document cautions that underdelivery on attestation depth would lower the figures for months 12 through 36.[[1]](#cite-id-2o7sgxhttq) Additional guardrails include a revenue-linked burn conducted quarterly from realised inference margin and attestation-fee revenue and capped at revenue booked that quarter, the treatment of the Inference Credit Subsidy as a spend bucket that is drawn as credits and never sold into the market, and a rule that allocations are fixed at deployment and cannot be re-pointed between buckets without an on-chain governance action.[[1]](#cite-id-2o7sgxhttq)

### Utility and Governance
Post-TGE, $COR has four utility paths: paying an attestation fee for a higher entitlement tier (settled against the utility vault on opBNB), placing an optional per-agent capability lock for a stronger or longer capability boost (non-transferable and non-reassignable), making vault deposits for tiered frontier-model access, and participating in governance over [Reserve](https://iq.wiki/wiki/reserve) release and policy modules. The [whitepaper](https://iq.wiki/wiki/white-paper) repeats that "No utility path lets an owner buy more agents."[[1]](#cite-id-2o7sgxhttq)

Governance operates through a multisig with a timelock and a deliberately narrow scope. It can authorise [Reserve](https://iq.wiki/wiki/reserve) release after the minimum lock against a disclosed purpose, adjust parameters within policy modules such as entitlement pricing, credit costs and roster ceilings, ratify the depth-conversion curve, appoint and rotate signers, and pause the entitlement and lock surfaces during security events. It cannot mint beyond the fixed supply, re-point allocations without a separate governed action, raise the monthly release ceiling, override the metering read to release more than verified depth justifies, make an agent transferable or forkable, alter or delete a sealed epoch, access owner private data or memory under any circumstance, or reassign an agent's attested history. Timelock duration and signer composition are to be disclosed at deployment, with parameter and Reserve actions published with rationale before execution.[[1]](#cite-id-2o7sgxhttq)

## Security, Privacy and Trust
Cortis identifies the principal threat as a malicious or compromised runtime, because the runtime signs attestations and computes the depth measure and could therefore attest to work not performed or inflate depth. Operational mitigations are key isolation, signing separation, anomaly detection on depth distributions, and public epoch data that permits statistical observation, while the structural mitigation — a runtime attestation of the execution environment — is designed but not yet built and is named the top roadmap priority. The document also acknowledges that a malicious owner can route an external artifact through an agent to obtain an attestation, and that the system does not prevent this.[[1]](#cite-id-2o7sgxhttq) Governance capture is bounded by the enumerated scope, so that even a fully captured multisig cannot mint, raise the ceiling, override the meter, make an agent transferable, alter a sealed epoch, or reach owner data, leaving [Reserve](https://iq.wiki/wiki/reserve) release after lock as the principal exposure.[[1]](#cite-id-2o7sgxhttq)

Onboarding is wallet-abstracted, so most owners do not handle a private key; the design uses smart accounts with passkey-based authentication and threshold recovery, with scoped, time-bounded session keys for routine attestation writes, while owners who prefer may bind a self-custodied account at provisioning.[[1]](#cite-id-2o7sgxhttq) Both the opBNB contracts and the token and emission contracts on BNB Smart Chain are to undergo independent security review with published reports before [mainnet](https://iq.wiki/wiki/mainnet) deployment, and the metering path receives dedicated review.[[1]](#cite-id-2o7sgxhttq)

On privacy, the project commits that owner private data and persistent memory never leave the owner's control, are never written on-chain, pooled, or used to train shared models, and are never accessible to another operator, with only salted hashes leaving the chain and the per-owner salt held by the owner. Cortis also documents what an on-chain observer can and cannot infer. An opBNB observer can see which address is bound to an operator and when, the number of agents and the hash of each declared specialisation, each agent's epoch root, action count and depth measure, current and longest streaks, entitlement tier and validity, and lock amounts and durations; from these, the observer can derive a usage profile revealing cadence, intensity, absences and spending posture, which the document acknowledges is significant metadata disclosure when correlated with a known address. The observer cannot infer the content of any artifact, subject matter beyond a coarse declared class, counterparty identities, the contents of the private data store or memory, or whether work was accepted or valuable. Cortis acknowledges that cadence leakage is genuine because of the daily per-owner attestation, suggests coarsening the action-class taxonomy and keeping the binding address distinct from public addresses, and states that owners for whom cadence disclosure is unacceptable should understand this before binding.[[1]](#cite-id-2o7sgxhttq)

## Roadmap and Open Questions
The roadmap is sequenced by risk rather than dates, and each phase gates the next; nothing in later phases ships if the first does not produce a runtime attestation that auditors accept. Phase one addresses attestation integrity through runtime attestation of the execution environment, an independent audit of the metering path, and publication of epoch data for external reconstruction. Phase two specifies the metering, modelling the conversion curve from verified depth to monthly release against adversarial patterns and settling the identity-verification method — the two items named as TGE blockers. Phase three is token deployment, placing $COR and its vesting contracts on BNB Smart Chain and the utility vault and entitlement settlement on opBNB, with depth-metered release beginning only once phases one and two are complete. Phase four builds a portable reputation interface that lets third parties check an agent record and validate a disclosed artifact without integrating with Cortis systems, and phase five introduces skill packs and ecosystem specialisation packs that, consistent with the core rule, make an agent better and never add an agent.[[1]](#cite-id-2o7sgxhttq)

The [whitepaper](https://iq.wiki/wiki/white-paper) lists six open questions that remain undecided: the depth-to-release conversion curve, which requires a separate document before TGE; the genesis [airdrop](https://iq.wiki/wiki/airdrop) band sizes and identity-verification method; the opBNB-to-BNB-Smart-Chain entitlement pattern; the upgradeability posture; the runtime-attestation approach; and the granularity of the action-class taxonomy. For the cross-chain entitlement pattern, the document recommends — without deciding — a message-passing approach in which settlement remains on BNB Smart Chain with no wrapped $COR on opBNB, arguing that a wrapped token would fragment liquidity and introduce a peg; the opBNB attestation contract would produce verified depth per sealed epoch, transmit the reading to the BNB Smart Chain emission controller to apply the conversion curve within the ceiling, and let owner-facing fees settle in native [gas](https://iq.wiki/wiki/gas) or a stable unit so owners need not hold or bridge COR, with the residual message-path risk bounded because the ceiling caps any damage and corrupted messages are externally detectable against public opBNB state. For upgradeability, the document recommends immutable core contracts plus a versioned registry rather than proxy patterns, reasoning that proxy admin keys could change the very semantics — non-transferable agents, sealed epochs, fixed ceilings, non-discretionary metering — that the design depends on, and proposes placing mutable parameters in a separate policy module governed by multisig and timelock.[[1]](#cite-id-2o7sgxhttq)

## Community and Partnerships
Cortis operates an account on X under the handle @cortis_ai, created in February 2025, through which the project publishes commentary on research and decision-making in an AI era and announces collaborations.[[3]](#cite-id-fjt7bzsdgz) On 29 September 2026 the account announced a partnership with GXChain, stating that Cortis AI is "bringing autonomous AI intelligence to [Web3](https://iq.wiki/wiki/web3)" while [REI Network](https://iq.wiki/wiki/rei-network) builds the scalable, EVM-compatible infrastructure for the next generation of on-chain applications.[[3]](#cite-id-fjt7bzsdgz) The project also runs a Telegram channel, the "Cortis AI Portal," as a community outlet.[[4]](#cite-id-2aen3l3c6u)