Payroll style transactions

[AlexandraRoatis]

Would it make sense to introduce a payroll transaction that would batch different payments initiated from a single account and directed to multiple other accounts?

The main question is if we can leverage batching multiple transactions that originate from the same account to reduce the fees for that account.

I can envision many applications that could benefit from this style of transaction, but I'm not sure to what extent we could reduce the computation costs by batching them together.

[AlexandraRoatis]

This topic can be approached at different levels, some that have come up are:

1. performing such transactions only between user accounts;
2. what are the implications of allowing the batched transactions to be contract calls;
3. implementing this type of feature as part of the token standard.

[AlexandraRoatis]

Some benefits of adding this style of transactions:

• updating the state requires changing the from account only once;
• the transaction pool needs to perform fewer transaction reordering and nonce management;
• mining pools are a good first use case since they can 1. reduce fees due to the reduced cost of sending the payouts; and 2. improve reliability since now they need to keep track of fewer transactions to ensure that they have been performed.

[qoire]

This is an interesting approach, just wanted to add that if I wasn't concerned about gas fees, the current way I'd achieve this is:

• Create a smart contract with those addresses pre-loaded
• Load the smart contract with necesary balance
• Execute the smart contract, thereby withdrawing to all users.

Obviously the downside to this is integration (but feasible if we support the correct tooling) and gas costs.

[kermankohli]

We're working on a protocol for recurring payments (8xprotocol.com) and may be able to help you out. Feel free to get in touch with me directly!

[AlexandraRoatis]

submitted as AIP: aionnetwork/AIP#14