If you have been building on the KUB network long enough to have opinions about it, there is a formal path for turning one of those opinions into a standard. It is called a KIP, a KUB Improvement Proposal. A KIP is a design document. It either describes a new feature for the KUB network, or it proposes a change to the processes and conventions around it. If you have read an EIP on Ethereum or a BIP on Bitcoin, you already understand the structure of the proposal. The KIPs repository tracks every past and ongoing proposal, which makes it the closest thing the KUB network has to a written record of why the chain works the way it does. Start with the conversation, not the document. The most common way to waste effort here is to write the proposal first. The process starts with a discussion thread on the KUB Discord forum. Ideas get worked through there before anything is drafted. Only once there is consensus that the idea is worth specifying do you read KIP-1, the proposal that describes the KIP process itself, and start writing. This ordering is not bureaucratic politeness. A proposal that arrives fully drafted with no prior discussion has skipped the step where other people tell you the constraint you did not know about. Once discussion has run its course: - You write a draft following the KIP guidelines. Including a reference implementation is optional, but a proposal that comes with working code answers a lot of questions that a proposal without it has to answer in prose. - You open a pull request on the KIPs repository at github.com/kub-chain/KIPs. - You revise. This is the long part. The draft gets edits until it is mature enough to submit for review, then it is listed on GitHub for review by KUB, and you make further changes based on that feedback. KUB conducts a final review before the proposal moves to Final status. From there the KIP is implemented and adopted, and it becomes the standard. Read KIP-1 for the required structure and section-by-section guidelines before you draft. It is the authoritative source on format, and getting the format right on the first pass saves a review cycle. Read KIP-1. Then open a thread and make your case to people who will push back on it. KIP process: docs.kubchain.com/governance… Repository: github.com/kub-chain/KIPs Working on something you think should be a standard? Reply and tell us what it is.