The existing code,
auto to = to_acnts.find( value.symbol.name() );
if( to == to_acnts.end() ) {
to_acnts.emplace( ram_payer, [&]( auto& a ){
a.balance = value;
});
} else {
to_acnts.modify( to, 0, [&]( auto& a ) {
a.balance += value;
});
}
This means that should the receiver not be pre-existing in the table with the corresponding symbol then the sender pays the RAM cost to create a record to do so.
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.
Then, your own computer can listen for such action, check if they're on the airdrop list, and then trigger a transfer action, transferring the tokens to the receiver without such RAM cost.
This wouldn't cast the net as wide as one would like as not every planned recipient would hit this 'register' action, however, you could have an 'Airdrop period' where if you do his this action, you're guaranteed to get the token early/day 1, if you don't, then you'll have to wait a little longer.
hey @johnwilliamson nice idea buddy! with that we don't even need an intermediary table! it looks perfect! I'm still waiting for @dan answer because I don't want to redo any job if he tell us that they are planning or working in something of
eosio.tokento claim tokens already!That would mean the tokens are effectively moved from the smart contract account to the users account? or the user just pay the RAM used for his row in the smart contract?
Yes. This would have happened anyway once a user moves the tokens, however, if the airdropper doesn't want to pay that upfront cost initially or doesn't have enough confidence that those who receive the tokens will move them quick enough they can look into using this solution.