OutlierVentures/QTM-Interface

Implementing agent utility share and meta utility share allocations

Closed this issue · 13 comments

This is now the issue for working on the agent <> utility interaction.

Note that the holding supply amounts (From Holding Supply of prev. Month + Incentives + Airdrops) are not processed yet as they depend on later modules/steps!

However, you should have some data to start with for the utilities considering the green tested rows.

Note that utility share allocations (QTM rows 103 to 108) should be calculated from the individual agent utility share allocations. There are no "agent utility share" allocations being calculated in the spreadsheet QTM version, but we should do it for the radCad version to keep track of which agents allocate how many tokens to which exact utility. You'll find corresponding utility attributes for agents are already being integrated. See the picture below for reference.

So far these attributes are not used and the logic for them being used still has to be implemented.

image

Originally posted by @achimstruve in #25 (comment)

Can you help clarify this for me. For the utilities do you want me to calculate it at the macro level like in the model or use the agent level to get the high level calculations because now the functionality is in there?

And if I am aggregating from the agent level I assume I should be updating the agents attributes too? let me know.

  • First you need to calculate the utility share allocations on the agent level.
  • Afterwards you aggregate their numbers to the macro numbers. These should then match the results from the QTM rows 103 to 108. You might need to introduce some more state variables for that (e.g. in the token_economy dictionary)
  • Calculating utility share allocations on the agent level means that you should use those agent attributes to store the respective values.

I hope this is clear. If not, don't hesitate asking more!

That all makes sense, thank you.

I will likely make a new meta bucket allocation dictionary within token economy with each allocation as key pairs.

I wonder if it's worth while to create a general purpose function to aggregate agent attributes to a macro level. It could be useful for holding/selling/utilities/vesting and probably a bunch more

i.e. agent_aggregation(attribute,agents)
Go through each agent based on the attribute and return a macro value

It looks like you might have already started a file to do this? agent_utility_behavior? I am a little confused on what you have built vs what we need. I am going to do my best to get some things done but on our next call it might be helpfully to spend some time looking at all of the different files as a whole and talking about them. We have agent_utility_behavior, agent_meta_bucket_behavior which seem like they are solving for the same thing? or if not they are close enough in goals where they should just be one

I think one thing that would be helpful is if we could highlight the items in the sheet when we have them but also add the dataframe location to the left of the item so we dont duplicate what is built

If you could give me edit access to that model excel sheet I can label the data frame location of some of the variables so we can use it as an improv data dictionary. Also not all variables on the sheet need to be in state variables, just because of excels format you had to explicitly states them all but we should focus on just storing the ones that we need to leverage across modules and for presentation at the end

That all makes sense, thank you.

I will likely make a new meta bucket allocation dictionary within token economy with each allocation as key pairs.

I wonder if it's worth while to create a general purpose function to aggregate agent attributes to a macro level. It could be useful for holding/selling/utilities/vesting and probably a bunch more

i.e. agent_aggregation(attribute,agents) Go through each agent based on the attribute and return a macro value

The 3 meta bucket allocation attributes are already contained in the token_economy state variable dictionary. Also they are already getting updated along with the individual agent meta bucket allocations. However, we could put the 3 meta bucket allocations inside a dictionary inside the token_economy dictionary if we want. Not sure if this will provide a benefit.

Good idea with the macro level aggregation of agent attributes! You can do it, if you want!

It looks like you might have already started a file to do this? agent_utility_behavior? I am a little confused on what you have built vs what we need. I am going to do my best to get some things done but on our next call it might be helpfully to spend some time looking at all of the different files as a whole and talking about them. We have agent_utility_behavior, agent_meta_bucket_behavior which seem like they are solving for the same thing? or if not they are close enough in goals where they should just be one

You are right that I created two agent behavior related files. This is the background:

  • agent_meta_bucket_behavior.py: its purpose is the management of individual meta bucket allocations for agents as well as the aggregation towards the macro token_economy dictionary.
  • agent_utility_behavior.py: this was the old script I used previously. I abandoned it to streamline the process more towards the implementation we see in the spreadsheet QTM. As you see it is nowhere used in the whole model and incomplete. I just left it there in case you want to have a look at it for the individual agent utility allocations as I already started thinking about it back then. You can either use that file and build it out or you create your own new one and build it from scratch. In the later case feel free to just delete it.

If you could give me edit access to that model excel sheet I can label the data frame location of some of the variables so we can use it as an improv data dictionary. Also not all variables on the sheet need to be in state variables, just because of excels format you had to explicitly states them all but we should focus on just storing the ones that we need to leverage across modules and for presentation at the end

You should have editor rights on this QTM version now. I agree that we do not necessarily need all data table rows being represented as a state variable. Which of these would you consider leaving out?

Hey thanks for all of the clarification. I was stuck on that meta_utilities file because I did not know if you were about to implement it or not for the utility bucket micro allocations.Now that I know you are not I will just move forward and just build my own.

Thanks for the editing rights, for example stuff like the token removal % and token amount. These values are needed for a higher up calculation at every step but we can just calculate them with the simulation on the spot and not store them anywhere because we have no real need to leverage them outside of their simulation calculation.

Also if I have the meta bucket allocation couldn't I just work down to the utility micro allocations? Or is there a reason to go bottoms up with agents? Do each of them have their own allocations? or is that something we are hoping to build out now and leverage later?

Also if I have the meta bucket allocation couldn't I just work down to the utility micro allocations? Or is there a reason to go bottoms up with agents? Do each of them have their own allocations? or is that something we are hoping to build out now and leverage later?

There are two different "meta bucket categories":

  1. The macro level meta buckets
  2. The agent level meta buckets

Both are already available (see also the green marked rows in the spreadsheet QTM):

  1. is in the token_economy dictionary and not calculated in the spreadsheet QTM
  2. is stored in the corresponding individual agent attribute

The utility share allocations should be calculated from the agent level meta buckets. This is how it is done in the spreadsheet QTM as well. If you see any benefit in going another route, I am very open to hear it.

hey I think we can close this to clean up our issues board.