You are viewing a single comment's thread from:

RE: EOS RAM and Bandwith Analysis: Airdropping steps on Junglenet

in #eos6 years ago (edited)

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.

Sort:  

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.token to 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?

Coin Marketplace

STEEM 0.22
TRX 0.20
JST 0.034
BTC 92868.99
ETH 3121.42
USDT 1.00
SBD 3.14