Analyzing the eosio.token contract we see that the token stats is stored under the SYM scope. So if I want to read a token stat, like supply, I need to execute:

cleos get table eosio.token EOS stats

Replace EOS for any token that you create. My question is why it's architected in this way? Wouldn't be better if it was stored in the _self scope? Because if I run this instead:

cleos get table eosio.token eosio.token stats

I can have and work with a list of all created tokens under this contract and have a better vision. Actually how could I list and know all the created tokens if I don't know each SYM scope?

3 Answers 3


By using the scope you can have easier fetches. Think of it like the exact index you are searching for without have to use upper/lower bounds.

If we take that same logic to a user's info we could do

cleos get table contract username account cleos get table contract username balance cleos get table contract username friends

instead of cleos get table contract contract accounts -L lower -U upper

Logically, I'm also sure this is better resource wise as it only has to check for a single record, and not iterate the set.

  • That makes sense. The only con that I see is that we don't have a way to list all the usernames in your scenario, or all the created tokens in mine. Is that correct? May 12, 2018 at 16:17
  • 1
    reference table
    – nsjames
    May 13, 2018 at 11:43
  • yeah so we always need to balance performance vs storage. I don't like it because in your scenario I could have username as primary key for all the three tables and always utilize get instead of play with lower and upper bounds... In the end I would need to test both to check bandwith vs storage, and which approach is worth it. May 13, 2018 at 12:42

Does anyone have the definition of scope ? To me, it basically looks like a way to compartmentalize data in a contract so that it only accessible within a certain space. In the above example, the data account balance and friends will exist in the contract only for the matching username given. When a different username is given as the scope, a new account balance and friends will exist for that usernames scope.

But also note that in that example account balance and friends are probably multi_index containers themselves and each can contain multiple data objects within them. So you could have multiple friends objects in your username scope.

In the token example, each account is used as the scope for the account balance. That way you have a container called accounts which holds multiple account objects, where each account object holds your balance for that given token symbol. This way when you query a users account using their scope you will get a list of all the tokens (every ticker symbol) that users has an account with a balance for.

I think they do it this way to keep all the token symbols that a users has in one place. Whereas if you scoped it to the contract itself, you would have to redesign the two containers accounts and currencys_stats where each account would need to hold each new token created, like with a vector or something. I guess this makes it easier to separate accounts from each other instead of getting a giant list of every account with every token symbol in existence. And easier to know who has to pay for the storage of each new token symbol added. How did they knew to design it like this in first place? Idk


The scope can be used to narrow down a table list to contain only some fraction of the total entries available.

However, you can also have the best of both worlds if you are willing to pay for the RAM involved.

Why not create a scope called global, which contains all of the entries from each individual scope, or alternatively contains a list of each scope name. Then you have a way to loop through several scopes at once as appropriate.

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.