Skip to content

Commit dc63ef4

Browse files
authored
Merge pull request #7 from Swader/v1
Proposing v1.0.0
2 parents 6e7b77d + 4def7be commit dc63ef4

File tree

16 files changed

+1192
-7
lines changed

16 files changed

+1192
-7
lines changed

CHANGELOG.md

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
## RMRK v1.0.0 - 05.02.2021.
2+
3+
> ⚠ Because 0.1 was so broken it would have required a very large custom processor for a very small
4+
> number of published RMRKs, we decided to deprecate it fully, CONSUME all published NFTs, and
5+
> re-issue them, re-sending to their owners (this was done in agreement with both the current owners
6+
> and the original minter).
7+
8+
### RIPs
9+
10+
- [RIP #001](https://github.com/Swader/rmrk-spec/issues/2): the NFT entity's computed ID field has
11+
been updated to include minting block number.
12+
- [RIP #002](https://github.com/Swader/rmrk-spec/issues/3): Embedded data - ability to directly add
13+
data to an NFT and a collection, avoiding reliance on third party metadata. Accompanying metadata
14+
is still recommended.
15+
- [RIP #005](https://github.com/Swader/rmrk-spec/issues/6): Changing recommendation to use
16+
`batchAll` instead of `batch`
17+
- [RIP #006](https://github.com/Swader/rmrk-spec/issues/10): Implemented EMOTE interaction
18+
- [RIP #007](https://github.com/Swader/rmrk-spec/issues/13): Removed version from collection payload
19+
20+
### Fixes
21+
22+
- Fixed some dead links and typos.
23+
- Standard versions have been added to MINT and MINTNFT where previously there were none. Tools
24+
should consider these interactions as 0.1 where non-specified.
25+
- NFT standard used "name" as "instance" and as missing "instance". This has been fixed and
26+
additionally clarified.

README.md

Lines changed: 10 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,8 @@ The standards currently cover the following basic interactions:
1717
- CHANGEISSUER changes the owner of the collection, affecting who can issue NFTs
1818
- SEND, BUY are transactional
1919
- LIST is used to list an NFT as for-sale on-chain
20+
- MIGRATE (starting with 1.0.0) allows a collection issuer to migrate a collection and its child
21+
NFTs to a new standard
2022

2123
Inspect each standard folder to see the specifics about these interactions and how to integrate
2224
them.
@@ -35,16 +37,18 @@ A released version is **never** worked on again - all changes must happen via [R
3537
and will apply to the next version only. It is up to the implementing library / UI to see previous
3638
versions as invalid or demand a migration from an old version to a new version of an NFT (this will
3739
usually involve a [CONSUME](#interactions) of an earlier NFT and a [MINTNFT](#interactions) into a
38-
newer version of the collection). To be kept up to date on version changes, please _Watch_ this repo
39-
or [subscribe to Dot Leap](https://dotleap.substack.com).
40+
newer version of the collection) or a [MIGRATE](#interactions) interaction. To be kept up to date on
41+
version changes, please _Watch_ this repo or [subscribe to Dot Leap](https://dotleap.substack.com)
42+
or [NFT Review](https://news.nft.review).
4043

4144
### Currently published standards:
4245

43-
- none
46+
- [0.1](https://github.com/Swader/rmrk-spec/releases/tag/0.1)
47+
- [1.0.0](https://github.com/Swader/rmrk-spec/releases/tag/1.0.0)
4448

4549
### Standards under development:
4650

47-
- [RMRK0.1](standards/rmrk0.1/README.md)
51+
- n/a
4852

4953
## Contributing
5054

@@ -97,8 +101,8 @@ To implement this, the CryptoKitties game devs would:
97101
> programmatically from CryptoKitties game devs' end, but this introduces a reliance on their
98102
> service for the continuation of the game.
99103
100-
> This is an active area of research which we hope to have ironed out by v1.0 of the standards -
101-
> ideally with an action-triggered MINT addition to the standard.
104+
> This is an active area of research which we hope to have ironed out soon - ideally with an
105+
> action-triggered MINT addition to the standard.
102106
103107
## Other Information
104108

dumps/remarks-4892957-5437981-0x726d726b.json

Lines changed: 362 additions & 0 deletions
Large diffs are not rendered by default.

implementers-guide.md

Lines changed: 31 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,14 +4,44 @@ Because RMRK is append-only and no state is being changed, every new block has t
44
introduce non-obvious state changes into the global NFT space living on RMRK. As an example, an
55
[NFT](standards/rmrk0.1/entities/nft.md) can change ownership due to a
66
[SEND](standards/rmrk0.1/interactions/send.md) interaction, or due to a
7-
[BUY](standards/rmrk0.1/interactions/send.md) interaction. It is an implementer's duty to reconcile
7+
[BUY](standards/rmrk0.1/interactions/buy.md) interaction. It is an implementer's duty to reconcile
88
all these changes across historical blocks to get an accurate picture of the current state.
99

1010
> Note: By implementing things in the wrong order or not following recommended implementation
1111
> guidelines, an implementer can cause financial loss to NFT minters, buyers, and sellers. There is
1212
> no way to distinguish invalid interaction submissions compatible with RMRK from those that are
1313
> valid, except by reconciling the **whole RMRK history from genesis**.
1414
15+
## Remark Dumps
16+
17+
For convenience, dumps of all RMRK remarks on Kusama in are stored in this repository for ease of
18+
use. Running the `fetch` function of [rmrk-tools](https://github.com/swader/rmrk-tools) with the
19+
appropriate block numbers will produce the same dumps, should one wish to double-check these data
20+
sets.
21+
22+
## Consolidators
23+
24+
Consolidators are tools that take as input a list of remarks from the chain (ideally from dumps -
25+
see above), process them one by one, and come up with a consolidated state of the NFT ecosystem on
26+
that chain. The reference implementation is the [rmrk-tools](https://github.com/swader/rmrk-tools)
27+
consolidator.
28+
29+
## Edge Cases and Caveats
30+
31+
### Missing version
32+
33+
Spec 0.1 had a bug - the version number of the standard was not included in the MINT and MINTNFT
34+
interactions. Where missing, this version should be implied to mean 0.1. Since 1.0.0 onwards every
35+
interaction has a version number.
36+
37+
### Batching
38+
39+
- `batch` operations are illegal since version 1.0.0 and `batchAll` should be used. See
40+
[RIP #005](https://github.com/Swader/rmrk-spec/issues/6).
41+
- whenever a single NFT has multiple interactions in a single block, ALL of them MUST be ignored and
42+
deemed invalid. This is to prevent various double spends and other tricks possible in the time
43+
span of a single block's execution.
44+
1545
---
1646

1747
This guide is still under development...

standards/rmrk0.1/README.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,3 +14,11 @@ The following **interactions** are possible:
1414
- [LIST](interactions/list.md) (List an NFT for sale)
1515
- [BUY](interactions/buy.md) (Buy an NFT)
1616
- [CONSUME](interactions/consume.md) (Burn an NFT)
17+
18+
## Known Issues
19+
20+
- some NFTs published under this standard have been published without dedicated tools and are
21+
malformed.
22+
[Example](https://polkascan.io/kusama/transaction/0xb8396caf702b3197cd6286b8d7424b255dd79e1e4d49e4a05ee66cae8d4bb3f3).
23+
- this spec version had a bug in that it did not specify a standard version in the MINT and MINTNFT
24+
interactions. When the version is missing from the MINT, it should be assumed to mean 0.1.

standards/rmrk1.0.0/README.md

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
# RMRK 1.0.0 standard
2+
3+
The following **entities** are defined:
4+
5+
- [COLLECTION + Metadata](entities/collection.md)
6+
- [NFT + Metadata](entities/nft.md)
7+
8+
The following **interactions** are possible:
9+
10+
- [MINT](interactions/mint.md) (Minting a collection)
11+
- [CHANGEISSUER](interactions/changeissuer.md) (Changing the issuer of a collection)
12+
- [MINTNFT](interactions/mintnft.md) (Minting an NFT inside a collection)
13+
- [SEND](interactions/send.md) (Sending an NFT to a recipient)
14+
- [LIST](interactions/list.md) (List an NFT for sale)
15+
- [BUY](interactions/buy.md) (Buy an NFT)
16+
- [CONSUME](interactions/consume.md) (Burn an NFT)
Lines changed: 121 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,121 @@
1+
# Collection
2+
3+
This standard defines how **Collections** of NFTs are minted. Collections cannot be sent and are
4+
effectively immutable after being created, with the exception of the issuer value. The current
5+
issuer of the collection can assign a new issuer using a CHANGEISSUER interaction.
6+
7+
## Collection Standard
8+
9+
A collection MUST adhere to the following standard.
10+
11+
```json
12+
{
13+
"name": {
14+
"type": "string",
15+
"description": "Name of the collection. Name must be limited to alphanumeric characters. Underscore is allowed as word separator. E.g. VALHELLO-ITEMS is NOT allowed. VALHELLO_ITEMS is allowed."
16+
},
17+
"max": {
18+
"type": "number",
19+
"description": "How many NFTs will ever belong to this collection. 0 for infinite."
20+
},
21+
"issuer": {
22+
"type": "string",
23+
"description": "Issuer's address, e.g. CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp. Can be address different from minter."
24+
},
25+
"symbol": {
26+
"type": "string",
27+
"description": "Ticker symbol by which to represent the token in wallets and UIs, e.g. ZOMB"
28+
},
29+
"id": {
30+
"type": "string",
31+
"description": "A collection is uniquely identified by the first four and last four bytes of the original issuer's pubkey and the symbol. This prevents anyone but the issuer from reusing the symbol, and prevents trading of fake NFTs with the same symbol. Example ID: 0aff6865bed3a66b-ZOMB."
32+
},
33+
"metadata?": {
34+
"type": "string",
35+
"description": "HTTP(s) or IPFS URI. If IPFS, MUST be in the format of ipfs://ipfs/HASH"
36+
},
37+
"data?": {
38+
"type": "object",
39+
"description": "See Data"
40+
}
41+
}
42+
```
43+
44+
When either metadata or [data](#data) is present, the other is optional. Data takes precedence
45+
always. Note that because metadata contains description, attributes, third party URLs, etc. it is
46+
still recommended to include it alongside `data`.
47+
48+
### Data
49+
50+
The `data` object is composed of:
51+
52+
- protocol (strict, see Protocols below)
53+
- data
54+
- type (mime type)
55+
56+
#### Protocols
57+
58+
| Protocol | Mime default | Description |
59+
| --------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
60+
| `ipfs` | image/png | Points to a directly interpretable resource, be it audio, video, code, or something else |
61+
| `http(s)` | image/html | Points to a directly interpretable resource, be it audio, video, code, or something else (not recommended for use) |
62+
| `p5` | application/javascript | Processing.js code |
63+
| `js` | application/javascript | Plain JS code |
64+
| `html` | text/html | HTML code, no need for `<html>` and `<body>`, can support dependencies but it's up to the author to prevent the dependencies from disappearing |
65+
| `svg` | image/svg+xml | SVG image data |
66+
| `bin` | n/a | binary, directly interpretable |
67+
68+
## Metadata
69+
70+
A collection SHOULD have metadata to describe it and help visualization on various platforms.
71+
72+
```json
73+
{
74+
"description": {
75+
"type": "string",
76+
"description": "Description of the collection as a whole. Markdown is supported."
77+
},
78+
"attributes": {
79+
"type": "array",
80+
"description": "An Array of JSON objects, matching OpenSea's: https://docs.opensea.io/docs/metadata-standards#section-attributes"
81+
},
82+
"external_url": {
83+
"type": "string",
84+
"description": "HTTP or IPFS URL for finding out more about this project. If IPFS, MUST be in the format of ipfs://ipfs/HASH"
85+
},
86+
"image": {
87+
"type": "string",
88+
"description": "HTTP or IPFS URL to project's main image, in the vein of og:image. If IPFS, MUST be in the format of ipfs://ipfs/HASH"
89+
},
90+
"image_data": {
91+
"type": "string?",
92+
"description": "[OPTIONAL] Use only if you don't have the image field (they are mutually exclusive and image takes precedence). Raw base64 or SVG data for the image. If SVG, MUST start with <svg, if base64, MUST start with base64:"
93+
}
94+
}
95+
```
96+
97+
## Examples
98+
99+
Collection:
100+
101+
```json
102+
{
103+
"name": "Dot Leap Early Promoters",
104+
"max": 100,
105+
"issuer": "CpjsLDC1JFyrhm3ftC9Gs4QoyrkHKhZKtK7YqGTRFtTafgp",
106+
"symbol": "DLEP",
107+
"id": "0aff6865bed3a66b-DLEP",
108+
"metadata": "ipfs://ipfs/QmVgs8P4awhZpFXhkkgnCwBp4AdKRj3F9K58mCZ6fxvn3j"
109+
}
110+
```
111+
112+
Metadata:
113+
114+
```json
115+
{
116+
"description": "Everyone who promoted [Dot Leap](https://dotleap.substack.com) via the in-email Tweet link is eligible.",
117+
"attributes": [],
118+
"external_url": "https://rmrk.app/registry/0aff6865bed3a66b-DLEP",
119+
"image": "ipfs://ipfs/QmYcWFQCY1bAZ7ffRggt367McMN5gyZjXtribj5hzzeCWQ"
120+
}
121+
```

0 commit comments

Comments
 (0)