Commit 638c98d9 authored by Julien Hamilton's avatar Julien Hamilton

New TZIP repo structure

parent 21d31e49
tzip: 1
title: TZIP-0001 (TZIP Purpose and Guidelines) FAQ
status: WIP
type: Meta
author: John Burnham, Jacob Arluck
advocate: John Burnham, Jacob Arluck
created: 2019-04-12
## What is a TZIP?
Response copied from [TZIP-0001](/Proposals/TZIP-0001/
An TZIP is a design document providing information to the Tezos community,
describing a feature for Tezos or its processes or environment, and supporting
the formal protocol governance process.
## Why do we need this?
Let's start from the assumption that Tezos needs some sort of asset standards
comparable to the role "ERC" plays on Ethereum, which is something a lot of
people have asked for. If we accept this premise, then there are two options:
1. Informal standards with no standards process
2. Formal standards with a a standards process
There are examples of both kinds of standards in the blockchain community, but
in our opinion informal standards are much more common. In general, informal
standards make decision-making processes opaque and result in poorer quality
standards documents. High-quality standards don't just appear overnight; they
are public goods that have to be carefully and thoughtfully *built*. We think
that a formal standards process is the best way to do this.
## Wouldn't it be simpler to just write the application standards first?
We are developing the application standards
[A1: Michelson Contract Interfaces and Conventions](/Proposals/TZIP-0004/,
[FA1: Unsafe Ledger](/Proposals/TZIP-0005/ at the same time as the Meta-level TZIPs.
This is a lot more work, but we think it's a fairer and more fruitful
alternative to just unilaterally promulgating our own standards.
We do genuinely need the application standards we're working on, but already
we've found that we've held our work to higher level of quality by thinking of
them in the context of a larger standards process.
## What's to prevent TZIP from becoming a centralized authority like EIP?
EIP has power in Ethereum because it acts as [Schelling
point]( in their system
of hard fork governance. This is reinforced by the fact that the EIP editors
are substantially the most influential or notable members of the Ethereum core
developer community.
Tezos has a different, and we believe more game-theoretically optimal, Schelling
point in the protocol amendment process by the Tezos Quorum. We've proposed this
design of the TZIP process to support the Quorum by making TZIP an effective
process for producing good quality documentation that is completely non-binding
upon anyone. In a very real sense, we've tried to imagine what EIP would look
like if it only had an "Informational" standards track.
## Who are the editors going to be?
We don't know! We've left this question open because it needs to be answered by
the Tezos community as a whole. We hope we can all collectively design a fair
and legtimate mechanism for electing (and removing) TZIP editors. One possible
way to do this might be to use a Quorum vote to select the editors. Another way
might be to have an in-person election at some future Tezos conference.
Whatever the mechanism, we think it should be democratic and transparent:
If the composition of TZIP editors ends up looking analogous the composition of
EIP editors, we will consider this entire proposal to have been a failure.
tzip: 1
title: TZIP Purpose and Guidelines
status: WIP
type: Meta
author: John Burnham, Jacob Arluck
advocate: John Burnham, Jacob Arluck
created: 2019-04-10
## Summary
TZIP (pronounce "tee-zip") stands for Tezos Improvement Proposal, which are
documents that explain how the Tezos blockchain works or how it ought to work.
This document is a TZIP which explains how we make more TZIPs.
## Abstract
Tezos is now a large and decentralized project, which can silo information and
inhibit collaboration across different projects, companies and continents.
This can lead to duplication of effort and low attention density on specific
issues. Poor information flow leads to resource misallocation and can
cause confusion in users and outside observers. At the same time, the
distributed nature of Tezos gives the project vitality and dynamism.
This document proposes a central clearinghouse for standards documents by
modifying the Ethereum Improvement Process to be a descriptive rather than a
prescriptive social institution. Unlike Ethereum, Tezos already has a
prescriptive decentralized governance institution: The quorum of Tezos bakers
and delegates. The goal of this proposal is to support that institution by
encouraging high-quality technical discussion, documentation and, where
appropriate, non-binding standardization.
## What is a TZIP?
An TZIP is a design document providing information to the Tezos community,
describing a feature for Tezos or its processes or environment, and supporting
the formal protocol governance process.
The role of a TZIP is purely supplementary, hortative or descriptive; the Tezos
protocol is defined at all times by the implementation whose hash has been
incorporated into the current protocol ID and approved by the Tezos quorum.
TZIPs can and will diverge from and contradict one another, so long as all
active TZIPs remain compatible with the current protocol.
A TZIP should contain a concise technical specification and rationale which
unambiguously articulates what the proposal is, how it may be implemented, and
why the proposal is an improvement. A TZIP should additionally contain an FAQ,
which which documents, compares and answers alternative options, opinions and
Each TZIP has both authors and advocates, who may be (but are not required to
be) the same individuals. Whereas the *TZIP author* is responsible for
generating the proposal and any necessary accompanying materials, the *TZIP
advocate* is responsible for communicating the proposal to the community and
maintaining the TZIP FAQ. Healthy proposals should have multiple independent
advocates and a robust accompanying FAQ.
## TZIP Rationale
We intend TZIPs to be one possible mechanism for proposing new features, for
collecting community technical input on an issue, and for documenting the design
decisions that have gone into Tezos. TZIPs are maintained as text files in a
versioned repository; their revision history is a (possibly incomplete)
historical record of the feature proposal.
For Tezos developers, TZIPs can be a useful way to generate feedback, clearly
communicate functionality to users, and track the progress of their work.
Maintainers of Tezos tools and libraries can list the TZIPs that they have
implemented, which can give the community a convenient way to know the current
status of a given project.
There are many types of TZIP defined in [TZIP-0002], where the TZIP Editors
maintain an up-to-date list. Unlike some other standardization schemas, instead
of purely numeric serial numbers, TZIPs use "TZIP indices", a system similar to
the Library of Congress Classification that mixes alphabetic topic prefixes
("A", "P", etc.) with serial numbers which may be extended with a `.` character
(e.g. `FA1.2` is an extension of `FA1`) This index namespace is also defined
in [TZIP-0002].
It is highly recommended that a single TZIP contain a single key proposal or
new idea corresponding to its type. The more precise the TZIP, the more
successful it is likely to be.
A change to a single library or application may not require an TZIP, whereas a
change that affects multiple independent libraries or applications probably
A TZIP must meet certain minimum criteria, which may change depending on the
TZIP type. Some TZIP types may require an attached reference implementation of
the proposed improvement. Other TZIP types may require two independent
implementations. If so, the associated software should be of minimal possible
complexity and be focused primarily on illustrating the contents of the single
proposal to which it is attached. Reference implementations should show evidence
of correctness, ideally via formal methods, but at minimum via comprehensive
## TZIP Roles and Responsibilities:
Parties involved in the process are the:
- *TZIP authors* write proposals and accompanying materials and request TZIP
status changes. In the case of multiple authors, a single author will be
designated as primary.
- *TZIP advocates* endorse proposals, seek community feedback and maintain the
proposal FAQ
- *TZIP editors* advise authors and advocates on how to improve the quality of
their proposal in all aspects (content, prose, implementation detail), ensure
the compliance of the proposal and the process with relevant TZIPs, approve
changes in proposal status, assign TZIP indices to proposals and maintain the
TZIP index namespace as a whole.
- the *Tezos quorum* defines the Tezos protocol and approves all consensus
critical amendments
### TZIP Editors
There currently are no TZIP Editors, pending the design and community or quorum
approval of a fair and legitimate process to select and remove Editors.
Once such a process is designed, the following is a list of candidates who have
expressed interest in serving as TZIP Editor:
[TODO: Add list]
For each submitted TZIP, the editors will select one or more editors to assume
responsibility for the proposal. This editor or editors will:
- Read the TZIP to check if it complies with all relevant standards articulated in
this document and elsewhere, both global TZIP standards and those particular
to the TZIP type.
- Edit the TZIP for prose (spelling, grammar, sentence structure, etc.),
markup (GitLab Flavored Markdown).
- Review any accompanying resources, such as implementations, proofs, papers,
links, etc.
- Determine whether the FAQ fairly expresses and responds to criticisms of the
If the TZIP does not meet the standards at each of these stages, the editors
will send it back to the author for revision, with specific instructions. This
process may repeat as many times as necessary. The editors may additionally
refer the TZIP to outside reviewers with relevant knowledge. Editors may also
outright reject a TZIP submission, which is unsuitable for review or is
otherwise non-compliant with the standards outlined in relevant active TZIPs.
Should the editors approve the TZIP, they will:
- Assign a TZIP index to the proposal.
- Merge the corresponding pull request. The TZIP editors have sole ownership
over the `tzip` GitLab repository.
- Coordinate any further steps with the TZIP authors and advocates, as required
by the specific TZIP type.
The editors will, at all stages of the TZIP process, render fair and
impartial judgement. An editor cannot review a TZIP of which they are an
advocate or an author.
Throughout this process, the editors agree to follow and enforce TZIP Code of
Conduct, described in [TZIP-0003: TZIP Code of Conduct][TZIP-0003]
## TZIP Workflow
Authors should solicit feedback from the Tezos community first before submitting
their proposal to the editors. As prior work on the same or similar topics may
not be immediately apparent or accessible from publicly available information,
inviting community advice can both save time and effort and result in a stronger
Examples of appropriate public forums to gauge response to a TZIP include [the
Tezos subreddit], [the Issues section of this repository], and [tzip Slack
channel]. In particular, [the Issues section of this repository] is an excellent
place to discuss your proposal.
A TZIP will move along the following process:
graph LR
A(START) -->|Public feedback| WIP
subgraph Editing
DRAFT --> |Changes| DRAFT
LC --> |Revert| DRAFT
Each status change is requested by the primary TZIP author and reviewed by the
TZIP editors. Authors may use merge requests to update the status, which will
include links to relevant discussions of the TZIP. The TZIP editors will process
these requests as per the conditions below:
* **Work in progress (WIP)** -- Once the author has asked the Tezos
community whether an idea has support, they will write a draft TZIP on
their own fork of the `tzip` repository and submit a [merge request] with the
`WIP` tag. Authors should include an implementation if this will aid people in
studying the TZIP.
* :arrow_right: Draft -- The Editors will review the merge request at a high
level and determine if the TZIP is developed enough to proceed to the
**Draft** stage.
* :x: Draft -- Some possible reasons for denying draft status include being
too unfocused, too broad, duplication of effort, being technically unsound,
not providing proper motivation, addressing backwards compatibility, or
having generated enough community interest through the advocates and the
FAQ. If rejected, the editors will close the merge request.
* **Draft** -- Once the first draft has been approved, authors may submit
follow-up commits with further changes to the draft until such point as they
believe the TZIP to be mature and ready to proceed to the next status. Many
types of TZIP in draft status must be implemented at least once to be
considered for promotion to the next status.
* :arrow_right: Last Call -- If agreeable, the TZIP editor will assign Last
Call status and set a review end date (`review-period-end`).
* :x: Last Call -- A request for Last Call status will be denied if material
changes are still expected to be made to the draft. Editors expect that
TZIPs only enter Last Call once.
* **Last Call** -- This TZIP will listed prominently on the website (subscribe via RSS at [last-call.xml])
* :arrow_right: Pending -- TZIPs which require protocol amendment
* :arrow_right: Protocol -- Informational TZIPs explicating the current
* :arrow_right: Active -- Most TZIPs will move to Active, which indicates that
the TZIP is compatible with the current protocol, and may be updated without
changing its TZIP index
* :arrow_right: Final -- Some TZIPs may move to Final, which indicates that
the TZIP is compatible with the current protocol, but may **not** be updated
without changing its TZIP index
* :x: -- A Last Call which results in material changes or substantial
unaddressed technical complaints will cause the TZIP to revert to Draft.
* **Pending** -- TZIPs awaiting vote in a future protocol amendment.
* :arrow_right: Protocol -- Adoption by a vote of the Tezos quorum.
* :x: -- A Pending TZIP which requires any changes will revert to Draft
* **Protocol** -- TZIPs which are part of the current protocol.
* :x: -- Superseded -- Amended by a vote of the Tezos quorum.
* **Rejected** -- An TZIP that is fundamentally unsuitable without substantial
improvements and additional public feedback.
* :arrow_right: WIP -- The authors make substantial improvements and solicit
additional public feedback.
* **Active** -- Most TZIPs will move to Active, which indicates that the TZIP is
compatible with the current protocol, and may be updated without changing its
TZIP index
* :arrow_right: Superseded -- The TZIP is superseded by a new TZIP.
* **Final** -- Some TZIPs may move to Final, which indicates that
the TZIP is compatible with the current protocol, but may **not** be updated without
changing its TZIP index
* :arrow_right: Superseded -- The TZIP is superseded by a new TZIP.
* **Superseded** -- An TZIP which was previously Final, Active, or Protocol but
has been replaced by another TZIP in Final, Active, or Protocol status,
which will reference the Superseded TZIP
## What belongs in a successful TZIP?
Each TZIP should have the following parts:
- Preamble - RFC 822 style headers containing metadata about the TZIP, including
the TZIP type, a short descriptive title (limited to a maximum of 44
characters), and the author details. See [below] for details.
- Simple Summary - “If you can’t explain it simply, you don’t understand it well
enough.” Provide a simplified and layman-accessible explanation of the TZIP
- Abstract - a short (200-500 word) description of the technical issue being
- Motivation - The motivation is critical for TZIPs that want to
change the Tezos protocol. It should clearly explain why the existing
protocol specification is inadequate to address the problem that the TZIP
- Specification - The technical specification should describe the syntax and
semantics of any new feature. The specification should be detailed enough to
allow competing interoperable implementations.
- Rationale - The rationale fleshes out the specification by describing what
motivated the design and 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 may also provide
evidence of consensus within the community, and should discuss important
objections or concerns raised during discussion.
- Backwards Compatibility - All TZIPs that introduce backwards incompatibilities
or supersede other TZIPs must include a section describing these
incompatibilities, their severity, and solutions.
- Test Cases - Test cases for an implementation are strongly recommended as are
any proofs of correctness via formal methods.
- Implementations - Any implementation must be completed before any TZIP is
given status “Last Call”, but it need not be completed before the TZIP is
merged as draft.
- Copyright Waiver - All TZIPs must be in the public domain, or under a
permissive license substantially identical to placement in the public
domain. See the bottom of this TZIP for an example copyright waiver.
## TZIP Formats and Templates
TZIPs should be written in [Markdown] format.
## TZIP Header Preamble
Each TZIP 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.
` tzip:` <TZIP index code> (this is determined by the editor)
` title:` <TZIP title>
` author:` <a list of the author's or authors' name(s) and/or username(s), or
name(s) and email(s). Details are below.>
` advocate:` <a list of the advocate's or advocates' name(s) and/or username(s), or
name(s) and email(s).>
`* gratuity:` <a Tezos address controlled by an author capable of receiving
gratuities from grateful Tezoi>
` * discussions-to:` \<a url pointing to the official discussion thread\>
` status:` <WIP | Draft | Last Call | Final | Active | Pending | Protocol |
Rejected | Superseded>
`* review-period-end:` <date review period ends>
` type:` Defined in [TZIP-0002]
` created:` <date created on>
` * updated:` <comma separated list of dates>
` * requires:` <TZIP indices)>
` * replaces:` <TZIP indices)>
` * superseded-by:` <TZIP indices>
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 optionally lists the names, email addresses or usernames of
the authors/owners of the TZIP. Those who prefer anonymity may use a username
only, or a first name and a username. The format of the author header value must
> Random J. User &lt;[email protected]&gt;
> Random J. User (@username)
if the email address or GitLab username is included, and
> Random J. User
if the email address is not given.
#### `discussions-to` header
While an TZIP is a draft, a `discussions-to` header will indicate the mailing
list or URL/s where the TZIP is being discussed.
#### `type` header
The `type` header specifies the type of TZIP according to Appendix A.
#### `created` header
The `created` header records the date that the TZIP was assigned a number. Both
headers should be in `yyyy-mm-dd` format, e.g. 2001-08-14.
#### `updated` header
The `updated` header records the date(s) when the TZIP was updated with
"substantial" changes. This header is only valid for TZIPs of Draft and Active
#### `requires` header
TZIPs may have a `requires` header, indicating the TZIP numbers that this TZIP
depends on.
#### `superseded-by` and `replaces` headers
TZIPs may also have a `superseded-by` header indicating that an TZIP has been
rendered obsolete by a later document; the value is the number of the TZIP that
replaces the current document. The newer TZIP must have a `replaces` header
containing the number of the TZIP that it rendered obsolete.
## Auxiliary Files
TZIPs may include auxiliary files such as diagrams. Such files must be named
TZIP-XXXX-Y.ext, where “XXXX” is the TZIP index (replacing `.` characters with
`_`), “Y” is a serial number (starting at 1), and “ext” is replaced by the
actual file extension (e.g. “png”).
## Transferring Primary Authorship
It occasionally becomes necessary to transfer primary authorship of TZIPs to a
new primary author. In such cases, the previous primary author will remain as a
co-author or an author emeritus. This can occur by unilateral decision of the
primary author, via request of a co-author and approval by the editors, or in
extraordinary circumstances unilateral decision of the editors.
## History
This document was derived heavily from Ethereum's [EIP-1] which was in turn
derived from [Bitcoin's BIP-0001] written by Amir Taaki and [Python's PEP-0001],
written by Barry Warsaw, Jeremy Hylton, and David Goodger. In many places text
was simply copied and modified. A further influence from `TZIP-0001` was Martin
Pospěch's [tip-1].
None of the authors of [EIP-1], [BIP-0001], [PEP-0001] or [tip-1] text are
responsible for its use in the Tezos Improvement Process, and should not be
bothered with technical questions specific to TZIP. Please direct all comments
to the TZIP editors.
## Copyright
Copyright and related rights waived via
[the Issues section of this repository]:
[merge request]:
[TZIP-0002]: /Proposals/TZIP-0002/
[TZIP-0003]: /Proposals/TZIP-0003/
[Ethereum's EIP-1]:
[Bitcoin's BIP-0001]:
[Python's PEP-0001]:
tzip: 2
title: TZIP Index
status: WIP
type: Meta
author: John Burnham
advocate: John Burnham
created: 2019-04-10
## Summary
## Abstract
## Background: A brief history of the RFC document
Expressing standards in a "Request for Comments" or `RFC` document is a
tradition that goes all the way back to the beginning of the Internet. The
first RFC was an informal memo written in 1969 by Steve Crocker to the `ARPANet`
Network Working Group to figure out how to get `ARPANet` hosts to talk to each
other properly (you can read `RFC-1` in its full glory, complete with ASCII
diagrams here:
Since then, the `RFC` process has evolved and is now formalized under the
auspices of the `IETF`, which additionally canonizes certain `RFC`s (or sets of
`RFC`s) as [Internet Standard][Internet Standard] which contains standards for
things like `ASCII` (RFC-20), `TCP` (RFC-793), `DNS` (RFC-1035), etc. ([a list
of notable `RFC`s][RFC])
Roughly speaking the `RFC` [process][pubprocess] works like this:
1. Submit a draft to the RFC Editor
2. Various review procedures for independent submissions (RFCs generated
by the IETF itself skip this step)
3. Editing and review by the RFC Editor
4. Assign an `RFC` serial number
5. Author's review
6. Publish
All in all, this process typically takes a few months, but delays are common;
it is designed to be deliberative and thorough, to "move slow and break
A full state diagram for the RFC Editor process:
The relevant part of this process for our purposes is step 4 (Assign an `RFC`
serial number). RFC numbers are issued in order, steadily ticking up as each
submission in the RFC Editor queue is approved for publication. With some
exceptions, this pattern has held mostly steady since `RFC 1`.
In 2015, the nascent Ethereum community faced a need for a more formal
standardization process and so [took inspiration][issue-16] from the above
`IETF` process for `RFC`s, which their current [Ethereum Improvement
Proposal][EIP] process resembles (by descent through Bitcoin and Python, which
have analogous `Bitcoin Improvement Proposal` and `Python Enhancement Proposal`
processes). The `RFC` name itself lives on in the `Ethereum Request for
Comments` or `ERC`, an `EIP` subtype that deals specifically with
application-level standards (most notably token standards such as `ERC-20`).
## Problem: Blockchain RFCs
There are two major problems with using an `IETF`-style RFC process to
generate standards for a blockchain or cryptocurrency platform:
First there is a problem of governance: Who approves the standards? Does the
standards process have legitimacy and community buy-in? Can disagreements on
standards be resolved through means other than hard-forking? This problem is
relatively well understood, particularly in the Tezos community, so I will not
focus on it here.
Secondly there is a problem of branding: The term "ERC-20" has
become a brand name used by projects and investors in the ICO marketplace.
"ERC-20" even has its own [Wikipedia page][ERC20]
In one sense, this is a standard working properly, people need common language
to cooordinate with one another. However, using the name "ERC-20" (i.e. issue
number 20 in the EIP repository) for this purpose is perverse. Standards serial
numbers are not designed for marketing copy; imagine calling `TCP/IP`
"[RFC-1347]/[RFC-791]". At best, the additional layer of jargon
obscures meaning. At worst, it can lead to cargo cult mentality in those who
misunderstand the purpose of standards and thus conflate compliance with the
generation of real value.
"What's the difference between ERC-20 and ERC-223? Oh, about 103."
An egregious (and fascinating) example of this abuse is the adoption of the
`*RC-20` pattern by other platforms, such as the use of `TRC-20` by `TRON`
(which does not, as far as I can tell, have a formalized `RFC` process).
To be clear, this problem is not the fault of designers the EIP process, which
is in-line with other successful RFC processes such as Python. The problem is
in the unexpected emergent interaction between technical standards and the
largely marketing-driven token economy.
## Solution: Meaningful RFC serial numbers
We can mitigate the above problems by giving `RFC`s more meaningful serial
We define the TZIP index code as two components:
1. An alphabetic Domain prefix (e.g. `FA` or `P`) which signifies the standard's
topic or domain of relevance. This prefix can be empty, which indicates a
meta-level standard (a standard about the standards process itself). The
mapping between specific letter prefixes and domains is maintained in a
2. A serial number represented as a list of dot separated numbers (e.g. `1.2.3`
or `15`), which signfies whether the standard is an extension or
specialization of another more general standard. For example `2.34` would be
extension number 34 of root standard number 2.
As a worked example, let us imagine where we would classify a port of the
`ERC-20` standard to Michelson as a Tezos Standard index code.
`ERC-20` instantiates an asset by maintaining a ledger of accounts and balances
and providing an interface to transfer balances between accounts. `ERC-20`
balances are fungible (all units of the asset are interchangeable and without
distinction, aside from their ownership).
Let's suppose that the code `A` is mapped to the topic "Application", and its
extension `FA` is mapped to "Financial Application" in our Domain Prefix Registry
(prefixes specialize from right to left by prepending characters). Our prefix
for our `ERC-20` port is thus `FA`.
Serial numbers are assigned in the same approval queue as the RFC process, so if
there is already a standard with the code `FA1`, which our `ERC-20` port is not
an extension of, our index code will then be `FA2.`.
Crucially, domain prefixes export distinct namespaces, so `A1` and `FA1` are
not necessarily related and might be completely independent. Whether or not
a TZIP of a given type applies to all TZIPs in its subtypes is to be defined by
the TZIP in question.
Now let's further suppose that some time later we return to our `FA2` standard
and wish to make an extension, say by adding a transfer restriction function to
the contract interface. Supossing there have been three extensions to `FA2`
already, our assigned index code for our extension will be `FA2.4`. However,
should the extension cause a meaningful divergence from the root, perhaps by
implying a radically different purpose or implementation, the standards editor
may assign a separate root index code (e.g. `FA3`) or a code in a different
domain prefix altogether.
Standards may be extended indefinitely by appending additional `.` characters.
However, it is likely that repeated extension will be less preferable at a
certain point than issuing a new root code.
In contexts where the overall index code may appear with abbreviations
or serial numbers from external platforms (such as `RFC` or `EIP` numbers), the
letters `TZIP` should be prepended to the code like so:
TZIP-0012 FA2
TZIP-0013 A3.4
Meta-level standards (such as this one `TZIP-0002`) should always have `TZIP`
prepended to their index codes.
## TZIP Index: Types
### List of Types
| Type Prefix | Topic |
| | Meta |
| A | Application |
| LA | Layer-n Application |
| FA | Financial Application |
| I | Interface |
| L | Language |
| N | Networking |
| O | Operations |
| P | Protocol |
| X | Cryptography |
| Z | Informational |
### Descriptions:
**(A) Application**: Applications built on top of Tezos, particularly smart
contract or higher layer applications.
**(LA) Layer-n Applications**: Higher-layer applications which use the Tezos
chain e.g. for settlement or communication.
**(FA) Financial Applications**: Applications involving the management,
allocation or transfer of instruments which mediate economic value, such as
assets or liabilities.
**(P) Protocol**: improvements to the Tezos protocol requiring a
recourse to the protocol amendment process.
**(N) Networking**: improvements to the peer-to-peer layer
**(X) Cryptographic**: improvements to cryptographic primitives
**(I) Interface**: improvements around client API/RPC specifications and
**(L) Language**: improvements to smart contract, formal proof, or
implementation languages. Examples are specifications for
[Michelson], [LIGO, [SmartPy], [Morley], [Liquidity], [Fi] or best practices
for Tezos projects using OCaml, Haskell, Rust, JavaScript, Coq, Agda, etc.
**(Z) Informational**: Tezos design issue, or provides general guidelines or