EOSIO Payout Engine: a reliable way to automate your payments

Automated token payments on EOSIO blockchains, especially on congested ones like EOS Mainnet, is a tricky business: transactions may fail because of insufficient CPU or NET or RAM resource, or may get dropped because of network congestion or microforks.

Typically a business that needs to send automated token payments is relying on a number of infrastructure services: it can check if a transaction is in an irreversible block by querying Hyperion or dFuse API, or set up its own Chronicle servers that would deliver such information.

My new Payout Engine is a holiday project that I wanted to implement for a long time. It solves the problem of dropped or failed transactions, and guarantees that the token recipients will get their payments, and no double spending would occur. Also the payer does not need to keep track of transactions. It just needs to send them when there’s a difference between due and paid amounts.

The project is deployed on EOS, Telos, and WAX. It’s deducting 0.5% fee from the deposits, in order to support the infrastructure and further development.

The workflow is pretty simple, and requires only a minor JavaScript programming effort:

• Anyone willing to send the tokens regularly (called Payer further on) creates one or several schedules (a schedule defines the payer and the token currency).
• Payer places a deposit in currency defined in the schedule. The contract deducts 0.5% fee from the deposit immediately. The deposit can be transferred manually, and does not require any specific memo text.
• Payer executesbook or bookm actions, specifying the recipients and amounts that each recipient should receive in the whole recipient’s lifetime. In other words, if Alice pays Bob 100 EOS weekly, on the first week she would call the book action with recipient=bob and new_total=100 EOS. On the following week, she would call it with new_total=200 EOS, and so forth. The contract keeps track of tokens it has sent already to Bob, so if any of those transactions fail, Bob will receive all missing tokens on the next try. Alice keeps track of her payments in her database, and can easily compare the due amount with the paid amount in the contract table. The bookm action allows specifying a customized memo string for each recipient. Both actions take an array of multiple recipients, so it’s practical to batch them together in order to save on CPU costs.

EDIT: a fully functional payer server-side tool is available, accompanied by a complete example on Telos Testnet.

Once the tool gains traction, it will be protected by a multisig among recognized community members.