This is non-trivial, although possible.
Architecture with a separate account isn't the problem per se. (The DAO had it to separate income from current holdings, as I understand it.) The main issue is that you can't simply iterate through every token holder, or you'll hit the block gas limit after enough token holders. (The question you linked to is about this.)
The pattern more commonly used, withdrawals, is where the user specifically asks for money, and at that time the contract pays them. While this makes sense in most situations, such as an auction contract where the users have individual balances, what does it mean if rewards accumulate to tokens? Is the reward calculated when the user withdraws, based on the time since last withdrawal? Then an attacker withdraws, sends tokens to another address, and repeats.
I am not sure exactly how the DAO avoided this, as I did not understand the math involved. Which leads to the following point.
Security-wise, there's all sorts of small mistakes that can lead to disaster. Notably, The DAO heist itself was due one such small mistake in this category... in withdrawRewardFor()
as it happened.
The DAO had expert programmers and a paid security audit, and they still missed this. I would be incredibly cautious about this entire area. I'm not saying it's impossible, just risky.
You are writting a complex transfer function, the only difference is the sender cannot control the amount given away.
If you want to create a token faucet I'd make the recipient to send the transaction. Also having a cool down period of two minutes to limit possible abuse.
uint previous_giveaway;
uint last_giveaway;
function drip() returns (bool success) {
// Only allow to drip every two minutes to limit abuse
if (now - last_giveaway < 2 minutes) {
return false;
}
last_giveaway = now;
// deliver half than last time
uint giveaway_value = previous_giveaway / 2;
if (giveaway_value == 0){
giveaway_value = starting_giveaway;
previous_giveaway = starting_giveaway;
}
// It is a faucet mint new tokens
balances[msg.sender] += giveaway_value;
totalSupply += giveaway_value;
Transfer(0x0, msg.sender, giveaway_value);
return true;
}
To call that contract from a webapp using web3 v1.0 something like this should work
const token = new eth.Contract(abiToken, addressToken);
await token.methods.drip().send({ from: "address" });
The contract will deposit a few tokens to "address".
Best Answer
I assume you mean being able to create vanity addresses that start with some characters of your choosing. If it's that so, you can check this tool:
https://github.com/MyEtherWallet/VanityEth
** I haven't tried it, can't vouch for it and its security.
** If you are going to use it, make sure the accounts or contract addresses generated really work before using it in production.