Commit 23c5640d authored by Rocco's avatar Rocco 🎉 Committed by Rocco

Update all proposals to reflect #s - sans links

parent 401f3b16
---
tzip: 1
tzip: 001
title: TZIP Purpose and Guidelines
status: Final
type: Meta
......@@ -56,11 +56,11 @@ 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-2]. Some TZIPs, such as contract
There are many types of TZIP defined in [TZIP-002]. Some TZIPs, such as contract
specifications, also have a *name* that consists of the TZIP type (e.g. `A`,
`FA`, `I`), concatenated with a serial numbers which may be extended with a `.`
character (e.g. `FA1.2` is an extension of `FA1`). Again, this is defined in
details in [TZIP-2].
details in [TZIP-002].
It is highly recommended that a single TZIP contain a single key proposal or new
idea corresponding to its type. A change to a single library or application may
......@@ -91,9 +91,9 @@ A TZIP can have the following statuses:
| Status | Actor | Description | Action(s) to get that Status | Next Status(es) |
| :----------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------- | :---------------------- |
| `Work In Progress` | Author | This covers the initial work being done to create the TZIP and its accompanying resources | 1. Author submits a MR to:<br/>&nbsp;&nbsp;- reserve a TZIP number, say *xx*, in the [README](/README.md#current-tzips)<br/>&nbsp;&nbsp;- add the *Work In Progress* status in the README<br/>&nbsp;&nbsp;- create a *tzip-xx* folder in [proposals](/proposals)<br/>2. Author creates a new branch, *tzip-xx*, to work on it | Draft, Withdrawn |
| `Draft` | Author | The TZIP is now in good shape, and is ready to be shared with the community to get iterative feedback | 1. Author submits a MR from the *tzip-xx* branch, including the status change to *Draft* in the README<br/>2. Reviewer merges the MR to *master* | Submitted, Withdrawn |
| `Withdrawn` | - | The authors decide that the TZIP is no longer needed, or the reviewers decide to reject it (e.g. for non-compliance) | 1. Author or Reviewer closes the *tzip-xx* branch<br/>2. Author or Reviewer updates the TZIP and README with the *Withdrawn* status | - |
| `Work In Progress` | Author | This covers the initial work being done to create the TZIP and its accompanying resources | 1. Author submits a MR to:<br/>&nbsp;&nbsp;- reserve a TZIP number, say *xxx*, in the [README](/README.md#current-tzips)<br/>&nbsp;&nbsp;- add the *Work In Progress* status in the README<br/>&nbsp;&nbsp;- create a *tzip-xxx* folder in [proposals](/proposals)<br/>2. Author creates a new branch, *tzip-xx*, to work on it | Draft, Withdrawn |
| `Draft` | Author | The TZIP is now in good shape, and is ready to be shared with the community to get iterative feedback | 1. Author submits a MR from the *tzip-xxx* branch, including the status change to *Draft* in the README<br/>2. Reviewer merges the MR to *master* | Submitted, Withdrawn |
| `Withdrawn` | - | The authors decide that the TZIP is no longer needed, or the reviewers decide to reject it (e.g. for non-compliance) | 1. Author or Reviewer closes the *tzip-xxx* branch<br/>2. Author or Reviewer updates the TZIP and README with the *Withdrawn* status | - |
| `Submitted` | Reviewer | The TZIP has been approved by the community and is submitted to the reviewers | Author updates the TZIP and README with the *Submitted* status | Final, Draft, Withdrawn |
| `Final` | Reviewer | The TZIP has been approved by the reviewers | Reviewer updates the TZIP and README with the *Final* status | Deprecated, Superseded |
| `Deprecated` | - | The TZIP is no longer valid and shouldn't be used anymore. It is kept here as a reference but hasn't been superseded by any newer TZIP | Reviewer updates the TZIP and README with the *Deprecated* status | - |
......@@ -185,7 +185,7 @@ bottom of this TZIP for an example copyright waiver.
TZIPs should be written in [Markdown] format. TZIP templates are available in
the [Templates](/templates) folder.
Additionally, the authors agree to follow and enforce the TZIP Code of Conduct,
described in [TZIP-3].
described in [TZIP-003].
To make the text easier to review, all TZIPs should be hard-wrapped at 80
characters.
......@@ -200,7 +200,7 @@ order.
- `tzip:` TZIP number. The number should be requested via a merge request as
soon as the TZIP is in *Work In Progress* status
- `title:` A short descriptive title, maximum 44 characters. If the TZIP has a
*name* (see [TZIP-2]), then it is added as a title prefix (e.g. *FA1 - Abstract
*name* (see [TZIP-002]), then it is added as a title prefix (e.g. *FA1 - Abstract
Ledger*)
- `author:` Name(s) of author(s), ideally with their username(s) or email
address(es). Examples: *John Doe*, *John Doe (@username)*, *John Doe
......@@ -210,7 +210,7 @@ receiving gratuities from grateful Tezos users
- `discussions-to:` Optional. A url pointing to the official discussion thread
- `status:` Can be: Work In Progress | Draft | Withdrawn | Submitted |
Deprecated | Superseded
- `type:` TZIP type as defined in [TZIP-2]
- `type:` TZIP type as defined in [TZIP-002]
- `created:` Date the TZIP was created, format yyyy-mm-dd
- `requires:` Optional. TZIP numbers, representing TZIPs that this TZIP depends
on
......@@ -248,8 +248,8 @@ Copyright and related rights waived via
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
[TZIP-2]: /proposals/tzip-2/tzip-2.md
[TZIP-3]: /proposals/tzip-3/tzip-3.md
[TZIP-002]: /proposals/tzip-2/tzip-2.md
[TZIP-003]: /proposals/tzip-3/tzip-3.md
[Markdown]: https://docs.gitlab.com/ee/user/markdown.html
[EIP-1]: https://github.com/ethereum/EIPs
[BIP-0001]: https://github.com/bitcoin/bips
......
---
tzip: 10
tzip: 010
title: LA1 - Wallet Interaction Standard
author: Alessandro De Carli <a.decarli@papers.ch>, Mike Godenzi <m.godenzi@papers.ch>, Andreas Gassmann <a.gassmann@papers.ch>, Pascal Brun <@pascuin>
discussions-to: https://forum.tezosagora.org/t/wallet-interaction-standard/1399
......
---
tzip: 10
tzip: 010
title: Wallet Interaction Standard
author: Alessandro De Carli <a.decarli@papers.ch>, Mike Godenzi <m.godenzi@papers.ch>, Andreas Gassmann <a.gassmann@papers.ch>, Pascal Brun <@pascuin>
discussions-to: https://forum.tezosagora.org/t/wallet-interaction-standard/1399
......
---
tzip: 12
tzip: 012
title: FA2 - Multi-Asset Interface
status: Draft
type: Financial Application (FA)
......@@ -39,7 +39,7 @@ created: 2020-01-24
## Summary
TZIP-12 proposes a standard for a unified token contract interface,
TZIP-012 proposes a standard for a unified token contract interface,
supporting a wide range of token types and implementations. This document provides
an overview and rationale for the interface, token transfer semantics, and support
for various transfer permission policies.
......@@ -413,7 +413,7 @@ Token metadata is primarily useful in off-chain, user-facing contexts (e.g.
wallets, explorers, marketplaces). As a result, FA2 optimizes for off-chain use
of token metadata and minimal on-chain gas consumption. A related effort to create
a separate metadata standard is also underway via
[TZIP-16](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-16/tzip-16.md).
[TZIP-016](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-16/tzip-16.md).
Each FA2 `token_id` has associated metadata of the following type:
......
---
tzip: 13
tzip: 013
author: Kirill Kuvshinov (@kkirka)
advocate: Kirill Kuvshinov (@kkirka)
status: Work In Progress
......
---
tzip: 13
tzip: 013
title: FA1.3 - Fungible Asset
author: Kirill Kuvshinov (@kkirka)
advocate: Kirill Kuvshinov (@kkirka)
......
---
tzip: 14
tzip: 014
title: GraphQL interface to Tezos node data - Scalars
status: Draft
type: Interface
......@@ -77,4 +77,4 @@ Reference implementation of the Tezos GraphQL schema and respective scalar reso
Publicly available endpoint exposing Tezos node data over GraphQL using a reference implementation from [tezos-graphql-nodejs](https://gitlab.com/tezos-graphql/tezos-graphql-nodejs) project is hosted at [TezosLive.io](https://www.tezoslive.io).
### EIP-1767: GraphQL interface to Ethereum node data
[EIP-1767: GraphQL interface to Ethereum node data](https://eips.ethereum.org/EIPS/eip-1767) is a specification of the GraphQL interface for Ethereum node data. There are not many similarities between the scalars or their GraphQL schemes as their respective RPCs differ greatly.
\ No newline at end of file
[EIP-1767: GraphQL interface to Ethereum node data](https://eips.ethereum.org/EIPS/eip-1767) is a specification of the GraphQL interface for Ethereum node data. There are not many similarities between the scalars or their GraphQL schemes as their respective RPCs differ greatly.
---
tzip: 15
tzip: 015
title: A2 - Token Transferlist Interface
author: Michael J. Klein (@michaeljklein)
status: Draft
......@@ -9,7 +9,7 @@ created: 2020-05-14
## Summary
TZIP-15 proposes a standard for a transferlist interface:
TZIP-015 proposes a standard for a transferlist interface:
a lightweight permission schema suitable for asset allocation and transfer.
This schema is versatile and can either be used as part of a token
......
---
tzip: 16
tzip: 016
title: Contract Metadata
status: Work In Progress
type: Interface
......@@ -18,11 +18,11 @@ needed for a scalabe integration experience by wallets, explorers, and
applications.
To address this need and ease the integration, discoverability, and querying of
Tezos smart contracts, we propose TZIP-16. TZIP-16 is a standard for encoding
Tezos smart contracts, we propose TZIP-016. TZIP-016 is a standard for encoding
access to such smart contract metadata in JSON format either on-chain using
tezos-storage or off-chain using IPFS or HTTP(S).
TZIP-16 defines:
TZIP-016 defines:
- A basic structure to find _some_ metadata in a contract's storage.
- An URI scheme to find data: on-chain (contract storage) or off-chain
......@@ -37,8 +37,8 @@ TZIP-16 defines:
The standard is meant to be extended/specialized by other TZIPs, for instance by
adding fields to the JSON format of the metadata or imposing certain off-chain
views. We intend to extend existing token APIs specified in TZIP-12 and TZIP-7
with such metadata and off-chain views using TZIP-16.
views. We intend to extend existing token APIs specified in TZIP-012 and TZIP-07
with such metadata and off-chain views using TZIP-016.
## Table Of Contents
......@@ -50,7 +50,7 @@ with such metadata and off-chain views using TZIP-16.
- [Metadata JSON Format](#metadata-json-format)
- [Optional `assertMetadata<hash>` Entrypoints](#optional-assertmetadatahash-entrypoints)
- [Machine-Readable Specifications](#machine-readable-specifications)
- [How To "Derive" From TZIP-16](#how-to-derive-from-tzip-16)
- [How To "Derive" From TZIP-016](#how-to-derive-from-tzip-016)
- [Known Implementations](#known-implementations)
- [Rationales / Design Choices](#rationales-design-choices)
- [Future Work & Extensions](#future-work-extensions)
......@@ -85,7 +85,7 @@ metadata fields, a Michelson function “`get-balance`” which gives an account
current balance from the storage. The author of the contract can store this
information on IPFS and add only an IPFS-URI to the contract's storage.
Conformity to the TZIP-16 (or a derivative) standard allows a wallet
Conformity to the TZIP-016 (or a derivative) standard allows a wallet
implementation to find the IPFS-URI and decode its contents to find the
particular implementation of the `get-balance` off-chain-view in order to
display a user's balance in its interface.
......@@ -98,7 +98,7 @@ machine-readable definitions).
### Contract Storage
To provide a TZIP-16-compliant initial access-point to the metadata from a given
To provide a TZIP-016-compliant initial access-point to the metadata from a given
on-chain contract (`KT1...` address) one must include a `%metadata` field in
the contract-storage.
......@@ -273,12 +273,12 @@ This standard defines a few top-level fields:
- A list of strings.
- Each string should allow the consumer of the metadata to know which interfaces
and behaviors the contract *claims* to obey (other than the obvious TZIP-16).
and behaviors the contract *claims* to obey (other than the obvious TZIP-016).
- In the case of standards defined as TZIPs in the present repository, the
string should obey the pattern `"TZIP-<number><extras>"` where `<extras>` is
additional information prefixed with a space character.
- Example: an FA2 contract would (at least) have an `"interfaces"` field
containing `["TZIP-12"]` or `["TZIP-12 git 6544de32"]`.
containing `["TZIP-012"]` or `["TZIP-012 git 6544de32"]`.
`"errors"`:
......@@ -319,7 +319,7 @@ Example:
"tools": ["SmartPy dev-20201031", "Flextesa 20200921"],
"location": "https://gitlab.com/smondet/fa2-smartpy/-/blob/c05d8ff0/multi_asset.py"
},
"interfaces": [ "TZIP-12" ],
"interfaces": [ "TZIP-012" ],
"errors":[
{ "error": {"int": "42"},
"expansion": { "string": "You did something wrong"},
......@@ -502,10 +502,10 @@ JSON-Schema specification of the contents of the “Metadata JSON Format”
described above. A few valid examples are available in the
`proposals/tzip-16/examples/` directory.
## How To “Derive” From TZIP-16
## How To “Derive” From TZIP-016
This proposal is meant to be extended and specialized by other standards. Here
are some of the ways one can define TZIP-16 extensions:
are some of the ways one can define TZIP-016 extensions:
- Defining new fields in the metadata-JSON.
- Making some of the metadata content mandatory, e.g. requiring the
......@@ -514,7 +514,7 @@ are some of the ways one can define TZIP-16 extensions:
- Using other _keys_ of the `%metadata` big-map for storing particular data.
- Using the metadata-URI definition to locate other pieces of data.
Other aspects are better proposed as a backwards-compatible changes to TZIP-16.
Other aspects are better proposed as a backwards-compatible changes to TZIP-016.
For instance, adding a new URI scheme to locate (meta)data can be better handled
within this standard.
......@@ -523,7 +523,7 @@ the works.
## Known Implementations
The section will reference known implementations of (part of) TZIP-16:
The section will reference known implementations of (part of) TZIP-016:
- The work-in-progress merge-request
[`smondet/tezos!7`](https://gitlab.com/smondet/tezos/-/merge_requests/7) adds
......@@ -572,9 +572,9 @@ specification.
## Future Work & Extensions
A few extensions and improvements of TZIP-16 are already planned or in progress:
A few extensions and improvements of TZIP-016 are already planned or in progress:
- Augment/upgrade the TZIP-12 and TZIP-7 standards with metadata support.
- Augment/upgrade the TZIP-012 and TZIP-07 standards with metadata support.
- Specify *off-chain-events*: events are similar to off-chain-views, but they
extract knowledge from (the sequence of) contract **calls**, like “balance
updates”; cf.
......
---
tzip: 17
tzip: 017
title: Contract Permit Interface
author: Michael J. Klein (@michaeljklein)
status: Draft
......@@ -9,7 +9,7 @@ created: 2020-08-11
## Summary
TZIP-17 proposes a standard for a pre-sign or _"Permit"_ interface:
TZIP-017 proposes a standard for a pre-sign or _"Permit"_ interface:
a lightweight on-chain emulation of `tzn` accounts.
This document provides an overview and rationale for the interface as well as an implementation in Lorentz
......@@ -209,9 +209,9 @@ See `Cleaning up Permits` for more detail.
Individual permits may be revoked by setting the expiry for that Permit to `0 seconds`
### TZIP-16
### TZIP-016
This contract MUST implement [TZIP-16](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-16/tzip-16.md).
This contract MUST implement [TZIP-016](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-16/tzip-16.md).
The following off-chain-views are required and MUST be provided with Michelson
implementations:
......
---
tzip: 18
tzip: 018
title: A2 - Upgradeable Contracts
author: Diogo Castro (@diogo.castro)
status: Work In Progress
......@@ -20,7 +20,7 @@ created: 2020-08-17
## Summary
TZIP-18 proposes mechanisms for defining upgradeable contracts. More
TZIP-018 proposes mechanisms for defining upgradeable contracts. More
precisely, we describe how to define administrator-forced upgrades and
user-defined upgrades.
......
---
tzip: 19
tzip: 019
title: A3 - Tezos Decentralized Identifier (DID) Manager
author: Wayne Chang (@wyc) <wayne@spruceid.com>
status: Work In Progress
......
---
tzip: 2
tzip: 002
title: TZIP Types and Naming
status: Final
type: Meta
......@@ -28,7 +28,7 @@ LA1).
Additional types of TZIP may be proposed, and existing TZIP types may also be
deprecated by future Meta TZIPs. All the updates will be maintained in this TZIP
([TZIP-2](/proposals/tzip-2/tzip-2.md)).
([TZIP-002](/proposals/tzip-2/tzip-2.md)).
## Naming
......
---
tzip: 20
tzip: 020
title: Off-chain Events
author: Michael Zaikin <mz@baking-bad.org>
status: Work In Progress
type: Interface
created: 2020-10-07
requires: TZIP-16
requires: TZIP-016
---
## Summary
......@@ -22,4 +22,4 @@ The current approach is using custom handlers for known contracts. Obviously, it
* Simple enough to implement/integrate with existing codebase;
* Not tied to any specific entity nor implementation.
A reasonable approach is to take all the custom logic out of the indexer and enable contract developers to write those pieces of logic. A suggested path is to reuse TZIP-16 inerface and introduce several new Off-chain View kinds for deriving token balance updates (receipts).
\ No newline at end of file
A reasonable approach is to take all the custom logic out of the indexer and enable contract developers to write those pieces of logic. A suggested path is to reuse TZIP-016 inerface and introduce several new Off-chain View kinds for deriving token balance updates (receipts).
---
tzip: 21
tzip: 021
title: Contract Multimedia Metadata
author: Josh Dechant (@codecrafting)
status: Work In Progress
......@@ -9,7 +9,7 @@ created: 2020-11-12
## Abstract
This proposal is an extension of [TZIP-16][1] and describes a metadata standard for
This proposal is an extension of [TZIP-016][1] and describes a metadata standard for
multimedia asset(s) linked with contracts.
## Motivation
......
---
tzip: 3
tzip: 003
title: TZIP Code of Conduct
status: Final
type: Meta
......
---
tzip: 4
tzip: 004
title: A1 - Michelson Contract Interfaces and Conventions
status: Deprecated
type: Application
......@@ -72,7 +72,7 @@ with field annotations, and all top-level union type arguments are unannotated.
Nevertheless, it is advisable that specific implementations adhere to a
consistent tree-struct convention, examples of which can be seen in various
extensions of this standard (such as [`TZIP-6`](/proposals/tzip-6/tzip-6.md)).
extensions of this standard (such as [`TZIP-006`](/proposals/tzip-6/tzip-6.md)).
### Example
......@@ -185,7 +185,7 @@ indentation and whitespacing rules.
This standard defines only tuples and unions of size two.
Introduced syntax sugar becomes especially useful in extensions of the
standard where this syntax is generalized
(see [`TZIP-6`](/proposals/tzip-6/tzip-6.md) for example).
(see [`TZIP-006`](/proposals/tzip-6/tzip-6.md) for example).
# CASE macro
......
---
tzip: 5
tzip: 005
title: FA1 - Abstract Ledger
status: Deprecated
type: Financial Application
......
---
tzip: 6
tzip: 006
title: A1.1 - Balanced Trees for nested or and pair types
status: Deprecated
type: Application
......@@ -9,9 +9,9 @@ created: 2019-05-04
## Summary
This standard extends `TZIP-4 (A1)` by defining a right-hand balance tree structure
This standard extends `TZIP-004 (A1)` by defining a right-hand balance tree structure
for `or` and `pair` types. Structure of comb defined in
[TZIP-4](/proposals/tzip-4/tzip-4.md#entrypoints) is the most obvious one, but the worst-case
[TZIP-004](/proposals/tzip-4/tzip-4.md#entrypoints) is the most obvious one, but the worst-case
performance of operations on it scales linearly with number of elements
in the comb which is suboptimal. Whereas tree structure allows reaching better
average performance of access and update operations.
......
---
tzip: 7
tzip: 007
status: Final
author: Konstantin Ivanov <kivanov@serokell.io>, Ivan Gromakovskii (@gromak)
created: 2019-04-12
......@@ -9,7 +9,7 @@ created: 2019-04-12
Parameter is the only easy way for a caller to pass some data to a contract.
We do not know in advance which data an arbitrary contract can use.
If we specify a concrete parameter type which is a tree of `or` types where each leaf corresponds to some method from TZIP-7, it means that contract can not have any other input data, hence it can not have methods other than those listed in TZIP-7.
If we specify a concrete parameter type which is a tree of `or` types where each leaf corresponds to some method from TZIP-007, it means that contract can not have any other input data, hence it can not have methods other than those listed in TZIP-007.
While we can use a proxy contract to adapt a more general parameter type to a concrete one, such an approach has the following disadvantages:
1. It is harder to implement and use, hence more error-prone.
In particular, special care should be taken to make sure that proper `SENDER` value is propagated by the proxy contract.
......@@ -24,11 +24,11 @@ Since the caller of a contract can specify an entrypoint she wants to invoke, we
## Why do not you require concrete shape of parameter tree?
Michelson documentation defines "a contract with entrypoints" as "a contract that takes a disjunctive type (a nesting of `or` types) as the root of its input parameter, decorated with constructor annotations".
We could require this disjunctive type to have a particular shape, e. g. to be a right- or left-hand comb or a balanced tree with all TZIP-7 methods located in some specific place.
We could require this disjunctive type to have a particular shape, e. g. to be a right- or left-hand comb or a balanced tree with all TZIP-007 methods located in some specific place.
However, such a requirement would have a few drawbacks:
1. It complicates composability of contract interfaces.
If our interface requires certain methods to be in a particular place and another interface has a similar requirement, these two interfaces most likely will be incompatible.
If we only require all TZIP-7 methods to have a common node in the tree of `or`s, we'll encounter an incompatibility issue if another interface has methods with the same names and a similar requirement.
If we only require all TZIP-007 methods to have a common node in the tree of `or`s, we'll encounter an incompatibility issue if another interface has methods with the same names and a similar requirement.
2. It imposes unnecessary restriction on contract developers.
We consider this restriction unnecessary, because the entrypoints feature allows one to call contract's method without knowing anything about its parameter shape.
Without this restriction high level languages can pick representation of nested `or` types which is more suitable for them.
......
---
tzip: 7
tzip: 007
title: FA1.2 - Approvable Ledger
status: Final
type: Financial Application
......@@ -33,7 +33,7 @@ See also:
This document does not specify contract metadata.
For a metadata specification, see
[TZIP-12](/proposals/tzip-12/tzip-12.md#token_metadata)
[TZIP-012](/proposals/tzip-12/tzip-12.md#token_metadata)
## Errors
......@@ -105,5 +105,5 @@ Also, ERC-20 is known to suffer from some vulnerabilities, and we took them into
account when implementing our interface.
[TZIP-12](/proposals/tzip-12/tzip-12.md) defines `FA2`: a contract standard
[TZIP-012](/proposals/tzip-12/tzip-12.md) defines `FA2`: a contract standard
that generalizes and extends `FA1.2`.
---
tzip: 8
tzip: 008
title: Payment Request Format
status: Work In Progress
type: Interface
......@@ -257,7 +257,7 @@ Decoding usually involves the following:
### Extensions
Some use cases would benefit from being able to transmit more information in the payment requests. This can be done by extending the standard. The extensions should be described by a separate standard and use a field based on the name of the standard to store their data. This will help avoid collisions with other extensions.
For example, an extension described in TZIP-0009 that adds an information field could store its data like this:
For example, an extension described in TZIP-009 that adds an information field could store its data like this:
```json
[
......@@ -296,7 +296,7 @@ The payload format closely mirrors the format expected by Tezos RPC, so that it
To make the standard as simple to implement as possible, we have decided against a more abstract payload format.
### Misc. Information Field
The requests only include a subset of fields from the RPC format. To keep the standard simple, there are no extra fields such as a miscellaneous information field to describe a transaction. This could then be displayed by users' wallet, but wouldn't be sent anywhere. Extensions to the standard are possible, and a misc. information field is described by [TZIP-9](/proposals/tzip-9/tzip-9.md).
The requests only include a subset of fields from the RPC format. To keep the standard simple, there are no extra fields such as a miscellaneous information field to describe a transaction. This could then be displayed by users' wallet, but wouldn't be sent anywhere. Extensions to the standard are possible, and a misc. information field is described by [TZIP-009](/proposals/tzip-9/tzip-9.md).
## Implementation
JavaScript implementation is provided as an [npm package called tezos-uri](https://www.npmjs.com/package/tezos-uri). The code can be viewed [at gitlab](https://gitlab.com/smartcontractlabs/tezos-uri). This section contains advice and ideas related to implementing the standard and integrating it with wallets.
......
---
tzip: 9
tzip: 009
title: Info Field for Payment Requests
status: Work In Progress
type: Informational
......@@ -13,7 +13,7 @@ Miscellaneous information extension for payment requests.
## Abstract
This document describes an extension to [TZIP-8](/proposals/tzip-8/tzip-8.md) that adds an extra field to Tezos payment requests. The field can contain simple description of payment or their purpose. Wallets can dispay this in transaction history or when approving the payment.
This document describes an extension to [TZIP-008](/proposals/tzip-8/tzip-8.md) that adds an extra field to Tezos payment requests. The field can contain simple description of payment or their purpose. Wallets can dispay this in transaction history or when approving the payment.
## Motivation
......@@ -44,7 +44,7 @@ Information about the purpose of the payment will use a field called `info` with
## Appendix
### TZIP-8 Implementations Supporting the Standard
### TZIP-008 Implementations Supporting the Standard
* TBA
### Wallets Implementing the Standard
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment