[EDIT:] The old proposal required another Storage flag, but now it doesn't need anything, except an interop method Storage.Add. Using it, and mempool value caches, verification transfers can be performed safely.

Example:

// .... during verification
Storage.Add("myaddress", -100);
Storage.Add("youraddress", +100);

This is supposed to work on verification, because values can be cached on mempool, and when Block is finally proposed, the "correct" value will be calculated following to tx deterministic order. So, if Tx A transfered something as network fee, and Tx B tries to do the same, this "double spending" won't be allowed on mempool time (not need to wait for block processing).

[EDIT:] old explanation using flags.
There's a nice solution for Neo native and user tokens, if we create the concept of Storage for balances. Usually, a Storage can hold any kind of information, and it could be read-only or read-write, depending on an attribute. We propose another attribute isBalance, that can also be used together with the const attribute.
The behavior of isBalance key is the following: it only accepts non-negative bignumbers; every change creates a an special notification that can be aggregated after contract execution.

Example:

// creating a storage balance
BigInteger funds = 0;
Storage.PutEx("myscripthash", funds, StorageAttribute.IsBalance);
// This automatically generates a notification `contract_hash + special balance flag + key + value_changed_up +funds`
// ...... NEP-5 transfer example 
BigInteger myfunds = Storage.Get("myaddress");
BigInteger yourfunds = Storage.Get("youraddress");
Storage.Put("myaddress", myfunds - value_transfer);
Storage.Put("youraddress", yourfunds + value_transfer);

This helps implementing network fees in verification time (will explain better on a longer proposal): neo-project/specification#3