You are viewing a single comment's thread from:

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

in #eos • 6 years ago (edited)

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.

6 years ago in #eos by
$0.00
    5 votes
    Reply 8
    Sort:  
  • Trending
    • [-]
     6 years ago 

    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.

    [-]
     6 years ago 

    sure man, just hit me up at telegram @leordev - I will be glad to help!

    $0.00
      1 vote
      • and 1 more
      Reply
      [-]
       6 years ago 

      is there any guides to be a block producer?

      $0.00
        Reply
        [-]
         6 years ago 

        I just saw your post on stack exchange as well. Thanks for this super useful information.

        $0.00
          Reply
          [-]
           6 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.

          [-]
           6 years ago 

          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!

          $0.00
            Reply
            [-]
             6 years ago 

            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?

            $0.00
              Reply

              Coin Marketplace

              STEEM 0.26
              TRX 0.20
              JST 0.037
              BTC 94320.05
              ETH 3419.91
              USDT 1.00
              SBD 3.88