Dan, thanks a lot for your input, it means A LOT to me!
So, that's something that I'm discussing with other fellas... What means "people claim"? I'm already engaged to create a claim action and setup a claim table (intermediary), so when people claim their airdrop I would just transfer from my contract account to the claimer account setting the claimer as the payer.
Am I missing something? It's already out-of-the-box on the issue action? Because it does not look like as the issuer is the payer.
I am confused about this as well, because in the eosio.token contract, the issuer pays for the new tokens storage. Even if you issued to a middleman account, the sender (from) always pays for storage, correct? @leordev I would love to be apart of this discussion with you and your team. I am also thinking about how the eosio.token contract is implemented on the mainnet and how we can create our own tokens using this contract.
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.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?
Dan, thanks a lot for your input, it means A LOT to me!
So, that's something that I'm discussing with other fellas... What means "people claim"? I'm already engaged to create a
claimaction and setup a claim table (intermediary), so when people claim their airdrop I would just transfer from my contract account to the claimer account setting the claimer as the payer.Am I missing something? It's already
out-of-the-boxon theissueaction? Because it does not look like as the issuer is thepayer.I am confused about this as well, because in the
eosio.tokencontract, theissuerpays for the new tokens storage. Even if you issued to a middleman account, the sender (from) always pays for storage, correct? @leordev I would love to be apart of this discussion with you and your team. I am also thinking about how theeosio.tokencontract is implemented on the mainnet and how we can create our own tokens using this contract.sure man, just hit me up at telegram @leordev - I will be glad to help!
is there any guides to be a block producer?
I just saw your post on stack exchange as well. Thanks for this super useful information.
The existing code,
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?
Eos updates are still being posted on Steem Blockchain........ When will you update us on 2.0? @dan
nice! but if people never claim, can sender rescind tokens sent to restore ram?
probably burn it after some period? so only active users get it