Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow set metadata parameters on JettonInit phase #23

Open
ya7on opened this issue Dec 27, 2024 · 3 comments
Open

Allow set metadata parameters on JettonInit phase #23

ya7on opened this issue Dec 27, 2024 · 3 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@ya7on
Copy link
Member

ya7on commented Dec 27, 2024

At the moment only following parameters could be set on jetton deploy/init:

  1. jetton_name
  2. jetton_description
  3. jetton_symbol
  4. max_supply

And if jetton master should be initialized with any other paramter like image_data or decimals it will only be possible via another request to jetton (JettonSetParameter)

I suggest to update JettonInit message with dynamic list of input fields to allow initialize jetton with any metadata fields

But how to do this? At the moment i don't have good solution for it

@ya7on ya7on added enhancement New feature or request question Further information is requested labels Dec 27, 2024
@iamIcarus
Copy link
Collaborator

iamIcarus commented Dec 27, 2024

My first thought is to adopt a similar approach as the optional custom_payload used in the JettonTransfer message. In this case, we could introduce a parameter named something like metadata , which would serve as a flexible container for additional fields such as image_data, decimals and others.

The metadata parameter could map to a struct that accommodates all optional parameters.

Do you prefer a dynamic list (dictionary) of input fields instead of this?

@ya7on
Copy link
Member Author

ya7on commented Dec 27, 2024

Do you prefer a dynamic list (dictionary) of input fields instead of this?

I think it should be dynamic list because we can't describe all possible fields of metadata in advance. Some jettons theoretically could have custom logic for metadata fields.

The metadata parameter could map to a struct that accommodates all optional parameters.

You mean something like this?

message JettonInit{
  // non metadata fields first
  max_supply: Int;
  // metadata fields will be stored like in `contracts/teps/tep64.tact`
  // key - sha256 of string key
  metadata: map<Int, Cell>
}

@iamIcarus
Copy link
Collaborator

iamIcarus commented Dec 27, 2024

I was thinking something like the below, a structural predefined optional values. Your suggestion to have metadata as a map will be more future proof to changes

message JettonInit{
  // non metadata fields first
  max_supply: Int;
  //.....
  //.....
  //.....
  metadata: Cell?;
}

struct Metadata {
    decimals: Int? as uint256;
    totalSupply: Int? as uint256;
    name: Slice?;
    string: Slice?;
    attributes: Cell?;      
    //....
    //....
    //...
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants