Transaction Flow

Crescendo relies on ERC20 approval transactions to dictate actions taken in a bulk transaction. At runtime, crescendo will read a list of addresses supplied by the executor of the batch transaction.

CrecUniswap Overview

The above image shows the transactions and transfers involved in a complete, hypothetical iteration with 2 users. A dashed line indicates a propogated transaction, whereas the following solid lines indicate effects of the transaction, including token transfers, or emitted events.

• The first section (steps 1-4) indicates the step where users "initiate" the trade on Uniswap by sending an approve transaction to their appropriate ERC20 wallet. One or more Minters is listening for the events emitted from the approval (as per ERC20 standard), and, in steps 2-4 , the amounts are emitted. The minter can verify that these approvals are for Crescendo by checking the destination address, as well as verifying the amount is valid with CrecUniswap readonly function (not shown)
• As more ETH blocks are minted, the Crescendo algorithm will offer an increasing reward for calls to exec (5). When it is calculated that this reward is profitable for the Minter, the Minter will broadcast an exec call to CrecUniswap with an array of addresses which previously sent events
  • The functionality of one Crescendo will vary from one system to another. In the case of Crescendo Uniswap demoed above, all tokens are pulled in from User1 and User2 (6, 7). A fee is extracted (8), any necessary trades completed on Uniswap (9), and the swapped tokens are returned (10, 11).
• After a call to exec is executed (even if 0 addresses are processed), a reward is returned to the miner (in recent implementations, its not actually sent during the transaction, but instead recorded and later retrieved with a call to "claim" to save gas)

Few other notes to keep in mind about the process above:

• If there is a problem with any of the addresses trades and they are not able to be executed (ex. deadline exceeded, or not enough trade amount out), the address will be automatically excluded without failing the transaction. This way, a very large number of batched transactions (say 50) can be executed successfully even if 1 or 2 addresses fail.
• In general, the decrementing will invalidate the approval for future transfers--preventing any replay without any need for a nonce or other gas consuming measures. Its a nice effect
• Data can be included in the approval transaction to prevent the transaction from being executed when it should not. For example, the Uniswap strategy includes the option to specify a "minTradeAmount" which will invalidate the trade unless at least "minTradeAmount" is returned from the trade.