You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updated polkadot dependencies to v1.2.0. sp-io is no longer exported from frame support, so had to add it directly as a dependency on the pallets, and update all imports accordingly. sp-std is no longer exported from frame support, so had to add it directly as a dependency on the pallets, and update all imports accordingly. The balance transfer method is exposed through the token Mutate trait so had to import it, and update the call to transfer with the correct parameters. DispatchError is no longer exported from frame support so had to import it directly from sp_runtime. The https://github.com/paritytech/substrate repository has been archived, so updated all dependencies to use the new repo https://github.com/paritytech/substrate
Copy file name to clipboardexpand all lines: README.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ An index is a short and easy-to-remember version of an address. Claiming an inde
18
18
19
19
The Recovery pallet is an M-of-N social recovery tool for users to gain access to their accounts if the private key or other authentication mechanism is lost. Through this pallet, a user is able to make calls on-behalf-of another account which they have recovered. The recovery process is protected by trusted "friends" whom the original account owner chooses. A threshold (M) out of N friends are needed to give another account access to the recoverable account.
-[Front End template](https://github.com/substrate-developer-hub/substrate-front-end-template) from Parity
67
67
68
-
2. Review tooling for data caching and query -[Useful API sidecar](https://github.com/paritytech/substrate-api-sidecar) from Parity -[Awesome Substrate tools section](https://substrate.io/ecosystem/resources/awesome-substrate/#tools)
68
+
2. Review tooling for data caching and query -[Useful API sidecar](https://github.com/paritytech/polkadot-sdk-api-sidecar) from Parity -[Awesome Substrate tools section](https://substrate.io/ecosystem/resources/awesome-substrate/#tools)
Copy file name to clipboardexpand all lines: docs/pallets-review/fruniques.md
+11-11
Original file line number
Diff line number
Diff line change
@@ -2,34 +2,34 @@
2
2
3
3
## Spawn mechanism
4
4
5
-
Taken from #1
5
+
Taken from #1
6
6
7
7
`Fruniques` is a stateful pallet. It needs to store additional data to maintain various relationships and state. We need to design/build the data structure for this additional state, as described below.
8
8
9
9
There are a few NFT protocols in the Polkadot ecosystem: https://wiki.polkadot.network/docs/learn-nft
10
10
11
-
Of these, we should build to the [`Uniques`](https://wiki.polkadot.network/docs/learn-nft#uniques) patterns. It is the implementation from Parity and I believe the most recent. It is the only one compatible with Statemint/Statemine. We can build to multiple protocols if it makes sense, but let's start with `Uniques`.
11
+
Of these, we should build to the [`Uniques`](https://wiki.polkadot.network/docs/learn-nft#uniques) patterns. It is the implementation from Parity and I believe the most recent. It is the only one compatible with Statemint/Statemine. We can build to multiple protocols if it makes sense, but let's start with `Uniques`.
12
12
13
-
In addition to a regular `Unique`, a [`Frunique`](https://hashed.systems/hashed-chain) needs to store a reference to the parent, a different `Unique`. There also needs to be a heuristic for specifying if metadata is inherited from the parent or not. It seems like Metadata is a set of Key:Value pairs that can be assigned at the `class` level (a group or collection of NFTs) and at the `instance` level (a single NFT).
13
+
In addition to a regular `Unique`, a [`Frunique`](https://hashed.systems/hashed-chain) needs to store a reference to the parent, a different `Unique`. There also needs to be a heuristic for specifying if metadata is inherited from the parent or not. It seems like Metadata is a set of Key:Value pairs that can be assigned at the `class` level (a group or collection of NFTs) and at the `instance` level (a single NFT).
> NOTE: the cannabis use case may be able to be implemented with a lighter weight protocol, but it seems like it might be handy to use the same structure
20
-
1. Seeds come from a vendor as a package with a count, e.g. 100 seeds in a bag. This bag is an `InstanceId` even though it actually contains 100 seeds.
20
+
1. Seeds come from a vendor as a package with a count, e.g. 100 seeds in a bag. This bag is an `InstanceId` even though it actually contains 100 seeds.
21
21
2. Seeds that germinate get cubed; others are scrapped.
22
22
3. When a seed is cubed, it receives its own `InstanceID` (I've been calling this a `spawn` function) for the first time. The count of seeds that did germinate should be tracked, but not individually, and they are scrapped.
23
23
4. Successful cubed seeds become mother plants; perhaps through some iteration or trial/error to discover most productive mother(s).
24
24
5. Mother plants produce clones (and may produce flower directly).
25
-
7. The parent-->child relationship is well represented as a [Directed Acyclic Graph](https://hazelcast.com/glossary/directed-acyclic-graph), which is what we are building on chain.
25
+
7. The parent-->child relationship is well represented as a [Directed Acyclic Graph](https://hazelcast.com/glossary/directed-acyclic-graph), which is what we are building on chain.
26
26
8. Clones may be sold directly to clone buyers.
27
-
7. Clones produce flower, measured in weight. When flower is harvested, the weight values of the material are recorded as continuous value. So the `InstanceId` would map this specific `bag of weed`, and there would also be a data element for weight.
27
+
7. Clones produce flower, measured in weight. When flower is harvested, the weight values of the material are recorded as continuous value. So the `InstanceId` would map this specific `bag of weed`, and there would also be a data element for weight.
28
28
29
-
The sum of this continuous value for all peers should always equal the continuous value of the parent. This is a critical feature that maintains the economic hierarchy of the NFTs. Tax credits can be subdivided based on this continuous value, but just like the weed, none can be lost or compromised along the way. This feature - the `NFT Rollup` enables many use cases.
29
+
The sum of this continuous value for all peers should always equal the continuous value of the parent. This is a critical feature that maintains the economic hierarchy of the NFTs. Tax credits can be subdivided based on this continuous value, but just like the weed, none can be lost or compromised along the way. This feature - the `NFT Rollup` enables many use cases.
30
30
31
31
9. Flower gets tested, and results are implied across that entire harvest/mother? The test results include a set of files and also a set of values. We need a structure to assign this data/metadata across the appropriate `InstanceIds`.
32
-
10. Flower is sold to dispensaries.
32
+
10. Flower is sold to dispensaries.
33
33
34
34
-[ ] Research and prototype a pallet data storage mapping to hold the appropriate data to maintain the hierarchy and enforce the aggregation rules.
0 commit comments