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.
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)
Type: Standards Track
Category: Core
Created: YYYY-MM-DD
Requires: CIP-N (one-line reason), CIP-M
Related: CIP-K (optional; delete if unused)
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.
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 toReview. Delete this section when the list is empty.