You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 30, 2022. It is now read-only.
token::add_balance would assert that the table row it finds (to) exists. That way a eosio.token::transfer would never charge RAM to any user (other than the loophole with notified contracts which is dealt with separately with the subjective fix in eos v1.2.3 and eventually with an objective fix that comes with a protocol upgrade).
This change in behavior would mean that it would no longer be possible to use a single eosio.token::transfer action to transfer some token to a recipient that does not have a table row associated with that token. Since the table rows already are not automatically removed when the balance reaches zero but instead requires an explicit close action, it should typically not be a problem except for the first time the token is being received.
To solve that bootstrapping problem, a new action eosio.token::open (see EOSIO/eosio.contracts#61) can be used to create the appropriate zero-balance table row at the expense of the payer that authorizes that open action.
It may be typical for the recipient themselves to pay for the initial RAM of opening that zero balance table row so that they can receive those tokens from others. However, some users or contracts may wish to pay for that cost themselves. For example, an unsolicited airdrop may prepend the transfer operation with the open action to ensure the airdrop goes through. An "airgrab" which wants to reduce RAM costs of the token issuer may instead require the user requesting the airgrab to first open the zero balance table row.