3

I need to create my.token smart contract on EOS that will be exactly the same as eosio.token contract but my.token's symbol_code will allow a much bigger string. Something like 50 character long instead of just 7 uppercase letters.

with eosio.token you can have balances like: "10.0000 EOS", "1234.0000 KARMA", etc
what I need is to be able to have balances like: "10.0000 this.is.the.custom.name.of.the.currency"

I'm planning on replicate the asset definition replacing the symbol_code class with a my_symbol_code class in which i will be reimplementing the three key functions responsables for making the transformation some_kind_of_number_type <==> std::string back and forth; those functions tree are:

symbol_code( std::string_view str ); // the constructor
char* write_as_string( char* begin, char* end ) const;
bool is_valid() const; // cheks the string length

I will try to replicate the 12-max-character encoding strategy for eosio::name which uses uint64_t as numerical representation, but I will be using uint256_t in order to reach a 48-max-character encoding.

Since only uint64_t can be the returning type of the primary_key function, I will be using multi_index.available_primary_key for PK and I will create a uint256_t secondary index key for this "long string symbol code" implementation. Then the logic of my.token smart contract must use this secondary index instead of primary.

Q: how to implement a 48-char-long symbol token? is this approach ok?

I would love to have your opinions and suggestions about this plan, whether you know a better solution or you see a technical problemas or whatever knowledge that can make me save time in achieving this goal.

Thanks

1
  • Instead of writing your question like this, why not pose it is a proper question and then submit your own answer to it. People can then edit the answer and improve it or give comments on it. This is totally OK in stackexchange! Commented Nov 22, 2018 at 9:25

1 Answer 1

2

Yes, your approach is good. Only issue is efficiency. Your tokens will be processed using more CPU than the regular eosio.token contract tokens due to the extra steps to match by the secondary key.

Good luck, and don't forget to share a link to the implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.