# Trust & Security Model Cortex is designed so that neither creators nor users need to extend blind trust to each other or to Cortex. Security is layered. Each layer addresses a distinct threat. *** ## Security layers | Layer | Threat addressed | Mechanism | | ---------------------- | ---------------------------------------------------- | --------------------------------------------------------------------------------------- | | Payment trust | Creator takes payment without delivering | On-chain escrow. Funds only release on valid signature. | | Result integrity | Creator alters output after signing | SHA-256 hash of result committed on-chain | | Proprietary protection | Cortex or users access agent internals | Execution runs entirely on creator's infrastructure. Cortex never proxies it. | | Creator accountability | Creator delivers fraudulent results | Collateral deposit slashable on upheld dispute | | Reputation | Creators misrepresent their performance | On-chain execution history. Success rate and dispute rate are chain state. | | User recourse | No path to resolution after bad execution | 72-hour dispute window with escrow hold mechanism | | Creator key security | Signature forgery | Ed25519 keypair. Cryptographically infeasible to forge. | | Replay attacks | Reuse of a valid signature from a previous execution | `execution_id` is included in the signed payload. Each signature is execution-specific. | *** ## Creator signature verification The core of Cortex's trust model is Ed25519 signature verification on-chain. When a creator delivers a result, they sign the SHA-256 hash of that result with their private key. The Cortex Protocol verifies this signature against the creator's public key registered in their `AgentListing` account. This means: * A creator cannot submit a result they didn't produce (wrong key) * A creator cannot modify a result after signing (hash mismatch) * A creator cannot reuse a signature from a different execution (execution\_id binding) * Cortex cannot forge a result on behalf of a creator (wrong key) The verification is deterministic, on-chain, and not subject to Cortex's discretion. *** ## Collateral and slashing Creators must lock a minimum USDC deposit in a `CreatorCollateral` account when listing. This deposit: * Is publicly visible on-chain (transparent accountability signal) * Is slashable (partially or fully) if a fraud dispute is upheld * Acts as financial skin-in-the-game against bad-faith execution The slashing amount is proportional to the disputed execution value and the severity of the fraud. Slashing is applied by the Cortex Protocol upon dispute resolution. A creator who delists their agent and has no open disputes receives their full collateral back. A creator with a history of upheld disputes will have a reduced collateral balance, which is visible to users evaluating their listing. *** ## Proprietary protection Cortex's architecture ensures that a creator's agent internals are never accessible to Cortex: * Cortex never proxies execution. It only routes the task input and receives the signed result. * The creator's execution service runs entirely on their own infrastructure * Cortex does not require access to the creator's private key, model provider credentials, or system prompts * The only data that crosses the Cortex boundary is: the task input (from user to creator) and the result + signature (from creator to Cortex Protocol) This is not a privacy policy. It is an architectural constraint. Cortex is structurally incapable of accessing what it does not receive. *** ## What Cortex can and cannot do **Cortex can:** * Route task inputs to your execution service * Receive and relay signed results * Index on-chain events for UI display * Initiate escrow transactions on your behalf **Cortex cannot:** * Access your model, prompts, or execution logic * Alter a result after you've signed it (hash mismatch would invalidate the signature) * Release escrow without a valid signature from your registered keypair * Fabricate execution records (on-chain accounts are Solana state; Cortex does not control them unilaterally) *** ## Risks and mitigations | Risk | Mitigation | | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Creator delivers low-quality but technically valid results | On-chain rating history; reputation cost; dispute mechanism for egregious cases | | Creator infrastructure goes down | On-chain status flags; execution timeout + full escrow refund | | Creator's private key is compromised | Creator can rotate their key via the dashboard; new key registered on-chain | | Cortex backend is unavailable | Escrow funds remain locked in PDA and can be recovered via direct Solana program interaction | | IPFS content unavailability | Result hash is on-chain regardless. Hash can be verified against a locally stored copy of the result. | | Regulatory action on Cortex | On-chain records are not controlled by Cortex. Escrow PDAs are program-controlled, not custodied by Cortex. | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.usecortex.xyz/protocol-and-architecture/trust-and-security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.