But you could produce a signature which proves that you own the private key associated with a historical hunter for banking its coins, right?
A voting system could even work without such a proof, and be really simple and fast.
For example, vote is cast by sending coins to the "historical hunter" player address.
The voting must have a closing time (block height), the actual vote (i.e. yes or no, 1 or 0, or perhaps a choice #1, #2 ... #10), and a "weight" in coins.
If 2 different polls never have the same closing time, and closing time is always multiple of 100, then to vote "Yes, #4, for the round of voting that closes at block 1358000, with a weight of 50k" can be done by simply adding all these numbers and sending 50000.01358014 coins to yourself.
If recipient is not a historical hunter's address (on record in game state), the act of voting can create a new record, with
"unknown whale" as hunter name. (*)
parsing of all incoming payments
https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/gamedb.cpp#L94gamestate record,
this doesn't interfere with normal huntercoin function, and it's probably easy to include both in daemon
https://github.com/wiggi/huntercoin/blob/betterQt-with-storage/src/gamestate.h#L279A vote would be overwritten by one with more coins, and deleted if its tx id (what is the fastest way to get OS independent hash of it?) is seen as "input" of another tx.
(*) Min amount can be low or zero but then it's stored only for a few days, to avoid spam.
Same if NPCs start to do artificial atmospheric actions, sneak around, or give cosmetic items to hunters
(i.e. the facility that can store items forever is an item itself)