Aspects of the EOSIO blockchain core functionality exist as system contracts which you can see here: https://github.com/eosio/eosio.contracts. The top 21 elected block producers can make changes to the system while it's running which automatically updates how the chain functions. The last major onchain update to the system contracts was v1.2.1 as you can see here: https://eosauthority.com/approval/view?scope=argentinaeos&name=systemupv121&lnc=en
There have been a number of new features, bug fixes, and performance improvements since then. We're proposing an upgrade to the eosio.token contract to what you can see in the latest release version 1.5.1: https://github.com/EOSIO/eosio.contracts/releases/tag/v1.5.1
The token contract has not been updated since the initial launch of the chain. You can see a code diff of the changes to deploy here: https://gist.github.com/lukestokes/39180d103799e0bbaafedb928f19198b (or view it yourself with the git command git diff v1.2.1...v1.5.1 eosio.token)
Upgrading the token contract is important because it uses the updated compiler which provides better performance. The CPU performance of the chain is an important thing to continuously improve for EOS users.
It's important for block producers and concerned community members to independently verify these changes to ensure what is deployed on chain is exactly was is expected and what has been tested for months on the Jungle Testnet. The steps to verify these changes have been outlined in this blog post along with a video showing an example of how it works: https://steemit.com/eos/@lukestokes/how-to-review-an-eosio-set-code-multisig-transaction
According to the release notes here https://github.com/EOSIO/eosio.contracts/releases, the eosio.token code was modified to support eosio.cdt v1.4.x and eosio v1.4.x. It also had changes in the following releases which this deploy will include:
v1.4.0:
Token contract The eosio.token::open action will now verify that the symbol provided to the action actually exists before attempting to open a new zero-balance table row for the symbol (#102).
v1.3.0:
Token contract A new action open (#61) is introduced to complement the existing close action. The open action allows an arbitrary payer to create (and pay for the RAM of) a new zero-balance token table row for an account. The initial setup using the open action makes it possible for a transfer of that token to the account (even for the first time) to not incur RAM costs to the sender.
This new action is the first step in a significant change in the behavior of the transfer action of the eosio.token contract.
As was discussed in a prior blog post, a recommended EOSIO protocol upgrade will eventually be introduced to objectively enforce the restrictions on billing RAM to other accounts from within the context of an action notification (which as of the v1.2.3 release of EOSIO is already possible to enforce subjectively by block producers).
And now as part of this release, the current behavior of eosio.token::transfer to implicitly create a token table row if one does not already exist is deprecated, and the new behavior of the action (#62) will eventually be enforced in a future release of eosio.contracts. The new behavior (which is not yet enforced as of this release) will require a zero-balance token table row to already exist in order for the transfer to succeed. Clients that want to maintain the old behavior of transfer going forward (for example unsolicited airdrops that should succeed even if it means the sender has to initially pay the RAM costs for the receiver) should modify their transactions to first open the balance before they then transfer the token into that new balance.
With the above two changes (objective enforcement of restricted RAM billing during notify and no table rows implicitly created during a eosio.token::transfer action) eventually fully realized, it would become possible to guarantee that the sender of tokens via a simple eosio.token::transfer action would not be billed additional RAM.