New transaction types for creating streams

[PaulRBerg]

Spec Questions

As discussed here, we will introduce a new tx type to allow users to transfer MNTs. What about streams?

1. Should we make it possible to start streams at the same time with transferring multiple tokens? Or should this be another tx type?
2. Should it be possible to create multiple streams with a transaction, or just one at a time?

My Thoughts

In the spirit of rapid iteration and for keeping UCG in check:

1. No, to avoid having to manage complicated txs in which a streamable NT is both transferred and streamed.
2. No, each tx type can start a maximum of one stream.

RFC

CC @sablier-labs/sabvm

Relevant: see the rollup.codes docs on Arbitrum's tx types and on Optimism's tx types.

[razgraf]

I agree with your conclusions. At least for Genesis, we should keep it simple.

The first idea (transfer NT + start-stream with NT) can probably be abstracted away by a smart contract when we introduce them right? Same with the second now that I think of it.

[PaulRBerg]

Thanks for confirming!

It might be possible to abstract it away with a smart contract if we have good support for AA and/ or EIP-3074.

[IaroslavMazur]

Should we make it possible to start streams at the same time with transferring multiple tokens?

Besides the arguments in the OP against this (which I agree with), I don't see why someone would want/need to transfer any tokens at the same time with creating a stream. Do you?

The 2 actions (stream creation and token transfer) sound independent enough to require happening in separate txs.

---

Should it be possible to create multiple streams with a transaction, or just one at a time?

I agree that this is a problem for another day/SabVM version. 🙌

[PaulRBerg]

I don't see why someone would want/need to transfer any tokens at the same time with creating a stream. Do you?

IDK, maybe trading purposes? Pay a fee and DCA into a DEX at the same time.

[IaroslavMazur]

Pay a fee and DCA into a DEX at the same time.

In this specific example, it would, indeed, be useful to be able to transfer the tokens alongside creating a stream.

Although, if I were a DCA-supporting DEX, and given that the Stream would, potentially, be continuous/indefinite, I'd, probably, want you to keep paying me a maintenance fee/subscription to keep the service running, instead of only charging you once, in the beginning.

Hence, implementing "transfer-and-create-stream" would only be helpful for "batching" the initial transfer and Stream creation. After that, the user will, likely, need to keep transferring tokens to the DEX manually, anyways.

Having said the above, I don't think the benefits of implementing this outweigh the costs.