From 19765e42ca760d84c8cc7cfdf2afd309cc0a4d08 Mon Sep 17 00:00:00 2001 From: Ken Anderson Date: Thu, 11 Feb 2021 13:34:50 -0800 Subject: [PATCH] Update HIP process and seed new HIP --- .gitignore | 1 + HIP/0000-template.md | 61 ----- HIP/hip-0000-hip-process.md | 287 +++++++++++++++++++++ LICENSE | 201 +++++++++++++++ README.md | 61 +---- assets/hip-0000-hip-process/hip-states.jpg | Bin 0 -> 38416 bytes hip-0000-template.md | 66 +++++ 7 files changed, 561 insertions(+), 116 deletions(-) create mode 100644 .gitignore delete mode 100644 HIP/0000-template.md create mode 100644 HIP/hip-0000-hip-process.md create mode 100644 LICENSE create mode 100644 assets/hip-0000-hip-process/hip-states.jpg create mode 100644 hip-0000-template.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 000000000..496ee2ca6 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.DS_Store \ No newline at end of file diff --git a/HIP/0000-template.md b/HIP/0000-template.md deleted file mode 100644 index da3b02774..000000000 --- a/HIP/0000-template.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -Title: -Authors: -Status: -Type: -Category (*only required for Standard Track): -Created: -Updated: -Requires (*optional): -Replaces (*optional): ---- - -Hedera Improvement Proposal (HIP) Template - -## Summary -Please provide a simple summary of your improvement proposal. - -## Motivation -Please elaborate in a few sentences why this would be an improvement to the existing ecosystem of Hedera software. - -This could be a problem it solves, a use case being developed that could benefit, etc. - -## Goals - -Please provide a bulleted list of goals you'd like this to accomplish. - -* Enable more individuals to get involved with Hedera. -* Standards can be more easily created, benefitting the entire community. - -## Non-goals - -Please provide a bulleted list of items you're not trying to achieve. - -* Debate or discuss other projects. - -## Specification -The technical specification should describe the syntax and semantics of any new feature. - -This is the opportunity to let the community know how you think it should be implemented. - -Please include images, graphics, or resources that may help visualize the specification, e.g. UML diagrams, flowcharts, etc. These should be named with the same prefix as the proposal, and checked into the same directory. - -## Backwards Compatibility -HIPs that do, or could potentially introduce backwards incompatibilities must include a section outlining potential issues. - -The HIP must explain how the author proposes to deal with these incompatibilities. - -HIP submissions without a sufficient backwards compatibility treatise may be rejected outright. - -## Scope and Impact -Please outline all affected properties, whether clients, SDKs, or tools, that would be impacted by this change. - -## Test Cases -Where makes sense, please provide outlined test cases or example test cases that would exhibit desired behavior. - -## Implementation -What is the implementation plan for this issue? - -Do you already have a solution planned and waiting to be accepted? Show us here! - -Does it require Hedera support, or potential funding? Let the community know. \ No newline at end of file diff --git a/HIP/hip-0000-hip-process.md b/HIP/hip-0000-hip-process.md new file mode 100644 index 000000000..8535d0a75 --- /dev/null +++ b/HIP/hip-0000-hip-process.md @@ -0,0 +1,287 @@ +--- +hip: tbd +title: Hedera Improvement Proposal Process +author: Ken Anderson (@kenthejr) +type: Process +status: Draft +created: 2021-02-11 +--- + +## What is a HIP? + +HIP stands for Hedera Improvement Proposal. A HIP is intended to provide information or initiate engineering effort to update Hedera functionality. The HIP should be technically clear and concise. + +HIPs are intended to be the primary mechanism for proposing new features, for collecting community input, and for documenting the design decisions that have gone into Hedera Hashgraph. The HIP author is responsible for building consensus within the community and documenting dissenting opinions. + +Because the HIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. + +HIPs are not meant to address *bugs* in implemented code. Bugs should be addressed using issues on the implementation's repository. + +## HIP Types + +There are three kinds of HIP: + +1. A **Standards Track** HIP describes a new feature or implementation for Hedera. It may also describe an interoperability standard that will be supported outside of the official Hedera node software stack. The Standards Track HIP abstract should include which part of the Hedera ecosystem it addresses: + + **a. Core:** This includes proposals addressing the Hashgraph algorithm, peer-to-peer networking, etc. These types of features are implemented on Hedera consensus nodes. + + **b. Service:** Hedera services sit on top of the Core node software and provide the functionalities that are accessed by users. These currently include the File Service, Consensus Service, Token Service, and Smart Contract Service. This type of proposal should be used to add to or improve the service-layer of Hedera. These types of features are implemented on Hedera consensus nodes. + + **c. API:** The primary interface for Hedera is called the Hedera Application Programming Interface, or “HAPI” for short. HAPI is a gRPC interface for client software to interact with the Hedera service-layer. The serialization protocol for HAPI is protocol buffers, also known as “protobuf”. These types of features are implemented on Hedera consensus nodes. + + **d. Mirror:** A mirror node runs software designed to retrieve all or some of the records generated by the Hedera consensus nodes and make those records available to users in a way that is meaningful, reliable, and trustworthy. + + **e. Application:** Application standards may be used to standardize software in the Hedera ecosystem that aren’t mirror or consensus nodes. This includes application network software, external contract validators, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of an Application standard would be the Stablecoin Contract and Non-fungible Token Contract written in Java as a layer-2 solution using the Hedera Consensus service to maintain trust. + +2. An **Informational** HIP describes a Hedera design issue, or provides general guidelines or information to the Hedera community, but does not propose a new feature. Informational HIPs do not necessarily represent a Hedera community consensus or recommendation, so users and implementers are free to ignore Informational HIPs or follow their direction. + +3. A **Process** HIP describes a process surrounding Hedera, or proposes a change to a process. Process HIPs are like Standards Track HIPs but apply to areas other than the node and ecosystem software codebases. They may propose an implementation, but not to Hedera’s codebase; they often require community consensus; unlike Informational HIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, and changes to the decision-making process. Any meta-HIP is also considered a Process HIP. + +## HIP Workflow + +### Hedera Council + +The Hedera Council or “the Council” is made up of large organizations who participate in decisions related to the technical development roadmap, treasury management, and general governance. The Council has the final say on Core, Service, API, and Mirror node Standards Track HIPs. + +### Hedera Core Developers + +Hedera Core Developers or “core developers” include those who are tasked with development of any part of the Hedera platform or ecosystem; this includes employees of Hedera, contractors hired by Hedera directly, and community developers who have received grants to develop and maintain a project. + +### HIP Editors + +The HIP editors or “editors” are individuals responsible for managing the administrative and editorial aspects of the HIP workflow. HIP editorship is by invitation of the current editors or by assignment by the Council. + +### Start with an idea for Hedera + +The HIP process begins with a new idea for Hedera. It is highly recommended that a single HIP contain a single key proposal or new idea. The more focused the HIP, the more successful it tends to be. Hedera collaborators and maintainers reserve the right to reject a HIP if it appears too unfocused or too broad. If in doubt, split your HIP into several well-focused ones. + +Each HIP must have a champion -- someone who writes the HIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The HIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is HIP-able. Circulating the idea in Hedera’s Discord server (https://hedera.com/discord) or in an issue in the Hedera HIP Github Repository (https://github.com/hashgraph/hedera-improvement-proposal) is the best way to do so. + +Vetting an idea publicly before going as far as writing a HIP is meant to save the potential author time. Asking the community first if an idea is original helps avoid too much time being spent on something that may be rejected based on prior discussions. It also helps to make sure the idea is applicable to the entire community and not just the author. + +Once the champion has discovered with the Hedera community the acceptability of the idea, the proposal should be submitted as a draft HIP via a Github pull request. The draft must be written in HIP style as described below, else it will fail review immediately (although minor errors may be corrected by the editors). + +### Submitting a HIP + +The standard HIP workflow is: + +* You, the HIP author, fork the HIP repository, and create a file named hip-0000-my-feature.md (where “my-feature” is descriptive) that contains your new HIP. Use 0000 as your draft HIP number. This file should be created from the HIP template. + +* In the “Type” header field, enter “Standards Track”, “Informational”, or “Process” as appropriate, and for “Status” field enter “Draft”. + +* Push this to your Github fork and submit a pull request. + +* The HIP editors review your PR for structure, formatting, and other errors. Approval criteria are: + + * It is sound and complete. The ideas must make technical sense. The editors do not consider whether they seem likely to be accepted. + + * The title accurately describes the content. + + * The HIP’s language (spelling, grammar, sentence structure, etc.) and code style should be correct and conformant. + + Editors are generally quite lenient about this initial review, expecting that problems will be corrected by the reviewing process. + + If the HIP isn’t ready for approval, an editor will send it back to the author for revision, with specific instructions. + +* Once approved, editors will assign your HIP a number and merge your PR into the main branch. + +HIP editors will not unreasonably deny publication of a HIP. Reasons for denying HIP status include duplication of effort, being technically unsound, or not providing proper motivation. + +Developers with git push privileges for the HIP repository may claim HIP numbers directly by creating and committing a new HIP. When doing so, the developer must handle the tasks that would normally be taken care of by the HIP editors. This includes ensuring the initial version meets the expected standards for submitting a HIP. Alternatively, even developers should submit HIPs via pull request. + +After a HIP number has been assigned, a draft HIP may be discussed further in the Hedera Developer Discord server or in issues referencing the HIP. + +HIP authors are responsible for collecting community feedback on a HIP before submitting it for review. + +### HIP Review & Resolution + +Once authors have completed a HIP, they may request a review for style and consistency from the HIP editors. + +However, content review and final acceptance of the HIP must be requested of the core developers, which may include community developers responsible for the codebase being proposed for improvement. + +For a HIP to be accepted, it must meet certain minimum criteria. It must be a clear and complete description of the proposed improvement. The improvement must represent a net value-add. The proposed implementation, if applicable, must be solid and must not complicate the network unduly. + +Once a HIP has been accepted, the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to “Final”. For Process HIPs and Standards Track HIPs that introduce protocol standards, once the process or protocol has been implemented and recognized as official by a combination of the community, core developers, and the Council, the status will be changed to “Final”. + +To allow gathering of additional design and interface feedback before committing to long term stability, a HIP may also be marked as “Provisional”. This is short for “Provisionally Accepted”, and indicates that the proposal has been accepted for inclusion, but additional user feedback is needed before the full design can be considered “Final”. Unlike regular accepted HIPs, provisionally accepted HIPs may still be Rejected or Withdrawn even after the related changes have been implemented. + +Wherever possible, it is considered preferable to reduce the scope of a proposal to avoid the need to rely on the “Provisional” status, as this status can lead to version compatibility challenges in the wider Hedera ecosystem. + +A HIP can also be assigned the status of “Deferred”. The HIP author or an editor can assign the HIP this status when no progress is being made on the HIP. Once a HIP is deferred, a HIP editor can re-assign to draft status. + +A HIP can also be “Rejected”. Perhaps, after all is said and done, it was not a good idea. It is still important to have a record of this fact. The “Withdrawn” status is similar - it means that the HIP author themselves has decided that the HIP is actually a bad idea, or has accepted that a competing proposal is a better alternative. + +When a HIP is Accepted, Rejected or Withdrawn, the HIP should be updated accordingly. + +HIPs can also be superseded by a different HIP, rendering the original obsolete. This is intended for Informational HIPs, where version 2 of an API can replace version 1. + +The possible paths of the status of HIPs are as follows: + +![HIP States](../assets/hip-0000-hip-process/hip-states.jpg) + +Some Informational or Process HIPs may also have a status of “Active” if they are never meant to be completed. An active HIP may be made "Inactive" or "Replaced" by another HIP. + +### HIP Maintenance + +In general, Standards track HIPs are no longer modified after they have reached the Final state. Once a HIP has been completed, the Hedera codebase becomes the formal documentation of the expected behavior. + +If changes based on implementation experience and user feedback are made to Standards track HIPs while in Provisional state, those changes should be noted in the HIP, such that the HIP accurately describes the state of the implementation at the point where it is marked Final. + +Informational and Process HIPs may be updated over time to reflect changes to the development practices and other details. The precise process followed in these cases will depend on the nature and purpose of the HIP being updated. + +## What belongs in a successful HIP? + +Each HIP should have the following parts/sections: + +1. Preamble -- RFC 822 style headers containing meta-data about the HIP, including the HIP number, a short descriptive title (limited to a maximum of 44 characters), the names and, optionally, the contact info for each author, etc. + +2. Abstract -- a short (~200 word) description of the technical issue being addressed. + +3. Motivation -- The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright. + +4. Rationale -- The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. + + The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion. + +5. Specification -- The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. + +6. Backwards Compatibility -- All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright. + +7. Security Implications -- If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. + +8. How to Teach This -- For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. + +9. Reference Implementation -- The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation. + +10. Rejected Ideas -- Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. + + In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued. + +11. Open Issues -- While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. + +12. References -- A collections of URLs used as references through the HIP. + +13. Copyright/license -- Each new HIP must be placed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) + +## HIP Formats and Templates + +HIPs should be written in markdown format. There is a template to follow. + +### HIP Header Preamble + +Each HIP must begin with an RFC 822 style header preamble, preceded and followed by three hyphens ( --- ). The headers must appear in the following order. Headers marked with “*” are optional and are described below. All other headers are required. + +- hip: HIP number (this is determined by the HIP editor) +- title: HIP title +- author: a list of the author’s or authors’ name(s) and/or username(s), or name(s) and email(s). +- type: +- \* category: +- status: +- created: date created on +- \* discussions-to: a URL pointing to the official discussion thread +- \* updated: comma separated list of dates +- \* requires: HIP number(s) +- \* replaces: HIP number(s) +- \* superseded-by: HIP number(s) + +Headers that permit lists must separate elements with commas. + +Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd). + +#### `author` header + +The author header lists the names, email addresses or GitHub usernames of the authors/owners of the HIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author header value must be: + +Random J. User + +or + +Random J. User (@username) + +if the email address or GitHub username is included, and Random J. User + +if email or username are not given. + +It is not possible to use both an email and a GitHub username at the same time. If important to include both, one could include their name twice, once with the GitHub username and once with the email. + +At least one author must use a GitHub username in order to be notified on change requests and have the capability to approve or reject them. + +#### `discussions-to` header + +While a HIP is a draft, a discussions-to header will indicate the URL where the HIP is being discussed. Examples of places to discuss your HIP include an issue in this repo or in a fork of this repo, the Hedera Developer Discord, or Reddit r/hashgraph. + +No discussions-to header is necessary if the HIP is being discussed privately with the author. + +As a single exception, discussions-to cannot point to GitHub pull requests. + +#### `type` header + +The Type header specifies the type of HIP: Standards Track, Informational, or Process. If the track is Standards, the HIP must include the category header. + +#### `category` header + +The category header specifies the HIP category (Core, Service, API, Mirror, Application). This is required for Standard Track HIPs only. + +#### `created` header + +The created header records the date that the HIP was assigned a number. This header should be in ISO 8601 format (yyyy-mm-dd), e.g. 2019-09-16. + +#### `updated` header + +The updated header records the date(s) when the HIP was updated with “substantial” changes. The header is only valid for HIPs of Draft and Active status. This header should be in ISO 8601 format (yyyy-mm-dd), e.g. 2019-09-16. + +#### `requires` header + +HIPs may have a requires header, indicating the HIP numbers that this HIP depends on. + +#### `superseded-by` and `replaces` headers + +HIPs may also have a superseded-by header indicating that a HIP has been rendered obsolete by a later document; the value is the number of the HIP that replaces the current document. The current document must change status to “Replaced” once the superseding HIP is changed to “Final” status. The newer HIP must have a replaces header containing the number of the HIP that it rendered obsolete. + +### Linking to other HIPs + +References to other HIPs should follow the format HIP-N where N is the HIP number you are referring to. Each HIP that is referenced in an HIP MUST be accompanied by a relative markdown link the first time it is referenced, and MAY be accompanied by a link on subsequent references. The link MUST always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main HIPs site, mirrors of the main HIP site, etc. For example, you would link to this HIP with [HIP-1](./hip-1.md). + +### Auxiliary Files + +Images, diagrams, and auxiliary files should be included in a subdirectory of the assets folder for that HIP as follows: assets/hip-N (where N is to be replaced with the HIP number). When linking to an image in the HIP, use relative links such as ../assets/hip-1/image.png. + +## Reporting HIP Bugs, or Submitting HIP Updates + +How you report a bug, or submit a HIP update depends on several factors, such as the maturity of the HIP, the preferences of the HIP author, and the nature of your comments. For early draft stages of the HIP, it’s probably best to send your comments and changes directly to the HIP author. For more mature, or finished HIPs you may want to submit corrections as a GitHub issue or GitHub pull request so that your changes don’t get lost. + +When in doubt about where to send your changes, please check first with the HIP author and/or a HIP editor. + +## Transferring HIP Ownership + +It occasionally becomes necessary to transfer ownership of HIPs to a new champion. In general, it is preferable to retain the original author as a co-author of the transferred HP, but that’s really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the HIP process, or has fallen off the face of the ‘net. A bad reason to transfer ownership is because the author doesn’t agree with the direction of the HIP. One aim of the HIP process is to try to build consensus around a HIP, but if that’s not possible, an author can always submit a competing HIP. + +If you are interested in assuming ownership of a HIP, you can also do this via pull request. Fork the HIP repository, make your ownership modification, and submit a pull request. You should mention both the original author and the HIP editors in a comment on the pull request. If the original author doesn’t respond in a timely manner, the HIP editors will make a unilateral decision. + +## HIP Editor Responsibilities + +For each new HIP that comes in, an editor does the following: + +- Read the HIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don’t seem likely to get to Final status. +- The title should accurately describe the content. +- Check the HIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), and code style. + + If the HIP isn’t ready, the editor will send it back to the author for revision, with specific instructions. + + Once the HIP is ready for the repository, the HIP editor will: +- Assign a HIP number (generally the PR number) +- Merge the corresponding pull request +- Send a message back to the HIP author with the next step. + +Editors don’t pass judgement on the HIPs. We merely do the administrative & editorial part. + +## Style Guide + +When referring to a HIP by number, it should be written in the hyphenated form HIP-X where X i + +## History + +This document was derived from Bitcoin’s BIP-0001 written by Amir Taaki, Ethereum’s EIP-1 written by Martin Becze and Hudson Jameson, and Python’s PEP-0001 written by Barry Warsaw, Jeremy Hylton, David Goodger, and Nick Coghlan. In many places text was simply copied and modified. The authors of the text from which this document was derived are not responsible for this document's use in the Hedera Improvement Proposal process, and should not be bothered with technical questions specific to Hedera or the HIP. + +## Copyright +This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) \ No newline at end of file diff --git a/LICENSE b/LICENSE new file mode 100644 index 000000000..7a9155b99 --- /dev/null +++ b/LICENSE @@ -0,0 +1,201 @@ + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + + 4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + + 5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + + 6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + + 7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + + 8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + + 9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + + END OF TERMS AND CONDITIONS + + APPENDIX: How to apply the Apache License to your work. + + To apply the Apache License to your work, attach the following + boilerplate notice, with the fields enclosed by brackets "{}" + replaced with your own identifying information. (Don't include + the brackets!) The text should be enclosed in the appropriate + comment syntax for the file format. We also recommend that a + file or class name and description of purpose be included on the + same "printed page" as the copyright notice for easier + identification within third-party archives. + + Copyright 2019 Hedera Hashgraph LLC + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. \ No newline at end of file diff --git a/README.md b/README.md index ec67f0805..3cbe47fcc 100644 --- a/README.md +++ b/README.md @@ -10,25 +10,11 @@ HIP stands for "Hedera Improvement Proposal". These improvement proposals can ra ## Purpose -The goal of HIPs is to have a place to propose new features, to collect community thoughts and input on a particular issue, and further to document all these subject matters in one place. It’s a great way to document these discussions and proposals [here on GitHub](https://github.com/hashgraph/hip), because any [revisions made on these text files will be recorded](https://github.com/hashgraph/hip/commits/master). +The goal of HIPs is to have a place to propose new features, to collect community thoughts and input on a particular issue, and further to document all these subject matters in one place. It’s a great way to document these discussions and proposals [here on GitHub](https://github.com/hashgraph/hedera-improvement-proposal), because any [revisions made on these text files will be recorded](https://github.com/hashgraph/hedera-improvement-proposal/commits/master). -## Types +## Process -There are four types of Hedera Improvement Proposals: - -- A Standard HIP - describes any changes that affect most or all clients using or running Hedera Hashgraph, this can be a change to the network protocol, transaction validity rules, proposed application standards/conventions, or any changes or addition that affects the interoperability of applications using Hedera Hashgraph. Standard HIPs can be broken down into the following categories: - - - Core: This type of proposal includes improvements to the core Hedera Hashgraph protocol and services ([cryptocurrency](https://hedera.com/cryptocurrency), [smart contracts](https://hedera.com/smart-contracts), [file service](https://hedera.com/file-service), and [consensus service](https://hedera.com/consensus-service)). - - - Interface: This type of proposal includes improvements around client API/RPC specifications and standards, and also certain language-level standards. - - - Economics: This type of proposal includes improvements to the Hedera fee structure, token distribution, proof-of-stake, and other areas relating to the economics of Hedera. - -- An HRC - This type of proposal is a Hedera “request for comment” - HIPs under this distinction require elaboration or commentary from the core Hedera team before recategorizing or moving forward with the proposal. - -- An Informational HIP - This type of proposal provides general guidelines or information to the Hedera Hashgraph community, but does not propose a new feature. Informational HIPs do not necessarily represent Hedera Hashgraph community consensus or recommendation, and so users are free to ignore Informational HIPs. - -- A Process HIP - This type of proposal includes any changes that affect the Hedera development process. Process HIPs are similar to Standard HIPs but modify tools and software beyond just the core Hedera Hashgraph protocol. Proposals of this category are typically more than simple recommendations, often requiring users to pay attention and make subsequent changes to additional software. Because of the impact in the Hedera development process, these proposals often require a community-based consensus. Examples include but are not limited to: developer guidelines, changes to an existing decision-making process, and changes to the tools or environment used in Hedera development. +See [hip-1](HIP/hip-1.md) for details on the HIP process. ## Qualifications @@ -44,45 +30,10 @@ Each HIP should only be one single key proposal and/or idea. The idea should be 4. Reevaluate your proposal to ensure sure the idea is applicable to the entire community and not just to one particular author, application, project, or protocol. -##### Note -An excellent place to discuss your proposal and get feedback is in the [issues section of this repository](https://github.com/hashgraph/hip/issues), or on [hashgraph.org](https://hashgraph.org), a community forum dedicated to discussing hashgraph; there you can start formalizing the language around your HIP and ensuring it has broad community support. - -If you're still here and think you can suggest an improvement, please go ahead and [file an issue](https://github.com/hashgraph/hip/issues); we love contributions! - -## Workflow - -Parties involved in this process are often, but not always, you (the HIP author), the Hedera Hashgraph Community, the HIP editors, the [Hedera Governing Council](https://hedera.com/council) (HGC), and/or Hedera Hashgraph LLC. - -#### The following is the process that a successful HIP will move along: - - 1. Work in Progress (WIP) +##### Note - 2. Draft - - 3. Last Call - - 4. Accepted by the community - - > Note: steps 5 & 6 only apply to Standard HIPs requiring core protocol changes, and therefore Governing Council approval. - - 5. Proposed to the HGC - - 6. Accepted by the HGC - - 7. Final - -Alternative statuses include: - - - Deferred: HIPs with this status has been put off to be discussed again at a later date. - - - Rejected: HIPs with this status are either: fundamentally broken, not accepted by the community, or not accepted by the HGC. - - - Superseded: HIPs with this status were previously at some stage of acceptance, but is no longer considered state-of-the-art. - -The status change of each HIP is requested by the HIP author and it is to be reviewed by the HIP editors. To update the status, use a pull request. For convenience, always include a link for people to continue discussing your HIP or see the conversations that have already taken place. +An excellent place to discuss your proposal and get feedback is in the [issues section of this repository](https://github.com/hashgraph/hip/issues), or on [Hedera's Discord Server](https://hedera.com/discord); there you can start formalizing the language around your HIP and ensuring it has broad community support. ## Disclaimer(s): -These improvement proposals are intended to be the community voice for changes, but the implementation of Hedera Hashgraph is left to the engineers working at Hedera, and decisions regarding the platform and codebase strategy or future roadmap are ultimately made by the Hedera Governing Council. At some point, Hedera may have their own improvement made separately from this community managed repository, and may make changes not outlined in an HIP. - -These proposals and discussions have no effect regarding private (permissioned) implementations of the Hashgraph consensus algorithm; additionally, this repository and it’s contents are run by the Hedera Hashgraph community, which means they do not necessarily reflect the views and opinions of Hedera Hashgraph LLC. +These proposals and discussions have no effect regarding private (permissioned) implementations of the Hashgraph consensus algorithm; additionally, this repository and it’s contents are run by the Hedera Hashgraph community, which means they do not necessarily reflect the views and opinions of Hedera Hashgraph LLC. \ No newline at end of file diff --git a/assets/hip-0000-hip-process/hip-states.jpg b/assets/hip-0000-hip-process/hip-states.jpg new file mode 100644 index 0000000000000000000000000000000000000000..c457ba68e3c5d103e3f718a7c2b0e9784f6a95ba GIT binary patch literal 38416 zcmeEv2_TehyZ>XCHQ9+NOO&m$6{4tY36(vjk}V-2Bg2U7B!uF%giyA!q$FdPkg{fE z8B*5FSjK}f^M9td-i5yN_I>A^@0{;{zNa3>7&Fg(&wXFZ@Atc|A-^Y&09*Br>mCQF zr~p6*`UjA)z};gACwl-eFaY)d0Kf>)Q_%x7&@C!}8v3&B+imC%s00AIulEChDV5-F zw{55-e}8Co{RE&lyo2nN2JwToX z4j4JQdAfNxx?R~JFS{2wps8y>OL=za_&>m*LQ(xOKnd++z?Qo+pr${$2H;?% zs-<~LLnQ)Gb5PN6P>~w|81(9NR9}y;e+GS_qNbsxqi0~;!o&GQ&Sj?V1fV8$bK8x@8cQ( zv;gX_2Mskf4IK>)4IMolbkH->Qw~NZ#;*s{w}a*D!A3dQe>=#~lTbm=K}$=^0R7*} zyoGt|-+hn=p=Ei9i~(3^pbf!6!vSaj>%`0mN#Ot3Nke}7KR52;U!*l0SyAx#Qz>;Y z#wx2(R^^l3ONS)k1BTd%b7_9N2+quj;j&9%5{wcz>h6hX9%kSZsg5ZI){{{mQ!kML z!a;D344f)F6~GRjP3J&O+ypzw0F9ay8EBo-z+OcjBLkV7V;V#jTrnAt%O9S|U38z3lv{OuklSvT=L5S`QQ2AS(DlXkHm2QuOGEEmc~(MC60Pu+L)29?1Sc{O z=ao+e-hUoLuj`fTEw2KSnGwI8cy=D5L-kuVKX2UUdN@1r$e4lt$u4OxtLF+26~fL1 zvL1JSCexF0s{8W2)a2I}G^GHbrKQn<4AgxDBgw!~i6#`tkA;)q#@LP(6}K=HVHZM~ z44hOKEk^x&A^soPhr^%`-W9$b%(uar7LUw2)F$_Z&Xmn+TKQQo_Nz@>pVEJJE>5D$ z&F%DD{|SEUgb=Qgpkx9Qj-3tF(uLF_15e~@(W~xwA;5Q?%lI&i{O+#|HjZIE$Dh}) zg!Jb1a04ctU^n|IT>*o-sdfzIOvv9d)cfhc7Z=aT^YN|864A-Zb|1274hxfkV+aPK zLPdS?DlGysqKt;zsQIE8(8(QB$Kxc=yx_$WPnu$H%+=B44L6N&PF&fKZ_(_h3#9XR)hA`O^FEfirK#}^xrf3 z|NR=BN8f@yl?x?O;UXK;qHnxjwJ`PW_fArjDHM zAMbb_8~+H{SI=w?t`3nRBr~Z0bQ0CqANXs4oCfQUmgJ(8ZRATIqe13}6PAZUZn-A7 zDoR-qyzrvhR0r*KT(b_lFBc979b9L}J2b{b`b&c?D4h4mDMzKC`pQGMiXTl2%y=u` zj(w!NA5-h>;-vWEpcKuE*Ijf#09P`w`Z|I*2TqTnFs-_vHg4J~(VDY1Z5JBv8v9_1 zfX`muvh!JQ9Hu7|QKZ9Dv31sG)ZR%+$CfRM)z2kk0C~-D%OyM_-5B>_Nb)inuy1v+ z^AQSU&4M{a=qDwRE`Pol-lV#4Sh$4WO7*0B?P_OV1FWQ(C?;A57wFUN^mLJLx()W( z-13p}|A28J6v-5Ru-4~pZ|iI-(U}rHkbR6v-6(h0eH?lgUJNeRp%@B@GTD}mW5uwk zE+CaF@jiv@0jhwQ)_HRtXB(7Vvq!X z>Yh1I#A0MLrwtn2Yu_bk*O8ECe)Mu7OB}t9=@GfZom{LpR^9JkiY#(W_J4X?_i|-$ zl^ON!q>E3&jntcM+Md@6MFW@K9peIwe?O^4V5Nq{_(C|TSwn~nOqo0~L-*Cgs7Puc ztUiskcQIA#1pY*6^BB9Jj%7zJNu)ZI6OnQ%;c!}?VWLQ_IfK#1EW7Pe`I3bHVSiBE zT1T|N;H{UW>WiRDaX+G%5R4BEFMIzvq{{>+5h$CfpC?wHddis$ za8!n$PcYT_K=ZmJke$}7%kz)(3EUGdD_=>%LkWmINR{v3qd}M5UB&R=Y(?}EjMJbn zse)lmQ>W~?EJrR0Z{hDw>QkIj7sJOiyD<`-yU_Ni95z^a#rlPVq?Ydcd#w7*a8d)TO?+5~T7TL-E=m9BTddzC&vJVf~IQ z@l+=1`L3&f(RWzeZp`7Ks>g{m3i;sEdS15(RhRzsS}uESOeA_M(aP4g7*3R~y7lIu zLfDtfGK!`zDk>8DIN)w+@9)Xdo(h$#aPs=FSCVFtCt}69&J6ujL0Gg)#(#$eLVa4d zM@BB$rwlPCs$%fLJ*3RS^3z25hpW%`G)dZuI!ORQHri`SU=X1QZ}WUC6we!uR75>+ zOgq@EFwl_Lv{JNf=zZ;{V;6><`?=0n|uuR#SbQnPN4g0mFpMteVtr}EKCivlZeN2u4% z?!bdwR7GPh$Tgkx837i}07o_&r7>CP%FbjN@k~TMHTP~ zA7MzIa?D_3z|Pfmgph$Pi|4UW2$;s-MU+3^G*KYa$-XzQ#)<#1lOU|&z^YJTpLz!FoNFxNo#L=qi#QZ;vjTzSemnNz1&ddO`7K zRm4Z@dJmzdnlSu{N46$W#~)GC_Rsgm1e3NplZ0{A&+iWt4e-Y+9y+^c+nQD-HqV-h z>@_j?#kl`Lfy*27D%rCmPY&=AFp@N%P(kR@Gbs8h?MGmcJ{U7v=r41P@c9(_NzcVD z;m%L1lN@5t++A`9Uc)$ws9)tb532Q|Z$K_CJ!F`@S{_7?rH3{S6PBZrIBTUJ^_mt+ zB)Vpog^858UBfjjv%DGT=Zek>T4d#-nh(ielbF|>gN`R4Ve_M>zg$KIby((Q%78Qb(*WMFAekJRwQZx~!LALzHHO56%s6kbx_h2sre zoRzZdDRPzl;?^stgdeZG-6AV1F1II3ew(N%V^**cz&*2Q#1Me+Ae~GZg{_CDv66wV zn6T;L=^C|zWI)0I&rWLSpeF;9%?)02i+{A~RPz$I&=-U8a}9#9aNc1aqI>R?<)NPO z-URN{H+P<{I#oy2D_m>cl_EN`Z{J}tZ&ly;c3=8n97_9Lm3KB#_j#|P3>@BBbwEwQ zp(>7N%>Uc_ zi`R=h3Ef=tQ#2le^=>RrUK{fYp4AranUAH;gPFcN3{xg5t*6P6gr_mCg+BPxP5x3P z?`#nTWrJ{|3g2U9QO);A9WJy>Wbb)gPWBsLbQVx(Xmt^9u({fhd7kUlcD8!O#c^l_%{7pL{+mc+{LsCzf#GnH z>^q6KMb!fj`X@`A^qq1)DCS$L*2yYNepDUv{va0HWF1z6f!>Fvn0|CETA0KOAu-I= zJEkfNo=g_IC|H)4;RdGC{HpAE@4kM#a^!RLN8P6lk4%p<}F~e1Ti^=YCfH;_aNLPjKOv1ow*}k{8Qk6S`fZ?qDWfpBZ^LCXmje&O4>SE_mui zFVbU_eLMWp1#X}67h(K6b(CGKe0|MjMj}<;5IE+LtZmowgiDVBT*kkj+#|x<$v}J# z7)k~%I0T^<$3|6_SO0d7-u1uQa#K737&MYJy9LKwGsK5y53X{?%hjvHdJC!?#$wc) zje0K^%HCg4GkmC%c2Qoh=tXQo(hfTv(Lkx$RY{r}4Qv6*E`3!xjRi{7Lr;={u|-t9 zIjL1+(LxQ%>4Vu)$w2e;H?TG2$$BDcq67gY^-MyLL63O{<@vU2(q!P>MVtePOU0WE zz=~1On@U3xXeL-dh;7SA2T{^^*fLvC4w|? z_q)*GIt$kkqS0kpofz3mwKpY!K z-G_d6SeOEFY#cg-acmg14K!c?0%JCgJqFw`YzPp7Li>$l-~8?@%~7o4f6sLyv1_}h zFs5i+;+*x{;+@@|gW8SN%FoLypT^n;B6i``bMUQPVS1G+w_m^3*%8PlHL?2VT$25^ zA}SKbtjzLe&w@+p*C<~SbY?H}QHcpdc1X=`+qIt3b?w9Khv!Yl zu5X^7|LL{yFS3OHl`r!ws?IIUh6+qr(?#m^`ELi4PT);b7;aX@B{vD zdFLG=e6>!Fw>@X-`mGcwvgYaV@b@g-zigVuxC=)pb&M-7zbXI5s6)*-k@2wX{==UF z)MGNMAX~cuS=HVI{!&70hy&Y*0B;6=p#(z;ata#};2(j%G{Y0c5CgXf0j4;G4d8DE zJL+HNI-f&%4VbHm?+EsE696rzXDj8xqzjjr`3Y+NUWFf=74~0_HR-#$SJgs`Wh4Mm z6!@P?$27=2|FSFjZ>{h@+z(|6P)reT0YY5a1&2`d;vk*xI)Y&aiYj)MLMd`X2RmxA zl4%23_ebLHXKs^wzs?~|2WcnrBrddW?U3w3V+pja8m5-l)L#o}7`*IpEt0JYFN$&> zaKfEE;m%rBB7Yh4=w{r3q91IZCc_m;G&O3*qY6q|&1}9gd_S|$zXv~mxgozfxWC?z z-@>1t*pR(Na4*K-oLZ|-mS6T4>j86mTK0-x$@u>RGh`_Mn`Olf!|_TnSiTE*`qYPrKqr?1 z`h2XPw{D;hwjyzM)GBg~Z^zJ%Knv<5+M5Sx@ixOYRQPz3o?K1(+V(k(CGNgF$aemL zoc@_LzVR_D^}6f%>f5GQP10W6w?tGJcX{#IQerincK9bKS~G%TweTEnPp_Q`cWxh{ z-EJDX$tlG2tC9>HARIM34dM*DJh|r))Eum#8}b-EXTru-1Z2)jXAJu92h6Qhu6Eelf6AXK#UamJ~4) zuMbgdy+-v1b_h#lK$u-T`eUy@1i`$&hn-tjKJpFMq&fy+n*shU!}HD>5Cj0Bp39_^ zjISWyhChHV<#+7#JBIpqe20ibbG$3RX9W=j1`%B);{B`_B{?B~2lI zOv0v><8ujjz}a*DI}!PHeKy>}LNQ1EL@g>S%1eA-%D3N6k@18Lg@Yh?LldWSy3$pMIH`;Vuq?hiN3n?uX%|W~q3)^C~LTa~j2GqbvR<%Zoc( zG94E+ZS=)ymz`1d#V0wsO`nfV)of*d_-in^G1vYP!tgzs+>mQ;Mi{POWl((5LJQJ()4d{59h zU+Ua1dw0yU`X55>09Qs1X%XH;j<%;q&A7Q%OHN~kgX}xE%?dla$e+B$x2PI)neF33 zk#rH;=)pD1>rnyzo$uhxwRjZa0T`_uS!Ip0(!{k5apRgQ{4y<_R>PnBS((M_Rj$c= z$UpF`qP$FVdS}>y+qW~G?x%AD<41F6*~bjSZPajXHCF7b1CzsS>g~=x>QzZ*$^wZG zJnWNN-JFH02rVqm+n;3VOI5r%$?Lc)K)odseTXDS>V^JLI|_LaSH$chUq{-VUe8m# zvv*gw!k`)aX+_%9@f(-VhaPW@6OXX&s=7}dj1iNFNQ9N4XF12L+=B8)(pe`gP39Uv z#Yo@0@@K`PDqf$$=001~ww-EmQE>kf!gKWYms6dREdVUj(`>xBksSh;%W@vzPLHzQ z^tR*;sdB~*HwxH?7g$fWAPCD>;D))a&Whpk(zo683*)mxv?{Kc(gvz0feCo;(e#-W zoN6PA%U>p%6W*=RTo!sV=vYNnS@8JFG*z9Oq{~UCwu&cML|w8vr)rV{1o$}|^LGbD z32*Qwzf`L|1A`r$M}=T@{#;e~qt_E-GN%Q^tP1!|tyPZpbbqL@9H?F^C{jK!l2apkF`Qm5i$)Q*qOrc66(lwM4gadnfp9eGo0r-qnu-qi+bHb531a-I+);dXD_FZ1Yd>2=qE)E7wyUQwdg z4cp+mtmZEvr*HC~4RG6L$Z7GL{AVL7_#oLiZZpK+?j_Bs|A34BuMSWW^vuz}1CBFd?=L3Ac3&pS zj|^V3mTOe5ZM&|Nzop^@N=AQg^qs10w;#2ai_4U4JHrGlp*Dp&OCzunZ(?#sEqaYp z?GPErnfN1J@vEH!#|X1{o?L89|Ei1riJm0`cK;XHY2V0H0p}E7yp#JQtHvw058dbd zg1DD-*~k73AT}DH-ke#j3^GUr$;?z)KO%~v@qH1BR{A=4hcVwm|Di47BFBSeKK71c zQu>)%#B|1~PK_nd4VQ*S5G{(Vk&ac}1&ZQ$rG(LgJN!hA`;OzbpC z-DP#J>vRS`BYIA9rycruURQx?sgWC>JFA^H*qV(L#(xf88Z^^$Lb_wEt~^yONqzM=L%^>`?F{UZnT z_ui)ZCZ4AG2jdI&s4By?14Q_9Fc;6z3}aW{qcyTFH>%>)f?~NYGB~vt<$z&6?Be>d z(tOO`x{Yt($*JQE{E9@6HAzI==UNmSNdO7MKZpq=?#7LNK7lT)sCs8*`Yd@(?`}I+ z$;pb|pv%#1`K8j0clW+wz?2y=v<`EVsKC-Oxw=D~wd#s^m+0p3G6T~-3xNp7VZ2mj z+G~e6z9P?ut`8P=NY+}j*0xGsIZ}7aV+0D*2JoC%xp4KJh>`&)(imKhDHvJrRu|Nl z(q}!{Dau-f*JAx7(9cEeok2FMr9{QUFF;~NNhARB<3mS!dd3r9;sy2ba-roi`X)VJ zE@N@ilgq3=k3Q&n?bMHdc$O~O?)L4RU8;z|p{$exIomYngt9OE>wJL5AbJ^YH))L2GR)oCq?Z-K!?MlR0MLML0OrGG}HTDYQQ)tLX zYFqVxIW~BDR67V_u?$03o5Rjm1evP{HRgpH^MsFUiM<=LI{WBN>Jj%$ap z{V8g(XBisO`Uw!aP`XXL5nk%U`@u_jeZ64RE4llLyN?#>x#(Yg zQbc{zye3UlG`v|Y1!_O+$eZdNIsmOo%O2Sx-nCQnqzh597{_;_y0-g{ z+inqPO5vhyIuc6;99WebVC-u8xZ%;HDB=-3gCSl`38%j+U$Nj6Ci3{g4qszim&>uQ z<6LgPHc3t8db0CyaaLXid#VDgf9QZhv^T{IApJ(&!jf&!56(K4S~@2wWzv;A7reM4 zU0A5q);hm3?|Pg1T0%<)ZwBd=z_plBG%cdl2uv9hax((2je8pVdgPW}>2KkUKa`!9 zDD_zkj}=Q;a1XYQyHA^5Jh4Fp_bZXX&Ic~zBx+%0ZuR*w!O$h7%_=zOr&v8?y_3(< zSZKE`c<9xb^O!R}HG6i?`}2lahM9Lb*oe%d0iq<%CjI^it}N>Uf3L*|pPgSm$*Hm| zlvOjFllnkGM>b|qP(oxwwI+dTDIf|`gu(U0tFD1BNq+_t@nj$x;@Y6{2XKF1odzcT zJ){ZfRfslwGq3*c#oC@#!44^V5dX=?O4(uj&5Y7szrYBfrLS-)<>fX~Uwy?Br^|-Cvty=@u4pmKrC;hy4bX(VbqMLFDydo_P~_LTs`hm za&*2`e_nY_O zLBhg4is)eBZQXJXYYz7gH3grSE`IvO&iV~5@qiJ~G6G1_eECWU#G@gWSk#}w68l24 zGse9gU6MZYki|`5n4yYyyL(_;J9b@xjwVib?-e@0kKvgAasLKP-%RS7*$~m7)Gd%i zcY`QVq*Hk=vfgx`0!FB5yfpDJexFk*SDKUcqy0gS9U9kB^%DLN^L(7h4{5{+5Juc2 zNlCbFYB-_$;|VTrHSC8YR=)(}vg$0aJ;+7qTT}3^w*@=XwqPIM8%x~1ZR@Lvn*AlW zj{rf*%k1FAIfz*f8-|$WG>BPl{1)%F3`6uX2O6T64?*;D1QbDG+z1!fQ#{%GD@Lnd z+($~{5>p>K4Q=alb#W~$lVWrTL|op57>_u5bHB=7mV)f9hj&24%N&K!;8*=haw|h5 zw?x?-X`eQ6zc+>CKI#UM+=foW#0%e2&<&S@K+UYI?e}l5>Nea;)4a!4Y$Sg$kM;U!n^|PdYW%~sowx1INvHg5mo95tq{_!){xe2-1{B%|% zp7k^m6++PZDc&%!S^(itzuJ@dHHCgxKv6buWT9joFPK@sYAX!fpB+@IKsED6xyL_p z`^N$2#(9R}HY}xYIKrlR{=pP~#}PKp^Jy5tcs(KOc${HSHM5D4u0%b?5n#(s7YR@g z%tW)H&ZD8Y0bZ8gEElCt-Q&-N*yW<~8aJiRV~j0ScC(ZFQw6}U!Ov#M^jlE$UA$VHP6q7ID?8O8^IS2!E}d2#u<5P<^?)KdD5NzT zm8+lIhM+gl8`Cl5nC!Fku(5RE-73>w$m}d|FnNC{E1w!KS0#Q zH#e}eA@WbZj5m1MjojNCFD*saz)@b-D*f!#Ks}pM?8-%0Px1;Bpi8Whfp8Sz;8gmm zEYm7ABsd~G`N}gwik=G&VW`EyLlj(i)|SFELflJ32PDd!th^2pjS#)<41?w@Djk|L zNCRfj)km4LUJVGt=GT}x0qF`;aw!`Gsv!P>SoLqoa{qwbz<)z-+Wr=DbLiN0Is`)) z8GzL6!l?K6#^fL|`&Fp)^{=qX|28$$zp|8MGxGZ{q#v3m19V7NP!2C;lB5ZGjLorw z`KJPTp2zj+^|;98>To9rnBLkV6iDxNs^J_D%|VfunpHFnC`f0{PFbx9?`pB#GcjO}y%Tc!)sBb{nE@K|Xgk<@ zNETk_c1we!%4wvPdD`W4P4y0I(Gw2U_hMb-)DGoX>y_kaww?~08%R(MZ-hJyqkyCP7K5az)M`?jGy+$XB z8iN?@(P0@(N0?UjXok#4wJy2QU8*1h0%}rt0siv>uA$gD=ihGQI=d+4fyNIJIF`;{3P3S#V&v?u5?mHI9WegW2b*szZpQert2MqzZ zidzmKDi`cJ)8n#qNDm{$FV11%{q?}$uZ(#P2Fda7jvP*Pqphc z!mfvg-miGKG|Q}qH%;)$pS=FG_`=g`yhi2?@z#4(^)9k9sgJhvg$E|y(muP5YAKa_ z9)45fGCXuhrW?6m4EH%)L5>~7OiGurqRw4MaKq|k$hmeLFeS8N2nh7SU zF?bA0ub z#87N(qm_j;hh*2x55YDBdqc0;^|MX%?_3LaM4rAEQh%3smVW3={YRBIMziPG#zm^u z2rgif@911;nlwH%3aRDmC!91Yb9Kwf;#|u~d8fVRZ6-4h^eu9td;6Ss|5E*V`|W*) zVTSME;-D6x5%e1!)UFpXWJAPjLRngLQC#ccz9oZ$E{lbyeD0K2YL1#FYm`auqEXwo zMP;`{#8@%f4IWzQmm9XU8_6)HE3L-qBa;+XWZQWGq2RPr)c5SO=kg3wp%FNVLC)(gX2wVAkP)ZxNf+~%zi-$DNw^PuY4a`gwH zs;CvztUO+$!JX8ugx>DY1Xj8T?Dupz*^6*-anN65)kBDIyiU6P+E_p}VC8TeJ#djF zkcuGl2c8>(Q7uaFOAu@?jvIo7s=T>(e@d&)X0MY(k7rA{xd3|wh}bW^*XI5H=NGaM zCIkS{Hy_*0XkfRmKSWR5rzB*IgW6;uSx*i6Dq(fChw^`+%)ldGP| z)&=S|DRw#8#>}+at60Qu7X@-b5}pEb0czsR{JRM@r)%kA91& z?Cyol=RcoJ=Y;LaEsL$Xd!kOsD(C6bIMH3(C2dZ71g*Aj=6wFJ1t{pe@DHHRA0$bC zh#3BnJRbF3Cj8y~3iGYnpe8T&EYcy#z?ux?zZh}Nolxkmzbk`1gCeoo>}sn~;1<%0 zQTY0;>&2uSbbeHni#Lb*g*Amre9gix4VTKz3>HsSB!789LAh={$ZHpG@9B9Hd|qLpL!LLz;vzy{^~JWf zHeIo}lg-46S5zvN=7Qs>TXSx1NMS3dBv zj5M5Yn%Sx&?SJnrNf?yEIy4st57B`>SpyR)Y$+pX0cKx)y8!{WZlcN;pBCvhefe$r z+jPbHdKE{6MZcEJ_)xN|DD>hO_Vw@ZC(}yqSW=A@DjK%6n%h}`ke)rQ&Wp3pdN??R zxt726nSS1v#mT~R95r}duBiA*9c0~o%`d0Sso?t1IRhCi|yw5gQ~vvY9dk&0Fy+8|NrNW8mQZfKF)WM!2y%nbReL;@~3sIx`h5Lvt$h)V_yT-}`tYK1D6FherMDAb? zd=SG8mEBUURN%D;h9G)$*8Z(k`+Y==4vJ|K!?Jf;`2J3U6|H}USnOg+6ad^o<441~to znSa(c!dldW=pXfPOc6WoX$)dgxH?0+Dhe{=rUq)IT^U<)Y}VlocH$eck3TB zSW~VZ>>qgkBq|xt9;sZd{&+pRTCg4W`FNLNyAG(|#4ILIl&h3LT}vPX>^xq{%u)mg z7B1R-k~`w7xS58AN38Wn)9w@IKns82cV#fS*AP5$ywoFq<@w+zAGBkaCmE1(<#ZjE zzhv9b6VIEnjOsi)Xnl6Vl+#dcVV{q9qV~OE_-)@X5q1{ZNJ zC^RY;5jUY^d8-`jB4BN^pf3;=YgzFgyYOW+WO*iPww%XMJh@-3iAm@Jiyk2S9Y8Ms zIRIJl{un$^gN`JA>4`I%qlyN?D7h~gX+C{7c&XCl!Qv!!sY*kMA?M@6Z`!!FQ#Xu> z_2n5K-i`{a76uuxMG3OOP=_f?hhWeCPtNybJo67+KIhYK0_E_u$7D^o^*Q3WSVou@ zHn9_wpsX3}!_Ecxi#r)R!a1rGa}fCkfp*Vt^_i50tkR~MY*;l#sF9e!a(D=uj!1+1 zY@NuzB*z4z^g4^OpV~VL`wHre#AZ62xe$CiLHdzS(_uBUJhK>52NVS$J#fs}+-T%! zFT$X6gE0TQa^^{bn7>!g;GNS3yI%Ded#iGmpOJh6&`<{)3fzDcQkt%9s)&2{qhh!p zuxS4>rEou6vbVxLHpfPKRjsgIQN_J>TDi%Mid9*&D}7D#UDc6XpFV-Yyxr#ytWPpr zcqSf6ox@ne;NCnmys^yh{|>0vS23ybG@*FX^!k@zAGWNVslCk}&R#Ae?X_2A7k%=?yr$1j(y#&p?Gck5`3Nd zzY(qe6|u&{h^fl;9Zm zbQIJC>;n9Ns-mSPl~D4oELp!gx@?hSPUvowZClP;(USRe_?TI=SZCSYaXd8b^c z6Br%Q0V)w4hB|>cX%poQp=M>wl#Y+gXsB6P=QrBaJ{{^<#tU^UEPDXMwQE4l z%H*JCWwJyQs57MAH_q+f*ZE&HpPO-or7;p4$O|DbHKaX;0+Xx-L(|3>SGC=5MnYC*L)C;pF z=6n=?(J#$OWFDmtefWO&hVne_oKnp?_1D<}D=u*@2Zt)}loS@l<;ZSsB@n#;6DOH)u{71{&sfS>a*q<4{je>HEX+UYSE z-Fu=MKIcUNg6UjxgNkbcYfVK(oMIv~MR z5j5LbM6joeHr!D_(Mo0ym4}a%4wn8^tH=mvqW!r?&+T_mJ2x-NVSKTJ%OPq|IUD!D zC7Uf8taa5d9SR4s%}irk8J~q1Je@xoSMUnuJ+7MQmL&KrgFSPi_#TpO&Cp3$37;4` z@=~iNO$z7N5uWklS!Zrv!H)8fS?O3CmwchN(&L(scNlP83^I@PhZI_DpVC@S$JCQ{ zsxx(aDRl0@yS=v+;2hL-CmdBjpE66$`%Faqmw^@WO7$T}nrTa^(K(2tFT2rI)**zT z!5SomFTuDGHm&V1d#Y4(`iHD0x>hvDMbiv)gG*l=3&dyYO$&aMylguN=|5A>;)`pF zL)G`=6*~qLqkZeIA6uVU+oqxPY3j{xJHOcAV;^Qta%)D700%PIEh!G-`?byg zg0mwr7-eh^8fqL8`tVw^Vo!Td!3BbN$c5gLyR9x}?&UcCgKs*O=`QCHu7B;wx=HQJ zJ@+$u?BB2c`zZc{?=;`4LV-U!@3VgZe;9D+wF=a#nIho#wUP;PKaeBqCF()AP6y;( z-tH*QkfQK0sA+$36hz06fr+hVZz-J`egf6$L%*ehBz`{y75!MZO2=jPBVzhLAw1fo zI`}WptWf;?Mp@8zNBSdNi<>feHbhPB@;PPStTZ+~;NvM7xBU51y&|p%SyMd-xgW=LoFrKcz?y0n(X3H$| zPS~!k=GuaT0}AB64rv~KP9TO0omF1jPin_7Kx%Nf_1kJLg#O9yvbinJ6-pJR819?$ zwQ5S7YF8UYH2H=2=uJ;C?%3)9_l8z93YXpt$Cat`Ae2Yp?@^^1SebWav+$WTw^RbE zVnDn(;gbu5RLl;Rd)umN>n$=t@ajzx9Te-qaiz6rR`tR4T!_U;jLvm}InP(6m-z+u z%MgdQ$ytAIj5#LQM6!HBHwo(vDJQ#v2n$Kco-(&)f?tVVb` z`>w8n%SDSii!lDlnNBUC#cQ!&o>Y}{G-#cz-3`H0DcGyZ)S1=Bpz|677>WG_g9_}b zfw2({GbdGIQk_TrjE2a-WkHUs_9khs4;(#ZeLP!4r(#d~o>J5?>yK=+D&NoYDQ230)85}yP7Jn zE_=Fk6Uv^CKPyj=7O_H%o2Bu=_KQgEzf<>Q4>Q2GCd2ioauc(0vzw4c2~tay!e>R- z6p<2m<*2gVo@g!`P_F)hfrH-N0c&(pj@6@k+(EUwnI64J+vSo0)R;{b{vhSW#{{5p zhI9SPBg^$KP_$rioj(i=%{$`Zp-gyMoY7CIklN{(X`f&ZRY-NeA#U5klo2cpxw1`0 z`CHNdU#tEo>Y0vC&s3?yodt_BOmBo#4Z7~%!u0lH6hjzy1Z!$@8D}tsMNmJ=gFeoJ zuaN0K){jwdK#(^6%>J#k_q(IsLEYh9 zItpYUm5!SI#>&7oh%{ut0xv~sK4b;up&``)6xDqJ3aVS)4=Jpm9&*Ztzl!cRd*lG9 zM>nP!Duy4EfQsRFQi|c1C=tm9FHb4|{6X3N4-{nH08b9H1*XtnRm_Kby6nbqo`1U_rjnhZ1!!;l-{*1tzz<4W5 zAKo03dD)R?$sTldK34cow~ap2Y+vOKLS53h0o$r}+ID1^3Gs{dlx4|ljQ^TytFOzE zb9C8Ii^#gfWh)bX|55FgBd!6-l*r=aFfXZ7{-T53(Nz?-he3of>S2nAZZZ7dWST|OIBU!vTRsL)(G z&&%wl=FKxj7|60aFZSwT;K7dPAtk??B`<*H&}k54`9uw@WBnCwM0kFo8A9I+u%bgJr%v zeU!M~5HlY*NTooLV%MO{9cFW}!#9W6@Cqm4*|9M(_noXTP@v*n_C|L4W}V<-NZRf2FD)X#7-z0MQtJv#W^)C@F{B)%J) zoE&ZrE;`;C z3<|TIS@zAv-W#|iDR?h(`^7k)47R|(a6}s&)8G1;{rd;)e9bJ2S9Xwie%fI{y#}vW zkb+qKs3;C=jSOsq+6?ue7x|ngn4nLo`3WZkwfO;xP>pFkUmJKh)Y|MW|FwZfwE8OR z9HoJWpq7H~m>tx>&KY0Dz5IWPx_(p5{x$0Qjj;F$)DUi)6y2=k>cs(`NDk7))Z&o=@((dku~4O z1d09b<Al zewC=;D_am%(&@+Q@!33bL>CeK;El}PK<6^RxrE$@-Z zeeuEmq9!fl$D*q>=Z}cdEJFFl3O?7r6%uU(EEz_n)06loc~-US<{~TUKK3Rh&a$B1 zTh2D-o3~R%UP;sUxt)!_V`|=SedYd*Vnqm!l^>-`EXNIKgYmer#(dwA-G$?R`o{Rm zVTAvXud4kG*8=J4E``ER)UR)sajZD5Sv2iMopH=yhq!mgS?{BLq@Dg9*N+FI=(Dc- z@8Boq`|y~}7bv6}$lkpvLCtfn1m%gl;{2+5KXDtF`he6aEC!a|ceL4!cL*UmJ(#@K zmbMMQ7q>neJakt)N(|rP<(RZpPmHCo>h1vQHC3zM6D;~hI=!0EnBZKP4Hr&5IveUj zFWV=OP#Cq(`e3~J`2`a#nw?_Rj6*(`lb0+3A{1-~OW*~uw~}zm%~0^FE}YT~ItZg( ze6ajpd9H3*K@BWL3szIg>Swo|)oe*LJy%eo;P??}?m|KVi7*ifGUI*g`e1A#pluNX z)8y+5e`?*|;hp!v@6Iu<<#yXoBDNRZckh2astEIxv|Kw5X?=vH&`~fU5*L*4c}M#T z4G|U6t#IvxJDBKC_iepkgy0XXE~FTtJ6*5d=FF2WrdiYgyTxJ`lxv`|ZIv!B4#8+N zq=yR2SPfGdxJgY}#zgn7)e{!_2NamS&f5|0J#gF0b0#<=rd1pBW?#^17F6w^3!<@Z zv-@)V-@vz_?TVR+dsW6imFG=+UsD$&b$5+Ct}g5L+M-D36sMaw?#6_^&5<>~OlN=R z_?F@xIQx`9Na6kWm##leQVRF=qP^N~>n?Vx)mc%Y?8GaCxX_*0TG8abKlf~g z$g+*=_it85Ky&X<%##0NJ(!ww3O}f>WNe-#F%S_*zd3v zOLL^@-q_FTfAZ(=pTqOro)1Cx{OX1TL^&Asp>jh4vP=@AsI>D@6MOsKazi*rjRqPo z@sA}Se`uQbr}pkY@(ImEO`K^0UaCf29P}t^RS>HqdQ{ZS3nN>F2ZX;L^5 zY5+!wAHe=G)j{3{9y0;IC3Jt)zTaYqw>^DV_X#Ehv3%Tm#d#7cor;0L6UT#YOO8P5kb9Ic@JJ^NSmDD`~^7h2*yF$gFFZx$!Hvn2_F(E z#q}l}s3IT--EdeoB+-=hzVP4NBLW9%5n4 zi0iFp3sKi8&xZLhWo*Z51x?Vp-raL+S@`fqpA;8K?) zUZ}#mR*brVafsv&!;(-#{K@AJEC(QIR-J0rAm7;2t~nPhfAXjW|5I1{tGa4t8UGdm z{1e0q?1Uyz8Vy6+lL0}bav)6g%(D{b!o4i6q_?H(>y-~RyxTnI?~(y8OqD!oOAL+; zGR^Rr`W)D{$zDwRh70~ghz-v(0sPb>VN@H-g!kJVjJ9ys)U z$LIVGT*?J&OsDpd5)2N*4pWE>N|XTYZ&4^pfK&Fj8HIGLUT%ni%4P7sDfaB2BYg-&LX)yyyW$DUUt7~;jA z@EjK&Ne1xfAQaTCS`}hHp~xYxDCjGM3U%()lWTTc+dcz*&H`;({FKu7@(O%!fq1WeOV%1x0RdosDk2$0%}Q>$4Vs5Fu6PqOOK; zLi*tu>PRAS9Y@|)!)h~MHkJGOZCC0vED(!hOldo#LoDBljSBU-1JJ8Gk$8z0gPJs0 z9KiIkurl+MjbO93GncB@SH+kqYvoVFYdidWo<1VLm`oh*hc2=+NP^x!So% z3=3~Mi<)uvROP1!LfEcF-{|AazLVqS3-rCgmKL_A^O0ZX--nU>vfa%!=unr^L&*TA zns|l{Sa0%9jem6g+O$!rA-jH|RfnhD<8E1LjjLi-KK9!b=#sX^yu9TeN43Pw{SnTm zz85sZ%7uJ!TRP;RS=yV%8*liecPY%%an4#Jz+lfS?Vbz%SN64gpjl9k=~Un_wjw~y zV>H#!02h*lXE^y3UD{c!D2e=k?Ol5`RBIm|rrfU`6O^R>RSPXF!o zuD$kN``z=-e%|Nzd!A>^JHqbq2KN~!Ut+y)NnGM@vTvO%8a(k*wX)vFKw&L*79)M& z<-BT=vguJg29MDyA`#+m>)m>+y!*QQ8eUx^&uX(~R0P;*M$rwOF9kN5^^go4cMN&I zMsFDMHXjSvzH`XkPp)dey^yoYH3jpFVso*#`{7gKjR<_2gDgLYQqAd&1!n z|JWjbDV~Y#pTuy$fMe*REOr1Ww%-Gbz{Zu2tD+dDvd^LtsB`NEK)RU*kp8`uMtsI3 ze$09Pua9{?5s`pZUMuwmQjA5;+rzme4yO$@V}etE1973_XRkOx=DDnqI6&0Lr(<>q;Th-7g;%?yw~bu+P`G9iYfNr#cH#sE(%oyPP4$BW%K`&_qi2U}oFHNJRO zXHoo5i0UYzM+N(KiRlW^$c-E+Du^}K9s;d&H<3ah);RJVS!0I>S;;lrm`?~>gL^aN zh!xuuByUWCCOIfKD|r=Ip8t-h)dyM0gi3Dfo_IqY`%?Cgi+-;;eRZ-K1`S?05iHkB z8pOnNbgEM6U4gdhXqy=q@x=1BoRKA)Pi>g!^kh|X!RX$kJkC`8o(7v7G{#Ytyq;;nl7b(b=ePH7%a zR&J;kSA&RT?nasPhv4KvJ~Dwh$Z0h|E|?yX`^a%!DD50*;E6<7hd#rI zC5>95&45dAkJiuFWr&r{y%FpL`W0KFaZk+y?kg;RgC_DUXl8{V_3GS3HCkX|!HZc> zT3{rH2)N}9-)ZNH(&{pTd3DdhX{{s9@(PN5fyB|6u@n_=k2J&zSE7qTwm%kDqFsVM z%$T%gIns0%PtGqNFAOBu&G^@eQOEmq_5~Go7*!K1519!YnCj}E72LIEhMfmH25P(M znWbyjFxq@vM+C)zO%bcy<+Mc(l zKS}>)P$A}lTFbKJV4f7i%k)Q0-q(8h%#?v2iHZqc#>%r}iY4hs4)V$JzqzMip!Fyq$8B zu!}fm5m}7*4vJD3ZLMo^TYjsQ_MLj{onPDJCaxm)|AwyHlNlY8%SI&XD7vuncJ})8 z8EHilyG&@(-s%@^VCj|5@*{P_J)(MwutqHU7*KyE9EAA9v=&a#h$b{KYuoSLn99dsML zH*L$QJBfNhbPo-(`bsS1a0ZEIHXXoK7?RC9`3@MGz5|BUY%^{z8X#vV_OpvW*e84| z?hE9vuLDsA3U$x?%D7PmCSdQF1{=Y*#6w#+Yr&@{Q=Wz2+Kuxp7@R0|@~V}u=>cw6 zN7}UDNe7ksG?Pvz-*$ltD3!=6FTDhMcAiXG0bWQPcw23rK(f2un?ij)4jRHfANq0X z-)siH{9=4XgHB~xFrGIX^POu!)W!Qx>PUFIt?9FKxPH#M`*PRR?wQ#^E%?s~g2mG) zx}!#!Y=UEg6fl%~@I4pq*Y5Q`E@W()GCkbD4qiw%L^JNmkRNWIZ!Xpw3W?uvmq6Gi z^W@+w31t|)%%K6sFhhpL4`+sgezJ#7nqF?m8^7MX>$^EUcTL0jj@3>hdAI0G#dCr~ z*hhK{Q42+k#s;?~Orz-&bt76#J<9PZdZy^ve$>9GjlKRn%lB@psENQ@c`h59A)puW z>ROq>>M_y3TujhO2-e-?7V1M@4PoLlUkqLLsC${7V@4PJZzX z*pmC-%uNA``0v>A$3?jjOn+idi;+9Jf>m&E)@eqmY^^#gyx9p8OE&S(K|S!QNL_N1 zp&fArm96o>GvG`iaqhIlrt8W|VSpt?eP<^0uVi5P|5Wb7t43PolsuZzM&nCjbXzg> zqj8v`iDRxUrF%NFNT(Y2dK(7J7zkgu;CokbJI}Tyer^QD1zJaVupSEmlMht&Oue6* z+D8-4ccakn%?wmnqy3;E_pN@4)6L9ZX|4k8%FiP6*JqOWl9>E7v4Y{N0)Y-LJ$g5m zai0H9W=cd3=mlPVX7c=^*h}7#JJsjgR75T?^!=5f)cg-^WMq6ZOjhrzAkLYAX)vrpJ$A{W%K@H2k}?FqVI7n{y$;QEgoX5&EC%PXGG0WKrk>zl@-?AnCe0m z_b2RpLO!$S_M!RmaH2&|S!uS!6+xxtLa%ga609&PFL@u+c|-YiAe#xTRmSZMcdV1H zsEp2J#K1`bSA&AkJ`C5QqV^`qHr+yH62IDGkEO3&7#o!@CvGM((+ZT9yB;*#e?-)Iq?Z~+Lu1St%{fz*QN-R&EkOnDRoAP+)~Qr_IF2Tm8b~^J zN}jQtgJ#ZIpe-Fw-h3Gh!^1L{u=2;p(TH+pmoXJNK!J-`oS*<3;`%Mi`zJ`hY{baK z4#8vi4qf3*IBF=A9D>Yf6Hw`&F24*YGN6cJX^fhljMYvr#>`H+;brO(ULtdZJ-f*R zaN?=eDmH_IGKPsfw!W>C;uOsGg+w&o2L^S-R-%H;^LHe zIa)y|{=S*2{WUQ$jTeFS!dogu1gC4}IlIqhHD_mZsxO4_fVQM%W)qs|489H3*Ex3S +title: +author: +type: +category: +status: +created: +discussions-to: +updated: +requires: +replaces: +superseded-by: +--- + +## Abstract + +Please provide a short (~200 word) description of the issue being addressed. + +## Motivation + +The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright. + +## Rationale + +The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. + +The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion. + +## Specification + +The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. + +## Backwards Compatibility + +All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright. + +## Security Implications + +If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. + +## How to Teach This + +For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. + +## Reference Implementation + +The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation. + +## Rejected Ideas + +Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. + +In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued. + +## Open Issues + +While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. + +## References + +A collections of URLs used as references through the HIP. + +## Copyright/license + +Each new HIP must be placed under the Apache License, Version 2.0 -- see [LICENSE](LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) \ No newline at end of file