Although an AT can work well as a way of distributing funds (within limits of the number of accounts it could do so due to memory constraints) the main issue I see is that AT has little knowledge of what is "going on" within the blockchain it sits on (and this is pretty much by design so it can be "portable" across different blockchains that use different "proofs").
Perhaps we could add some "platform specific" AT API functions to help with this kind of thing but it for now I doubt it is going to be a priority for our team (we are always happy to have others join us if others want to push to get platform specific features provided).
for me the idea that one AT "speaks" to another is the interesting part in this pool concept.
this way i hope to be able to secure the mined balance for the pool.
setting up an AT which handles the coin sending to the pool AT may be sufficient.
a simple trigger if the balance of a mining AT reaches a block reward level increase should still work.
to prevent that nobody can simply send coins to the pool AT to become included in the coin distribution the pool AT shall only consider coins send by the mining AT as valid. but if someone adds a triggerable amount of coins to his mining account it should not break the overall coin distribution dramatically simply because this miner may get on average less coins back than send.
regarding the fees i am not sure if all this makes sense.
based on a timeframe of one week the miners AT would have to run about 2520 times.
if the cost for code executions are evaluated on runtime the short version would be to exit if the balance increase does not trigger and the longer to send out coins to the pool.
set the fact that the miner mines at least 10 blocks in that timeframe of one week the fees would be about 3.5% with current rewards.
for the pool wallet AT it should be enough to run only once after the timeframe has ended.
i think if i find some time i will take a look onto the assembler and try it out. i still have some burst to play with.
