...
 
Commits (7)
......@@ -32,7 +32,7 @@ alternative options, opinions, and objections.
| [TZIP-11] | Contract Specification Schema | 01/10/2020 | Work In Progress |
| [TZIP-12] | `FA2` - Multi-Asset Interface | 01/24/2020 | Draft |
| [TZIP-13] | `FA1.3` - Fungible Asset Standard | 01/02/2020 | Work In Progress |
| [TZIP-14] | GraphQL interface to Tezos node data | 02/03/2020 | Work In Progress |
| [TZIP-14] | GraphQL interface to Tezos node data | 04/01/2020 | Draft |
| [TZIP-15] | Token Whitelisting | 05/01/2020 | Work In Progress |
## How to Contribute
......
......@@ -90,8 +90,8 @@ the batch may contain zero or more entries and there may be duplicate token IDs.
Most token standards specify logic that validates a transfer transaction and can
either approve or reject a transfer. Such logic could validate who initiates a
transfer, a transfer amount, and who can receive tokens. This standard calls such
logic *permission policy* or *permission behavior*. Unlike many other standards,
transfer, the transfer amount, and who can receive tokens. This standard calls such
logic a *permission policy* or *permission behavior*. Unlike many other standards,
FA2 defines the default core transfer behavior, that MUST always be implemented
(see [Core Transfer Behavior](#core-transfer-behavior)), and a set of predefined
permission policies that are optional (see
......@@ -101,7 +101,7 @@ implement. Selected permission policies are applied to all tokens and token owne
managed by the FA2 contract.
The FA2 defines the following standard permission policies, that can be chosen
independently, when FA2 contract is implemented:
independently, when an FA2 contract is implemented:
* `operator_transfer_policy` - defines who can transfer tokens. Tokens can be
transferred by the token owner or an operator (some address that is authorized to
......@@ -109,16 +109,16 @@ transfer tokens on behalf of the token owner). A special case is when neither ow
nor operator can transfer tokens (can be used for non-transferable tokens). The
FA2 standard defines two entry points to manage and inspect operators associated
with the token owner address ([`update_operators`](#update_operators),
[`is_operator`](#is_operator)). Once an operator is added, it can manage all owner's
tokens.
[`is_operator`](#is_operator)). Once an operator is added, it can manage all of
its associated owner's tokens.
* `owner_hook_policy` - defines if sender/receiver hooks should be called or
not. Each token owner contract MAY implement either an `fa2_token_sender` or
`fa2_token_receiver` hook interface. That hooks MAY be called when a transfer sends
`fa2_token_receiver` hook interface. Those hooks MAY be called when a transfer sends
tokens from the owner account or the owner receives tokens. The hook can either
accept a transfer transaction or reject it by failing.
The FA2 standard defines a special metadata entry point ([`permissions_descriptor`](#permissions_descriptor))
that returns a *permissions descriptor* record. Permission descriptor indicates
that returns a *permissions descriptor* record. The permission descriptor indicates
which standard permission policies are implemented by the FA2 contract and can be
used by off-chain and on-chain tools to discover the properties of the particular
FA2 contract implementation.
......@@ -525,7 +525,7 @@ details see
[FA2 Permission Policies and Configuration](#fa2-permission-policies-and-configuration).
The FA2 contract MAY also implement an optional custom permissions policy. If such
custom policy is implemented, the FA2 contract SHOULD expose it using permissions
custom a policy is implemented, the FA2 contract SHOULD expose it using permissions
descriptor `custom` field by giving it a `tag` that would be available to other
parties which are aware of such custom extension. Some some custom permission MAY
require a config API (like [`update_operators`](#update_operators),
......@@ -696,8 +696,8 @@ Standard error mnemonics:
| `"TX_DENIED"` | A transfer failed because of `operator_transfer_policy == No_transfer` |
| `"NOT_OWNER"` | A transfer failed because `operator_transfer_policy == Owner_transfer` and it is initiated not by the token owner |
| `"NOT_OPERATOR"` | A transfer failed because `operator_transfer_policy == Owner_or_operator_transfer` and it is initiated neither by the token owner nor a permitted operator |
| `"RECEIVER_HOOK_FAILED"` | Receiver hook is invoked and failed. This error MUST be raised by the hook implementation |
| `"SENDER_HOOK_FAILED"` | Sender hook is invoked and failed. This error MUST be raised by the hook implementation |
| `"RECEIVER_HOOK_FAILED"` | The receiver hook failed. This error MUST be raised by the hook implementation |
| `"SENDER_HOOK_FAILED"` | The sender failed. This error MUST be raised by the hook implementation |
| `"RECEIVER_HOOK_UNDEFINED"` | Receiver hook is required by the permission behavior, but is not implemented by a receiver contract |
| `"SENDER_HOOK_UNDEFINED"` | Sender hook is required by the permission behavior, but is not implemented by a sender contract |
......
---
tzip: 14
title: GraphQL interface to Tezos node data - Scalars
status: Draft
type: Interface
author: Andrew Paulicek <[email protected]>, Miroslav Bodecek ([email protected])
created: 2020-04-01
---
## Summary
This document describes a set of custom scalars used in the GraphQL interface to Tezos node data.
## Motivation
Using custom scalars tailored to the Tezos types gives a lot of benefits for validation. Projects implementing Tezos GraphQL schema using these scalars will able to provide validation. It is especially useful for validating hashes and addresses, which are using `base58check` encoding.
## Specification
### Scalars
``` graphql
# Tezos address. Represented as public key hash (Base58Check-encoded) prefixed with tz1, tz2, tz3 or KT1.
scalar Address
# Timestamp specified as a ISO-8601 UTC date string (2020-02-04T15:31:39Z)
scalar DateTime
# JSON represents any valid JSON object
scalar JSON
# Raw Michelson expression represented as JSON
scalar MichelsonExpression
# Arbitrary precision number represented as string in JSON.
scalar BigNumber
# Micro tez. Positive bignumber. 1 tez = 1,000,000 micro tez.
scalar Mutez
# Operation identifier (Base58Check-encoded) prefixed with o.
scalar OperationHash
# Block identifier (Base58Check-encoded) prefixed with B.
scalar BlockHash
# Protocol identifier (Base58Check-encoded) prefixed with P.
scalar ProtocolHash
# Context identifier (Base58Check-encoded) prefixed with Co.
scalar ContextHash
# Operations identifier (Base58Check-encoded) prefixed with LLo (List of a list of operations).
scalar OperationsHash
# Chain identifier (Base58Check-encoded) prefixed with Net.
scalar ChainId
# Generic signature (Base58Check-encoded) prefixed with sig.
scalar Signature
# Public key (Base58Check-encoded) prefixed with edpk, sppk or p2pk.
scalar PublicKey
# Nonce hash (Base58Check-encoded).
scalar NonceHash
```
## Implementations
### Tezos GraphQL schema
Reference Tezos GraphQL schema using the scalars is defined here: https://gitlab.com/tezos-graphql/schema
### Scalar resolvers
Reference GraphQL scalar resolvers implementation for base58check types is available here: https://gitlab.com/tezos-graphql/tezos-graphql-nodejs/-/blob/master/src/resolvers/scalars/base58-resolvers.ts
## Related work
### TaaS-GraphQL
Reference implementation of the Tezos GraphQL schema and respective scalar resolvers is available here https://gitlab.com/tezos-graphql/tezos-graphql-nodejs.
### TezosLive.io
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