This is a follow up to my previous study that you can find here: https://steemit.com/eos/@leordev/eos-ram-and-bandwith-analysis-airdropping-steps-on-junglenet - If you didn't read it yet, go ahead to understand the airdrop steps and costs.

I've just been in touch with the community about this study and about Dan's Token Claiming comment, which was pretty much like a ninja: threw a bomb and pooof.... Gone! See below:

Dan Larimer like a NINJA!

The Airdrop costs is something being discussed in the community, not a problem for big players, but it is for indies devs like me. So let's see how claiming a token would recover the airdrop costs.

Token Claiming

So after thinking a lot about of that, and talking about it with other community members, @nsjames just opened my eyes to this:

   if( from.balance.amount == value.amount ) {
      from_acnts.erase( from );  // <<< IMPORTANT LINE
   } else {
      from_acnts.modify( from, owner, [&]( auto& a ) {  // <<< IMPORTANT LINE
          a.balance -= value;
      });
   }

Code from official eosio.token contract, check it here: https://github.com/EOSIO/eos/blob/master/contracts/eosio.token/eosio.token.cpp#L97

The above code is from eosio.token::sub_balance and that's what I think @dan meant by "after people claim their tokens you get the ram back".

Whenever a user transfer his tokens to any other account, it will obviously execute the sub_balance to verify, calculate and subtract the user balance. The magic happens here: by doing that, the owner of this balance will automatically be set to be the payer of balance record - so this is the moment that it leaves the RAM of the Airdropper account. (This token balance will be even erased in case the new balance is zero - to free any RAM from whoever would be the owner. Nice optimization!)

So, if you airdropped your tokens to thousands of accounts, you can simply wait for the token owners start to move their tokens, because they will be set as the RAM payers and you will start to recover your initial investment of RAM back to your dApp! GENIUS!!!

I only see a problem with that... The above "auto-claim" upon token usage is amazing but maybe does not work for low funded developers, indies, that still want to have a chance to airdrop... Also even recovering upon usage we will never know when the accounts will start to use the tokens, so the RAM allocation can be recovered in 1 month, or 10 years, who knows?

How to achieve ZERO cost Airdrop with ZERO Investment?

I was already thinking about ideas to create an intermediary claiming table that the users could register for a drop and then transfer it after with a claiming action somehow yadda yadda... That's when super @johnwilliamson came up with this idea:

What if we created a preexisting record where there was a 'register' method which allowed anyone to call it and create an empty record in the to_acnts table, with a balance of 0.0000.
John Williamson in comment in the previous RAM & Airdropping Study

This is great! So if we create an action in our dApp contract, as suggested by John, called register (as for Airdrop Register) which creates a zero balance record in our accounts table with the RAM being allocated by the benefitted airdrop user, the costs of the Airdrop will be ZERO!

Nice solution huh? I see a lot of positive effects for doing that like setting up an Airdrop registration with deadline to create urgency and attention about your project, create a nice beautiful hot site for it explaining your project and so on... It's all Market Food and should be nicely used to promote your project and inform the users what they should expect from you. I bet that with automatic claim approach there will be a lot of people receiving Airdrop of projects that they don't care.

The cons of this approach is that there are people that will probably miss your airdrop, and here I see also more market food like fallbacks campaigns. Now, if you airdrop to everyone, people that don't care about your project will start to move the market by getting rid of your tokens... I guess....I think it's just a matter of planning the best fit of your project, if you want to select your public, etc... I'm just a good developer, horrible at economics and marketing, sorry about even trying to have an opinion about that lol :)

Tooling

So with all of this we see that we have at least two Airdrop options and in both of them you will have your RAM back at some point, or not even needing to allocate any.

As of today's date, the price of the RAM is ~0.017 EOS/Kb (~$0.185 USD) which would totalize around 639 EOS compared to 563 from my prior post from 3 days ago. That's almost 80 EOS difference! Do you know how I easily calculated it this time? With the amazing EOS Resource Planner:

Thanks @eosnewyork for building this great tool! The community appreciates it!

Finally, after you plan and setup your airdrop strategy you still need to issue the tokens. Do you have any idea in how to do that? I have, check these Airdropping tools:

https://github.com/EOSEssentials/EOSDrops - @nsjames shining again

https://github.com/EveripediaNetwork/airdrop - this is the airdrop script that Kedar from the huge Everipedia is working on

I can see both are under development, so my strategy will be to get some popcorn and just wait for the progress of these two geniuses! Just kidding guys, let's collaborate the way we can!

More of RAM, Bandwith and CPU

Are you aware of MonsterEOS? Not yet? Access http://monstereos.io - It's a tamagotchi game that I've being developing for fun and just released on the MainNet with the help of @johnwilliamson (BIG THANKS BUDDY!) - go ahead and create your first Monster, as I'm writing this there's almost 600 created monsters:

ooops... I don't think @dan will like his face on that picture...

I'm having such a GREAT learning experience about RAM, CPU and Bandwith usage. Like people that could not feed their pet because of CPU. Crazy huh? So think about that, people can't create a lot of monsters if they don't have enough resources to keep them alive, you need to feed, put the pet to sleep and wake them up every day. Not to say that each monster allocates around ~290 bytes of the user RAM.

Anyways, I just brought this up because I will probably release more studies about EOS resources usage, but no more talk about airdroppings.

Case Closed for Airdropping Resources!