Thanks Leo! I had assumed that the token owner always owned the RAM so this caused me to go back and look at eosio.token.cpp. So it looks like in the standard eosio.token, when you get an airdrop, the token contract (party 1) owns the RAM. But if the holder (party 2) then does any other transfer, say to party 3, party 2 is now owns the row of RAM in party 1's multi-index. This is really interesting becuase I did not realize that multi-index had row-level ram ownership. However this party 2 ownership appears to take place only if party 3 did not previously have an entry for that token. If party 3 did own some of ABC token already, then to_acnts.modify is called, in which case the existing RAM owner is maintained. Does this all sound correct?