> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cowboy.inc/llms.txt
> Use this file to discover all available pages before exploring further.

# CIP Template

> Copy-and-fill skeleton for a Cowboy Improvement Proposal, matching the section structure of published CIPs

*Copy this file to `docs/cips/cip-N-short-name.md`, replace the frontmatter `title` with `"CIP-N: Title"` and the `description` with a one-sentence summary of the change, then replace every italic guidance line with your own text. Delete guidance you do not use. Section numbering follows the majority of published CIPs (for example CIP-17 and CIP-24): every top-level section is numbered, starting with `1. Abstract`.*

> [!NOTE]
>
> **Status:** Draft\\
>
> **Type:** Standards Track\\
>
> **Category:** Core\\
>
> **Created:** YYYY-MM-DD\\
>
> **Requires:** CIP-N (one-line reason), CIP-M\\
>
> **Related:** CIP-K (optional; delete if unused)

> [!NOTE]
>
> **Cowboy Cloud and Cowboy Chain.** This CIP specifies the Cowboy protocol. Cowboy Cloud runs on this protocol today. Cowboy Chain, a public network on the same protocol, is under consideration for a future release. Where the two differ, this CIP says so.

*Keep this callout. If the CIP's subject does not exist on Cowboy Cloud, append "This CIP applies to Cowboy Chain only." inside it.*

*A new CIP's `Status` takes exactly one of the lifecycle values: `Draft` (open for change), `Review` (last call), `Final` (changes need a new CIP), `Landed` (implemented in the reference code), `Withdrawn`, or `Superseded by CIP-N`. `Living document` is reserved for non-normative companion guides and is not a CIP status. `Type` is `Standards Track` for anything normative. `Category` is `Core`, `SDK`, or a short qualified form such as `Core (RPC)`. Add `**Updated:** YYYY-MM-DD` when a `Final` or `Landed` CIP receives an errata edit.*

## 1. Abstract

*Two to four sentences stating what this CIP specifies and the one design choice a reader must know to understand the rest. No motivation here; that comes next.*

## 2. Motivation

*State the problem in the protocol as it exists today and why the current primitives do not solve it. Write this as a general background and goal: it must never reference the working session, review round, or discussion that produced the document.*

## 3. Design Goals

*Bulleted properties the design must have. Each goal should be checkable against the specification below.*

## 4. Non-goals

*What this CIP deliberately does not address, so reviewers do not ask for it and readers do not assume it.*

## 5. Definitions

*Terms introduced or given a precise meaning by this CIP. Reuse existing CIP terms by reference (`CIP-3 §2`) instead of redefining them.*

## 6. Specification

*The normative content. Use RFC 2119 keywords (MUST, SHOULD, MAY) and give exact data structures, instruction names, wire encodings, state keys, error variants, and fee or gas treatment. Split into numbered subsections by component (state, instructions, host functions, events, RPC) rather than by narrative.*

### 6.1 State

*New or changed consensus state: key layout, value encoding, and who may write it.*

### 6.2 Instructions and Host Functions

*Each new instruction or host function with its arguments, sender authorization, effects, failure modes, and gas.*

### 6.3 Parameters

*A table of every protocol constant this CIP introduces, with its value, unit, and whether it is governance-adjustable. If a value is not yet fixed, say so and name what fixes it.*

## 7. Rationale

*Why the specification is shaped this way. Cover the alternatives that were considered and the reason each was rejected. Resolved decisions belong in the specification text above; this section explains them, it does not re-litigate them.*

## 8. Security Considerations

*Attack surface introduced or changed by the CIP: denial of service, griefing, economic exploits, determinism hazards, and privilege boundaries. State the mitigation for each and any residual risk that is accepted.*

## 9. Reference Implementation

*Point at the implementing code by repository and path (`node/execution/src/...`, `sdk/python/...`), and at the conformance tests that exercise it. Every load-bearing claim about existing behavior must be grounded in current code; cite the file and line or the commit that was inspected. If nothing is implemented yet, describe the implementation scope and list what remains.*

## 10. Open Questions

*Optional. Questions that must be resolved before the status moves to `Review`. Delete this section when the list is empty.*

## 11. References

*Optional. Related CIPs, whitepaper sections, and external specifications.*


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.