Paratoken Standard #32
Conversation
Initial draft of the Paratoken standard
| - [Asset Identification](#asset-identification) | ||
| - [Paratoken Structure](#paratoken-structure) | ||
| - [Base Interface](#base-interface) | ||
| - [Common Types](#base-interface) |
There was a problem hiding this comment.
| - [Common Types](#base-interface) | |
| - [Common Types](#common-types) |
| The paratoken standard enforces the use of [`Universally Unique Asset Identifier`](uuaid/uuaid.md) as an | ||
| identifier of the asset on its API. |
There was a problem hiding this comment.
I don't think uuaid/uuaid.md is included in the PSP, maybe add a hosted link?
There was a problem hiding this comment.
I'm also curious to learn more about Universally Unique Asset Identifier
There was a problem hiding this comment.
Yes, this needs further clarification
| /// owner. | ||
| fn create_asset( owner: Origin, policy: MonetaryPolicy); | ||
|
|
||
| /// Transfer the ownership of `asset` from `origin` to `target`. |
There was a problem hiding this comment.
| /// Transfer the ownership of `asset` from `origin` to `target`. | |
| /// Transfer the ownership of `asset` from `origin` to `new_owner`. |
| /// Mints new `amount` of `asset` and transfer to `owner` account. | ||
| fn mint( owner: Origin, asset: T::AssetId, amount: T::AssetBalance); | ||
|
|
||
| /// Destroies `amount` from `token` of `asset`. |
There was a problem hiding this comment.
| /// Destroies `amount` from `token` of `asset`. | |
| /// Destroys `amount` from `token` of `asset`. |
| // Balances and transfers | ||
| // =================================== | ||
|
|
||
| /// Transfers `amount` of `token` from `asset` from `from` account to `target` account. |
There was a problem hiding this comment.
| /// Transfers `amount` of `token` from `asset` from `from` account to `target` account. | |
| /// Transfers `amount` of `token` from `asset` from `from` account to `to` account. |
| token: T::TokenId, | ||
| amount: T::AssetBalance); | ||
|
|
||
| /// Fetchs the balance of `tokens` of `asset` for `owner` account. |
There was a problem hiding this comment.
| /// Fetchs the balance of `tokens` of `asset` for `owner` account. | |
| /// Fetches the balance of `tokens` of `asset` for `owner` account. |
|
|
||
| ## Policies | ||
|
|
||
| Polices define what is the behaviour of the asset for specific operations. |
There was a problem hiding this comment.
| Polices define what is the behaviour of the asset for specific operations. | |
| Policies define what is the behaviour of the asset for specific operations. |
|
@coinfork Feel free to ping me here, once you are happy with this. I can merge the draft, so that it’s easier to share and potentially to get additional feedback. |
Sounds good! We'll be pushing a few updates first. |
|
|
||
| /// Only this issuer can mint tokens but just once. | ||
| /// That ensures that no more tokens will be created after the first minting. | ||
| OneTimeIssuer(AccountId), |
There was a problem hiding this comment.
Is MintingPolicy mutable? If it is, then we don't need this. The asset owner can update the policy to NotAllowed after the minting is done.
There was a problem hiding this comment.
At the moment, MintingPolicy can be both mutable and immutable to suggest that OneTimeIssuer is required.
| token won't support any inflation. | ||
|
|
||
| ```Rust | ||
| struct Mutability { |
There was a problem hiding this comment.
| struct Mutability { | |
| enum Policy { |
Otherwise it is very confusing
and maybe you will also want something like
enum Mutability {
Immutable,
Mutable { by: AccountId },
}
There was a problem hiding this comment.
Scoped mutability is an interesting idea
There was a problem hiding this comment.
Having the attribute of mutability for a policy is confusing to me. Stuff will happen and policies must be updated.
Could something like below considered (having a set of authorities)?
/// Authorities with privilege to update policy.
/// `None` means no one can update the policy making it immutable.
pub type PolicyMakers = Option<Vec<AccountId>>;Some voting mechanism could also be implemented for PolicyMakers so it's "fair".
| pub enum Event<T: Config> { | ||
| /// A new asset was created by `owner`. | ||
| /// \[ asset_id, owner \] | ||
| AssetCreated(T::AssetId, T::AccountId), |
There was a problem hiding this comment.
| AssetCreated(T::AssetId, T::AccountId), | |
| AssetCreated { asset_id: T::AssetId, owner: T::AccountId }, |
Named fields are supported now, we might as well use it.
| } | ||
| ``` | ||
|
|
||
| ## Extension: Batch |
There was a problem hiding this comment.
maybe this should be in another meta operation standard?
There was a problem hiding this comment.
What is a meta operation standard? @xlc Can you elaborate?
There was a problem hiding this comment.
I mean this doesn't really needs to be token related. For features like batch transaction, proxy, multisig etc, they could be in another standard for those utility/meta operations.
There was a problem hiding this comment.
You might be right that that is preferable.
Note, though, that the proposed batch transactions here allow for optimizations (e.g. optimized batch minting of NFTs) which generic batches (e.g. via pallet_utilitly::batch) would not.
| | 0x0001 | 1.0.0 | [Batch Extension](extensions/batch.md) | | ||
| | 0x0002 | 1.0.0 | [Chunks Extension](extensions/chunks.md) | | ||
| | 0x0003 | 1.0.0 | [Enumerable Extension](extensions/enumerable.md) | | ||
| | 0x0004 | 0.1.0 | **TBD** Teleportation | | ||
| | 0x0005 | 1.0.0 | [Operator](extensions/operator.md) | |
There was a problem hiding this comment.
after scrolling down I found the ## Extension: * sections of psp-32.md
wouldn't it make more sense to point at these sections, instead of extensions/*?
|
|
||
| /// Creates a new asset using the given `policy` where `origin` will be the | ||
| /// owner. | ||
| fn create_asset( owner: Origin, policy: MonetaryPolicy); |
There was a problem hiding this comment.
Shouldn't this return an AssetId? MonetaryPolicy is not defined.
| amount: T::AssetBalance); | ||
|
|
||
| /// Fetchs the balance of `tokens` of `asset` for `owner` account. | ||
| fn balance(owner: Account, asset: T::Account, token: T::TokenId) -> T::AssetBalance; |
There was a problem hiding this comment.
What's the difference between asset (T::Account?) and token here?
| // =================================== | ||
|
|
||
| /// Returns the asset attribute of `key` for the given `asset`. | ||
| fn asset_attribute( asset: T::AssetId, key: T::AttributeKey) -> Option<T::AttributeValue>; |
There was a problem hiding this comment.
T::AttributeKey should be just AttributeKey, given that you define AttributeKey later on. I assume you intend this to be a shared/standardized type. The draft does not explain what "attributes" exactly are or for what purpose those should be used. You briefly touch on it in the summary at the beginning, but a (small) proper subsection would be better.
There was a problem hiding this comment.
Also, there are many assumptions about that generic type T. Should T implement a trait with specific associated types? All those associated types (Account, AssetId, AssetBalance) should probably be fixed and well defined anyway.
| The paratoken standard enforces the use of [`Universally Unique Asset Identifier`](uuaid/uuaid.md) as an | ||
| identifier of the asset on its API. |
There was a problem hiding this comment.
Yes, this needs further clarification
|
Please note that we also have to following drafts open: |
Initial draft of the Paratoken standard